[foms] WebM Manifest

Tue Mar 15 12:58:35 PDT 2011

On Tue, Mar 15, 2011 at 8:32 PM, Mark Watson <watsonm at netflix.com> wrote:
> DASH doesn't specify where you get the manifest from, just its format.
>
> So, if you want to write a specification for a file with embedded manifest, you can certainly do that.
>
> The one issue would be that I doubt you want to embed the URL for the media file inside the file itself. DASH has some text about base URLs, which work in a similar way to HTML or XML documents generally, so it may be sufficient that in your specification for embedding a DASH manifest in a Matroska file you specify that the "Document Base URL" is the URL of that file. Then the URLs within the manifest can be relative to that and in particular if those relative URLs are empty then they just refer to the same file.

Yes, the way URL would be defined may differ a little. Given there's
no need to point to outside URLs, just an offset in the file to tell
which part is where. At first I wanted to do in in EBML to make it all
compatible with WebM/Matroska (for existing readers). I'd like to make
it more generic, but I'm not sure this is achievable.

Also I don't think XML would be a wise choice here. There are probably
plenty of parsers that would not strop reading when necessary (not end
of file marker). The offset may also get screwed by changing the end
of line format (but offset should be relative to the end of the
manifest file anyway).

Anyway, I propose the general idea here for discussion. In case there
is something totally broken about it that I don't see.

Steve

> ...Mark
>
> 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
>>
>
>

-- 
Steve Lhomme
Matroska association Chairman