W3C home > Mailing lists > Public > public-html@w3.org > September 2009

Re: <video> and <audio>

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 08 Sep 2009 19:26:14 -0700
Cc: Anne van Kesteren <annevk@opera.com>, HTML WG <public-html@w3.org>
Message-id: <5909BAA0-DBCA-484B-96FA-549D4E1A25B2@apple.com>
To: Adrian Bateman <adrianba@microsoft.com>

On Sep 8, 2009, at 9:45 AM, Adrian Bateman wrote:

> However, this means the web developer has to make the judgement  
> about where
> the best switchover point is without knowing what else the device is  
> doing.
> In this case we guess that if the device has a network bandwidth of  
> 256kbps
> then it should play the 192kbps stream.
> <video ...>
>  <source src="video64.mp4" type="video/mp4" feature="mediabandwidth: 
> 64">
>  <source src="video192.mp4" type="video/mp4" feature="mediabandwidth: 
> 192">
> </video>

This is an interesting idea, but note that it doesn't work with the  
current <video> source selection algorithm, which is to select the  
first source that the UA believes it can handle. So for the markup  
above, a browser is supposed to use the lower bitrate video even if it  
can handle the higher bitrate. To work as expected, you have to list  
the options from highest bit rate to lowest.

Also, if you want UAs to display *something* even if they think all  
bandwidths available are too low, then the final option needs to not  
list a bandwidth at all, so it won't be excluded. Another possibility  
is to change the source match algorithm to have some special case for  
this, for example require that if all sources have bandwidth that is  
too high, then try the lowest of the available bandwidths and see if  
any sources match, and so on. This would have to work even if there  
are differences other than bandwidth, such as choice of codec. And it  
could get very complicated if the "features" are more complex

Overall, it seems like this approach is potentially error-prone for  
authors, since the source matching algorithm is not designed to deal  
with hints, as opposed to binary pass/fail conditions. It is a first- 
match algorithm, not a best-fit algorithm.

Received on Wednesday, 9 September 2009 02:26:58 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:51 UTC