Bringing Five Alive: Best Practices for HTML5 Video Deployment

HTML5 equips organizations to leverage open standards and stream videos without depending on a third-party player or plug-in. An MPEG/H.264, Ogg/Theora, or WebM/VP8 video can each be played in the standard web browser, whether it is a PC, Mac, Linux, iOS, or Android device.

This gives businesses the opportunity to have a media strategy targeting all popular platforms and devices rather than having to create a separate model for each. HTML5 presents this opportunity, with its pros and cons, for businesses to capitalize on and to reach out to their viewers across multiple formats and multiple platforms.

Technically, HTML5 defines a simple way of doing this using the video element. However, the support for this element is not ubiquitous, and it can be daunting at times to understand its benefit as well as its implementation.

The purpose of this article is to introduce best practices for using HTML5 video. The target audience for this article is business and technical users alike. The prerequisite is some background working with videos and a desire to create the best viewing experience.

These best practices will help businesses understand technology, develop the right media strategy, and provide robust applications for happy viewers.

The Big Picture: Why HTML5?
For an online media presence, an organization requires a rich website that displays regular content, RIA (rich internet applications) content, and media content. While regular content is rendered in standard HTML, the other two parts come with options. Both Silverlight and Flash provide frameworks for developers to create RIA, as well as build video players to stream video content. For operating systems such as iOS and Android, there’s the Apple SDK and Android SDK. This requires businesses to learn each SDK, analyze each target screen (computer, mobile, STB) separately, and develop and maintain separate code bases for each.

HTML5 is an attempt to provide an alternative, in part or in full. It will be possible to provide RIA content as well as media content in HTML5 natively without installing third-party runtimes. Note that this doesn’t imply that it’s always the best choice, but it does provide a common denominator.

The most interesting aspect of HTML5 is how best to use its ability to play media content in web browsers. The impact of HTML5 here is highest and will be a primary focus of this article. The rest of the article will list best practices that can be both strategic and technical. While it’s not necessary to read them all, it is nevertheless recommended to get a holistic view. At the end of the article, there’s also a link to a sample demo site that depicts some of the concepts in this article. (The code can be reused freely; I’d appreciate a note with any comments.)

Future of HTML5: The Ecosystem
In reality, much of HTML5’s success will be governed by how the ecosystem evolves between Adobe, Google, W3C (World Wide Web Consortium), Microsoft, Mozilla, MPEG LA, etc. While W3C ultimately defines the spec of HTML5, it is up to the organizations that provide browsers, codecs, frameworks, and applications to drive the usage and popularity of technology.

There are both pros and cons as to how the industry has thus far adopted HTML5. Let’s review some facts:

• While Silverlight is Microsoft’s flagship choice, IE9 will support HTML5 video. It will be interesting to see how this works out for Silverlight.
• HTML5 spec is authored by a Google employee. Google has also been promoting WebM, which it made open source. Together, this provides a potent alternative for high-quality streaming.
• HTML5 is promoted by Apple. Apple doesn’t support Flash and doesn’t have plans to do so. This is good news for future adoption of HTML5 and the development of new tools around it.
• Adobe plans to support WebM in Flash. It will be interesting to see the impact of the increasingly popular open source codec on HTML5 and on Flash itself.
• The RIA scene is dominated by Flash and Silverlight platforms for media applications on the web. HTML5 still needs to evolve and be more widely adopted. A classic example is SVG (Scalable Vector Graphics), which was released years ago. While it is a powerful graphics tool, its adoption has been quite slow.

When designing a media strategy, it is important to keep these factors in mind and decide accordingly how to target the market. For example, for a large media enterprise, it’s important to have a media presence that works irrespective of the codec, browser, or device. So the enterprise needs to provide applications to its users for maximum reach to avoid any incompatibility arising out of the ecosystem.

HTML, Flash, or Silverlight?

HTML5 is seen as a replacement for Flash or Silverlight, but its effectiveness really depends on what you’re trying to achieve. At times it’s necessary to use a mix of technologies. If a business’ need is to leverage existing applications already built in Flash, the strategy might be to continue to leverage that in addition to adopting HTML5 standards. The technologies become complementary rather than competitive. If a business is starting from the ground up and looking to use open source standards, the approach might be to use HTML5 exclusively. This is quite different from an organization that has already heavily invested in a Flash-based RIA and video player.

What Should My Strategy Be for Mobile Devices?
HTML5 video is particularly important for widely popular iOS devices that do not support Flash. The call for HTML5 is loudest here; in non-iOS devices, HTML5 is only a choice because most of the browsers have third-party plug-ins anyway. Taking the previous example of a business that already has adequate reach on computers using Flash or Silverlight, the business might not need to invest in that area but look for extending HTML5 only on iOS devices.

iOS application developers can use HTML5 to develop video applications instead of the iOS SDK. An HTML5 application can be directly bookmarked in the device and provide video playback, just like a normal App Store application. This gives better control in the player’s functionality, providing features such as sharing with social networks and viewing ratings. A visit to YouTube’s HTML5 site is exemplary to this fact.

What Kind of Container Formats Should I Target?
HTML5 video comes with its pros and cons. Until its adoption is ubiquitous, there will be no single browser that supports all codecs. Unless the target device only runs iOS, videos should be encoded in different formats to maximize the reach.

The three formats that can be covered in most of the browsers and devices are WebM, Ogg, and MP4 for on-demand streaming. For live streaming, WebM, Ogg, FLV, and MPEG TS (transport stream) should provide the necessary reach to all devices and browsers.

How Can I Provide Cross-Browser Compatibility?
The first thing to ensure is that the browser supports the video element of HTML5. As of this writing, at least one of the latest versions of each of the major browsers—IE, Firefox, Safari, Chrome, Chromium, Opera, iOS, and Android—supports it. But that's not the case for earlier versions.

Until organizations and users update their browsers to supported versions, the reach is limited because only the latest versions support the video element. Statistically, the installed base of HTML5-compatible browsers is only about 40%–50%. For an enterprise with reach to all screens, it is advisable to have a fallback plan to use other popular players such as Flash. (Note that in 64-bit browsers such as Minefield, HTML5 is the only option; Flash and Silverlight don’t support 64-bit browsers as of this writing.)

Here’s the current 32-bit browser support per container format for the browsers that I tested and that didn’t require the installation of a plug-in (I didn’t test IE, so I haven’t included it here):

If the target is Firefox, Ogg and WebM are supported. But if the browser is Safari, it’s useful to also have the same video encoded in MP4 to provide a fallback option to playing Ogg. Also, as can be seen, between MP4 and Ogg or MP4 and WebM, all browsers are covered. If the browsers in question are not the latest ones, then it’s best to have videos encoded in all three formats with cascading fallback options.

If encoding videos in different formats is not an option, it’s best to detect the support, which can be done in several ways (see the demo at http://iberindia.com/demosite/html5/html5demo1.html) and display an alert or a message using the following code on the screen:

Depending on the HTML5-compatible browser, this line of code should automatically fall back to the error function if the video element is not supported.

The JavaScript compatibility between browsers could also be an issue. Just as a well-designed site works in any browser, HTML5 designers should take care that the code is well-tested and exhibits the same results in all supported browsers.

For applying advanced features, such as playlists, subtitles, and sharing on social networks, further programming using JavaScript and HTML will be needed until the video element evolves to support this natively. Note that even the basic player’s look and feel might appear different in each browser.

The video element comes with standard controls such as play, pause, and volume. It is possible to customize these using JavaScript and HTML. Using the following code, for example, it is possible to have an extraneous button play the video:

How Can I Build My Media Experience Using Only Open Source?
For many organizations, there might be a need to use only open source technologies. HTML5 opens doors to this possibility. The largest impact is an alternative to H.264 that attracts royalty through MPEG LA to distributors and producers. The alternative is to use WebM or Ogg with the video element.

How Can I Provide a Good User Experience?
It is important to analyze the viewership and accordingly plan the video element for a good end-user experience.

Let’s begin with the size of the video. It’s quite simple in the video element to specify the size of the video as it was originally recorded. It is also possible to scale the size down by specifying a new size. However, specifying a size larger than the original can cause a zoom or letterbox effect that might not appeal to the viewer.

If the size of the video on the page is large, then it’s best to specify no automatic buffering using the preload attribute. This allows bandwidth to be saved when the video page is loaded for an on-demand video by not downloading the video as soon as the page is loaded (if the video is live, this doesn’t apply). The case in which it might make sense to have preloading is when the objective of a page is to always show the video. The preload attribute also gives a few other options that can be viewed in the HTML5 specification:

If a site has a single video, the loop attribute can be specified to play the video nonstop (e.g., a corporate video on a company’s website). This attribute would try to download the video as well as play it as soon as the page loads.

Similarly, if the video needs to play automatically when the user lands on the page, it can be done using the autoplay attribute:

In case there is no autoplay or preload attribute, it is good to provide a poster image that shows up until the video starts playing. This can be done using the poster attribute:

Although JavaScript could be used to program the behavior of these attributes, it is useful to have it built in to the video element to avoid JavaScript cross-browser compatibility issues.

The type of the attribute specifies the mime type of the video. It’s good practice to supply as many details as possible here, including the codecs used. If not, some browsers will try to download and decode the video, which can again be bandwidth-intensive and induce a huge latency, resulting in a poor experience for the end user.

Sample Demo Site
This sample demo site shows three VOD files—WebM, Ogg, and MP4. Note that these are not streamed from a server but simply hosted. However, it does depict what is playable depending on the screen. It is best to develop a unified player that falls back to Flash or Silverlight (this is not depicted in this demo site; there are several open source players and frameworks that exist today to allow just that).

What follows are the steps taken to construct the demo site at http://iberindia.com/demo site/html5/html5demo1.html.

• Download sample WebM, MP4, and Ogg files.
• If only one of the codec formats is available, transcode to other formats.
• Create an HTML5 demo page.
• Test this from different screens to analyze behavior, look, and feel.

References

http://diveintohtml5.org

www.chromeexperiments.com

www.youtube.com/html5

http://dev.opera.com

www.apple.com/html5