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?
> 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-+
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Mlt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mlt-devel
