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

[GStreamer (GNOME Bugzilla)]

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

Edward Hervey <bilboed at bilboed.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #372608|none                        |needs-work
             status|                            |

--- Comment #13 from Edward Hervey <bilboed at bilboed.com> ---
Review of attachment 372608:
 --> (https://bugzilla.gnome.org/review?bug=796544&attachment=372608)

::: gst/isomp4/qtdemux.h
@@ +128,3 @@
+   * stream time in qtdemux->segment does not have a defined purpose.
Currently
+   * the only code converting values in this segment to stream time is the
code
+   * handling GST_QUERY_SEGMENT.

Hm.... the values in a TIME seek are always expressed in "stream time". Are you
100% certain it's never used except for segment queries ?

@@ +142,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
+   * gst_qtdemux_sync_streams().

Also very importantly, the segment.position can be updated by
gst_segment_do_seek(). The last field (&update) will tell you whether it was
modified or not.

@@ +149,3 @@
+   * segments. (FIXME: In consequence, edits with rate != 1.0 will have wrong
+   * stream time... although probably nobody uses such an obscure feature with
+   * so little player support anyway).

*cough* you might want to remove that comment ?

Also you have some cases where upstream seek handlers (such as DLNA sources, or
anything) can push applied_rate != 1.0  (they will have applied the requested
rate, but what you receive should be decoded normally).

@@ +159,3 @@
+   * event is sent from upstream. In the latter case, the upstream segment
+   * replaces all qtdemux->segment. That is the case when upstream is
+   * adaptivedemux.

This is *generally* the case, but not always. You could have a DLNA-compatible
element that can handle seeks, or an appsrc, or some element you don't know
about.

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