The State Of HTML5 Video
Contents:
HTML5 has entered the online video market, which is both exciting and challenging for developers in the industry. With the HTML5 specification and the various browser implementations in constant flux, we at LongTail Video spend a signficant amount of time understanding the limitations of the technology and optimizing our own products for HTML5.
In developing the JW Player, we perform routine tests across the various browsers and devices to help determine the current state of online video. The State of HTML5 Video Report is a compilation of our research and latest test results, focused on HTML5 video playback. We are excited to share our findings with other developers/users in the industry as we explore just what HTML5 can and cannot support today. As we continue to build out our products, we will continue to update this report - publishing our up-to-date results here.
We have grouped our test results into the few topics we find to be most critical for online video. An overview of the browsers & devices are discussed below, with detailed links to our actual test pages for a more comprehensive look. 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 that you will benefit from our findings. As always, we look forward to feedback from the online video community.
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. It is difficult to get a solid snapshot of this, due to the major discrepancies between geographies and/or websites. For example, smartphone penetration varies greatly between countries and usage of Internet Explorer is much higher in corporate environments than at home. An analytics package like Google Analytics will tell you the exact breakdown for your site(s).
In this report, we use market data from StatCounter, one of the world's largest analytics firms. We combined their desktop and mobile data into a single report. Roughly 74% of the market now supports HTML5, up from 66% last quarter, when we first published this report. Since IE 6/7/8 do not support HTML5, alternatives like Flash remain very useful for video playback. However, both Chrome and Firefox surpassed the IE 6/7/8's combined market share last month.
On the mobile front, iOS and Android still lead by a wide margin; both support HTML5 video. Android at large still supports Flash, but we noticed that Android 4.0 (Ice Cream Sandwich) is not always released with built-in Flash support (e.g. not on Samsung's Galaxy S2). Eventually, mobile Flash support will disappear entirely.| Browser/Device | Market Share | HTML5 Video | Flash Video |
|---|---|---|---|
| Chrome | 27% | Yes | Yes |
| Firefox | 23% | Yes | Yes |
| Internet Explorer 6/7/8 | 22% | No | Yes |
| Internet Explorer 9 | 11% | Yes | Yes |
| Safari | 5% | Yes | Yes |
| iOS | 4% | Yes | No |
| Android | 2% | Yes | Yes |
| Opera | 2% | Yes | Yes |
| Other (feature phones) | 4% | No | No |
| View Details | View Details |
Note that connected TVs and set-top boxes are not yet a factor. The number of shipped devices is simply too small. Gaming consoles do have a decent install base, but they lack (intuitive) web browsing capabilities.
2. Media Formats
One of the biggest challenges with HTML5 video is the fragmented support for audio/video formats. On the desktop, the split is almost exactly 50/50, with Chrome/Firefox/Opera supporting the WebM format and Chrome/IE/Safari supporting the MP4 format. We're hopeful for a breakthrough, since Firefox recently announced that it would start supporting MP4. When this happens, MP4 support will be ubiquitous.
Firefox's announcement is mostly driven by developments on the mobile front, where MP4 reigns. Both iOS and Android only support MP4 video, although Android 4.0 introduced limited (software decoded) support for WebM video. Luckily, every browser and device supports the <source> tag for loading a WebM + MP4 source in one go.
| Browser/Device | Video Formats | Audio Formats | Multiple Sources |
|---|---|---|---|
| Chrome | MP4, WebM | AAC, MP3, Vorbis | Yes |
| Firefox | WebM | Vorbis | Yes |
| Internet Explorer | MP4 | AAC, MP3 | Yes |
| Safari | MP4 | AAC, MP3 | Yes |
| iOS | MP4 | AAC, MP3 | Yes |
| Android | MP4 | AAC, MP3 | Yes |
| Opera | WebM | Vorbis | Yes |
| View Details | View Details | View Details |
Note we have not included the Ogg video format in our tests. This format is not widely used and of lower quality than MP4 and WebM. Firefox 3.6, which is quickly phasing out, is the only browser version that supports Ogg but not WebM today.
3. Tag Attributes
The HTML5 video tag supports several attributes, most of which are supported to date across the various browsers and devices. We tested the most important ones: poster, preload, autoplay & controls. Internet Explorer ignores the preload=none attribute, which prevent the desktop browsers from reaching a perfect score. The implication here is that IE9 loads a part of your MP4 upon each pageview, instead of waiting until a user actually starts the video. This may add to a substantial increase in your streaming costs.
The mobile browsers ignore preload (video is never preloaded) and autoplay (video is never played upon page load). We believe this to be the correct approach, hence the N/A sign instead of a red cross. Unfortunately, the video controls on Android are not that usefull. Android 2.2 does not provide any controls and 2.3+ require clicking a tiny play button (as opposed to the whole video area) to start the video.
| Browser/Device | Poster | Preload | Autoplay | Controls |
|---|---|---|---|---|
| Chrome | Yes | Yes | Yes | Yes |
| Firefox | Yes | Yes | Yes | Yes |
| Internet Explorer | Yes | No | Yes | Yes |
| Safari | Yes | Yes | Yes | Yes |
| iOS | Yes | N/A | N/A | Yes |
| Android | Yes | N/A | N/A | No |
| Opera | Yes | Yes | Yes | Yes |
| View Details | View Details | View Details | View Details |
Note the design of the video controls in each browser is different, but all provide the same options: a play/pause toggle, a time slider and a volume slider. Firefox/Safari also render a fullscreen toggle (more info below) and iOS/Android omit the volume slider (in favor of hardware buttons).
4. JavaScript API
In addition to its HTML attributes, the video tag provides an extensive JavaScript API for controlling its content. Common use cases for this are the rendering of custom controls (like the JW Player does) or page interaction with the video timeline (like Popcorn.js does). We have performed a range of API tests, grouped by functionality. Scripting was found to be reliable and consistent across the various desktop browsers.
On the mobile front, things are different. First, both iOS and Android ignore getting or setting the volume. We think this is fair, since all these devices have hardware buttons to control volume. However, we do not agree with Apple's decision to block scripted play() commands. It makes the implementation of pre/mid/post roll advertising or auto-resuming playlists unnecessarily complicated. Last, a string of Android issues make video scripting on this OS a challenge. See the test details for more information.
| Browser/Device | Loading | Buffering | Playback | Seeking | Volume |
|---|---|---|---|---|---|
| Chrome | Yes | Yes | Yes | Yes | Yes |
| Firefox | Yes | Yes | Yes | Yes | Yes |
| Internet Explorer | Yes | Yes | Yes | Yes | Yes |
| Safari | Yes | Yes | Yes | Yes | Yes |
| iOS | Yes | Yes | No | Yes | N/A |
| Android | No | No | No | No | N/A |
| Opera | Yes | Yes | Yes | Yes | Yes |
| View Details | View Details | View Details | View Details | View Details |
Note we did not include tests around the networkState and readyState attributes. The HTML5 specification is vague in this area, leading to browsers reporting different values in identical situations. On top of that, these attributes are pretty low-level and not required for most video scripting applications.
5. Fullscreen Playback
While a minor feature at first sight, fullscreen playback essential to online video. It enhances the visual experience and increases viewer engagement. Although the HTML5 fullscreen specification is still in its infancy, most browsers have now implemented either a fullscreen control or a scripting API. Since the specification is not completed yet, the various fullscreen API calls contain vendor specific prefixes.
Both the iPad and Android tablets support a fullscreen control, but no API yet. The iPhone and Android phones always play video in fullscreen, so a control is not needed. Interestingly, Android 4 phones also started playing videos in windowed mode. Whether this is a good development remains to be seen. It adds yet another UX scenario to an already fragmented platform.
| Browser/Device | Fullscreen Control | Fullscreen API |
|---|---|---|
| Chrome | No | Yes |
| Firefox | Yes | Yes |
| Internet Explorer | No | No |
| Safari | Yes | Yes |
| iOS | Yes | No |
| Android | Yes | No |
| Opera | No | No |
| View Details | View Details |
Note the aspect ratio of a user's screen is often different from that of the video area on the page. Therefore, a nice feature is the ability to control the way the video fits the display (black borders or not). Many Flash video players, as well as TV's and iOS, have such an option. The new CSS3 object-fit rule will make this accessible to developers soon.
6. Accessibility
Since HTML5 is native to browsers, it can achieve a greater level of accessibility than plugins like Flash. Different accessibility standards (Section 508, WCAG) have different requirements, but in general two functionalities are always required: keyboard control and closed captions.
HTML5 videos can be keyboard controlled in IE, Firefox and Opera. IE/Firefox focus the entire tag, using SPACE to play/pause the video, plus LEFT/RIGHT and UP/DOWN for seeking and volume. In Opera, each individual button is tab-able. Though Chrome and Safari do not support generic keyboard access, their controls are available through e.g. VoiceOver or NVDA.
The HTML5 Text Track element (<track>) is designed to add closed captions to videos (plus subtitles, descriptions, chapters & metadata). The element is brand new, but every browser vendor is working hard to support it. This is especially important for mobile, since developers cannot use JavaScript to manually draw captions over a video element there.
| Browser/Device | Keyboard Control | Text Tracks |
|---|---|---|
| Chrome | No | No |
| Firefox | Yes | No |
| Internet Explorer | Yes | No |
| Safari | No | No |
| iOS | N/A | No |
| Android | N/A | No |
| Opera | Yes | No |
| View Details | View Details |
Note the HTML5 specification defines an alternative approaches to loading captions. It leverages video files with embedded text tracks. iOS supports this today (without API support), but no other browser has yet committed to implement this mechanism. Embedded text tracks are easier to deploy, but harder to edit and make available for search.
7. Adaptive Streaming
Adaptive streaming is a core component of online video. It enables buffer control (less waste of bandwidth), fast seeking (to not-yet-downloaded parts), quality adjustments (during playback) and live streaming (possibly with DVR). Currently iOS is the only platform with adaptive streaming, supporting Apple's own HTTP Live Streaming (HLS) protocol. Android 4 introduced HLS support too, but its market share is still low.
Adaptive streaming formats, like video codecs, are not part of the HTML5 specification. Standardization will therefore come from another body than W3C. MPEG is the most likely candidate. It has just release a standard for adaptive streaming, called DASH, which has gained broad industry support. No browser supports MPEG DASH yet, but we assume this will come.
| Browser/Device | HTTP Live Streaming | MPEG DASH |
|---|---|---|
| Chrome | No | No |
| Firefox | No | No |
| Internet Explorer | No | No |
| Safari | Yes | No |
| iOS | Yes | No |
| Android | No | No |
| Opera | No | No |
| View Details |
Note that every HTML5 browser supports seeking to not-yet-downloaded portions of the video by using HTTP 1.1 range-requests. Compared to Flash (which cannot do that), it reduces the need for adaptive streaming, as it enables the fast seeking feature.