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

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Sun Mar 5 13:37:45 UTC 2017


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

--- Comment #15 from Seungha Yang <sh.yang at lge.com> ---
(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, 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, I'm still confused why accumulation of SIDX
might be necessary.... because SIDX1 belongs only to "Segment1"
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 :)

> 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"?

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


More information about the gstreamer-bugs mailing list