How to prepare your mobile video ads for HTML5

As HTML5 grows its share of the online video market, web video publishers are beginning to look for ways to monetize videos being played outside of the traditional Flash advertising methods. But when someone watches a video in HTML5 mode, what should that experience be like? What's possible, given the current state of the tech?

How to prepare your mobile video ads for HTML5

HTML5: Desktop versus mobile

Before we begin talking about the challenges that face HTML5 video ads, it's important to acknowledge that video in HTML5 can behave very differently on the desktop than the same code running on a mobile device. Here are some of the primary differences:

* Platform-specific

As you can see from the table above, some concepts that advertisers take for granted, such as video ads that display a webpage when clicked, are not possible on smartphones. On most mobile devices, once an HTML5 video begins playing, whether it's an ad or not, the phone will enter full-screen video playback mode. This gives the user has full control over the playing video, including the ability to seek to the end of it.

Technical challenges

 As the major ad networks are beginning to offer support for HTML5 video ads, they face several important challenges.

Video codec incompatibility (WebM  versus MP4)
One issue HTML5 video publishers are already familiar with is that to support all platforms, video must be encoded into multiple formats: WebM (or Ogg Theora) for Firefox, and H.264 for everything else. Second, someone (the browser, ad network, video player, or publisher) will need to select the appropriate format and display it to the user. This can be difficult to implement in an ad scenario, especially if ad networks don't account for the user's browser when generating the ad response.

Cross-domain issues
An additional technical concern is that loading external assets (a VAST XML response from an ad server, for example) brings certain restrictions in JavaScript. These restrictions need to be worked around on the server hosting those assets.

<Video> tag access
Depending on the implementation, most ad networks require direct access to the player's <video> tag in order to play an ad in HTML5. This makes sense, considering that in iOS, each distinct <video> tag placed on a page needs to be clicked by the user for the video to be played. If the ad were to be played in a new <video> tag placed on top of the player, the user would need to click "play" twice -- once for the ad and a second time to watch the main video.

This presents some interesting problems. While the ad is playing, the player needs to treat the events flowing from the <video> tag differently than if the main video were playing. After the ad has played, the video tag needs to be restored to its original state (the video playing, its position, etc.)

Industry roundup

Considering the relative newness of HTML5 video (and the challenges listed above), it's no surprise that several video ad networks have not implemented full HTML5 support yet. That being said, there are a few ad networks that have made some progress on this front:

  • Google recently released HTML5 support in its Interactive Media Ads (IMA) product. This implementation allows publishers to set up VAST ads, with certain limitations based on device compatibility. The JW Player's Google IMA Plugin includes beta support for HTML5 mode.
  • YuMe has been steadily improving its HTML5 support, and most other video ad networks (Tremor Video, SpotXchange, BrightRoll, and others) have either announced plans to or are currently implementing support for mobile devices, which will mean HTML5-compatible ad media.

Future considerations

Just like with Flash, as more publishers attempt to handle more sophisticated scenarios, new techniques must be devised to handle them. Dynamic bitrate switching, for example, allows publishers to make on-the-fly optimizations for video ads based on screen resolution and available bandwidth. Apple HLS (HTTP Live Streaming) is on its way to becoming the standard streaming format on mobile devices -- with competition coming in the form of MPEG DASH.

Both HLS and DASH are based around the idea of a manifest file, which keeps track of smaller chunks of video that can be stitched together into a single seamless video. Inserting an ad into this stream can be as simple as adding the ad chunks inside of the manifest file at the appropriate times, a technique known as dynamic ad insertion. A more general optimization we'll be moving towards is ad delivery optimized for variable-bandwidth environments, because many mobile users are viewing content over slower wireless networks.

In short, we're still a long way from having a turn-key video advertising solution for all HTML5 viewers, but we're closer to achieving that goal than ever before.

Pablo Schklowsky is the lead developer for the JW Player at LongTail Video.

On Twitter? Follow iMedia Connection at @iMediaTweet.



Lembit Kivisik
Lembit Kivisik September 17, 2012 at 1:02 AM

Thanks for an exciting article. It starts to become a bit outdated though, barely 6 months later. If you target Android and iOS from versions 4 and up, the options are greatly better than described above. This is not to say that implementing mobile video ads for HTML5 is easy — there are still many implementation challenges involved also on recent mobile OS versions / handsets. However, I can say from experience that all of the stuff listed can be done on newer handsets, and HTML5 support is quite good especially on Android, from 4 and up. So, I sincerely encourage all marketers to explore mobile video advertising.