On Fri, Mar 16, 2018 at 12:52 PM Dan Dennedy <d...@dennedy.org> wrote:
> 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 made a couple of key experiments. In bug
https://github.com/mltframework/mlt/issues/271#issuecomment-373797288
I question the continued value of mlt_pool. I made a simple compile-time
option to replace it with malloc() and free(). As a result my particular
melt test case reduced from 1.75g RES to 0.52, and that 0.52 represented a
very short term peak! Usually, it is in the 0.3x range.
Next, in the affine transition code, I added a line to remove the image
from the B frame. A transition takes an A and a B frame, and it returns the
resulting image to the A frame. It is not generally considered proper
behavior for a transition to alter the B frame image; however, at the
moment I cannot recall a situation where the B frame is used after the
transition. This experiment reduced from 1.75g RES to 0.37, which again was
the peak! If I combine this with the mlt_pool removal, then it peaks to
0.24g RES.
I will do more testing to ensure these are safe changes to make.
------------------------------------------------------------------------------
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
