[foms] WebM Manifest

[Steve Lhomme]

On Tue, Mar 15, 2011 at 10:01 AM, Philip Jägenstedt <philipj at opera.com> wrote:
> On Mon, 14 Mar 2011 22:56:23 +0100, Frank Galligan <fgalligan at google.com>
> wrote:
>
>> Hi all,
>>
>> We have been talking about how to implement client-side HTTP adaptive
>> streaming for WebM for a few months. We have focused on VOD first (with
>> live
>> to come later). Most participants have agreed that the default baseline
>> format are streams that should be stored as separate non-chunked files.
>> This
>> format has the most advantages and least disadvantages for the three
>> major
>> parties involved with VOD video: content creation tools, content delivery
>> networks, and client implementations. The next issue that needs to be
>> addressed is the manifest format.
>>
>> I think most people have been following the DASH spec closely as an
>> option
>> for the WebM adaptive streaming manifest. But there still is a question
>> as
>> to whether the DASH specification will be licensed in an open manner
>> that is
>> consistent with WebM. I think most people in the community would like to
>> have one adaptive manifest format. I know there has been interest by the
>> proposed W3C Web and TV Interest Group of adopting DASH as the baseline
>> manifest format for adaptive streaming.
>>
>> If the Web and TV IG choose the DASH manifest as the baseline manifest
>> format for adaptive streaming, would all of you be OK with implementing
>> it
>> in your products?
>
> In short, no.
>
> I've previously glanced over the DASH spec and have done so again today,
> and I am not very enthusiastic about it at all.
>
> Since the spec is written for a non-browser context, it fails to make any
> use of existing browser infrastructure. Everything is done declaratively,
> whereas in a browser context one can leave many things to be dealt with
> using scripts. I think we should aim for a solution that doesn't strictly
> require fetching a manifest file over HTTP repeatedly, we could just as
> well build a solution using WebSockets, just to name one possibility.
>
> 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.

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.

Steve

-- 
Steve Lhomme
Matroska association Chairman