On Wed, Jan 11, 2012 at 9:37 AM, Dan Dennedy <[email protected]> wrote:
> 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,


Marco, this is fixed now. I noticed that ffmpeg (not libav) as used in
MacPorts uses the 0.7 branch of ffmpeg, which has the codec-specific
options of libavcodec v53. Anyways, I simply had to expand the lowest
version of libavcodec I am checking to support this feature, and now
it works. For example, you can now use x264-specific options 'preset'
and 'profile'. For example, profile=main preset=fast.

> 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-+

------------------------------------------------------------------------------
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
_______________________________________________
Mlt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Reply via email to