[foms] Proposal: adaptive streaming using open codecs

[Chris Pearce]

On 9/11/2010 3:30 a.m., Jeroen Wijering wrote:
>
> I agree there's a certain amount of ambiguity between lower level range-requests and the un-availability of seekpoints and decoder settings. What about a slightly modified version of appendVideo()?
>
> videoElement.appendVideo(videoURL,[startPosition,endPosition]);
>

We'd want to make the time range a [start,end) range, i.e. inclusive 
start, non-inclusive end. We don't want to be little gaps screwing 
things up.


> *) Both the startPosition and endPosition are in seconds and optional. If they are both omitted, this function is basically a way to build seamless playlist playback (as Silvia requested).
> *) Like with today's playback,  the browser decides to probe the header data if it doesn't have enough info (yet) on the file. In other words, when building a bitrate switching API with this, the browser fetches the index the first time (part of) this videoURL is requested.

Reading the metadata takes some time, users of the API would need to 
account for this when they switch.

> *) If the metadata of the appended video cannot be probed, the browser throws an error (MEDIA_ERR_SRC_NOT_SUPPORTED) and does not append the video. This means that, during append-metadata-fetching, the "readyState" of a video does not change.
We can't block on appendVideo(), we have to dispatch events if there's a 
failure to load from another resource. The question then becomes, do we 
want to fire all the same events which fire during a normal, 
single-resource load?

> *) Buffering and metadata availability will still happen inside the browser. When an appendVideo() is fired, the browser will typically rush to load the metadata ánd the media time range (as it does today).
>
> This seems to be a good tradeoff and starting point to experiment with adaptive streaming?
>

I'd prefer time ranges to byte-ranges, as we then don't need to worry 
about messing around with exposing indexes to JS.

Chris P.