GNOME Bugzilla – Bug 731576
qtdemux: Segment doesn't start at position 0
Last modified: 2015-04-01 16:12:15 UTC
http://download.wavetlan.com/SVV/Media/HTTP/H264/Talkinghead_Media/H264_test3_Talkingheadclipped_mp4_480x360.mp4 $ gst-launch-1.0 -v filesrc location=/tmp/H264_test3_Talkingheadclipped_mp4_480x360.mp4 ! qtdemux ! video/x-h264 ! identity silent=false ! fakesink num-buffers=1 | grep -i segment /GstPipeline:pipeline0/GstIdentity:identity0: last-message = event ******* (identity0:sink) E (type: segment (17934), GstEventSegment, segment=(GstSegment)"GstSegment, flags=(GstSegmentFlags)GST_SEGMENT_FLAG_NONE, rate=(double)1, applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, base=(guint64)0, offset=(guint64)0, start=(guint64)33333333, stop=(guint64)10323333333, time=(guint64)0, position=(guint64)33333333, duration=(guint64)18446744073709551615;";) 0x7f6f4000a800 As you cann the segment starts at 33333333 and not 0.
The problem revolves more around the fact that the demuxer will then push buffers starting with a PTS of 0.333 ... but a DTS of 0
CCing myself, as this reminds me the problem with negtive PTS, if PTS starts at 0. Why is having a segment not start at 0 cause issues? does a buffer with PTS = 33333333 and DTS = 0 get clipped ?
For reference, this file has an edts entry that starts at time 20 for the video track. edit atom (edts) edit list (elst) version 0 flags 0 total_entries 1 edit list table duration 6174 time 20 rate 1.000000 The timescale is 600. The first edts entry is played at time=0, but the media_time that it should start from is time=20 (that converted to the timescale actually means 1/30 seconds = 0.033333333s). So, there is no gap at the beginning, but the media starts playing from the time 0.0333s in the media time. Isn't this what qtdemux is doing? What real world issue are you seeing?
Time scale A time value that indicates the time scale for this movie—that is, the number of time units that pass per second in its time coordinate system. A time coordinate system that measures time in sixtieths of a second, for example, has a time scale of 60. Media time A 32-bit integer containing the starting time within the media of this edit segment (in media timescale units). If this field is set to –1, it is an empty edit. The last edit in a track should never be an empty edit. Any difference between the movie’s duration and the track’s duration is expressed as an implicit empty edit. From the qtff docs
So this can be closed then, right? If not, please re-open.