Labels: , ,

Labels: , , ,

Labels: , ,

Have you ever wished you could experiment with IMA HTML5 SDK features without having to download our samples, modify them for the feature, and host them on your own webserver? Now you can with our new Codepen snippets!

We’ve added codepen snippets to several HTML5 guides. These snippets allow you to modify and execute Javascript right in your browser. To test different aspects of a new feature, you can simply modify the Javascript and re-run the sample, without having to download the files or host them yourself. Codepen snippets are now available for the following guides:

Labels: ,

Labels: ,

A non-linear ad.

A full slot ad is a static or animated ad that usually appears before or after the content, occupying the entire view area. It renders a close button that when clicked closes the ad and, if rendered before the content, triggers the content to start.

A full slot ad.

Current behavior

Currently, non-linear ads are rendered as expected, but full slot ads are also rendered as non-linear ads. So instead of pausing, the video continues to play underneath them while they take up a large portion of the video display.

New behavior

With the new behavior, any non-linear AdSense or Ad Exchange ad greater than 90 pixels in height will be rendered as a full slot ad. This means it will take up the entire video display. When the user clicks the close button, the content will start.

We will also be adding a new UI to these full slot ads which includes a countdown timer and a skip button. You should remove any custom UI elements you’ve added for full slot ads to ensure there are no conflicts with this new UI.

Lastly, to ensure that your ads are rendered properly, make sure your AdDisplayContainer is rendered on top of everything else and takes up the full size of your video player.

Full slot ad with the updated UI.

Testing the changes

If you’d like to test these changes, you can load the test version of our SDK by replacing your load of ima3.js with ima3_test.js. This is a watermarked test binary that changes frequently and without notice; it is not intended for use in production.

As always, if you have any questions, feel free to contact us via the support forum.

 - , IMA SDK Team
Labels: ,

The new ad UI.

This change will also be rolling out to all mobile web ads that do not use custom click tracking. Note that ads that have no UI before the change will gain a UI with this change. This will allow our mobile web behavior to be consistent with native mobile behavior.

If you have any questions about these changes, feel free to contact us via the support forum.

 - , IMA SDK Team
Labels: ,

Labels: ,

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.
 - , IMA SDK Team

Share on Twitter Share on Facebook
Labels: ,


Older Internet Explorer versions

Currently only IE11 is supported; some publishers are using the IMA HTML5 SDK with IE10 without issues, but it isn't officially supported. SDK support will be focused on on IE11 and subsequent versions given the upgrade rate from IE10 to IE11. Version 9 and earlier of Internet Explorer are not supported by the IMA HTML5 SDK and likely will not correctly serve video ads.

Questions?

If you have any questions about Internet Explorer support or other IMA SDK questions, feel free to contact us via the support forum.

 - , IMA SDK Team
Share on Twitter Share on Facebook
Labels: ,

 - , IMA SDK Team
Share on Twitter Share on Facebook
Labels: ,

Labels: ,

The SDK's usage of the custom click tracking element is also changing. Currently, if a custom click tracking element is passed in to the SDK, it will always be wired to handle clicks. Soon, the custom click tracking element will only be used if the ad is a non-AdSense/AdX creative and the environment is iPhone or pre-4.0 Android. Please do not render your custom click tracking element over your video player as it may prevent clickthroughs after this change is put into place because it may intercept clicks on the SDK-rendered elements. We only recommend passing in a custom click tracking element if you are showing non-AdSense/AdX creatives and want a click tracking element in iPhone and pre-4.0 Android devices. See opt_clickTrackingElement under ima.AdDisplayContainer for more information.

What do you need to do now?

  1. Effective immediately, all implementation should pass in the custom playback element to ensure support of IMA video ads across all devices. Please read our guide on Upgrading to the new custom playback.
  2. If you are using a custom click tracking element:


How can I tell if the IMA SDK is using custom playback or custom click tracking?


Release 3.1.62 of the IMA HTML5 SDK introduces AdsManager.isCustomPlaybackUsed() and AdsManager.isCustomClickTrackingUsed() which you can use in your player to see if the SDK is currently using the passed in custom video player or custom click tracking element.

As always, if you have any questions,feel free to contact us via the support forum.

 - , IMA SDK Team
Share on Twitter Share on Facebook
Labels: ,

Share on Twitter Share on Facebook
Labels: , , , ,

Labels: ,