The HTML5 SDK has two main ways to render ads: what we call “standard” rendering and “custom ad playback.” To avoid confusion and to keep you all informed, here’s a breakdown of those rendering modes and how the SDK decides which to use.
Standard Rendering
If you're using the
HTML5 SDK you probably have a web page playing your content in a
<video> element. In standard rendering, the SDK will create another
<video> element and render it in the ad display container div you provided, which should be placed on top of your video player. The ads will then play in this SDK-owned video player on top of your content player. To the user, it looks like one video player switching from content to an ad, but in reality it’s another video player appearing on top of your content to play an ad and then disappearing. For a visual representation of what’s going on, see the image below.
Why use standard rendering?
The main benefit to this standard rendering involves buffering. Using a separate video player to render ads allows us to preserve your content buffer while ads are playing. If you’re playing a pre-roll, you can start loading your content when the ad starts and buffer the content the whole time the ad is playing. For mid-rolls, the separate player allows you to preserve your content buffer while ads are playing - if your viewer has buffered 10 minutes of your content, and you play an ad at the 5 minute mark, they won’t lose the content in the buffer for 00:05:00-00:10:00.
Custom Ad Playback
As avid blog readers will know, we recommend
always passing in your content video element as the custom playback element. If you’re not already doing this, check out our
guide to custom ad playback. The HTML5 SDK will intelligently use custom ad playback only when it deems necessary, as described below. When it’s not necessary, it will use standard ad playback.
What is custom ad playback?
When the SDK decides to use custom playback mode, it renders video ads
in the same player as your content. This means you lose the buffer-related benefits of standard rendering. If your viewer has buffered 10 minutes of your content, and you play an ad at the 5 minute mark, they
will lose the content in the buffer beyond the ad. Certain ad formats (such as AdSense) require an SDK-owned player and can't play in your content player.
Why use custom ad playback?
Simply put, some platforms do not support multiple, simultaneous, active video elements. On those platforms, the SDK can’t create its own ad player because the one allotted video player slot per page is already occupied by your content player. If the SDK tries to play an ad in a second video player, it will either fail to play (freezing the player) or make it impossible for the content to restart after the ad is finished (again freezing the player). Thus we must show the ad and video content in the same player.
How does the SDK know when to use custom ad playback?
The
HTML5 SDK looks at the UserAgent string of each browser on which it’s loaded. When it sees a browser that it knows has trouble with multiple video elements, it uses custom ad playback. Currently those browsers are limited to Android and iPhone. We’re in the process of phasing out custom ad playback on Android 4.0+ to bring the benefits of standard playback to users.
Now you know all there is to know about HTML5 video ad rendering. As always, if you have any questions feel free to contact us via the support forum.
- Shawn Busolits, IMA SDK Team
