[Bug 776200] dashdemux: Always parsing sidx for On-Demand profile

[GStreamer (GNOME Bugzilla)]

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

--- Comment #20 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Seungha Yang from comment #19)
> (In reply to Sebastian Dröge (slomo) from comment #18)
> > The way how seeking is done with the SIDX, it also seems to assume to have
> > information about *all* fragments in the SIDX. Not just the current one. So
> > if we only ever have the current one in there (as for my stream), SIDX based
> > seeking would not know what to do.
> ==> From my view point for SIDX, it is used to know how "a Segment" is
> divided into "Subsegments"
> So, we can just ignore the SIDX in your case, since the SIDX only contains
> only *one* subsegment information.

Yes, correct

> ISOBMFF is saying that
> [...]
> So, the my conclusion about SIDX based seeking is,
> we should 2 step seeking if SIDX is there. The first is MPD based (which
> defines top level "Segment" division) and the last is refinement a "Segment"
> using SIDX (if there). So, we can just concentrate on the current "Segment",
> and if any SIDX entries which pointing outside of the "Segment" can be
> ignored.

Correct, that is also my understanding but not how the code does it right now.
Which is what I wanted to point out above. The code assumes that if
isobmff-ondemand (i.e. sidx), then we only have to look into the sidx for
seeking.

See gst_dash_demux_stream_seek() which always returns if sidx after seeking
based on the sidx (even if the target position is not in the sidx and we need
to go to the code below that block where segments are switched).

So that has to be changed too here

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