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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #19 from Seungha Yang <sh.yang at lge.com> ---
(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.


ISOBMFF is saying that
"Each Segment Index box documents how a (sub)segment is divided into one or
more  subsegments (which may themselves be further subdivided using Segment
Index boxes).    
In that context, my understanding about SIDX is, the coverage of SIDX is
varying depending on how the "Segment" is defined.
For example, in case of usual On-Demand profile with SegmentBase, I'd like to
say there is only one "Segment" in each media stream. And, the *one* "Segment"
is divided into "Subsegments" by SIDX (which has full list of "Subsegments").
And, SegmentList/SegmentTemplate cases, each list of url-defined, byte-ranged
or template fragment is a "Segment". And, each "fragment" might be subdivided
into "Subsegment" if there is SIDX. So, we can seek to more precise position
using the SIDX.
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.

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