What video player are most publishers using?

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!

JW player

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:

• Multi protocol streaming support: HLS, DASH (Adobe RTMP not supported)
• 4k video playback support on HTML5 mode
• 60FPS video playback support
• RSS/XML and JSON format playlist support
• VAST 4.0, VPAID 2.0, VMAP support
• Integration with major ad server SDKs: Google IMA SDK & FreeWheel Ad Manager SDK
• Podding, waterfall/fallback, ad scheduling

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.

Ooyala

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:

• Content-aware player controls
• Closed captions (DFXP)
• Ability to share content on Social media
• Recommendation engine
• Supported formats: VAST 3.0, VPAID 2.0, VMAP 1.0, HLS and MP4, OSMF Flash HDS, Akamai packaged HDS, and DASH and HLS
• Backward seeking on live stream content playback
• Podding and cue point management
• Android & iOS SDK’s
• Google IMA integration via a plugin.
• Multi analytics platform support (Adobe, comScore, Nielsen, Google analytics, etc.)
• Native monetization offering via Ooyala pulse.
• Has multiple ad network integrations out of the box.

Pricing: See there customer pricing structure.

Brightcove

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.

Features include:

• Google’s IMA, OnceUX, SpotX, and FreeWheel integration
• 360 video playback support
• DRM content protection availability (Widevine Media format)
• Live stream multi-format delivery support (HLS, DASH, Apple’s FairPlay Streaming)
• Native iOS and Android SDK’s for in-app implementations
• Native tvOS (Apple TV) support
• Airplay support for non monetized content with native iOS SDK
• Native Analytics and Adobe Analytics integration
• Multiple audio tracks support on native iOS and Android SDKs
• Server-side ad serving support

Pricing: Only custom pricing available.

Video.js

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.

The project has a very helpful community with a wide array of plugins for 3rd party integration and additional services. It can be customized as per requirement (HTML, CSS & Javascript tweaking required) or can be used out of a box.

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:

• Custom playlist curation
• Airplay and chromecast support (Browser & device dependant)
• Google Analytics integration
• Live streaming support (HLS & DASH)
• Custom error reporting
• DRM content playback (Apple Fairplay)
• IMA SDK integration
• Ooyala CDN integration
• 360, VR & panorama video support
• Content recommendation engine
• Social sharing integration

Pricing:  Free

Feature comparison matrix

	JW Player	Ooyala	Brightcove	Video.JS
HTML5	✓	✓	✓	✓
Native Analytics	✓	✓	✓	✘
CDN	✓	✓	✓	✘
Customizable	✓	✓	✓	✓
Multi-bitrate support	✓	✓	✓	✓
Support	✓	✓	✓	✘
Contract	✓	✓	✓	✘
Secure delivery	✓	✓	✓	✓
API support	✓	✓	✓	✓
Free	✘	✘	✘	✓

Background information on video players

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.

How does a video player request and serve an ad?

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:

1. Pre-roll: The advertisement when played/rendered before the content playback is initiated.
2. Mid-roll: Any position between the start and end of the content is considered as mid-roll.
3. Post-roll: The ad when played/rendered at the end/completion of the content.

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.

Externally hosted

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.

Redirect tags

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.

Types of Video ad units/implementation/serving

In-stream

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:

1. Linear: These are generally ads in video format and are served by interrupting the content playback. There are three positions/timelines where linear ads can be served, before the content (preroll), during the content playback (midroll) and after the content has finished playback (post-roll).
2. Non-Linear: These are generally static images, or rich media enabled formats, which do not interrupt/pause the content playback. They are typical of smaller size and are overlaid at the lower/bottom section of the video player.
3. Companion: These are general display ads served along with the linear ads in the vicinity of the player to accomplish a more immersive experience and also to provide users an option to take action relating to the video ad served earlier even after it ended (useful in case of short video ads).

Out stream:

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).

Common points of failure specific to video ad serving:

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.

Losing out on revenue when an ad fails to play and triggers an error?

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:

1. Test the latency in the response of the 3rd party ad server and avoid using ad servers/tags which take a lot of time to return a response, when there are no winning bids/ads.
2. Set the player default timeout to a higher duration, depending on the average ad server response times of the tags trafficked into your ad server or from demand partners.

Tips & Best practices for serving video ads via Google Ad Exchange (AdX)

• To be able to serve ads via Google’s programmatic platforms, it is required that the video player to be integrated with IMA SDK without which there can be inconsistencies and discrepancy in reporting.

• If IMA SDK integration isn’t feasible, Google provides an alternative approach to serve AdX demand via the use of adapter tags. An adapter tag when served on a non-IMA integrated player, will emulate IMA SDK functionality for that specific request and provides all the function calls and functionality as that of an IMA SDK integrated player. Adapter tags can be generated by selecting the technology as ‘IMA Adapter’ when generating the video tags in Google AdX.

• Avoid serving IMA adapter tags on IMA SDK integrated players, as this isn’t a recommended approach and it may fail to play the ad, triggering a VAST 901 error.
• Ensure compliance with AdX video specific policies listed here, in addition to AdX program policies.
• Starting from April 2018 onwards, Chrome’s new policy update enforces a restriction on autoplay video ads. This will only impact if you are serving autoplay video ads with sound and doesn’t apply to autoplay video ads that are muted by default.
• Autoplay non muted video ads are allowed to serve only if any of the following criteria are met:
  • Before the ad initiated playback, the user has interacted on your website.
  • The user’s MEI (Media Engagement Index) is higher than a predefined threshold (Only for desktop). The calculation of the MEI index is detailed in this article.
  • On a mobile platform, if the user has pinned/bookmarked the site on the Device’s home screen.

Conclusion

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!

---

Additional questions

What is the JW player?

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.

What is the Brightcove player?

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.

What is the Ooyala player?

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.

What is video.js?

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.