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? > 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. 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. Of course, there could be something else in your project that accounts for a memory consumption issue. -- +-DRD-+ ------------------------------------------------------------------------------ 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
