HTML5 has become an essential technology for broadcasters with a multiscreen distribution strategy because it can be used to deliver video experiences to TV connected devices and mobile websites on smartphone and tablet devices. Already, the time and attention that consumers give to video in HTML5 environments is large and growing.
Consider these facts:
A lot of mobile video viewing happens in HTML5 environments.
In fact, 18% of consumers are watching mobile video only or mostly in HTML5 environments, according to the IAB’s Mobile Video 2015 report. The report says that when consumers watch videos on their smartphone, 40% use the mobile web as much or more than mobile apps.
Mobile video viewing may cannibalize TV watching.
The IAB report also says that 22% of survey respondents, who owned a smartphone and had watched mobile videos, reported watching less TV because they watch video on their smartphone. In addition, 35% of survey respondents reported watching more video on their smartphone now than a year ago.
However, viewing times on mobile video are nowhere close to TV viewing, and this trend should not be disregarded.
Nielsen’s Q3 2015 Comparable Metrics report shows that the average adult user of a TV connected device watches 8 hours and 50 minutes per week of video on their TV connected device; the average adult user of smartphone video watches 45 minutes per week of video on their smartphone; and the average adult user of tablet video watches 1 hour and 15 minutes per week of video on their tablet. And some of these smartphone and tablet minutes may be spent in apps, without HTML5.
Multi-screen viewing behavior is here to stay and it’s going to trend higher over time. This means that broadcasters need a way for HTML5 to work for them.
Broadcasters won’t be successful with HTML5 alone
Open source HTML5 and general purpose HTML5 video players don’t support everything that broadcasters need in order to manage a successful multi-screen distribution strategy. As a result, the pressure is on for broadcasters to enhance HTML5 with technology that can overcome four challenges:
Challenge: Inconsistent user experiences that lead viewers to churn.
Broadcasters can run into a lot of inconsistencies across devices when using HTML5 because every device may handle different aspects of HTML5 and its related standards in different ways. For example, even though Media Source Extensions (MSE) are the common browser interface for HTML5 video, the quality of the implementation can differ depending on the user’s browser or even the underlying hardware decoder on the user’s device.
The answer: Inconsistencies need to be addressed with fallback options.
The same player technology can be used across devices to use HTML5 capabilities, where present, and then fall back to other capabilities of the player technology or device when needed. This requires a smart heuristic engine capable of addressing a wide range of device issues. When this kind of engine is present within the player technology, it provides viewers with the same high-quality video experience on all mobile websites, as well as on TV connected devices.
Challenge: Content protection across HTML5 does not follow a one size fits all approach.
Protecting content across devices is complex, especially when it comes to mobile web browser support. There are a number of popular content protection systems and different mobile web browsers work best with specific systems. For example, devices and browsers may support PlayReady from Microsoft, Widevine from Google, Fairplay Streaming from Apple, or Adobe Access. This makes it difficult for broadcasters to efficiently distribute protected content to HTML5 environments.
The answer: Aim to have one workflow that can prepare content for multiple DRM systems.
To maximize the reach of protected content, broadcasters need to support many DRM systems while maintaining a simple workflow. Specifically, the packaging flow and player needs to be able to support MPEG-DASH CENC or HLS Sample Based Encryption in order to use different DRM systems with the same set of content. Once in place, this enables a very streamlined and efficient workflow for distributing protected content.
Challenge: Broadcasters’ methods of monetizing content need to work within HTML5 environments.
The monetization of video content within HTML5 environments needs to be just as robust as it is within any other playback environment. When broadcasters invest in a multi-screen distribution strategy, every screen where content plays needs to be a net addition to the monetization model. If things like ad insertion don’t work in HTML5 environments, it leaves little incentive for broadcasters to use HTML5.
The answer: Deploy technology that enables the insertion of ads into HTML5 video across devices.
Not only do broadcasters need the ability to insert ads into HTML5 video, they also need access to both options for doing so: client-side ad insertion (CSAI) and server-side ad insertion (SSAI). It helps to have access to related capabilities as well, such as consistent support for VPAID 2.0 JS rich media ads, and methods to seamlessly handle differences in video encoding between ads and content. Finally, to optimize engaging ads and content, broadcasters need a granular measurement system that works across devices to generate audience insights, video consumption insights, and currency-quality metrics about ad inventory.
The best way to make HTML5 work for broadcasters
HTML5 alone doesn’t support everything that broadcasters need in order to manage multi-screen video distribution. It only partially solves for fragmentation, and it doesn’t provide unified ways to protect, monetize, and measure content across screens. However, technology providers can extend the capabilities of HTML5 with player technology and an underlying technology platform that caters to the needs of broadcasters. I frequently talk to leaders in the TV industry about making HTML5 work for broadcasters and can assure you that, with the right solution set, HTML5 can form the foundation of a successful multi-screen distribution strategy.