[foms] WebM Manifest

Steve Lhomme slhomme at matroska.org
Thu Mar 17 05:42:47 PDT 2011

On Thu, Mar 17, 2011 at 1:37 PM, Philip Jägenstedt <philipj at opera.com> wrote:
> On Thu, 17 Mar 2011 13:08:37 +0100, Steve Lhomme <slhomme at matroska.org>
> wrote:
>> On Thu, Mar 17, 2011 at 10:14 AM, Philip Jägenstedt <philipj at opera.com>
>> wrote:
>>> On Wed, 16 Mar 2011 17:03:13 +0100, Mark Watson <watsonm at netflix.com>
>>> wrote:
>>>> Hi Philip,
>>>> A couple of comments below...
>>>> On Mar 15, 2011, at 2:01 AM, Philip Jägenstedt wrote:
>>>>> On Mon, 14 Mar 2011 22:56:23 +0100, Frank Galligan
>>>>> <fgalligan at google.com>
>>>>> wrote:
>>>>>> 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.
>>>> This was deliberate as it was recognized that HTML/Javascript
>>>> environments were not the only ones where adaptive streaming would be
>>>> needed. We wanted to have a solution which was independent of the
>>>> presentation framework and I think it would be valuable for the industry
>>>> to have such a single solution, rather the multiple solutions for
>>>> different environments.
>>> Would it be an acceptable outcome if one can deliver to browsers using a
>>> DASH manifest with some JavaScript glue to parse the manifest and map
>>> that
>>> to the lower level APIs that browsers provide?
>> That would be really odd. First because it would be fixed to a set of
>> APIs, so would not be able to use newer technologies for adaptive
>> streaming in the future.
> Unless browsers implement support for those newer technologies you won't be
> able to use them in any case. This is the case regardless of what kind of
> API is provided, right?
>> It may also mean adapting and changing the
>> manifest if a bug is found in a specific browser version.
> This is even more the case if browsers have bugs in their native support for
> some manifest format. With JavaScript you can possibly work around it for
> that specific browser rather than changing the manifest for all clients. In
> any case, I don't think it's obvious at all that any approach here is more
> likely to be buggy.
>> IMO the information about the stream options and the way they are
>> processed should be completely decorrelated.
> What does this mean, in practice? Is this an argument against making it
> possible to do adaptive streaming using a stream concatenation API, or for
> something else?

It sounds like you're trying to have a JPEG file and the library to
display it inside the file. I think this is a bad design. The way to
handle a manifest should be up to the browser. And if you really need
a piece of JavaScript code to handle the manifest, then put it on the
web page, not inside the manifest.

Steve Lhomme
Matroska association Chairman

More information about the foms mailing list