[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