GNOME Bugzilla – Bug 765805
qtdemux: Only first fragment played for fragmented mp4 files recorded with non-seekable sink
Last modified: 2016-05-05 12:46:47 UTC
Fragmented mp4 files recorded with an non-seekable sink (e.g. tcpclientsink) are not played back correctly: the pipeline terminates after the first fragment. This was working with GStreamer 1.2 and 1.4. I noticed the problem with 1.6.3 and just reproduced it with master. Steps to reproduce: nc -l -p 3333 > test.mp4 & gst-launch-1.0 \ videotestsrc num-buffers=300 ! \ x264enc ! \ mp4mux fragment-duration=2000 ! \ tcpclientsink host=127.0.0.1 port=3333 sync=false This generates a 10 seconds video made of 2 seconds fragments. With GStreamer 1.2.4, gst-discoverer reports a zero duration and gst-play plays the file completely. With GStreamer 1.6.3 and master, gst-discoverer reports a duration of 2 seconds and gst-play plays only 2 seconds.
Haven't investigated very deeply, yet, but bisected it to: commit b40cfcfffb659138ed341badd6b76b02df4190b1 Author: Edward Hervey <bilboed@bilboed.com> Date: Wed Dec 10 16:55:44 2014 +0100 qtdemux: Update duration when we get more information When dealing with fragmented files, we will get more accurate duration information via the mfra and moof atoms. In order for playback to not stop at the initial duration (from the moov atom), we need to check and update the various duration variables when we find more information. Fixes playback of fragmented files in pull mode Particularly this change that is part of this patch: @@ -7160,6 +7215,7 @@ done: GST_DEBUG_OBJECT (qtdemux, "created dummy segment %" GST_TIME_FORMAT, GST_TIME_ARGS (stream_duration)); stream->n_segments = 1; + stream->dummy_segment = TRUE; }
The problem is actually the segment that qtdemux pushes after that patch, after it the stop of the segment makes downstream discard all buffers after 2s. Without patch: New segment: time segment start=0:00:00.000000000, offset=0:00:00.000000000, stop=99:99:99.999999999 With patch: New segment: time segment start=0:00:00.000000000, offset=0:00:00.000000000, stop=0:00:02.000000000,
one option is to leave the segment event open ended when it is a dummy segment on fragmented stream, or send a new one when the dummy segment is extended. The later is a bit trickier because the stop might be the result of a seek.
commit c70ed4c914d7e1896c467873edeb7309541dff66 Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Tue May 3 21:17:01 2016 -0300 qtdemux: update segment when new duration is found Otherwise the old segment will have a shorter stop time and would cause the stream to end too early. commit a5e02e948b0ff2ed5cd4e9e18dda44ce3c52f6d3 Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Wed May 4 11:37:29 2016 -0300 qtdemux: dismember activate_segment into 2 parts One that updates and push a new segment, the other will move the stream to the new segment starting position (Just noticed I forgot to add the bug number in the commits)
commit 4dba4505b068d3098f952afdda51038ffc91f9e7 Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Tue May 3 21:17:01 2016 -0300 qtdemux: update segment when new duration is found Otherwise the old segment will have a shorter stop time and would cause the stream to end too early. https://bugzilla.gnome.org/show_bug.cgi?id=765805 commit 9fa26f1eba984509784ed385687eb9779647256e Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Wed May 4 11:37:29 2016 -0300 qtdemux: dismember activate_segment into 2 parts One that updates and push a new segment, the other will move the stream to the new segment starting position https://bugzilla.gnome.org/show_bug.cgi?id=765805
Also merged to 1.8 branch