[foms] WebM Manifest

[Mark Watson]

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

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.

DASH does not require repeatedly fetching a manifest. The scenarios where repeated fetching is necessary are some specific live scenarios, but both live and on-demand can be implemented with a single manifest fetch. 


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

When you say "low level API" do you mean the ability to provide information to the player about the various available streams ? Or do you mean even lower, where the API allows you to provide raw media data, or URLs for media chunks, with all the rate adaptation etc. implemented in the Javascript layer ?

The latter was discussed before on this list. It is very attractive from the point of view of enabling experimentation with rate adaptation algorithms, but my conclusion after the discussion was that practically it would be difficult to come up with an API that was rich enough to enable meaningful experimentation. A simple "switch up/down" method call is not sufficient to implement a working adaptation algorithm: you need to know about switch points, byte ranges within streams, stream VBR profiles and a more detailed view of past throughput than just an instantaneous or fixed window throughput measure.

An alternative approach suggested at the Web&TV working group was that players might support a number of different algorithms of varying maturity, much as OS kernels support a variety of TCP congestion control algorithms. There would need to be an API to discover and configure the various algorithms.


> (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.)

Aesthetically, the XML is not the best, but we're trying to clean it up (already it is better than it was). There is just one namespace, which you need to have a valid schema. Many people would like to be able to use XML Schema tools. I don't think this is a big deal. Looking behind the XML, the information model is pretty clean and as Frank says a lot of thought has gone into this for several years now. You can easily create something simpler, but it would be nice to leverage the existing effort rather than start 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.
> 

When you say "browser vendors", who do you mean ? If you mean Opera/Mozilla/Google/Apple/Microsoft then I think the stakeholders for this topic include a much wider range of companies. Web technologies are finding application in many new environments where adaptive streaming is important (TVs and TV-connected devices being the most interesting for my company). The W3C recently set up the Web & TV Interest group and that might also be a good venue to get involvement from more stakeholders.

...Mark

> -- 
> Philip Jägenstedt
> Core Developer
> Opera Software
> _______________________________________________
> foms mailing list
> foms at lists.annodex.net
> http://lists.annodex.net/cgi-bin/mailman/listinfo/foms