Thursday, November 20th, 2008

This Week in HTML 5: Video tag changes

Category: HTML

<p>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.

Related Content:

  • HTML5: The end of native apps?
    Will the platform-agnostic common language HTML5 force apps from the device to the...
  • Understanding the HTML5 standard
    Vendors are implementing HTML5 to take advantage of improved compatibility despite the fact that the standard won't be final until late...
  • HTML5 guide
    HTML5 guide: The advent of HTML5 signals a new wave of Web programming methods, and a new slate of standards for enterprise application...
  • Is Java ready for HTML5?
    How quickly will Java developers be able to develop HTML5-ready server-side...
  • Video, HTML5 canvas and the codec cavalcade
    Browser support is again a new frontier. Video codec are a central issue. A variety of codecs are being offered for HTML5. Some codecs may be the...

Posted by Dion Almaer at 6:58 am
5 Comments

+++--
3.2 rating from 14 votes

5 Comments »

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


//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.

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.