[Bug 796544] qtdemux: Add comment about qtdemux->segment

[GStreamer (GNOME Bugzilla)]

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

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

::: gst/isomp4/qtdemux.h
@@ +119,3 @@
+  /* Configured playback region.
+   *
+   * segment.format is always GST_FORMAT_TIME.

Seeks with BYTES format are allowed, but they are transformed into a TIME seek
by searching the offsets in the sample table by gst_qtdemux_convert_seek()
before any change to qtdemux->segment is done.

@@ +125,3 @@
+   *
+   * segment.time is never read. It's not useful in this context, since the
+   *

"segment.time is never read" is actually not entirely true... There is an
exception: GST_QUERY_SEGMENT returns its start and stop values in streaming
time, which implicitly reads the time field. I should change that.

But for the rest of qtdemux, AFAIK, stream time in qtdemux->segment is
currently devoid of meaning. `time = start` is set just in case and to make the
former case work...

@@ +139,3 @@
+   * time (FIXME). This field is used to reply position queries. It's also
used
+   * (with a 2 extra second allowance) to signal EOS at the end of a track in
+   * segment.base contains the running time when playback started. The first

Yes. segment.position is sometimes unedited buffer time of the track
(QTSAMPLE_PTS) and sometimes movie time... so you can never be sure what you
are reading.

@@ +146,3 @@
+   * segments. (FIXME: In consequence, edits with rate != 1.0 will have wrong
+   * stream time... although probably nobody uses such an obscure feature with
+   * nanoseconds. Both fields should be updated at the same time.

Edit lists with rate different than 1.0 are supported in the sense that there
is code that handles them and that code is run... that code just happens to
have a bug -- or so I think, I have not devoted time to make a testcase for
this, I've just run the math for the stream time formula and saw a problem.

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