Thursday, November 20th, 2008

This Week in HTML 5: Video tag changes

Category: HTML

Mark Pilgrim is back telling us what is new in the world of HTML 5 and focuses on changes with the video tag and API:

The big news this week is a major revamping of how browsers should process multimedia in the <audio> and <video> elements.

r2404 makes a number of important changes. First, the canPlayType() method has moved from the navigator object to HTMLMediaElement (i.e. a specific <audio> or <video> element), and it now returns a string rather than an integer. [canPlayType() discussion]

The canPlayType(type) method must return the string “no” if type is a type that the user agent knows it cannot render; it must return “probably” if the user agent is confident that the type represents a media resource that it can render if used in with this audio or video element; and it must return “maybe” otherwise. Implementors are encouraged to return “maybe” unless the type can be confidently established as being supported or not. Generally, a user agent should never return “probably” if the type doesn’t have a codecs parameter.

Wait, what codecs parameter? That’s the second major change: the <source type> attribute (which previously could only contain a MIME type like “video/mp4”, which is insufficient to determine playability) can now contain a MIME type and a codecs parameter. As specified in RFC 4281, the codecs parameter specifies the specific codecs used by the individual streams within the audio/video container. The section on the type attribute contains several examples of using the codecs parameter.

Video and the Open Web is a huge issue. The idea of having video be a native object that other components can integrate with (e.g. rotate in canvas) is great. We need codecs implemented. We need penetration. We need more.

Posted by Dion Almaer at 6:58 am

3.2 rating from 14 votes


Comments feed TrackBack URI

One thing I never understood is why html designers don’t use True/False.
If an element returns to me maybe or probably I for one will assume that means true and give it a shot anyway and see if it blows up.

Comment by TNO — November 20, 2008

HTML gets fuzzy in the fifth incarnation. The verbose value set spelling out their meaning might be good when read by human but it’s not the case in most cases and this solution will require an obscure evaluation on js programmer side.
Integer values would do that job too.

Comment by funtomas — November 20, 2008

if (video.canPlayType(video.type)) {;
} else {
alert("too bad")

//versus this
switch(video.canPlayType(video.type)) {
case "probably":;

case "maybe":
if ( break;

case "no":
alert("too bad")

Can’t wait…

If this is how it get implemented, every library will just provide custom boolean wrapper functions for this, no one want’s to do string detection.

Comment by tj111 — November 20, 2008

Wont forget…
What if IE9 says maybe, FireFox says probably, Safari says probably, opera says maybe and Chrome says Probably.
Now lets say hypothetically with those answers this happens:
IE9 fails
FireFox plays
Safari plays
Opera fails
and Chrome lied about its answer and fails
Can you imagine the code you would need to branch for that?

Comment by TNO — November 20, 2008

Hmm, codecs and canPlayType gives me flashbacks to the insane mess codecs for Windows Media Player where before I stopped using it and stated using VLC or mplayer. If this mess comes to the web it’s a step backwards. I think why FLV and Flash have become so popular is that it’s just one format, one vendor and no mess it works the same way in all browsers. Also I think it will be hard for companies like Microsoft to adapt Ogg in favor of their own wmv and wma formats.

Comment by Spocke — November 22, 2008

Leave a comment

You must be logged in to post a comment.