I took some time today to build kdenlive (master branch) and test this
out...
On Thu, Feb 22, 2018 at 12:20 AM Jean-Baptiste Mardelle <j...@kdenlive.org>
wrote:
> On 17.02.2018 05:55, Kingsley G. Morse Jr. wrote:
> > I'm happy to provide you with an even smaller and
> > easier test case.
> >
> > Just
> >
> > 1.) copy the attached tar archive "bug.2.tar"
> > to the /tmp directory and
> >
> > 2.) do what the attached video shows
> >
> > $ cd /tmp
> >
> > $ tar -xvf bug.2.tar
> >
> > $ kdenlive bug.2.kdenlive
> >
> > Select track Video 3's Affine transition
> > by clicking on it with the mouse
> >
> > Click on the "Go to next key frame"
> > button.
> >
> > Wait a moment for
> >
> > "[mlt_pool] out of memory"
> >
> > in the console.
>
I did not get the above error even though my system only has 6 GiB RAM and
only 2.7 free at this time with Gnome Shell, Firefox with 2 tabs, and a
terminal window open. However, running top in the terminal I do observe the
RES going up to about 2.4g when running this test.
>
> Hi all,
>
> Sorry for the late feedback. So I made a few tests and found some
> interesting facts.
> The problem seems related to frame buffer.
>
> When setting the "buffer" property to 0 on the consumer (sdl2_audio) in
> Kdenlive, the memory usage stays stable (around 500Mb).
>
> When setting the buffer to 25 (default in Kdenlive), I get 2 different
> situations:
> - When using an HD 25fps profile, memory usage goes to about 700Mb
> - When using a SD NTSC profile, memory usage quickly goes up to 2.3Gb.
>
>
The only way I was able to reproduce the above was by using the Project
Settings dialog in Kdenlive to change the profile because in that case, for
me, images no longer load and all I get is black in the preview area. If I
edit the .kdenlive file to change the profile element, then I still
reproduce a high memory usage. Curiously, the lower resolution does use
about 200 MiB more than 1280x720 in my tests. The frame rate did not make a
difference. Also, it is not really necessary to select the Affine effect
and click next keyframe. Simply scrubbing the timeline or switching to
Project Monitor and playing the project through also uses up to ~2.4g RES.
> These tests were done with the image attached in the latest email
> (3800x2500 jpeg).
>
At this point, I should point out that, in MLT, using high resolution
images with affine generally requires a lot of memory. This is because
affine requests the full source resolution from the source producer and
bypasses the automatic scaling to project resolution. It does this so you
can use affine to crop and scale and take advantage of all the available
resolution. Imagine a heavy cropping scenario like a portrait photo
included in a 16:9 video resolution and wanting little-to-no black bars.
Best to do that by cropping from the original image instead of scaling
original image down to 1280x720, cropping top and bottom to achieve 16:9,
and then scaling that up to fill the video frame.
Affine works in RGBA such that there are 4 bytes per pixel. As a result
3800 * 2500 * 4 = ~36.24 MiB. If for some reason - for example, lack of
optimizations - there are 2 of these per MLT frame (after all there are 2
affine effects in the project), and there are 25 MLT frames in the consumer
buffer JB mentions above; then 36.24 MiB * 2 * 25 ~= 1.8 GiB. Add to that
memory used by the MLT and Kdenlive, and we start to approach the RES
number I was seeing. I should also point out that the RES number stays
around this high level and does not grow excessively while scrubbing,
playing, and clicking next keyframe.
Playing the project with "melt -consumer sdl2 buffer=1" uses ~1.5g RES
where buffer=25 makes it shoot up to 2.8g.
Now I can take a closer look at what can be done to reduce memory usage.
I will try to make more tests but wondering if the frame caching bugs
> when using profile with a non integer fps profile..
>
> Regards
> jb
>
>
> > So,
> > Kingsley
> >
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Mlt-devel mailing list
> Mlt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
