On Mon, Jan 9, 2012 at 11:03 PM, Marco Gittler <[email protected]> wrote: > > > Am 10.01.2012 08:02, schrieb Marco Gittler: > >> >> >> Am 10.01.2012 05:37, schrieb Dan Dennedy: >>> >>> On Mon, Jan 9, 2012 at 1:41 PM, Marco Gittler<[email protected]> wrote: >>>> >>>> Hi >>>> >>>> i try since some days to render a few files (avchd), but the render does >>> >>> When you say "avchd" here are you renderign to AVCHD-like format? >> >> yes complete example is found next. >>> >>> >>>> stops every time nearly the same frame. >>>> Also a partial render some frames before this part will hang and nothing >>>> happens. >>>> >>>> 1. is this normal that mlt uses up to 3 GB Ram for 20 min avchd video ? >>> >>> no, but multiple render threads (real_time< -1), a sufficiently large >>> render buffer (default is 25 frames) and more than 10 HD source clips >>> can use a lot of memory. There can be up to 10 avformat producers, >>> each with 10 images cached, and 25 images in the render queue. >>> >>> With 2 bytes per pixel >>> >>> (10*10 + 25) * (1920*1080) * 2 /1024 / 1024 = ~494 MB >>> >>> Of course, there are other MLT and various lib structures. Still 3 GB >>> seems high. Can you please try with processing threads set to 1 in >>> Kdenlive Settings? >>> >> ok i'll test this later this evening. >>>> >>>> 2. after some debug and look at the code, i found this output >>>> >>>> [consumer avformat] frame_size 1024 >>>> [consumer avformat] audio pts 48000 (0,533333) video pts 46800 >>>> (0,520000) >>>> <------- this part !! >>>> [producer avformat] >>>> /home/marco/Desktop/hd-video/ostsee_peenemünde/00278.MTS >>>> mlt_service_cache_get: name producer_avformat object 0x6064800 >>>> mlt_cache_get: get 5 = 0x6064800, 0xaa383e0 >>>> [consumer avformat] worker processing index = 23 frame 87 queue count = >>>> 24 >>>> [producer avformat] >>>> /home/marco/Desktop/hd-video/ostsee_peenemünde/00278.MTS >>>> pkt.dts 533301 req_pos 274 cur_pos 273 pkt_pos 274 >>>> [producer avformat] >>>> /home/marco/Desktop/hd-video/ostsee_peenemünde/00278.MTS >>>> got_pic 0 key 0 >>>> [producer avformat] >>>> /home/marco/Desktop/hd-video/ostsee_peenemünde/00278.MTS >>>> pkt.dts 535101 req_pos 274 cur_pos 273 pkt_pos 275 >>>> [producer avformat] >>>> /home/marco/Desktop/hd-video/ostsee_peenemünde/00278.MTS >>>> got_pic 368 key 0 >>>> cache_object_close: item 0x7f23a4e0ed90 object 0x7f data 0x7f239ad64020 >>>> refcount 1 >>>> mlt_cache_put: put 9 = 0x89, 0x7f23842df020 >>>> TFF in 1 out 0 >>>> [consumer avformat] waiting in worker index = 24 queue count = 24 >>>> [libx264 @ 0xae1e410] frame= 14 QP=28,38 NAL=0 Slice:B Poc:26 I:110 >>>> P:6557 SKIP:1493 size=67068 bytes >>>> [consumer avformat] video pkt pts 46800 frame pts 13 frame_size 0 >>>> cache_object_close: item 0x60673c0 object 0x6064800 data 0xaa383e0 >>>> refcount >>>> 26 >>>> [consumer avformat] audio pts 48000 (0,533333) video pts 50400 >>>> (0,560000) >>>> [consumer avformat] frame_size 1024 >>>> [consumer avformat] audio pts 49920 (0,554667) video pts 50400 >>>> (0,560000) >>>> Current Position: 63 >>>> >>>> and in consumer_avformat.c: >>>> >>>> while ( 1 ) >>>> { >>>> // Write interleaved audio and video frames >>>> if ( !video_st || ( video_st&& audio_st[0]&& audio_pts< >>>> video_pts ) ) >>>> { >>>> ... >>>> } >>>> } >>>> >>>> this will explain the endless loop (audio_pts> video_pts) >>> >>> The problem with your analysis is that you overlooked the "else if" >>> inside that while loop. Inside the else if block, the video_pts should >>> increment. If it does not increment, either encoding is failing (there >>> is a warning for this). Or, perhaps the version of libavcodec requires >>> a new way to compute the video_pts. However, the last lines of your >>> log show that video_pts has incremented to be> audio_pts. Then, >>> audio_pts shows increment. It is not clear where it is getting stuck >>> from that log snippet. >> >> you are right, i overlooked this. But then it is more unclear. >>>> >>>> this is the first time, that i have such issue. the file is original >>>> from >>>> the camera. >>>> >>>> should this be fixed in mlt ? >>>> looks like a bug to me, or better fix the file ? >>>> >>>> regards marco (i hope i can reproduce this with the file only and not >>>> just >>>> with kdenlive project for better testing) >>> >>> The camera format or source file integrity should not affect encoding. >>> Encoding is being fed uncompressed audio and video. >> >> >> real_time=-2 (don't know where this is from, may be older settings in >> kdenlive) with this parameter will cause the hang. >> -1 or 0 will let it work. >> >> melt 00278.MTS -profile atsc_1080i_50 -consumer avformat:aaaa.mp4 >> threads=4 f=mpegts hq=1 acodec=aac ab=384k ar=48000 pix_fmt=yuv420p >> vcodec=libx264 threads=4 real_time=-2 -verbose -debug >> >> also less consumer parameters will let it render.
I found there is still a problem in MLT catching up to libav* 0.53 changes with respect to handling codec-specific options (or x264). So, the above fails due to lacking x264 options or libavcodec's defaults or because MLT's attempt to set codec-specific options is corrupting some defaults. It should be noted that something like this that uses MPEG-2 does work: -consumer avformat:test.mxf properties=XDCAM-HD422 real_time=-2 I have been working on changes to get rid of so many deprecation warnings when building against head of ffmpeg or libav. I will fix it soon. -- +-DRD-+ ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ Mlt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mlt-devel
