Controversy has erupted in the past few months regarding the future of video over the Internet, in particular the refusal of Apple to authorize deployment of an Adobe Flash decoder for their iPad and the iPhone product lines.
In an open letter published in April, Apple CEO Steve Jobs gave a lengthy explanation of "why we do not allow Flash on iPhones, iPods and iPads." In place of Flash, Apple is promoting a new standard for video files called HTML5. In this column, we'll take a look at how this emerging standard might impact broadcasters who distribute content over the Web.
It's important first to understand what HTML5 is not. It is not a new video compression algorithm like H.264 or Dirac. It is not a new container format like MP4 (MPEG 4 Part 14), AVI (Audio-Video Interleave) or 3GP (used for 3G mobile phones).
It is also not a radical departure from what has come before, as it is built upon HTML and XML, which are two versions of the markup language that are used everywhere on the Web today.
WHAT IT IS
So what is HTML5? It is a new method for delivering instructions to Web-enabled devices about how to handle video content.
Many of today's browsers (Apple's Safari, Mozilla's Firefox, Google's Chrome) and ones that will be coming on the market in the near future (Microsoft's Internet Explorer 9) offer native support for video. This means that built-in support will be provided for decoding some types of compressed video within the browser itself, not requiring a plug-in such as Flash or Microsoft Silverlight to be installed.
For example, Safari, which is available for Mac and Windows operating systems, has native support for H.264 built into the browser's native code, as does Chrome. Firefox doesn't support H.264 internally (due to the natural reluctance of the open-source community to use a patented technology like H.264), but it does natively support another video codec called Theora, which is also supported by Chrome and by the VLC media player program.
So why the switch? Well, Mr. Jobs has a lot of reasons, but for most companies the key is open standards. While Adobe claims overall desktop penetration of their player at 98 percent, Flash is still an Adobe-exclusive product. So companies like Apple and Google might consider it to be in their best interests to find a way to offer an alternative to Flash. And, in HTML5, they may have found it.
To see how HTML5 works, look at Fig. 1, which shows how a video file could be configured for playback over a Web connection. In this case, the video has been compressed with H.264 Main profile, and the audio is compressed using low-complexity advanced audio codec (AAC).
Fig. 1: HTML5 in action, showing Web server, HTML5 code fragment, and Web page as displayed on portable device. These two content elements (shown in pink in the diagram) are then combined into an MP4 container (shown in yellow), which also contains other data that is useful in the streaming and playback operations. This other data might be a hint track that helps a streaming server determine how to packetize the video and audio files; or it could be metadata about the file or other useful stuff. This container (really a file) is then stored on a Web server until the user's browser requests it.
Continuing with Fig. 1, the user's browser needs to be told how to find and process the container with the audio and video content. That's where HTML5 comes in, with a set of instructions that are embedded in the code for the Web page that the user is viewing.
Note that, as with many Web media applications, the website that delivers the HTML5-coded webpage to the browser can be separate from the server that delivers the media content, as shown in this example. The HTML5 code can be written so that the video will automatically start playing when the user browses to the page, or it can be written to require the user to hit a play button.
It may be interesting to note that currently Apple's handheld devices ignore the parameter, thereby preventing users from consuming mobile bandwidth until they hit the play button.
IMPACT ON BROADCASTERS
The good news about HTML5 is that broadcasters don't necessarily need to purchase a new set of compression devices if they are already using H.264. This is true for some of the big Web video providers (such as YouTube) who are already encoding their content using H.264.
Of course, some tool changes will still be required, because many Web video streaming systems are based on Flash scripting. In the near future, these tools will also need to support HTML5, particularly if they are going to be useful for producing content for Apple's portable devices.
One major issue for HTML5 deployment is the current lack of a Digital Rights Management (DRM) capability. While the popularity of DRM-protected content has never been high with end users, many content owners are uncomfortable publishing their video assets on the Web without some form of protection against unauthorized redistribution of content.
This is particularly important for sites that charge user fees for content access, such as the forthcoming Hulu Plus service, which will be offering entire seasons of some popular network programs. For broadcasters, who may hold only limited rights to the content that they are streaming, delivering video streams that are not protected by DRM may simply be out of the question. In these cases, broadcasters may need to stick with Flash until or unless DRM is deployed for HTML5.
For the near future, many Web content providers will probably use some combination of both HTML5 and Flash video. This can be done quite simply, by embedding Flash video instructions as an
