[foms] WebM Manifest

[Steve Lhomme]

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