[foms] WebM Manifest

[Philip Jägenstedt]

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?

-- 
Philip Jägenstedt
Core Developer
Opera Software