This question was made over 9 years ago. It made sense then, it doesn\'t make it now. Flash is hard on its way out; sup
Flash is a real headache on non-Windows platforms. Not only is it slow and inefficient (as someone else pointed out), but it isn't very stable, either. As we learned at the most recent Apple WWDC, "browser plugins" (read: Flash) account for the majority of all application crashes across all of Mac OS X (and by "majority", I mean some absurdly high number like 80% or something, can't remember the exact figure offhand). This is such a problem on Mac OS X that for Snow Leopard, Apple has re-engineered Safari so that Flash runs, not just sandboxed, but in fact as an entirely separate process, so that when (not if) Flash crashes, Safari as a whole remains unaffected.
The instability of Flash on OS X, coupled with its poor performance, is why...
As far as users having to know anything about codecs is concerned, you can avoid this issue and serve them the appropriate codec (including Flash, if their browser doesn't support OGG or h.264) by using the simple non-Javascript html code found in this article.
One Con is the fact that the current html 5 spec has not been able to agree on a single codec due to browser vendor dissagreement.
From the article below:
"After an inordinate amount of discussions, both in public and privately, on the situation regarding codecs for and in HTML 5, I have reluctantly come to the conclusion that there is no suitable codec that all vendors are willing to implement and ship"
Browser vendor squabble
Ultimately, even if you do use the video tag, your video codec may not be supported in all browsers, even if they do support the tag.
As others have mentioned, this may not pose any real issue, but I believe having to make multiple versions of the same file available certainly negative.
There are many good points here, and like a Martial Arts fighting style, each point has its thrust, and each can be defended; but each can be defeated with the proper moves.
Anyone standing on arguments about "propietary" plugins will fall quickly. Microsoft, Apple, and Adobe all bear the guilt, but that's just BUSINESS. You won't change business overnight, and each layer of complexity added by a new tag such as <video> which supports a very technical interface will result in * slightly * different implementations by each browser.
HTML 5 works now, and so does Flash. How it is implemented, the skill it requires- this defines each resource, whether it's an employee's performance, a webmaster's power, or a domain's influence.
Although I'm only 40, I began programming when orange or green monochrome monitors were the color choice, and hardware installation came with prayer books instead of instruction manuals. Maybe you could figure out AT commands for the modem when it wouldn't configure with your hardware, and 64K RAM was like, WOWWWWW!
HTML 5/Flash is a minor nuisance compared to that crap. Let's all learn how to collaborate in community toward a better resource. There is an Open Source Flash Project, it will have bugs. So will HTML 5...
Every argument here is true, but not necessarily productive. Use that energy toward a solution.
Flash is controlled by a single company. That company can decide exactly what to do with the future of Flash and nobody else can affect it. Let's say, for example, that they (Adobe) suddenly decide charging a license fee for using Flash. What would happen to all the millions of web sites depending on it?
We need taking action, and that is now. We must use open standards, and we do need it badly. That's the only thing that makes the tag bleeding important to the world.
(Licensing fee for Flash might or might not seem like a realistic move from Adobe, but that does not matter. My point is that they are in control. Another thing that could happen is that Adobe decide to cancel Flash. Imagine what would happen then, if there were no tag.)
More pros for Flash:
Adobe can add new features and new codecs to video a lot quicker to a mass audience (generally under a year over 90% of users upgrade to the latest version of Flash) compared to browser vendors (there's still a large number of IE6 users out there and that browser came out in 2001).
Features found in Flash that I imagine will eventually make it to browsers but are not there yet:
As those who say Flash is not indexable, check out what Google has been doing lately with indexing Flash content thanks to a headless player Adobe has supplied. So if you do a google search for FLV files, you can see that Google already indexes Flash video files.
Meanwhile, Adobe Premiere CS4 has speech recognition that will output subtitles for video files in an XML format that can be easily used in Flash video. So expect video for Flash to become a lot more searchable in the future.
The biggest benefit of <video>? It's easy. Crazy easy. Ridiculously easy. Your-grandma-can-code-a-video-tag easy. <video src="myfile.ogv"></video> and you're done.
<video> also has clear benefits for your users. They get a browser-native video player, which can potentially be very efficient. They get a consistent UI that won't change from site to site. Mobile browsers that may not implement flash can still implement <video>.
The only con is a temporary one, and that is compatibility. IE8 doesn't support <video>, and it will be some time before IE9 is widely installed. As well, there's some fight over which codecs to support for the videos - Firefox, Chrome, and Opera all support both Ogg Theora and WebM, while Safari and IE are shipping H.264 (though either can support Theora/WebM with proper codecs). For now, this just means that you have to post your video in two formats and provide them both with the source element, i.e.:
<video>
<source src='video.webm' type='video/webm'>
<source src='video.mp4' type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'>
</video>
To add support for IE 8 and earlier, and other downlevel clients (like older versions of FF/Safari/Opera/etc), just put your standard video embed code inside the <video> tag, below the <source> elements. If the browser supports <video>, it'll ignore the embed. If it doesn't, it'll ignore the <video> and run the embed instead.