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
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 83% of the market now supports HTML5. Since IE 6/7/8 do not support HTML5, alternatives like Flash remain very useful for video playback. However, both Chrome, Firefox and IE9/10 surpassed the IE 6/7/8 market share by now.
|Browser/Device||Market Share||HTML5 Video||Flash Video|
|Internet Explorer 9/10||16%||Yes||Yes|
|Internet Explorer 6/7/8||10%||No||Yes|
|Other (feature phones)||7%||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 divided support for audio/video formats. On the desktop, the split is roughly 50/50, with Chrome/Firefox/Opera supporting the WebM format and Chrome/IE/Safari supporting the MP4 format. Once implemented in Firefox, MP4 support will be ubiquitous.
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|
|Internet Explorer||MP4||AAC, MP3||Yes|
|View Details||View Details||View Details|
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 thepreload=none attribute, which prevent the desktop browsers from reaching a perfect score. The implication here is that IE9/10 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.
With exception to iOS 6 on the iPad, 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 2.2 (nonexisting) and 2.3 (clunky) are not that useful. Android 4 introduced a much better UX, on par with iOS.
|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, a volume slider and a fullscreen button. IE9 has no fullscreen toggle and iOS/Android omit the volume slider (in favor of hardware buttons).
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 advertising or playlists unnecessarily complicated. Last, a string of Android issues make video scripting on this OS a challenge.
|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 draft, most browsers have now implemented a fullscreen control and scripting API. The various fullscreen API calls contain vendor specific prefixes.
Both the iPad and Android tablets support a fullscreen control, plus the (legacy)webkitEnterFullScreen() API. The iPhone and Android 2.x phones 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|
|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. Text Tracks
The HTML5 Text Track (<track>) element and VTT are a great step forward for making online videos more accessible. This tag makes it possible to not only add closed captions to videos, but also subtitles, descriptions, chapter makers & metadata. Most of the major desktop browsers, excluding FireFox, now support HTML5 captioning technology. Video captions are very similar to subtitles. The major difference is that captions describe all of the relevant audio detected in the video, whereas subtitles focus solely on the words spoken in the film.
At LongTail Video, we feel strongly about creating the means of equal access to online video content. By building products that support features such as multi-language video captions, we aim to increase viewer accessibility. Starting this March, new FCC regulations require that live and near-live programming, recorded within 24 hours of broadcast on television, begin full captioning compliance. Running late? We have a great article on getting started with Text Tracks.
What video publishers may not yet realize is that there is more to captioning videos than simply increasing accessibility among the hearing-impaired. In fact, there are quite a few side benefits including search engine indexing, in-video search, non-native-language viewer captions, and mobile device support. We’re confident that as video captioning further penetrates the HTML5 market, that captions will become even easier to publish.
|View Details||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 introduced HLS support in 4.0, only to have it dropped again in 4.1.
Adaptive streaming formats, like video codecs, are not part of the HTML5 specification. Standardization may 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 it may come. A first step in this direction are the Media Source Extensions Google and Microsoft are working on.
|Browser/Device||HTTP Live Streaming||MPEG DASH|
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.