What's the easiest way to put a video in an HTML page?

[d000hg]

Off to Light Relief with you. Shoo.

[VectraMan]

The primary purpose of HTML5 is to address those incompatibilities such that cross-browser problems are eradicated. This is why the vast majority of the spec relates to precisely defining the rules for parsing content, as they are currently implemented in browsers (which includes various odd behaviours that date back as far as Netscape Navigator 2). <snip>

Indeed, and if it succeeds that'll be good. But it's taken a long long time to get there, and to some extent it's too late as we've already had the huge explosion of the internet. If everybody had adopted Flash for everything 10 years ago, none of this would be necessary, because Flash simply defines where things are and what they look like. It's the fundamental problem with HTML, i.e. that it's an interpreted description language that's why we have browser incompatibilities, and why there's this long painful process to agree on standards and get the browser developers to adhere to them.

And you know that several years after HTML5 becomes an official standard (which presumably will be several years), there'll still be people running IE6 that you'll have to think about when designing your web page.

I'm sure a lot of people have got very rich off the back of the fact that doing anything for the internet is far more complicated than it needs to be, all thanks to the adoption of HTML for everything.

Actually I'm not saying Flash is fantastic, because it has its flaws and its origins as an animation format show when you tried to do something more interactive. And of course it's proprietary, which isn't ideal. I'd quite like to see a serious open source alternative that could be an "official" standard and finally shut up the dissenters. Then Apple would have to come up with a different excuse as to why they'd not allow it on the iFad.

Back on the subject of video, is H264 going to be adopted by HTML5? It seems unlikely, because of the patent issues - meaning anybody using it on a commercial website, or a paid for website, or for an internal coroporate system will have to pay a royalty to MPEGLA*. I understood that's what the argument was about currently, and Google were especially against it. Which means from the start HTML5-YouTube is going to have to use the inferior open source codec (I forget the name) and will have lower video quality that the previous Flash version. Progress again.



*To be clear, the same applies to Flash.

[NickFitz]

Back on the subject of video, is H264 going to be adopted by HTML5? It seems unlikely, because of the patent issues - meaning anybody using it on a commercial website, or a paid for website, or for an internal coroporate system will have to pay a royalty to MPEGLA*. I understood that's what the argument was about currently, and Google were especially against it. Which means from the start HTML5-YouTube is going to have to use the inferior open source codec (I forget the name) and will have lower video quality that the previous Flash version. Progress again.

On the contrary, YouTube now uses H.264 for its HD video, served to desktop machines via Flash (leaving aside the HTML5 beta, which is opt-in only). Although desktop machines receive its non-HD content in some other encoding (possibly MP4), it also serves that content to mobile devices as H.264, so presumably it could switch to all-H.264 at some point.

HTML5 doesn't prescribe specific codecs. There's a detailed list of the current state of web video in the book I originally linked to, but basically:

Google Chrome, and Google Android phones, support H.264. It's also the only format used in the YouTube <video> beta. They also support Ogg.

Safari supports H.264, as do iPhone and iPad, but not Ogg.

Mozilla are holding out against H.264 because of the need to maintain the purity of their licensing model. Firefox currently only supports Ogg.

Opera hasn't yet implemented <video> support; nor has Microsoft.

Flash supports H.264 in its .flv container format, and MP4.

The bottom line: if you use H.264 video with AAC audio in an MP4 container, you support Chrome, Safari, mobile devices from Apple, Google, and others, and Flash (9.0.60.184 upwards). With the Flash support, you can then serve the same file to IE, Opera, and Firefox as you serve to the others, using the fallback mechanism specified by HTML5. If you want to give Firefox users native HTML5 video, you have to re-encode the content using Ogg with Theora video and Vorbis audio.

[VectraMan]

HTML5 doesn't prescribe specific codecs.

Well that's just stoopid. What's the point of having a standard if you don't know what format to encode your video in, or worse have to write browser specific code to access different formats?

The main benefit of Flash is that it works the same everywhere, regardless of what it's running on or relying on codecs installed on the host OS. HTML5 video can't be said to replace it if the same isn't true. As you say you have to encode the same video three times to support the common browsers (and who's to say another might not do something different again?).

I think the non-HD Youtube video is On2 VP6, which is something that's been built into Flash for a while.

[NickFitz]

Well that's just stoopid. What's the point of having a standard if you don't know what format to encode your video in, or worse have to write browser specific code to access different formats?

The specification of the <img> element doesn't prescribe what format your image files should be in. This proved to be a good thing, as it meant support for new image formats such as PNG and animated GIF could be incorporated into browsers without having to either go back and rewrite the standard, or implement non-standard support. Who knows what amazingly efficient video encodings may become available in the future?

As you say you have to encode the same video three times to support the common browsers (and who's to say another might not do something different again?).

Twice, or once if you use Flash for those browsers that don't (yet) support H.264 natively. Even Mozilla may support H.264 one day: remember, GIF used to be patent-encumbered too.

[VectraMan]

Twice, or once if you use Flash for those browsers that don't (yet) support H.264 natively. Even Mozilla may support H.264 one day: remember, GIF used to be patent-encumbered too.

Did you edit your post to include that Flash supported MP4 containers? I didn't know that - okay, two formats. Two is bad enough, and if Firefox users start refusing Flash, there'll be no other way but to provide two copies of everything.

Regarding image tags, PNG's adoption was very slow, in fact the web is still full of creaky old 256-colour GIFs that would be much better as PNGs or MNGs. Perhaps if the format had been part of the official standard, web designers would have been more inclined to rely on it. As it is doubts over browser support means we end up with the lowest common denomonator.

[NickFitz]

Did you edit your post to include that Flash supported MP4 containers? I didn't know that - okay, two formats. Two is bad enough, and if Firefox users start refusing Flash, there'll be no other way but to provide two copies of everything.

I mentioned it in the final paragraph, but missed it from the penultimate one - that was the edit.

A good proportion of Firefox users already use a Flash blocker; it shows you that Flash content is available, and if it's something you actually want to see rather than an ad, you click on it to load it. I think the better ones would also allow you to whitelist sites, or possibly even specific Flash-hosting servers.

Regarding image tags, PNG's adoption was very slow, in fact the web is still full of creaky old 256-colour GIFs that would be much better as PNGs or MNGs. Perhaps if the format had been part of the official standard, web designers would have been more inclined to rely on it. As it is doubts over browser support means we end up with the lowest common denomonator.

The point is that the <img> element was specified in HTML 2.0 (Sep 1995) before PNG was (Oct 1996), so it couldn't have been part of the standard if the standard specified particular file formats.

The fact that there's a lot of legacy content using GIFs is irrelevant, just as the existence of HTML 3.2 or even HTML 2 legacy content is irrelevant to the adoption of HTML 4.01. PNG's adoption was actually pretty rapid, the main issue being IE6's lack of support for alpha transparency without various wretched hacks. Most web designers/developers of my acquaintance were using PNG as their preferred format in the early 2000s or even the late 1990s (except when JPEG made more sense, obviously).

[NickFitz]

Opera have just published an article by Bruce Lawson and Patrick Lauke (who are both jolly good chaps and worth going out on the ale with) about Opera's forthcoming support for HTML5 <video>. It does a good job of explaining the current cross-browser state of play, and includes a link to Kroc Camen's excellent article Video for Everybody! which explains in exhaustive detail how to implement QuickTime and Flash fallback purely in HTML (no JS required).

[VectraMan]

Just been having a look at the HTML5 on YouTube in Chrome (obviously Firefox doesn't work). I finally found something in HD to compare with Flash in IE, and not suprisingly they worked more or less the same. The volume control is broken for HTML5, and there's no full screen option (why - isn't that an obvious thing?), and Chrome was using slightly more CPU than Flash in IE. Seeking was generally much slower, and in fact I crashed it completely by trying to seek.

DailyMotion has HTML5, they even have the cheek to say:

The future is open. To watch this video without a proprietary plugin, download a more advanced browser.

Which would be nice except when you look at the HTML5 version it's strinking how much lower quality it is than the Flash equivalent That does work in Firefox, so they must be using Theora.

Also found this:

http://www.osnews.com/story/19019/Theora-vs.-h.264/

This guy doing a comparison of H264 vs Theora, and the latter is noticeably lower quality, especially when the camera pans. Interestingly Theora also took twice as long to encode - odd because normally higher quality means longer encoding times.