Thursday, November 20th, 2008
This Week in HTML 5: Video tag changes
Category: HTML
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 thenavigatorobject toHTMLMediaElement(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
codecsparameter? 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 acodecsparameter. As specified in RFC 4281, thecodecsparameter specifies the specific codecs used by the individual streams within the audio/video container. The section on thetypeattribute contains several examples of using thecodecsparameter.
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.
Related Content:
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.
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.
//this
if (video.canPlayType(video.type)) {
video.play();
} else {
alert("too bad")
}
//versus this
switch(video.canPlayType(video.type)) {
case "probably":
video.play();
break;
case "maybe":
if (video.play()) break;
case "no":
alert("too bad")
break;
}
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.
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?
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.