That is because it is the consumer electronics video standard. It’s essentially an online CD/DVD. The whole point is to be universal or it doesn’t work.

FlashPlayer 9 and FlashPlayer 10 video is also encoded in ISO MPEG-4 H.264/AAC, same as everybody else, so the video codec is not an issue. Anyone who tells you the codec is an issue either doesn’t know about audio video or has a proprietary codec to sell you.

Again: the video codec is not an issue. If you are publishing audio video and you want people to be able to see and hear it, use MPEG-4 H.264/AAC. Other encodings are not consumer video, they cannot be played outside of authoring environments on a Mac or PC. If you use another encoding you are essentially making video that only plays in video editors, not video players. You’re cutting 95% or more of your audience out of the loop.

The only outstanding issue in online video is who makes the video player that plays your inline video in the browser, and what language is the player controlled with? W3C will tell you the browser maker makes the player and it is controlled with HTML5 (which includes JavaScript and CSS, you don’t have to mention them separately) and there are specific API’s for controlling the video playback in HTML5, which runs on everything. Adobe will tell you that they make the player, and it is controlled with ActionScript3, which also has API’s for video playback, but which can only be made with their tools, and which only runs in one app from one vendor and then only on Mac and PC. Adobe is offering very little aside from confusion.

> The downside with HTML5 video as it stands is that there is no set standard
> for which video codec

No, that is not a downside. HTML5 is a Web app standard, it is not an audio video standard. Audio video standardization is outside the scope of HTML5, which describes how to markup video, not how to encode it. It is not now and has never been the job of W3C to choose the chips that go inside an iPod or Blu-Ray player, it is not their job to tell a movie or music maker how to encode their final product. W3C decides that the video tag should be called “video” and what attributes it can have, and how it can be nested to create valid markup, and how a browser should react to that video tag in various contexts. W3C does not have audio video experts, they are not a replacement for Motion Picture Experts Group, aka MPEG. MPEG is to audio video what W3C is to Web apps. MPEG decides what codec will be burned into the video decoder chip in consumer electronics devices, which do not have big PC-style CPU’s and cannot run arbitrary codecs like they are software apps. Just as your DVD player has an MPEG-2 decoder chip in it, your Blu-Ray player has an MPEG-4 decoder chip in it. (There is no MPEG-3 because the name would be confused with MP3, which is either MPEG-1 audio layer 3 if it is under 128 kbits or MPEG-2 audio layer 3 if it is 128 kbits and up.)

And just as there are now passionate debates about how the markup in HTML5 should look by Web developers and browser makers, 10 years ago there were equally passionate debates about MPEG-4 by audio video developers and consumer electronics manufacturers. MPEG-4 was delayed for 6 months at one point because a “content tax” was added, obligating music and audio publishers to pay a fee per item they publish. That is an old scam that technology people keep trying to pull, and Apple refused to implement MP4 until the content tax was removed.

The idea that a bunch of Web developers come in 10 years after MPEG-4 and say no, we’re not participating, we’re not going to play all the existing video from YouTube and iTunes, we’re going to do something else is ridiculous because then you’re saying YouTube is not part of the Web. Google did a study and found that if YouTube were in Ogg codec, the Internet would not have enough bandwidth for them even if they were the only website. Never mind the CPU time required to do that conversion from MPEG-4 to Ogg at this point.

Also, Web developers and W3C have to have humility when it comes to standardization because HTML standardization has always failed, while MPEG standardization has always succeeded. We did not make HTML4 apps during HTML4, we made IE apps. During HTML3 we did not make HTML3 apps, we made Netscape apps. Here we are in MPEG-4 and it’s in both QuickTime and FlashPlayer, it’s in both iPod and Zune, it’s in both YouTube and iTunes, it’s in iPhone and Android and other smartphones, it’s in Blu-Ray and the DVD-ROM’s that have HD video on them. It’s frickin’ everywhere. HTML5 has the potential to be the first truly successful markup standardization. Let’s see W3C and Web developers and browser makers focus on that and if you are successful, you’ll certainly have serious input into MPEG-5 and get it done in such a way that it is even more Web-friendly than MPEG-4.

But the idea that browser makers have something to teach consumer electronics about standardization is a case of STFU if ever there was one.

> FLV conversion could be a task of the past.

It has been a task of the past since 2008 and FlashPlayer 9, which uses MPEG-4 H.264/AAC video. We are on FlashPlayer 10 now and 11 coming soon. You can create one MP4 and serve it to Mac/PC in FlashPlayer and to every other kind of device as a plain hyperlink under the FlashPlayer movie. The one MP4 video file already plays everywhere. The codec is not an issue. The issue is just how the inline video is presented. So you have no excuse for the fact that your video is not playing on iPod and iPhone and other smartphones and media players. They are easy to support along with FlashPlayer with only one source MP4 media file. The time you are waiting for is already here.

> My main point is that video online is now more than just a box for the stream
> to play in.

You’ve hit a key point, but have it backwards by promoting FlashPlayer as the solution.

If you cut a hole in the browser and show FlashPlayer or other plug-in, you always have a box for the video to play in and that is all. The rest of the Web page is another application, a separate environment. In HTML5, you do not cut a hole in the browser to show video, you create a video tag with DOM Scripting just as you would create an img tag or other Web page element, and control it with the same techniques you would use to control a slideshow or rollover button or any other interactivity in the browser. So the video is actually part of the entire Web page. The controls can be anywhere on the page, they can look and feel just like the websites navigation bar and other interactive elements. The video can respond to or trigger any event within the Web app.

So if you want more than just a box playing video, you have to put the video natively into the Web app with HTML5. The first time a Web developer experiments with this and realizes that DOM Scripting now does interactive audio video their eyes light up “wait a second!” there are thousands of untapped possibilities.

> Advanced interactivity is expected, demanded now. At the moment,
> only Flash and Silverlight seem to have that capability (and the tools and scripting
> languages to go with it).

No. HTML5 very specifically has an API for controlling audio and video. That is how you create the play button, the time slider, the progress bar, and other controls that we typically see in a FlashPlayer video player. As I said, because these elements are native within the Web app, they not only interact with the video, but they can interact with any other element of the Web page. You can have the website’s navigation and logo go translucent when “Play” is pushed, you can have all of the elements of the Web page respond in some way to what is going on with the video. It’s all in one environment.

Apple has been criticized for a few years now because the interactivity for QuickTime Player has been getting extremely crufty and there was no attempt to improve it. The reason is that Apple internally decided long ago to support HTML5. Essentially, Apple’s interactive video focus moved from QuickTime Player to Safari. Now, interactive audio video is done just like interactive slideshows and rollover buttons. There are millions of people who can already author it and already have the standard Web development tools.

> Really? Got an example of advanced interactivity with video

All of the video on apple.com is done in HTML5, which contains interactive video API’s. HTML5 also has vector graphics, 3D graphics, and in Safari that is all GPU accelerated so that it currently runs much faster than the equivalent presentation in FlashPlayer while taking less CPU power and less battery life. This stuff is still fresh but the sky is the limit because it’s Web native. All the Web tools and techniques now apply automatically to audio video.

Another example is iTunes LP and iTunes extras. They are all HTML5.

Keep in mind that within FlashPlayer all you have is ActionScript and an API. When you click on a play/pause button in FlashPlayer, an ActionScript event fires and a function is called. When you click on a play/pause button in an HTML5 Web app, a JavaScript event fires and a function is called. With HTML5, this extends to include every element in the page, not just the elements within the FlashPlayer window. In practice it is easy to do many things in HTML5 that are either hard or impossible with FlashPlayer.

> With the slow rendering of a lot of browser of JS

JavaScript in Safari or Chrome is faster than ActionScript in FlashPlayer, and native browser content is GPU-accelerated in many cases and FlashPlayer is not.

The same interactivity can be used with JavaScript you don’t need freakin’ Flash to play it.

Really? Got an example of advanced interactivity with video (incl. things like fullscreen, live scaling, vector graphics, typography, etc.)? I’d love to see it. With the slow rendering of a lot of browser of JS, that might trading one evil for another. Of course, you can do amazing things with JS these days (280slides.com, etc.).

I’d be the first to agree that when a user just wants to play a video – no other interactivity required – a basic “video object” would be nice. But, that’s not the only use case – am I right?