RE: HTML5 Last Call May 2011 & DASH/Adaptive Streaming

I presume we can agree that some form of identifier of the representations for example using the id can be used. So one can get a list of available id's and if a new period has a change of available id's a notification is sent.

I am still of the opinion that the bandwidth could be passed but we can leave it for now for a later discussion.

/JanL

________________________________
From: Glenn Adams [mailto:glenn@skynav.com]
Sent: den 21 februari 2011 22:03
To: Mark Watson
Cc: Jan Lindquist; Philippe Le Hegaret; Ali C. Begen (abegen); Silvia Pfeiffer; Jean-Claude Dufourd; Richard Maunder (rmaunder); public-web-and-tv@w3.org
Subject: Re: HTML5 Last Call May 2011 & DASH/Adaptive Streaming

I agree, it does not seem essential. The server side could merely send the same info down via WebSockets or even by making use of a metadata timed text track.

Regards,
Glenn Adams

On Mon, Feb 21, 2011 at 1:50 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:

On Feb 21, 2011, at 1:09 AM, Jan Lindquist wrote:

>
>
> - There is a means of retrieving the available representations (from min to max) and the current representation.
>
> I'm not sure why this would be needed ?
> [JLI>] This is the range of streams and the available "bandwidths". So you get a list of what is available and which one is being used.
>
> By why? What would you use that list for ?
>
> JLI> The purpose is to be able for an application to keep track of the available levels and to keep track of the current selected level. The timing for the content provider to keep track of the available levels makes it tricky to have an accurate view of the player. I could then show a layered bars each bar representating a bandwidth (id) and it can change as the content is being viewed. It can give a good user experience to know what is going on with the content similar to know the status of my WiFi connection.
>

I'm wary of saying this is as simple as exposing the available bandwidths, especially since the bandwidth figure is defined in terms of the minBufferTime and so is meaningless without it. If I have two streams, with ( minBufferTime, bandwidth ) pairs of ( 1s, 1000kbit/s ) and ( 2s, 900kbit/s ), which has higher quality ?

If the requirement is just for displaying "signal strength bars" to the user, then it seems not to be essential - a service can always do this itself based on the @id. I think some better notion of quality would be needed to have a service-independent implementation.

...Mark


> ...Mark
>
> ...Mark
>
>
> Regards,
> JanL
>
> ________________________________
> From: public-web-and-tv-request@w3.org<mailto:public-web-and-tv-request@w3.org><mailto:public-web-and-tv-request@w3.org<mailto:public-web-and-tv-request@w3.org>> [mailto:public-web-and-tv-request@w3.org<mailto:public-web-and-tv-request@w3.org>] On Behalf Of Mark Watson
> Sent: den 16 februari 2011 07:11
> To: Glenn Adams
> Cc: Philippe Le Hegaret; Ali C. Begen (abegen); Silvia Pfeiffer; Jean-Claude Dufourd; Richard Maunder (rmaunder); public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org><mailto:public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>>
> Subject: Re: HTML5 Last Call May 2011 & DASH/Adaptive Streaming
>
> What I think would be useful, though, would be to specify that *if* DASH (say) is supported by an HTML5 video implementation *then* is should be done in a specific way.
>
> Otherwise we have the prospect of multiple different implementations supporting different things.
>
> For the examples you give below, it is at least clear what you support if you support a certain version of ECMAScript, say.
>
> For DASH used in HTML5 a minimal set of things that should be nailed down are:
> - that a URL for a DASH manifest can be provided in the @src or <source> element
> - what error should be reported if the manifest is invalid, or if the media it points to cannot be found
> - how to label DASH tracks so that the different kinds of track map to the Multi-Track API (or whatever is agreed for ISSUE-152) and a single way to do the mapping
> - what event to use to report automatic bitrate changes
>
> This is pretty basic stuff, but it would help if everyone that does it, does it the same way.
>
> ...Mark
>
>
> On Feb 15, 2011, at 5:33 PM, Glenn Adams wrote:
>
> For that matter, HTML5 does not require a UA to support either the HTML syntax of HTML5 or the XML syntax of HTML5. A compliant HTML5 UA could support neither (albeit with little utility).
>
> HTML5 does *not* specify:
>
> *   which top-level document types must be supported
> *   which version of ECMAScript must be supported
> *   which version/modules of CSS must be supported
> *   which version/modules of DOM must be supported
> *   which URI schemes (protocols) must be supported
> *   which non-streaming media types must be supported
> *   which streaming media types must be supported
>
> HTML5 is a technology framework specification that requires other specifications (profiles) to fill in these gaps. In the context of certain TV standardization activities, such work to define one or more profiles is already underway.
>
> N.B. I am not criticizing HTML5 for not making such choices. In fact, I think the editor and group has taken the best approach in that regard.
>
> G.
>
> On Tue, Feb 15, 2011 at 5:59 PM, Philippe Le Hegaret <plh@w3.org<mailto:plh@w3.org><mailto:plh@w3.org<mailto:plh@w3.org>>> wrote:
> On Tue, 2011-02-15 at 18:40 -0500, Ali C. Begen (abegen) wrote:
>> I think folks need to agree on the container format not the codec type. A good container format will be good for several codecs that exist today and will yet to come.
>
> My understanding is that the IP issues surrounding the codec types are
> also surrounding the container formats and the streaming technologies.
> So, I'd be surprised if any agreement was reached within the HTML
> Working Group on those topics. I can't imagine a different conclusion
> that the H.264/Theora discussion at this point. In any case, as Glenn
> alluded to, HTML has been technology neutral since the beginning. Unless
> I'm mistaken, we don't require implementations to support a specific
> image format.
>
> Philippe
>
>
>
>
>
>
>