- From: wolenetz via GitHub <sysbot+gh@w3.org>
- Date: Mon, 13 Jun 2016 18:25:55 +0000
- To: public-html-media@w3.org
wolenetz has just created a new issue for https://github.com/w3c/media-source: == Add non-normative note that makes it clear that appendWindowEnd trimming is allowed == In the coded frame processing algorithm, we currently have a non-normative note that makes it clear that we allow splice frame generation around appendWindowStart trimming (though we don't require it, and if implementations choose not to do such a splice frame, there is also well-defined behavior): > If presentation timestamp is less than appendWindowStart, then set the need random access point flag to true, drop the coded frame, and jump to the top of the loop to start processing the next coded frame. > NOTE > Some implementations may choose to collect some of these coded frames that are outside the append window and use them to generate a splice at the first coded frame that has a presentation timestamp greater than or equal to appendWindowStart even if that frame is not a random access point. Supporting this requires multiple decoders or faster than real-time decoding so for now this behavior will not be a normative requirement. I believe the intent of this appendWindowStart behavior should be matched by a similar new note around appendWindowEnd behavior. Currently, we have only the minimum well-defined behavior, without clarification of allowance for implementations to similarly make splice frames rather than drop them if they cross appendWindowEnd: > If frame end timestamp is greater than appendWindowEnd, then set the need random access point flag to true, drop the coded frame, and jump to the top of the loop to start processing the next coded frame. Since multiple implementations (FF, Chrome) currently support the intent around appendWindowEnd, I believe we should make this clear by adding a non-normative note to the spec for this trimming, like there already is for appendWindowStart. I don't believe this is substantive; please comment ASAP if you disagree. Barring any objections, I'll be producing a PR for this shortly. @jdsmith3000 @paulbrucecotton FYI Please view or discuss this issue at https://github.com/w3c/media-source/issues/97 using your GitHub account
Received on Monday, 13 June 2016 18:25:57 UTC