This post was most recently updated on July 6th, 2022
In this detailed blog post, we’ll take a closer look at the different video players available to publishers in the market, compare their features (comparison table included), look at video ad serving, different video ad units, and even the pitfalls of ad serving.
If you are currently working with Google Ad Exchange, we’ve included a section providing best practices for video ad serving as well. Let’s begin!
The JW player is one of the most used web-based players that support a wide range of formats (HLS, VAST 3.0, VPAID 2.0) and integrates with most of the major ad networks.
Find out more about VPAID vs VAST here.
This video player supports multi-platform ad serving with advanced features such as live stream support, closed captioning, and is future proof with native support for 360 & VR videos playback.
It provides native SDK’s for both Android and iOS for in-app implementations. It’s also a trusted provider for serving ads via Google’s DoubleClick suite and is a Google certified publishing partner.
JW player clients include Amazon, Vice, Univision, Fox, and many more. JW player in collaboration with SpotX has recently introduced native Header bidding (video) for monetization of content being served using JW player.
Demo & sample player implementations can be found here, to get an idea of the player capabilities and functional aspects.
Features available in JW player eight release:
Pricing for this video player starts at 5$ per month (billed annually). Custom pricing for monetization via ad serving based on the traffic is more than 50$ per month. IMA SDK integration is not available for the entry (5$ pm) and mid-level (50$ pm) offerings.
The latest release of the Ooyala video player boasts of a long list of features, which will cater to all your video publishing and monetization needs. Their UI design follows Google Material UX guidelines and is highly customizable to reflect your branding.
Some of the features available in Ooyala player 4.0 are:
Pricing: See there customer pricing structure.
Brightcove’s video publishing and monetization offerings are geared towards large publishers with high traffic and huge content catalogs. The Brightcove product suite caters to all of the requirements for video content publishing from basic content playback to content hosting, content ingestion, advanced analytics & marketing tools.
This will help reduce the number of moving parts, thereby eliminating any compatibility issues and increase reliability. Some of the biggest brands such as Ford, BBC, Oracle, Condenast, and GoDaddy use the Brightcove suite for their publishing needs.
Pricing: Only custom pricing available.
Unlike the other players on this list, Video.js is an open source offering of an HTML5 based video player with support for video monetization. The primary sponsor of the project is Brightcove, whose video player is also built on top of the video.JS framework.
See there guide here and the plugin available to support IMA SDK integration.
Some well-known clients include Instagram, Twitter, Microsoft, Github, IGN, The Guardian and many more.
Features supported by plugins are:
Traditionally video players had just one job to do, play the content with just basic navigational controls. Players had a list of video formats that they could render, and that’s about it.
Today, video players have evolved to cater to an ever-growing demand and many functionalities apart from just playing a video asset. With industry-wide adoption of HTML5, once widely used players, based on the flash framework are on a rapid decline.
There are multiple reasons for you to switch to an HTML5 player over flash-based players, of which the two main driving factors are speed and security.
However, if you are looking to serve flash-based content, there are multiple options for you even as of now, many video players do support flash format video files.
In the context of ad serving, flash is no longer supported by all the major web browsers.
A player first requires a video ad tag to be implemented, which will be triggered at the cue points where the ad is supposed to be rendered.
There are three primary positions where video ads are served:
When the request is made to the ad server, ad selection/RTB takes place, and the winning ad is returned in a VAST XML response with all the associated media assets and tracking event pings.
(VAST stands for ‘Digital Video Ad Serving Template,’ which is a specification developed by IAB to have a common XML response from all ad servers. Before which, each ad server and player required a response in different formats, which was not efficient)
Once the player receives the VAST XML response from the ad server, it fetches the creative asset files and renders them at the predefined cue points before/during/after the content playback.
The player will also fire the tracking events returned in the VAST XML at the associated event triggers. Should there be any failure/issue, a VAST error is triggered and logged in the ad server for future analysis.
There are three different ways media assets can be hosted in case of video ad serving:
Ad server hosted
Media assets are hosted within the ad server which is used to serve the ads. The advantage of this approach is a direct hosting URL of the media files are returned in the VAST response. This significantly reduces the latency and failure rate for fetching the media files by the player.
Media assets are hosted on a 3rd party CDN, and the hosting URL is returned in the VAST XML. This can add up the latency in fetching the media files, depending on the CDN response time.
This is the most commonly used type of media asset hosting where a redirect tag is trafficked in the ad server, and the same tag is returned in the VAST XML. The player then triggers the redirect tag which then fetches the media files in a second VAST response.
This option is typically used in implementations where another auction is carried out in a second ad server, and the media files/ad can be different for every request.
In this type of video ad serving, video ads are served within a player/App. The target Audience’s main focus, in this case, will be the content served via the video player specifically. 3 ad formats are generally served in this environment:
In this type of implementation, there is no focal content on a video player. The video ads are served in line with the display content on the page.
There are multiple ways or implementations for serving outstream video ads. The most common one being In-banner video, wherein a video ad is rendered within a display ad unit.
Other commonly used implementations are video interstitial, in page video (spawning a player).
Timeout: Every player has an option to set a predefined timeout, which when reached, the content will start playback. This ensures that the content/playback is not held up, should there be latency/delay in fetching the media files which provides an optimal user experience.
Empty VAST response: Is a possibility in case of redirect tags, if the redirect URL did not fetch an ad, i.e., the request to the 3rd party ad server went unfilled.
Multiple redirects: Some advertisers/creative providers return another redirect tag for the 1st redirect tag trafficked. This can be due to daisy chaining and infinite loops or delay in each of the redirect response.
To prevent this, video players have a redirect limit, which when reached, a VAST error will be triggered. If there is no set limit, the next point of failure will be reaching the timeout.
Unsupported media asset format: If the video player is unable to render the media files returned in the VAST XML, this error will be triggered. This error is not quite common as there will be multiple media files returned each of a different size, bitrate, encoding, etc. The player can choose the one that best suits the environment where the ad is to be rendered.
What if the tags trafficked into your ad server fail to fetch an ad?
The opportunity to monetize that specific request/impression will be lost. To solve this problem, the waterfall/fallback comes into play. When a fallback is enabled in your ad server, it will send a predefined number of winning ads in the VAST XML response.
If the first one fails due to any reason, the player will move on to the next ad in the list. This process goes on until the player can play an ad.
The obvious question in this scenario is, will this cause a delay/ increase the ad load and render times?
The overhead, in this case, is very negligible and the player runs through the fallback in a matter of milliseconds.
A possible point of failure even if fallback is setup correctly:
The only point of failure, in this case, would be if the 3rd party server does not return a response or returns an empty response for the lack of an ad.
In this case, the video player will wait for the timeout set, which once reached will initiate the content playback. The ads in the fallback will not have been even tried.
How to solve the problem of the timeout triggering before all the ads in the fallback have been tried?
There are two approaches to this:
Although we’ve laid out all the information for you in this article, video players and video ad serving can be complicated. To get help choosing the right one for your publishing business and implementing it correctly, sign up for a Professional account at MonetizeMore today!
The JW player is one of the most used web video players that support a wide range of formats and integrates with most ad networks. Find out more about its features in our blog post.
The Brightcove player is designed for large publishers with high traffic and big content catalogs. The player offers a wide range of features and caters to all of the requirements for video content publishing.
The Ooyala video player is a player that boasts of a long list of features catering to all publisher video monetization needs across multiple devices. We discuss the video player more in our blog post.
Video.js is an open-source video player that publishers can use for video monetization. Brightcove is the primary sponsor of the project. Their video player is built on top of the video.JS framework.
Kean Graham is the CEO and founder of MonetizeMore & a pioneer in the Adtech Industry. He is the resident expert in Ad Optimization, covering areas like Adsense Optimization,GAM Management, and third-party ad network partnerships. Kean believes in the supremacy of direct publisher deals and holistic optimization as keys to effective and consistent ad revenue increases.
Here’s the course that 300+ pubs used to scale their ad revenue.
Paid to Publishers
Ad Requests Monthly
10X your ad revenue with our award-winning solutions.Let's Talk