[foms] WebM Manifest

Tue Mar 15 11:03:02 PDT 2011

From a JS library developer's perspective I appreciate what Philip is saying about starting with APIs that allow HTTP streaming to be built. An option to set a source that will play next without gap, or something similar, would open up a lot of possibilities, and could probably be implemented cross-browser much more quickly than full DASH support.

-Steve

--
Steve Heffernan
Co-founder // Zencoder

On Mar 15, 2011, at 8:14 AM, Steve Lhomme wrote:

> In my case the manifest is "inside" that single file (as a header). I
> guess it could be an XML file, but I'd rather go with binary (EBML as
> in Matroska/WebM).
> 
> Is that OK with DASH ? If not I suppose it wouldn't be too hard to add
> support for it ?
> 
> Steve
> 
> On Tue, Mar 15, 2011 at 4:01 PM, Mark Watson <watsonm at netflix.com> wrote:
>> 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
>>> 
>> 
>> _______________________________________________
>> foms mailing list
>> foms at lists.annodex.net
>> http://lists.annodex.net/cgi-bin/mailman/listinfo/foms
>> 
> 
> 
> 
> -- 
> Steve Lhomme
> Matroska association Chairman
> _______________________________________________
> foms mailing list
> foms at lists.annodex.net
> http://lists.annodex.net/cgi-bin/mailman/listinfo/foms