Re: [Mlt-devel] bug in consumer_avformat ?

[Dan D. <da...@de...>]

On Mon, Jan 9, 2012 at 1:41 PM, Marco Gittler <ma...@gi...> 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?

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

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

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

-- 
+-DRD-+