Adrian Bateman from Microsoft, while replying to Maciej Stachowiak of Apple, has confirmed in a public mailing list at W3.org that Microsoft supports the <video> and <audio> elements in the HTML5.

Maciej Stachowiak (Apple) – New media elements: <audio>, <video> – We love these and have them implemented. We don’t see any major implementation issues in the current spec.

Adrian (Microsoft) – We support the inclusion of the <video> and <audio> elements in the spec. There are a couple of areas that we have some thoughts – we are still discussing the details but here is a quick summary:

a) We think there needs to be a mechanism for the media stream to notify the page of events to allow, for example, a transcript to be synchronised with the playback.

b) We have been discussing whether there is value in supporting additional optional information on <source> elements. This would be used to indicate properties of the media stream to provide more data for user agents to choose between the different sources.

Today, the <source> element provides a combination of MIME type (including codecs parameter) and media query to determine the available sources. We think an interesting use case is one where two sources use the same codecs but are encoded with different properties. For example, they may have different bit rates. Alternatively, two audio sources may be in different languages. We’re still actively debating this but would welcome feedback on this idea.

Further discussion:

I agree that adding some of these properties as media features is a good idea. However, I’m not sure if requiring web developers to form this into a mediaquery is the best approach. In particular, the user agent may be in a betterposition to make a judgement about the device/environment than the author ofthe page. Using media queries, a web developer would have to write something like:

<video ...>
  <source src="video64.mp4" type="video/mp4" media="max-networkbandwidth:256">
  <source src="video192.mp4" type="video/mp4" media="min-networkbandwidth:256">
</video>

However, this means the web developer has to make the judgement about wherethe 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 256kbpsthen 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>

In this example, the author is simply indicating the features of the mediasource and the user agent can determine which is best to play. Knowing thatthe user is currently also downloading a file in the background, it couldchoose the lower bandwidth file. Alternatively, a user setting couldinfluence which one to choose based on preference.

To this, Maciej from Apple resonds:

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.

Full discussion at public-html@w3.org