[foms] What data is needed for adaptive stream switching?

[Jeroen Wijering]

On Nov 23, 2010, at 10:24 PM, Chris Pearce wrote:

> Thanks for explaining Mark. Much appreciated.
> 
> On 24/11/2010 6:51 a.m., Mark Watson wrote:
>> This is where there is scope for experimentation. What I think would be great is to define an API which can indicate these decision points, provide the two data sets (past incoming bandwidth) and (future bitrate of each stream) at some sufficient level of generality and indicate back the decision. Then we can experiment with more and less complex input data and more and less complex decision algorithms.
> 
> So in terms of what changes to browsers we'd need to make to start 
> experimenting, we'd need to resurrect the @bufferedBytes attribute, add 
> a @currentOffset attribute, and add some way for JS to access the 
> RAP/keyframe index? Maybe we should add the @bufferedBytes data into 
> @buffered, so you can easily map buffered time ranges to byte ranges? I 
> guess these would have to be per-stream if we're playing multiple 
> independent streams.
> 
> Or would you prefer an explicit download bandwidth and a per stream 
> bitrate measure, calculated by the browser, over a specified time window?

A per-stream @bufferedBytes / @currentOffset would be perfect. No need for global bandwidth IMO.

As to framedrops / CPU load: I think a @framesDropped / @framesDecoded attribute pair still makes most sense.

> In terms of an API which can indicate decision points, maybe an event 
> which fires when playback enters a new chunk? Or fires when the download 
> of a chunk finishes? Be aware we can't guarantee that any DOM events 
> which we fire will arrive in a particularly timely manner, there could 
> be any number of other things going on with the event queue.

Depending upon the way the chunks are loaded into the videoElement (<stream>s with range-requests? Stream() API with chunks?), there might already be a way to derive whether a chunk has loaded (polling @bufferedBytes). An event would be nice, but not needed at present I think.

Likewise, @currentTime of a  videoElement should be enough to determine whether a new chunk is already playing or not, for now.


Kind regards,

Jeroen