In a previous post on this blog we talked about using JavaScript to create video elements on the fly. While that was a good use case for the Mozilla’s support site in this post we offer another set of methods that will likely find more use on the web. In fact you can see it in use on Mozilla’s What’s New in Firefox 3.5 video, this blog and we’re starting to see pickup on the web as a whole.
The examples here should work with Safari 4, Firefox 3.5 and IE using a flash fallback. If you’re looking for a complete example that includes support for the video element, quicktime, windows media, iPhone support, and finally flash support you might try checking out Video for Everybody. It’s been tested with a huge pile of browsers in different configurations and is a good start point if you’re looking for support for everything under the universe.
You might also check out Michael Verdi’s video tags with fallbacks article where he uses a much simpler, but somewhat easier to understand method.
A simple example
The video tag looks something like this in a web page:
<video src="zombie.ogg" controls></video>What this does is insert a video element into your page. Firefox 3.5 will load the video, determine its size and re-size the element to the natural size of the video.
Firefox 3.5 supports the Ogg Theora video format, a free and open standard for video. Opera and Google Chrome will also include support for Theora in later versions. Safari 4 can also support the same format when using the Xiph Quicktime component but is not guaranteed to be present. Apple has licensed the mpeg4 format for use in Safari 4 and it is supported by default.
If you want to support both formats you need to be able to provide more than one type of format. You also need to change the markup to tell the browser about the types of the files, which order they are preferred and then let the browser choose which one it should use to display the video element. For our example the code would look something like this:
<video controls> <source src="zombie.ogg" type="video/ogg"/> <source src="zombie.mp4" type="video/mp4"/> </video>
In this case the browser will first check to see if it supports the video/ogg video type. If it does, it will use that and load it. If it doesn’t it will move on to the next entry, the mp4 file and use it if it’s supported.
While most modern browsers have specific plans to support the video element, Microsoft has not made their intentions clear. So in order to support IE users into the near future you should provide fallbacks until Microsoft adopts this part of the new HTML5 standard. For our example we’ll use a simple flash fallback.
One nice thing about the video element is how easily it degrades to older browsers. If in the above example your browser doesn’t support the video tag and doesn’t support the source tag it will simple fall back to whatever happened to be included inside them. This makes it very easy to support fallbacks in a very easy way. Here’s what a flash fallback would look like that uses blip.tv:
<video controls> <source src="zombie.ogg" type="video/ogg"/> <source src="zombie.mp4" type="video/mp4"/> <embed src="http://blip.tv/play/AYGLzBmU8hw" type="application/x-shockwave-flash" width="500" height="396" allowscriptaccess="always" allowfullscreen="true"/> </video>
And that’s it. This example supports all browsers, degrades nicely and helps to move the web towards all in one blow. HTML5 isn’t finished, but web developers can certainly start taking advantage of the features that it provides in modern browsers today.
The full example is embedded below.
I’ll update my letter, and thank you, so kindly. I can finally see video on the web! I would only add that actual fall back text is *very* important. If the video doesn’t play for them, then a download link will help. Devices like the Palm Pre require it at the moment!
BTW Did you leave out in the second example code?
Embed is not a good solution : thisis a useless and depreciated html tag. Better way is to use Object tag, with fallback within.
As I explain in French : http://dascritch.net/blog.php/post/2009/05/28/Rien-nest-anodin-dans-lopen-source
@Da Scritch: I thought the embed tag was making a comeback in HTML 5. Personally, I don’t like the direction in which the Web is heading, but meh.
@da scritch : embed is not a deprecated element, it is part of html5 : http://dev.w3.org/html5/spec/Overview.html#the-embed-element
Great! Straight-forward HTML over Javascript any day.
This video tag is sure going to be a competitor for flash video when more browsers start supporting it in a good way. I can’t wait to see it’s potential unleashed!
So glad to see this method posted here!
You forgot to end the video tag in the second code snippet
I am only sad that if I specified a non supported video format in the tag, the fallback contents will not load. In my opinion it degrades badly: if I only specify a h264 video, the video player of firefox is loaded with a black screen because it can not play the video. It should display the fallback content.
doesn’t seem to work on my iPhone 3Gs
very nice. html5 looks that it is going to be handy
The code example should omit the </embed> tag (since embed is a void element, just like img), and should include the </video> tag.
Da Scritch, embed is valid in HTML5, although it does not support fallback.
How do I control the .play() method in javascript? should I call the video.play first, then the embed.play if the former fails?
Very cool. The mandatory use of Javascript was a real concern. I hope you decide to submit this as the recommended way to use video in HTML5.
@Bernard – If you specify the type to the video element the browser will display the fallback content. For example if you do this:
<video src=”foo.mp4″ type=”video/mp4″>
Fallback content!
</video>
And your browser doesn’t support mpeg4 it should fall back to the fallback content.
@Christopher – Both Mozilla (with h264) and Safari (with theora) do not conform to that. They both just display the empty video player.
@sxpert – Funny you should say that. I spent an hour last night trying to figure out how to get my friend’s iPhone to play video content. In theory it’s supported. In practice it’s poorly documented and doesn’t give useful error messages.
What a fucking retard, the guy on the video.
It seems wordpress is inserting <br />s for each new line inside the <video> markup, which makes it invalid HTML5. Clearly, this should be fixed in wordpress. As a workaround, you can avoid new lines in <video> in the markup.
Does the autobuffer param do anything yet? I want to embed 3-4 videos on a page, but even with autobuffer set to false, Quicktime in Safari and the Theora player in Firefox start downloading all of the videos on the page as soon as the page is loaded. Which isn’t something I want it to do without the user saying so, especially for users on bandwidth caps.
Is autobuffer supposed to be off by default? Because not including the parameter stops Firefox from autobuffering the video, but not Safari where Quicktime continues to download the entire video as soon as the page is loaded.
@Christopher Blizzard @Bernard van Gastel
I reported a bug with firefox https://bugzilla.mozilla.org/show_bug.cgi?id=498540 You are right – according to the html 5 specification, if the video (or audio) can not be played for any reason (including an unsupported codec), the fallback content should be displayed.
I do not use webkit (at the moment). Can someone please file a similar bug with them?
IMHO, this sort of non-compliance to the specification (especially such a young spec) is very bad, and should be fixed ASAP. I hope Webkit and Mozilla handle this non-compliance quickly.
@Kevin Yes, autobuffer is off by default as of Firefox 3.5 RC1. We now download only enough data to decode the first frame of the video. The presence of the autobuffer attribute signals that the author would like the entire video to be buffered. Note that autobuffer is what HTML5 calls a “boolean attribute”[0], where the presence of the attribute means the value is true, and the absence of the attribute means the value is false. So “autobuffer=false” is invalid markup, which is why it doesn’t do what you expect.
[0] http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#boolean-attribute
@Matt Yeah thanks. I figured that out just after I posted the comment. Removing it makes it work as expected in Firefox, now if only Safari/Webkit/Quicktime would get together and get theirs to not buffer unless told to.
This is all well and good, but doesn’t it mean that I’d have to upload and store videos in several different formats on my site?
I’m not willing to do that or even write the extra coding no matter how basic that it is.
I suppose it comes down to how badly that you want a visitor to your site to see a video.
I’ll stick with learning more about open video and providing it on my sites.
It looks like that users cannot fully control the video play process. For example. I open this page and play the video, however I find a problem that I have no way to reply it– once I tried to drop it to start point and click play, the video shows me the face as loading.
I use Firefox 3.5 RC2 English version on Windows XP SP3.
Craig, both WebKit and Firefox do conform to the spec AFAICT, as I’ve commented in the bug.
Is there somewhere that gives all the syntax for the tag?
Is it possible to specify a seperate thumbnail?
Resize the video?
Hi Chris, have you tested that in Internet Explorer yet? My memory is that they dropped understanding EMBED a few versions back, sticking with just the OBJECT that they invented and managed to get HTML4 to approve.
Does the above fragment actually work across all browsers, and for parameters such as script access, autoplay and such…?
tx, jd/adobe
@John Dowdell – yeah, I tried it in IE 8 and it seems to be working fine.
The fragment itself is pretty simple and doesn’t show many of the advanced features. I could add autoplay which all of the html5-video browsers support.
As for script access someone is working on a neat little access library that will wrap flash in the html5 api if the browser doesn’t support it:
http://gettingsoftware.posterous.com/html5flash-using-html5-video-and-audio-right
It’s a great bridge to get us from where we are today to where we need to be a few years from now.