Our State of HTML5 Video Report is a place for us to share with other developers/users in the industry just what HTML5 can and cannot support.
In developing the JW Player, we perform routine tests to help determine the current state of online video. This report focuses on the current state of HTML5 support and as we continue to build out our products, we commit to publishing our up-to-date results here. In hopes that the rest of of our community benefits from our findings, we grouped our test results into the few topics we find to be the most critical for online video.
As HTML5 Video evolves, so will this report. If a browser or device gains traction, we will be sure to add it here. The same goes for those features of HTML5 Video that are not widely used yet. We hope to hear from many of you, and that you join the HTML5 discussion on our
1. Market Share of Browsers and Devices
We kick off this report with the aggregated data on the market share of each browser and device, and the modes they currently support. It is often difficult to get a solid snapshot of this, due to the major discrepancies between the two leading data sources, StatCounter and NetMarketShare. Market shares also vary greatly between different geographic locations.
|Browser/Device||Market Share||HTML5 Support||Flash Support|
|Internet Explorer 6/7/8||28%|
|Internet Explorer 9||9%|
|Other (mostly feature phones)||4%|
2/3 of the market is already supporting HTML5. That being said, there is still a need for Flash. On the desktop, Internet Explorer 6/7/8 make up a large pecent of the market share (28%), and are here to stay for a few more years. Since they do not support HTML5, alternatives like Flash remain critical for video playback. As for the other browsers, their entire install base is already supporting HTML5 video.
Mobile phones and tablets have emerged as a new category over the last few years. Currently, only the iOS and Android market shares are relevant. Both support HTML5 video. Android still supports Flash, but as announced recently, future phones will not have the plugin anymore.
Connected TVs and settop boxes are not yet a factor. Popular devices (XBox, PS3, Apple TV, Roku) have neither web browsers nor app markets. This may change in 2012 as Apple and Google roll out new products.
2. Media Formats
One of the biggest challenges with HTML5 is the fragmented support for audio/video formats. Here’s the current breakdown for HTML5 mode:
|Browser/Device||Video formats||Audio formats||Multiple sources|
|Chrome||MP4, WebM||AAC, MP3, Vorbis|
MP4 support may drop dramatically when Chrome officially drops MP4. Although this was announced back in January 2011, it still not happened, which makes it hard to predict.
Both iOS and Android only support MP4 video. This will remain the case for any mobile device, until WebM decoders are built into hardware and integrated in to phones. See the WebM blog for progress on that effort.
Every browser supports the tag for loading multiple sources. Our tests show that including the type attribute prevents some preloading, but breaks compatibility with Android 2.2. Setting the codecs in the type attribute has no impact in any browser.
We have not included the Ogg video format in our tests. This format is barely used and of lower quality than MP4 and WebM. Firefox 3.6, which is quickly fading, is the only browser version that supports Ogg but not WebM today (5% market share in December 2011).
3. Tag Attributes
The HTML5 video tag supports several attributes, and most are already supported to date across the various browsers and devices. Next to the width, height and src, these are:
Firefox has not rolled out support for loop yet, but otherwise the tag attributes work on the desktop. Note that the brand new attribute muted is not yet widely supported, but we predict that soon it will be.
The mobile browsers ignore preload, autoplay and muted, but iOS 5 started supporting loop. Another difference between iOS 4 and 5 is that iOS 4 always preloads video using several range requests, while iOS 5 never preloads the video.
The video controls of each browser look different, but provide the same options: a play/pause toggle, a position slider and a volume slider. Safari provides 2 additional buttons: fullscreen and 30-seconds-back.
The video controls on mobile devices differ greatly from those on desktop browsers:
- On the iPad, controls are still quite similar, though there is no volume slider (volume is set with hardware buttons). As in Safari, there is a fullscreen button.
- On the iPhone, only a round play button in the middle of the poster is shown. When clicking, the video starts playing fullscreen. When exiting fullscreen, the round play button appears again.
- On Android 2.3, a control bar is displayed. The small play button must be clicked to trigger playback; clicking the poster does nothing. Though not as broken as Android 2.2, this is still a major UX issue.
4. Fullscreen Playback
While a minor feature at first sight, fullscreen playback is essential to the success of HTML5 video. Fullscreen video enhances the visual experience and increases viewer engagement. HTML5 support fullscreen playback is still in its infancy, as seen in this table below:
|Browser/Device||Fullscreen control||Fullscreen API||Object fitting|
Fullscreen support using built-in controls is scattered across the various desktop browsers. Firefox has a right-click menu item and Safari a controlbar button. On mobile, fullscreen is widespread. The iPad has always featured a fullscreen toggle, and video playback on the iPhone/Android is always fullscreen.
The W3C recently started working on a fullscreen API specification. Using this API, it is possible to render any HTML element in fullscreen, so custom controls can be added over/around a video. Safari and Chrome support this API in their latest versions, using the webkit vendor prefix. A similar implementation (using moz) will land in Firefox 10.
The aspect ratio of a user’s monitor is often different from that of the video element. Therefore, the ability to control how the video will fit to the screen is also important. On iOS, a built-in control is available to toggle between having the video contain and cover the screen. On Opera, the CSS3 object-fit property can be used to achieve the same. In other browsers, the video is always scaled to contain the screen.
5. Adaptive Streaming
Adaptive streaming is a core component of online video. It enables buffer control, mid-stream quality adjustments, live/dvr streaming and security through encryption and/or DRM. Adaptive streaming is not part of the HTML5 specification, but browsers can support it by loading manifests from an HTML5 <source> tag. Currently iOS is the only platform with adaptive streaming support in HTML5:
|Browser/Device||Apple HLS||Quality metrics|
Apple’s HTTP Live Streaming protocol is currently supported on Safari/iOS. Android has preliminary HLS support too, but it is still too buggy & new to be of any use. MPEG DASH is the protocol developed by MPEG to standardize adaptive streaming. It is brand new and not yet supported by any browser.
In order to actually measure and/or influence adaptive streaming behavior, QOS metrics must be made available. Several proposals float around W3C/WhatWG, but to date only Firefox has vendor-specific support for the number of frames parsed, decoded and presented.
Note that every HTML5 browser supports seeking to not-yet-downloaded portions of the video by using HTTP 1.1 range-requests. This reduces the need for adaptive streaming, as it enables seeking in longer-form videos.
None of the browsers support fully-featured accessibility in HTML5. Since HTML5 is native to browsers, it can achieve a greater level of accessibility than plugins like Flash. In order to make a video accessible it must be controllable using the keyboard, and must render closed captions and audio descriptions. The latter are enabled through the HTML5 <track> element. The table below outlines the state of keyboard & text track support in HTML5 mode, across the various browsers and devices.
|Browser/Device||Keyboard access||Text track support|
HTML5 Video elements can be controlled using the keyboard on IE, Firefox and Opera. IE/Firefox focus the entire video tag at once, using SPACE to play/pause the video, plus LEFT/RIGHT and UP/DOWN to control seeking and volume. In Opera, each individual control can be focused through tabbing.
Though being actively developed, HTML5 Text Track support has not yet landed in any browser. However, every browser has some type of beta version with preliminary <track> support. Once Text Track support lands in a production browser, we’ll update this section with more details and improvded test cases.
The the HTML5 Video specification defines two alternative ways to playback closed captions – subtitles and descriptions with video elements. The first one leverages videos with multiple inline audio/video/text tracks. The second one leverages the synchronized playback of multiple <audio> or <video> elements. No browser has yet committed to implement either of these mechanisms.