[Bug 22136] Inband Storage for SPS/PPS in ISO BMFF

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22136

Aaron Colwell <acolwell@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |acolwell@google.com

--- Comment #4 from Aaron Colwell <acolwell@google.com> ---
(In reply to comment #2)
> >Are you suggesting that clients must support both SPS/PPS in the Initialization Segment and inband SPS/PPS, or that segments must include inband SPS/PPS ?
> 
> My understanding is that many broadcasters really would like the first of
> your options. Even if this group won't agree to that, clarity about how
> MPEG's solution for inband SPS/PPS in ISOBMFF fits into this group's vision
> / concept of Initialization Segments would be a big step forwards. 
> 
> I know some are hoping that MSE could fully support an implementation of the
> the DASH-IF guidelines and while inband SPS/PPS are only "expected" in that
> document, broadcasters see them as particularly useful for live content.

I don't have access to this MPEG document so I can't look at the details. 
Here are the questions I have:
1. Why is this beneficial over just providing a new init segment? 
2. Won't you need to have a new init segment anyways to allow people to join
the broadcast at arbitrary points? 
3. Are inline SPS/PPS required at the beginning of every random access point?
4. What would break if the UA used the last appended init segment and started
decoding at the first random access point encountered?
5. Is this data included in the sample or is it side information that needs to
be combined with the sample before handing it to the decoder?

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

Received on Friday, 24 May 2013 00:52:06 UTC