HTML5 Video Guide – All You Need to Know for 2014

HTML5 video has been a hot topic for the last few years, but even though it seems to be conceptionally easy with simply an additional HTML video tag, there are important basics to consider before using it. If you are new to online video, I would recommend reading my beginner’s guide to online video first.

This guide will go through important components required for online video experiences, and map them to HTML5 capabilities. When making decisions for your users, you need to understand what’s important to them, and select the best user experience. This guide will specifically not focus on Flash. Even though it is practically the best option for video delivery on the desktop, this post is primarily dedicated to HTML5 video.

What you need to consider

• Video codecs
• Fullscreen support
• Adaptive Streaming
• Content Protection / DRM
• Mobile browser vs. Desktop
• Future

Video Codecs

The standardization of video codecs is not covered by the HTML5 video specs. Ian Hickson, maintainer of the HTML5 specs, wrote in 2009.

After an inordinate amount of discussions, both in public and privately,  on the situation regarding codecs for video and audio in HTML5, I have reluctantly come to the conclusion that there is no suitable codec that all vendors are willing to implement and ship.

I have therefore removed the two subsections in the HTML5 spec in which codecs would have been required, and have instead left the matter undefined, as has in the past been done with other features like img and image formats, embed and plugin APIs, or Web fonts and font formats. [more on whatwg]

The challenge of finding a standard video codec is described in my previous article. Meanwhile, the following table summarizes the current status.

With H.264 as the most used video codec on the web, it is possible to use H.264 HTML5 video in browsers where supported, and fall back to Flash video in browsers where it is not supported. Video.js as example allows this fallback, while using javascript for the UI.

Another alternative is to specify multiple video files in the video tag.

<video width="320" height="240" controls>
  <source src="movie.mp4" type="video/mp4">
  <source src="movie.ogg" type="video/ogg">
Your browser does not support the video tag.
</video>

The disadvantage of this approach is the need to maintain different encodes of the same content, which increases encoding time and storage costs. Which is acceptable for a small library, could become a burden for a larger content library.

Fullscreen support

Fullscreen support is critical for a good user experience. Currently in the W3C as a living specification, it is slowly becoming available across all browsers, with even Internet Explorer 11 starting to support the fullscreen API. Fullscreen support is crucial for a good user experience.

Adaptive Streaming

For details on available adaptive streaming formats, I am referring to my online video introduction blog post again. You don’t always need adaptive streaming, but it’s increasingly popular given the variety of connection speeds, and the user’s desire for interruption free HD web experiences.

Same as with codecs, there are no adaptive streaming format defined in the HTML5 specs, which inevitably leads to fragmentation.

Apple’s HLS is available on Apple’s Safari and iOS devices via the HTML5 video tag, while MPEG-Dash is currently available in Chrome and Internet Explorer 11 via the MediaSource Extensions.

It’s possible to deliver different adaptive streaming formats to different browsers, and fallback to Flash delivery in browsers without support, but it leads to a fairly fragmented workflow.

On specific platforms, such as Windows 8.1 or Chromebooks, it is possible to take advantage of MPEG-Dash, which Netflix is currently testing. In addition, many mobile websites deliver HLS video to users on iOS devices. As example, Apple’s live streaming events are delivered with HLS to Safari and iOS browsers only, which (only) works well for their core audience.

Content Protection / DRM

There are two categories of content protection available for HTML5 in conjunction with adaptive streaming formats. AES-128 clear key encryption for HLS, and DRM implementations with Encrypted Media Extensions for MPEG-Dash – the former is not considered DRM, while the latter is. The allowed browser DRMs are currently determined by the browser manufacturers, similar to the choice what codec to support – with the major browser manufacturers owning their own proprietary DRM solutions, the HTML5 unification of DRMs across browser will remain a challenging task for quite some time.

Mobile Browser vs. Desktop

The definition of HTML5 video for desktop and mobile is often leading to some confusion when it comes to the underlying video capabilities. As example, HLS playback is only available on iOS and desktop Safari, but not on Android and the majority of desktop browsers. Meanwhile, MPEG-Dash is not available in the iOS browser. Progressive download is the unifying HTML5 video delivery format across desktop and mobile.

Future

The current state of HTML5 video can be summarized as suitable for progressive download when accepting the fragmentation challenges, but it is still highly fragmented and divided when it comes to advanced streaming protocols and content protection/DRM. But as with every standardization process, dynamics are changing quickly, and 2014 will define the direction of MPEG-Dash and cross-browser DRM solutions.  Meanwhile, Flash Player is adding both DRM enabled HLS and MPEG-Dash native support, which will help create simpler video workflows across 99% of all desktop browsers.

Interested in MPEG-Dash knowledge exchange? Join the MPEG-Dash group and forum.