On Mon, Jul 26, 2010 at 10:20:32PM -0700, Dan Dennedy wrote: > On Mon, Jul 26, 2010 at 11:48 AM, Mikko Rapeli <mikko.rap...@iki.fi> wrote: > > I've run out of memory quite a few times lately with 1 GB of RAM and 2 GB > > swap. > > Kdenlive takes just around one GB of memory when the project is open but > > melt rendering is taking almost two, and having both of them running kicks > > in > > the OOM killer. > > Are you using v0.5.6 or later?
Latest from git. > > Any ideas where this might come from, or if this is as expected? > > Not sure, and it depends. > > > Command line: > > > > Started render process: "/usr/bin/melt" > > "/home/mcfrisk/.kde/tmp-ransu/kdenliveLL1922.mlt in=5578 out=38162 -profile > > hdv_720_30p -consumer avformat:/home/mcfrisk/video/verbier_2010/testi03.mp4 > > progress=1 f=mp4 hq=1 acodec=aac ab=128k ar=48000 pix_fmt=yuv420p > > vcodec=libx264 minrate=0 b=1000k b_strategy=1 subcmp=2 cmp=2 coder=1 > > flags=+loop flags2=dct8x8 qmax=51 subq=7 qmin=10 qcomp=0.6 qdiff=4 > > trellis=1 aspe...@16/9 an=1" > > > > Top readings towards the end of rendering: > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > 3507 mcfrisk 20 0 1947m 891m 1132 S 99.0 88.2 74:24.24 melt > > > > Kdenlive readings after project and all thumbnails are loaded: > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > 3609 mcfrisk 20 0 808m 677m 12m S 0.0 67.1 6:56.57 kdenlive > > > > I used the same machine and memory config last year to edit a slightly > > bigger > > project, timeline was twice as long. Can't remember such problems back then. > > Over the past year, I added some caching in 2 areas around the > avformat producer. First, the "guts" of the avformat producer object > are cached - 10 of them in non-VDPAU build, 5 of them in a > VDPAU-enabled build. Previously, after sequentially processing a > project, all avformat producer objects would have their guts intact. > This not only used some memory but more importantly it also held file > handles and threads if the decoding threads > 1. So, the caching > actually improvement resource because it allows the guts to be flushed > and reloaded as-needed. The introduction of VDPAU absolutely required > this change. I'm using VDPAU, at least ffplay and mplayer use it. Video preview in kdenlive is as jerky as without it on most clips, but this seems like some problem or slow path in handling the 5+1 audio channels. But that's maybe not related to the memory usage. > In order to relieve some pain with AVCHD and particularly in > conjunction with YADIF deinterlace, which requires previous, current, > and next frames, I added uncompressed image caching inside the > avformat producer. Each "active" (not flushed) avformat producer > object can have up to 10 of these. So in the worst case, in this > object class alone, there could be 100 uncompressed HD images. If > yuv422, these would use 395 MiB, and if rgba 791 MiB - depends on > which filters are applied. One can disable the image caching by > setting "noimagecache=1" on each producer in the .kdenlive file, but > you should then set "deinterlace_method=linearblend" on the consumer > to avoid using yadif. You can add this in the Kdenlive render profile. I'm using only progressive clips, but I'll try noimagecache if it helps to run both kdenlive and melt at the same time. If it doesn't I can try valgrind or some other tools to see where the memory pressure is coming from. Thanks. -Mikko ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ _______________________________________________ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
