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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #15 from Alicia Boya García <aboya at igalia.com> ---
(In reply to Edward Hervey from comment #13)
> Review of attachment 372608 [details] [review]:
> 
> ::: 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 ?

Stream time is always relative to a given segment. In qtdemux we have a seek
segment (qtdemux->segment) and a (per-track) stream segment (stream->segment).
The stream time of the stream segment matches movie time, which matches
indistintly buffer time and stream time of the seek segment.

About my certainty about the usages of stream time of the seek segment: I
grep'ped for usages of segment->time, filtered those that operate in the stream
segment and found no reads. Then I looked for usages of *_stream_time*
functions like gst_segment_to_stream_time() and only found the usages in
GST_QUERY_SEGMENT handling. Hopefully I'm not missing anything.

> @@ +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.

That's true, I'll update the 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).

Assuming you are referring to TIME segments comming from upstream, in that case
*all fields* are overwritten. This is mentioned later in the comment.
> 
> @@ +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.

Could you elaborate? I've not worked with DLNA elements so far in GStreamer, so
I don't know how they work different than other sources.

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