- From: <bugzilla@jessica.w3.org>
- Date: Fri, 24 May 2013 15:18:40 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22136 David Evans <davidew3c@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |davidew3c@gmail.com --- Comment #5 from David Evans <davidew3c@gmail.com> --- In response to the questions in Comment 4, here is the BBC's take on how this might be used: 1. Why is this beneficial over just providing a new init segment? Two reasons - updating the init segment in a live stream isn't easy as there is no way in most streaming specifications to force the client to pick up a new init segment. - secondly for compatibility with other specifications where the use of in band SPS/PPS is required or advised for certain use cases. 2. Won't you need to have a new init segment anyways to allow people to join the broadcast at arbitrary points? You still have an init segment, it just doesn't necessarily contain the SPS/PPS. 3. Are inline SPS/PPS required at the beginning of every random access point? Yes. 4. What would break if the UA used the last appended init segment and started decoding at the first random access point encountered? Nothing, that would work. 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? It's included in the sample. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 24 May 2013 15:18:45 UTC