[foms] WebM Manifest

[Philip Jägenstedt]

On Tue, 15 Mar 2011 13:32:57 +0100, Steve Lhomme <slhomme at matroska.org>  
wrote:

> On Tue, Mar 15, 2011 at 10:01 AM, Philip Jägenstedt <philipj at opera.com>  
> wrote:
>>
>> My position is that we should start from the bottom, implementing APIs  
>> in
>> browsers that make it possible to implement adaptive streaming using
>> scripts. If we succeed at that, then DASH could be implemented as a
>> JavaScript library. When we have that low-level API in place I think we
>> should look at simplifying it for authors by looking at a manifest  
>> format,
>> but I truly doubt taking DASH wholesale would be the best long-term
>> solution for either browser implementors or web authors.
>>
>> (About the syntax of the format, it's extremely verbose XML with
>> namespaces, something I was really hoping web authors would never have  
>> to
>> deal with again.)
>>
>> I think that those browser vendors that are interested in a streaming
>> solution using open formats get together and start to discuss a  
>> technical
>> solution. This list or the WHATWG would be sensible venues for that,  
>> IMO.
>
> Well, in some ways you are saying that DASH could work on browser. But
> rather on top of something defined at the lower level.

Yes, I believe it would be possible to implement basic DASH support on top  
of such an API. I'm certain there would be some aspects of DASH that  
couldn't be implemented (e.g. stream encryption) and people would just  
have to not use those features, or we'd have to extend the API.

> That lower level API could be useful and allow more innovations. On
> the other hand you could not do bare adaptive streaming without adding
> that JavaScript code.
>
> I have an idea for a different way of doing adaptive streaming, using
> just a single file. That file would contain all bitrate version
> contiguously. So switching from one bitrate to another would just be a
> matter of seeking in the file (not much different than seeking in
> different ones). The advantage is that it could be easy to mirror on
> servers and easy to post a video on any website (just upload one file,
> get the URL and you're done). But that could only work if the browser
> recognizes natively that kind of file (via a MIME type). If that
> requires another javascript library (on top of your low level API),
> that defeats the whole idea.

My approximate solution for the low-level API is something like this:

* XMLHttpRequest is used to get a data Blob for a resource.

* We have some mechanism to concatenate several Blobs into a Stream object

* setting video.src to the Stream object just works, similar to how video  
conferencing is defined.

What's missing here is to make XMLHttpRequest byte range aware, so that  
one could do the kind of thing you mention above.

-- 
Philip Jägenstedt
Core Developer
Opera Software