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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #16 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Seungha Yang from comment #15)
> (In reply to Sebastian Dröge (slomo) from comment #14)
> Thanks for your detailed suggestion :)
> Anyway, I guess your problem might be a bug of Attachment 342244 [details],
> I just found it. I'll update it soon.
> 
> About your suggestion, Can you confirm following is correct understanding?
> Each SegmentURL shares the same url but only mediaRange is different.
> > <MPD>
> > <Period>
> > <AdaptationSet>
> > <Representation>
> > <BaseURL>
> > <SegmentList>
> > <Initialization />
> --> Let's call this "Segment1"
> > <SegmentURL mediaRange="..." />  --> SIDX1 in front of moof, and only one entry for Segment1
> --> Let's call this "Segment2"
> > <SegmentURL mediaRange="..." />  --> SIDX2 in front of moof, and only one entry for Segment2
> > ...
> 
> If my understanding is correct

Your understanding is correct, yes

> I'm still confused why accumulation of SIDX
> might be necessary.... because SIDX1 belongs only to "Segment1"

For my stream yes, but there seems to be nothing that forbids something else.
We need to at least check for these cases and handle them gracefully instead of
e.g. crashing (currently things crash / use invalid memory on my stream
already, which is not acceptable of course :) )

> Maybe, if your concern is the *possible* case that information of "Segment2"
> is informed not only by "SIDX2" but also by "SIDX1". 
> If so, what we should do in this case is, ensuring/checking whether each
> SIDX.entries is inside of corresponding "Segment" or not. In other words, if
> some SIDX entries are outside of the corresponding "Segment", then just
> ignore it, although I'd like to think this case as *wrongly* encoded stream
> issue though :)

I don't think it's invalid. But yes, I agree otherwise

> > 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).
> 
> "whole SIDX" is meaning the whole SIDX in the MPD? Isn't it enough that
> ignoring SIDX for the corresponding "Segment"?

The whole SIDX of that segment, so yes what you said :)

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