GNOME Bugzilla – Bug 617532
[qtmux] Take into account new-segments for incoming streams
Last modified: 2011-04-12 14:01:43 UTC
qtmux doesn't take into account the new-segment events in order to calculate the buffer PTS/DTS. It should use a GstSegment per stream, and then use the running time (gst_segment_to_running_time()). In order to trigger this bug you need at least 2 segments of buffers with a gap between the two, like the following: NEWSEGMENT start: 10s, stop: 15s, position: 0s BUFFERS from 10s to 15s /* If you stop here, the resulting file will be OK, with a duration of 5s and playback going from 0s to 5s */ NEWSEGMENT start: 50s, stop: 55s, position: 5s BUFFERS from 50s to 55s /* The resulting file will be 40s long... whereas it only contains 10s of video, and there will be a playback gap between the first 5s and the remaining 5s */ One way to try this is to use tests/examples/playlist in gst-editing-services[0] (requires gnonlin and gst-convenience [1]) as such: ./playlist -r -f video/quicktime -a audio/mpeg,mpegversion=4 -v video/mpeg,mpegversion=4,systemstream=False -o file:///home/bilboed/outputfile.mov /media/data/medias/input.mp4 10 5 /media/data/medias/input.mp4 50 5 0: http://git.collabora.co.uk/?p=user/edward/gst-editing-services.git 1: http://git.collabora.co.uk/?p=user/edward/gst-convenience.git
Just reproduced it here. Attempting to fix.
Is there any muxer currently supporting this? Checked ogg, matroska and avi for new segment events handling, none seemed to handle it.
Btw, fwiw, see also bug #432612.
qtmux should be aware of new-segment events now, i.e. use running-time: commit c558a066fb1862bc4cb3c9a94090141e363df595 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Tue Mar 22 20:53:08 2011 +0100 qtmux: use running time for synchronization See also #432612.