Re: [Mlt-devel] A smaller test case now elicits "[mlt_pool] out of memory"
On Fri, Mar 16, 2018 at 12:52 PM Dan Dennedy 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 > 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 m
Re: [Mlt-devel] A smaller test case now elicits "[mlt_pool] out of memory"
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 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
Re: [Mlt-devel] A smaller test case now elicits "[mlt_pool] out of memory"
Hi Jean, Thank you very much for your polite and informative email. Both are fine qualities. For what it's worth, I installed debian's libsdl2 package with debugging symbols, root$ aptitude install libsdl2-2.0-0-dbgsym re-ran the small test case under valgrind $ valgrind --track-origins=yes --leak-check=full --freelist-vol=1 --log-file=/tmp/valgrind_with_sdl_dbg.log -v kdenlive tmp/bug.2.kdenlive counted how many times the key word "frame" occurs in valgrind's log, and found over a hundred. Here's an example: 67,108,864 bytes in 1 blocks are possibly lost in loss record 51,223 of 51,223 at 0x48317F4: memalign (vg_replace_malloc.c:858) by 0x4B8FD11: pool_fetch (mlt_pool.c:137) by 0x4B8FD11: mlt_pool_alloc (mlt_pool.c:292) by 0x18F91A44: producer_get_image (producer_pixbuf.c:718) by 0x4B76707: mlt_frame_get_image (mlt_frame.c:620) by 0x27A3DDE4: filter_get_image (filter_deinterlace.c:307) by 0x4B76707: mlt_frame_get_image (mlt_frame.c:620) by 0x1825D934: get_image (filter_fieldorder.c:33) by 0x4B76707: mlt_frame_get_image (mlt_frame.c:620) by 0x1825C1A5: filter_get_image (filter_crop.c:76) by 0x4B76707: mlt_frame_get_image (mlt_frame.c:620) by 0x18261ED7: filter_get_image (filter_rescale.c:221) by 0x4B76707: mlt_frame_get_image (mlt_frame.c:620) Maybe it's just a coincidence. I dunno. I look forward to your next update. Thanks, Kingsley > 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. > > These tests were done with the image attached in the latest email (3800x2500 > jpeg). > 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 > > > -- Time is the fire in which we all burn. -- 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
Re: [Mlt-devel] A smaller test case now elicits "[mlt_pool] out of memory"
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. 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. These tests were done with the image attached in the latest email (3800x2500 jpeg). 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
