On Sun, Apr 13, 2014 at 3:46 PM, jb <j...@kdenlive.org> wrote: > On Sunday 13 April 2014 12.23:31 Dan Dennedy wrote: >> On Sun, Apr 13, 2014 at 2:19 AM, jbm <j...@kdenlive.org> wrote: >> > Hi Dan and everyone. >> > >> > I have been silent for almost a year due to some health issue, but I am >> > fine now and slowly starting to work again on Kdenlive. >> > >> > A recent Movit related commit creates a huge memory leak when seeking in >> >> > Kdenlive. The responsible commit is this one: >> Do you have more information about what conditions are needed to >> reproduce this? Do I have to disable opengl? Do I have to apply >> cropping? I am not seeing the problem while scrubbing over a video >> clip for quite a while within Shotcut. I tested both with opengl >> module in use and not and with both cropping and not. Is it only when >> using a color or image producer? > > Ok, I did some more testing. > The problem happens with mpegts interlaced clips that were taken from a sony > camcorder (the same happens with HDV interlaced clips captured with dvgrab), > using the xgl consumer. > > Using MLT from current git with these mpegts interlaced clips, I get the > following results: > > melt myclip.MTS > = works fine > > melt myclip.MTS -consumer xgl > = crashes (backtrace at the end of the mail) > > melt -profile atsc_1080p_50 myclip.MTS -consumer xgl > = plays but huge memleak (2 GB of memory used after 20 seconds) > > > Reverting the recent change in filter_movit_crop.cpp by re-adding at line 56: > *format = mlt_image_none; > > Fixes the crash and memleak in xgl consumer (and Kdenlive). > I am using movit from today's git if it is relevant... > > I can mail you a sample clip if you need it. > > regards > jb > > > - - - - FFMpeg info about the clip - - - - - - > > Input #0, mpegts, from '00023.MTS': > Duration: 00:00:14.02, start: 1.040000, bitrate: 10268 kb/s > Program 1 > Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, > 1440x1080 [SAR 4:3 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc > Stream #0:1[0x1100]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, > fltp, 256 kb/s > Stream #0:2[0x1200]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / > 0x0090), 1920x1080 >
I figured out the problem. The frame image was getting converted to mlt_image_glsl too early. After the regressing commit, movit.crop was passing along the downstream format, mlt_image_glsl. This was causing the image converter to convert the output of the *producer* to glsl and setup the movit input and chain. Then, the deinterlace or field order filters, which must come before the movit filters, could force the output of a new image and format. Subsequent conversion back to glsl causes all sorts of problems with the movit management. I am going to revert the change in movit.crop; however, I do not have a solution for using framebuffer in conjunction with movit. -- +-DRD-+ ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
