ellipsis flag icon-blogicon-check icon-comments icon-email icon-error icon-facebook icon-follow-comment icon-googleicon-hamburger icon-imedia-blog icon-imediaicon-instagramicon-left-arrow icon-linked-in icon-linked icon-linkedin icon-multi-page-view icon-person icon-print icon-right-arrow icon-save icon-searchicon-share-arrow icon-single-page-view icon-tag icon-twitter icon-unfollow icon-upload icon-valid icon-video-play icon-views icon-website icon-youtubelogo-imedia-white logo-imedia logo-mediaWhite review-star thumbs_down thumbs_up

How to prepare your mobile video ads for HTML5

How to prepare your mobile video ads for HTML5 Pablo Schklowsky

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?

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.

Depending on the implementation, most ad networks require direct access to the player's

This presents some interesting problems. While the ad is playing, the player needs to treat the events flowing from the

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.

Pablo Schklowsky is a software engineer with over 10 years of experience building scalable front- and back-end web technologies.  As Tech Lead for LongTail Video, Pablo serves as the lead developer on the JW Player, a popular open-source video...

View full biography


to leave comments.

Commenter: Lembit Kivisik

2012, September 17

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.