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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #14 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Seungha Yang from comment #13)
> (In reply to Sebastian Dröge (slomo) from comment #12)
> > I don't think I can share my stream unfortunately, but if you can provide a
> > patch that works for your content with SegmentTemplate then I can test it on
> > mine and fix up anything that is missing.
> Then, can you provide only MPD to me? (or only some part of it to figure out
> hierarchy of xml doc.) 

It's basically

<MPD>
<Period>
<AdaptationSet>
<Representation>
<BaseURL>
<SegmentList>
<Initialization />
<SegmentURL mediaRange="..." />
<SegmentURL mediaRange="..." />
...

and the same repeated for other AdaptationSets


> > Also I think there's nothing that forbids for example something like my
> > case, but the SIDX actually contains information about the previous, next
> > and following segment. Or about the next and all previous segments. This has
> > to be all considered when parsing the SIDX to get a coherent view.
> 
> I'm a little bit confused by the terminology "Segment". Although I need to
> study the spec more, It does not seem to make sense that a SIDX has any
> information about outside of the "Segment" which SIDX belongs to. But it
> should include only the "Subsegment" information which SIDX belongs to,
> IMHO. In this context, your stream makes sense because each SIDX contains
> "Subsegment" index of which the SIDX belongs to.
> 
> In summary, it's still questionable that whether accumulating or searching
> prev/next "Segment" is necessary when parsing SIDX...

It might not be *necessary* but it should be handled in a useful way without
breaking :)

If I remember the MP4 spec correctly, the content of the SIDX seems to be
allowed to be basically anything. And at least the case of having entries in
there further away then just the next fragment exists (e.g. in your stream),
and the case where it only contains the next fragment and there's a new one
before each fragment (e.g. my stream).

Both seem valid cases of fragmented MP4 streams. Mine seems to require some
kind of accumulation of the SIDX (so you can get a "map" of the fragments
outside the current fragment), although the same information is also available
in the MPD at the DASH level (each SegmentURL is a byte-range into a single
URL).
It could be equally possible that e.g. at the DASH level you have one
"segment", but this points to a fragmented MP4 with two fragments (moof)... and
either a SIDX with both at the beginning, or a SIDX with each one entry in
front of each fragment.

I don't think it is necessary to support all theoretically possible
combinations at this point, but we should at least handle them in a way that
does not involve crashing or further breakage than needed. 


What do you think? I think as a first step it would be useful to just handle it
like following: whenever a SIDX is found, you only parse that one and forget
all others you saw before. The SIDX index is then updated according to the
current offset so that we're not at the beginning of the SIDX but at the SIDX
entry that represents what will now follow. If there is no entry that we can
correlated to the fragment that follows, we just ignore the whole SIDX (which
then possibly breaks seeking but not playback otherwise).

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