[foms] WebM Manifest

[Frank Galligan]

On Tue, Mar 15, 2011 at 5: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.
>
> --
> Philip Jägenstedt
> Core Developer
> Opera Software


To me I have have always thought the main purpose of the manifest is to
describe the resources of the adaptive streaming presentation. Then the
secondary purpose of the manifest is to describe how each resource relates
to each other. The secondary information is what everyone needs
to decide should be in/out depending on speed or performance gains vs
complexity. On the lowest complexity side we can state a baseline manifest
format will just list all the video and audio streams and the player will
need to download a piece or all of the streams to get the characteristics
and switch points. Then you can add more complexity to the manifest format
form there, I.E. resolution, bandwidth, chunking, switch points,...

Even if all the browsers start with an api and scripts. The "scripts" will
need to describe where the resources are located at the very least and most
likely contain secondary information on how the resources are related to
each other. So these scripts will become the data and the controller. My
main worry with not trying to standardize the manifest or data portion of
the scripts is that each player implementation will have a script that will
expect the "data" portion of the script to be laid out differently. So tool
vendors will need to support a few different adaptive streaming players
and/or website creators will need to modify the "data" portion of
the scripts to work with the "controller" portion of the script they are
using. Either way this will introduce more confusion and complexity.

Another reason to start with a manifest format is that it is real easy to
come up with a format. Most people already have an idea of what should be
included, URL's to files, resolution, streams which can switch seamlessly,
different language tracks, ... Maybe the manifest format won't hit every
edge case but I'm sure most people can come up with something very quickly
that will satisfy 90% of the uses cases. Then we can iterate from there.

So if all the browsers decided they wanted to start with an API and not
<video>.src = manifest.file (Not necessarily advocating this), I think it
would be better if the browsers picked a manifest format. This will help
the javascript client implementers as they can parse the resources all the
same way and focus on the controller script. This will help the tool
vendors because they don't have to worry about the controller script.

With regards to Dash I have always just seen it as resource that describes
the streams of a presentation and secondary information on how those streams
relate to each other. They have been working on it for a while so I think
they have flushed out more use cases then whatever people can come up with
in an hour. I'm not tied to Dash by any means. I just wanted to get
an opinion on it.

Frank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.annodex.net/cgi-bin/mailman/private/foms/attachments/20110316/c361789d/attachment-0001.htm