Seeking in the buffered range should always succeed.

[jyavenard]

From: https://w3c.github.io/media-source/index.html#mediasource-seeking describe the steps on how to seek with MSE "If one or more of the objects in activeSourceBuffers is missing media segments for the new playback position If the HTMLMediaElement.readyState attribute is greater than HAVE_METADATA, then set the HTMLMediaElement.readyState attribute to HAVE_METADATA. "

One can implicitly assume that seeking in the reported buffered range will always succeed. in particular as we have "The web application can use buffered to determine what the media element needs to resume playback."

When the mediasource readyState is "open", the buffered range only reports where we actually have data. However, if the readyState is "ended" (https://w3c.github.io/media-source/index.html#widl-SourceBuffer-buffered) "If readyState is "ended", then set the end time on the last range in track ranges to highest end time."

So let's assume that we have a media element that is made of an audio and video tracks. The audio track has a buffered range of [5-10] and the video track has [5-20]. When in "ended" readyState, the buffered attribute reported will as such be [5-20]" ; however we do not have audio data in the [10-20] range; so according to the seeking definition, the media element readyState should become HAVE_METADATA and seek can't succeed.

As such two possibilities: 1- Have buffered always return the buffered range intersection of all tracks, regardless of the readyState value 2- Specify in the seeking steps, that if the reported buffered range contains the position, seeking must complete (so the UA when completing the seek would then play whatever left data it has without stalling to the end of the buffered range)

I favour option 2.

[wolenetz]

Jerry and I will triage this today.

[wolenetz]

I similarly favor option 2. Apps likely already rely on the endOfStream() buffered and duration behavior, so option 1 would likely be a breaking (and more substantive) change. seeking in the reported buffered range should succeed, except there's a further edge case around seeking to precise duration in ended state: should the seek complete? My presumption is: yes (there's enough data to decode and render the frame(s) at the end of the media resource.) I'll separately investigate with chcunningham@chromium.org and sandersd@chromium.org if Chromium does something differently here (these end-of-media-resource cases are a bit roughly implemented in Chromium, and are something we've been fixing recently).

[wolenetz]

@jdsmith3000 Please chime in here, too :)

[jdsmith3000]

@jyavenard: I agree with @Wolenetz that only option 2 here seems like it could be done for the V1 spec. I want to be sure I understand your concern though. Can it be summarized as:

1. Seeking as currently specified can fail when seeking within the buffered range, if data is missing for either audio or video, and in that case playback would likely "stall to the end of the buffered range"?
2. One solution (option 2) is to specify that seeking within the buffered range must complete so that whatever data is buffered would be played rather than stalling?

Is there not a valid case where the buffered range reflects the longest supported data (audio or video) and the proper response to seek would be to download and append additional data?

[wolenetz]

Is there not a valid case where the buffered range reflects the longest supported data (audio or video) and the proper response to seek would be to download and append additional data?

This bug is about clarifying what should happen when the "end of stream algorithm" has (somewhat artificially) extended the last buffered range end time to be the "highest end time". This is the only case, of which I'm aware, where a SourceBuffer.buffered or HTMLMediaElement.buffered (for MSE) set of ranges includes a range that has a track missing underlying data for some part of that range (excepting in-band text tracks, which are a different beast - I'll file a new issue shortly to discuss that piece).

Option 2, with text focused on clarifying this requirement for seeks to complete if in 'ended' state and the seek time is within the last buffered range, seems the most surgical clarification to make. It also seems V1Editorial. @jdsmith3000 please chime in if you disagree with the triage or the proposal. I'll produce a PR shortly.

edit: I've filed #149 to discuss the spec for buffered range calculation w.r.t. text tracks.

[wolenetz]

(PR #151)