[media-source] Add non-normative note that makes it clear that appendWindowEnd trimming is allowed

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