- From: <bugzilla@jessica.w3.org>
- Date: Tue, 11 Jun 2013 09:55:57 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22134 Jon Piesing (OIPF) <oipfjon@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #5 from Jon Piesing (OIPF) <oipfjon@gmail.com> --- This comment is submitted on behalf of the participants in the joint discussions between the Open IPTV Forum, HbbTV and the UK DTG. Thank you for these clarifications which are very useful in helping us understand how MSE would work in our context. Comment #3 says “I'm happy to provide guidance on the situations you outline below, but it isn't clear to me what should be changed in the spec since I believe the existing text provides the appropriate hints about what to expect.”. We have tried to understand what “existing text” is referred to here. As far as we can see, the only link from the byte stream format to the source buffer behaviour is the following text in section 3.5.1. "If the input buffer starts with bytes that violate the byte stream format specifications, then run the end of stream algorithm with the error parameter set to "decode" and abort this algorithm. Remove any bytes that the byte stream format specifications say must be ignored from the start of the input buffer." If this is the only “existing text” then; - We recommend some text referencing this failure mode be added to the introduction to the byte stream formats section. E.g. ‘The behavior in the event that the bytes provided to a SourceBuffer do not meet the rules defined in this section is defined in section 3.5.1, “Segment Parser Loop”.’ - The text from section 3.5.1 talks about the input buffer starting with bytes that violate the byte stream format specifications. What if the violation of the byte stream format specs isn’t at the start of the input buffer? (If you prefer we can open a new issue for this question). -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 11 June 2013 09:55:59 UTC