[foms] WebM Manifest

[Mark Watson]

Steve,

Your "single file" idea is supported by DASH. In DASH a "Segment" is a continuous portion of a single bitrate. It could contain the whole duration of the content (e.g. in the on-demand case). The manifest provides a URL *and byte range* for each Segment, so if you wish you can concatenate the different bitrates into a single file and provide the byte ranges in the manifest.

...Mark

On Mar 15, 2011, at 5:32 AM, Steve Lhomme wrote:

> 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
> _______________________________________________
> foms mailing list
> foms at lists.annodex.net
> http://lists.annodex.net/cgi-bin/mailman/listinfo/foms
>