[foms] Proposal: adaptive streaming using open codecs

Jeroen Wijering jeroen at longtailvideo.com
Wed Nov 10 02:38:57 PST 2010


Hello Philip, Chris, all,

>>> I still strongly prefer to put the chunking+concatenating in a layer
>>> outside of<video>, by extending the suitably named Stream API, see
>>> <http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#stream-api>.
>>> 
>>> Here's how it might work:
>>> 
>>> var s = new Stream();
>>> s.appendURL('chunk1.webm');
>>> s.appendURL('chunk2.webm');
>>> video.src = s.url;
>>> 
>>> That's it. From the point of view of the video decoder, it's just an
>>> infinite stream.
>> 
>> I'm happy with this idea, provided that chunks can be appended after the
>> src is set.
> 
> Yes, that's exactly the idea. If you do this...
> 
> var s = new Stream();
> video.src = s.url;
> 
> ... then I'd expect a stalled event after 3 seconds and it otherwise  
> behaving exactly as if a network request had been started but no data  
> received yet.
> 
> Implementation-wise, what we'll have to do is some work on the Stream()  
> API and then making sure that chained WebM works well. (Actually Ogg could  
> be a better fit here, but I'd rather not confuse things by allowing VP8 in  
> Ogg.)

The Stream API looks good and is a nice separation from the videoElement!

For getting bandwidth data returned, what about an event that gets fired when a chunk is loaded by the Stream API? That might replace returning the "bufferedBytes" option, though that option works as well.

- Jeroen


More information about the foms mailing list