[Bug 752603] qtdemux: Unable to play streaming MP4 (H264+AAC) file from VLC

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=752603

--- Comment #55 from Alicia Boya García <aboya at igalia.com> ---
Review of attachment 372626:
 --> (https://bugzilla.gnome.org/review?bug=752603&attachment=372626)

::: gst/isomp4/qtdemux.c
@@ -6600,3 @@

-static GstClockTime
-gst_qtdemux_streams_get_first_sample_ts (GstQTDemux * demux)

Note this function was already returing the minimum tfdt, since QTSAMPLE_DTS <=
QTSAMPLE_PTS and by definition, the tfdt is the DTS of the first sample in a
track fragment.

@@ +9531,3 @@
             " extends to %" GST_TIME_FORMAT
+            " past the end of the declared movie duration %" GST_TIME_FORMAT
+            " movie segment will be extended", segment_number,

Note the message has been changed but the behavior was already in place before.
The log message was stating something different than what was actually being
done.

And indeed, this behavior makes more sense: the duration specified in the edit
list is reliable (it has to be, otherwise the track would be cut), whereas
other fields such as mvhd.duration and tkhd.duration are supposed to be
computed in the same way by the muxer, but their values are merely informative
(the spec does not demand using any of these for clipping the movie). Also
there is no point in trusting unknown muxers to write correct values there when
we can compute them by ourselves.

@@ -13787,3 @@
-  /* set duration in the segment info */
-  gst_qtdemux_get_duration (qtdemux, &duration);
-  if (duration) {

Note: In this if `duration` was always true. It's impossible for
gst_qtdemux_get_duration() to return zero; when there is no known duration it
returns GST_CLOCK_TIME_NONE.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.