[foms] WebM Manifest

[Steve Lhomme]

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