- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 08 Sep 2009 19:26:14 -0700
- To: Adrian Bateman <adrianba@microsoft.com>
- Cc: Anne van Kesteren <annevk@opera.com>, HTML WG <public-html@w3.org>
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. Regards, Maciej
Received on Wednesday, 9 September 2009 02:26:58 UTC