90 Days Later: Video Player Bidding Best Practices

Video Player Bidding helps you maximize monetization, provided you’re following these recommendations

After the launch of Video Player Bidding earlier this year, we’ve seen great adoption and some impressive  benefits, including faster time-to-first-frame for ads and a great supplemental boost of ad demand for publishers’ ad stacks. As with any great new product comes great learning experiences. With months of data and the associated on-going analysis, our goal is to educate our customers on best practices to optimize Video Player Bidding setups to maximize revenue potential.

 

 

If you’re unfamiliar with Video Player Bidding (an easy-to-implement version of video header bidding) check out our previous blog post or the great video below of JW Player cofounder Brian Rifkin and SpotX Chief Revenue Officer Sean Buckley discussing the solution, and look here for how to get started.

 

In the last three months, the data we’ve collected from Video Player Bidding has proven a few core advertising concepts we’ve recommended in other blog posts we’ve posted.

Know Your Setup

If nothing else, we’ve realized that many publishers are unclear as to the optimal player setup for their page layout and audience. This is a perfect time to do some analysis and introduce improvements and efficiencies.

 

  • Cloud-hosted vs Self-hosted

For cloud-hosted Players, we’d be remiss to not note that a publisher using a custom JavaScript embed will override any advertising settings put into the dashboard. This includes an advertising block in the Player’s JS setup.

For self-hosted Players, simply set up the advertising block with the “bids” block described in our documentation and examples.

 

  • Custom Header Bidding Solutions

We’ve found that many publishers have pre-existing header bidding solutions in place. This can present an issue with event timing depending on the implementation. Typically, the best solution is to provide the Player with a complete and finalized ad tag prior to setting up the Player. This allows publishers to take advantage of the efficiencies built into the Player’s ad scheduling functionality.

 

The example below describes how to get your custom bidding done and then set up the Player with the appropriate information so as to avoid any timing issues.

 

// Do your custom header bidding here, which should result in a created ad tag

 

var finalTag = baseTag + custParams

 

// Once you’ve built your ad tag with the appropriate key value pairs from your header bidding solution, you can set up the player

 

var playerInstance = jwplayer(“myElement”)

playerInstance.setup({

   “file”: “myVideo”,

   “advertising”: {

       “client”: “googima”,

       “schedule”: {

           “adBreak”: {

               “tag”: “finalTag”,    —— the tag supplied here is a variable, created above prior to player setup

               “offset”: “pre”

           }

       },

       “bids”: {

           “settings”: {

               “mediationLayerAdServer”: “dfp”,

           },

           “bidders”: [

               {

                   “name”: “SpotX”,

                   “id”: “85394”

               }

           ]

       }

   }

});

 

Note in this scenario, the use of the playAd API is not necessary.

 

  • Player and Site Considerations

In general we’ve found certain player setup attributes to perform better or worse with Video Player Bidding.

 

    1. Player size: Believe it or not, Video Player Bidding requires a player height and width on setup. Advertisers want to know the size and type of player their ads will be running on. We’ve found a fairly large number of publishers who are setting up the Player with null, undefined, or 0 height and width, thus giving the Player a formal size too late. This is one of the largest causes of player setup-related failures.
    2. Click-to-play vs ‘autostart:viewable’ vs autostart in view: Given the extra calls that need to be made for the bidding process, allowing the Player more time to set up and for the bidding process to complete increases the chance of success. Autostart in view typically leads to timing issues with all the other network calls on the page, so be prepared for a degradation in performance in this scenario.
    3. Multiple players on a single page: This is generally discouraged even outside of Video Player Bidding. With multiple players, it can lead to extra network requests from both the Player and the bidding process.
    4. Multiple bidding requests: Video Player Bidding is optimized for single prerolls. Bidding for multiple ad breaks, including 3+ midrolls, is not optimal due to the additional network requests it creates.

 

Mediation Options

Video Player Bidding offers multiple mediation options, each tailored to a specific publisher use case.

 

  • JW Player

This is the easiest way to get started with VPB — no additional line items are required in the Ad Server and is the most performant. If the bidder meets the static floor price, then the bidder wins. Otherwise, the Player uses the fallback tag defined in the corresponding ad break slot. Please ensure the floor in SpotX is set at or above the floor in JW.

 

The downside is the JW mediation option is not aware of any other campaigns (including direct sold) so these campaigns can be cannibalized for programmatic/header traffic. Additionally, as the floor price is static, the bidder may over/under bid for that request.

 

  • DFP

With this option, DFP determines the winner in that the bidder competes directly with DFP line items. Corresponding line items are needed in DFP.  SpotX can help with the setup of the corresponding items.

 

In this instance, please ensure that you are competing all demand in Price Priority. Competing Sponsorships and Standard line items in DFP above JWP priority will largely negate the benefits of the JWP integration. Expect very low revenue from the integration if VPB is run at a lower priority than traditional demand in DFP.

 

The downside of this mediation layer is the ads’ time-to-first-frame will be longer as the Player has to send the SpotX bid to DFP to determine the winner.

 

  • JW Player + DFP

This mediation option combines the JW Player and DFP mediation layers in that order. If the floor price isn’t beaten, the key value pairs are added to the DFP tag to compete against DFP line items. This is a good option for publishers who use DFP but want to take advantage of the performance benefits of JW Player mediation. Please ensure the floor in SpotX is set at or above the floor in JW.

 

  • SpotX

You should select this option if your primary Ad Server is SpotX. All Publisher Direct Sold demand should be run in the SpotX ad server, competing along with the Open Marketplace, allowing full control over priorities given to SpotX demand versus Publisher Sourced Demand.

 

Performance Expectations

Depending on the complexities of your setup as well as how your traffic is split between desktop and mobile, performance expectations should be managed. In short, an autostart player on a page with a large amount of other network calls on a mobile device is not optimal for Video Player Bidding.

We’re Happy to Help

We recognize that both normal Player setups and Video Player Bidding setups can be complicated, especially given your other systems and requirements.

 

For more information about improving your monetization with Video Player Bidding, schedule time to speak with a video expert.

 

Contact Us

CONTACT US

The post 90 Days Later: Video Player Bidding Best Practices appeared first on JW Player.

Why Aren’t My Ads Playing?

Part 3 of JW Player’s Support Team series on video platform tips, tricks, and best practices

One of the questions we receive the most often is “why are ads not playing in my player?” It is certainly understandable that this is an anxiety-inducing problem, as no ads means no ad revenue. What we find most often is that the player is doing everything correctly, but the ad network is simply not returning an ad for our player to play.

My goal with this blog post is to help you test that our player is doing everything correctly. When you have conversations with your ad networks, you can do so with 100% confidence that our player is not part of the problem. (But if you find that there is an error on our side, we will certainly escalate it to our engineers.)

You can always test your ad tags in our Ads Tester at https://developer.jwplayer.com/tools/ad-tester/

And if you have DFP ad tags, you can use their inspector at https://developers.google.com/interactive-media-ads/docs/sdks/html5/vastinspector

The general rule for DFP tags in our player is this:

  • If the ad plays in Google’s tester, then it should also play in our Ads Tester with the ad client set to Google IMA.
  • If the ad still does not play, try setting VPAID Mode to Enabled in our Ads Tester
  • If the ad still does not play, send it to us so we can test further. And make sure you do not have any geo-blocking or domain restrictions set on your DFP tag.

 

Initial troubleshooting questions / steps

1) What is the ad client and ad tag that you have configured in the player?

2) If you check your browser’s network inspector, filter for the domain name of your ad tag (or another part of the URL). Are you seeing the request for the ad tag?

Here is a screenshot showing how I filter in Chrome for DFP ad tags. I filter for “gampad” (don’t ask me why, but it has always worked for me, so it stuck. I would love it if someone from Google could tell me where the name gampad came from…)

3) What is the response from your ad network?

You are probably going to see one of four things in the response from the ad network:

  • The normal VAST response that contains an ad for us to play
  • A normal VAST response, but the ad creative is not a video, but rather a VPAID Javascript file
  • A wrapped ad, which I think of as a redirect
  • An empty ad response. We get something from the ad network but they do not have an ad for us to play.

Ad Network Responses

I do not want to confuse you with the specifics, but here is a sample response for each type:

 

1) VAST response with a video ad creative:

[code]

<VAST xmlns:xsi=”//www.w3.org/2001/XMLSchema-instance” version=”2.0″ xsi:noNamespaceSchemaLocation=”vast.xsd”>

<Ad id=”232859236″>

<InLine>

<AdSystem version=”2.0″>Alex_Vast</AdSystem>

<AdTitle/>

<Description/>

<Survey/>

<Impression id=”DART”>

<![CDATA[ //qa.jwplayer.com/~alex/pixel.gif?2 ]]>

</Impression>

<Creatives>

<Creative sequence=”1″ AdID=””>

<Linear>

<Duration>00:00:30</Duration>

<TrackingEvents>

<Tracking event=”start”>//qa.jwplayer.com/~alex/pixel.gif?1</Tracking>

<Tracking event=”impression”>//qa.jwplayer.com/~alex/pixel.gif?2</Tracking>

<Tracking event=”firstQuartile”>//qa.jwplayer.com/~alex/pixel.gif?3</Tracking>

<Tracking event=”midpoint”>//qa.jwplayer.com/~alex/pixel.gif?4</Tracking>

<Tracking event=”thirdQuartile”>//qa.jwplayer.com/~alex/pixel.gif?5</Tracking>

<Tracking event=”complete”>//qa.jwplayer.com/~alex/pixel.gif?6</Tracking>

<Tracking event=”pause”>//qa.jwplayer.com/~alex/pixel.gif?7</Tracking>

<Tracking event=”mute”>//qa.jwplayer.com/~alex/pixel.gif?8</Tracking>

<Tracking event=”fullscreen”>//qa.jwplayer.com/~alex/pixel.gif?9</Tracking>

</TrackingEvents>

<AdParameters/>

<VideoClicks>

<ClickThrough>

<![CDATA[ //www.jwplayer.com/ ]]>

</ClickThrough>

<ClickTracking id=”Alex”>

<![CDATA[ //qa.jwplayer.com/~alex/pixel.gif?10 ]]>

</ClickTracking>

</VideoClicks>

<MediaFiles>

<MediaFile id=”1″ delivery=”progressive” type=”video/mp4″ bitrate=”0″ width=”640″ height=”360″>

<![CDATA[

//content.jwplatform.com/videos/AEhg3fFb-bPwArWA4.mp4

]]>

</MediaFile>

</MediaFiles>

[/code]

 

If you see a <Creatives> section in the response. Hopefully there is a <MediaFiles> section. Check the type=” ” or the URL of the media file. If it ends in .mp4 then you have a normal VAST response. This ad should play in all browsers. Some ad networks will give you a .webm video, but these will play in Chrome or Firefox only.

 

2) VPAID response

[code]

<MediaFiles>

<MediaFile delivery=”progressive” type=”application/javascript” width=”960″ height=”540″ apiFramework=”VPAID”>

https://adnetwork.com/ads/vpaid.js

</MediaFile>

</MediaFiles>

[/code]

 

If you notice the MediaFile is Javascript or a .js file, then you have a VPAID response. Please see my notes on VPAID ad creatives down below.

 

3) Wrapped ad tag

[code]

<VAST xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:noNamespaceSchemaLocation=”vast.xsd” version=”3.0″>

<Ad id=”710743816″>

<Wrapper>

<AdSystem>GDFP</AdSystem>

<VASTAdTagURI>

<![CDATA[

https://pubads.g.doubleclick.net/gampad/ads?sz=640×480&iu=/124319096/external/utility_samples&ciu_szs=300×250&impl=s&gdfp_req=1&env=vp&output=xml_vast2&unviewed_position_start=1&cust_params=sample_ct%3Dredirectlinear&correlator=1292672814

]]>

</VASTAdTagURI>

[/code]

 

Notice the <Wrapper> tag on the third line. This means that the ad network response points to a new ad tag in the <VASTAdTagURI> section. What does this mean for your viewer? It means they have to wait for another file to be requested and to load, which means a longer wait for the ad to start. Hopefully the new tag we load will play an ad, but it could also return another wrapped ad tag redirect…

 

4) Empty ad response

This can look a few different ways:

[code]

<VAST xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:noNamespaceSchemaLocation=”vast.xsd” version=”3.0″/>

[/code]

 

or

 

[code]

<vast></vast>

[/code]

 

Essentially there are only a few lines in the response. From a technical standpoint, an empty response is a perfectly valid scenario. It tells us the ad network received the request but they chose to respond without an ad. It is unfortunate that this is the case, but at least you know the player is doing everything correctly. My first suggestion would be to ask your ad network what you can do to increase your ad fill.

 

What is the problem with VPAID Javascript responses?

First of all, VPAID is great when it works and the ads play.

But the problem when the ads do not play is that it is almost impossible for us to see what went wrong. And keep in mind that when our player loads a VPAID Javascript file from your ad network, they have complete control over the viewer experience. By everything, I mean the volume, is the ad muted, are there controls to pause or mute the ad, does that one VPAID ad go out and try to load other VPAID ads and make the viewer wait? All of these are controlled by your ad network, and we can only sit there and wait for them to tell us the ad is over.

 

So what can you do to troubleshoot?

My first suggestion is to ask your ad network for sample ad tags that fill 100% of the time for testing. If they cannot give you one, then I do not think they are being a good partner. They should prove to you that their technology works too, right?

DFP has sample ad tags at https://developers.google.com/interactive-media-ads/docs/sdks/html5/tags

SpotX will build you a sample ad tag at https://www.spotx.tv/tag-generator-src/TagGenerator.html

  1. Choose the laptop
  2. Choose “yes I do!’
  3. Choose “directly into my player”
  4. Choose “VPAID 2.0”
  5. Choose JW Player

We also have a few sample tags too:

https://playertest.longtailvideo.com/vast-30s-ad.xml

http://playertest.longtailvideo.com/vpaid-2-linear-v1.xml

 

As mentioned earlier, you can always test your ad tags in our Ads Tester at https://developer.jwplayer.com/tools/ad-tester/

 

Hope this is useful. Please let me know how else I can help,

Todd

Director, Technical Support Team

todd@jwplayer.com

 

For more posts from the Support Team series, click here.

 

To learn more about improving the performance of your video ads, schedule time to speak with a video expert.

 

Contact Us

 

The post Why Aren’t My Ads Playing? appeared first on JW Player.

How to Build the Perfect Video Test Page

Part 2 of JW Player’s Support Team series on video tips and tricks

There is always more than one way to do things, and certainly building websites is no exception. We are not familiar with the entire tech stack you have built on your website (a.k.a. we are not going to read through your minified code), but we are experts when it comes to JW Player. This might be the first time you are trying to implement our player on a page, but we do this every day. Like those insurance commercials, we know a thing or two because we have seen a thing or two…okay, make that closer to 50,000 support cases.

 

When you come to us with a support issue, the first thing we are going to try to do is reproduce it. Here are some key data points you can tell us right away to make it even easier for us to reproduce your issue:

  • Please send us a link to a test page that contains only the HTML and Javascript code necessary to reproduce the issue. We want to eliminate external JS libraries, custom CSS on the page, etc., but more and more we are seeing things like DRM videos or keys that cannot be requested by our IP address or infinite scroll pages that require us to scroll down to the fifth article before a player appears. And you never know, maybe building this test page will help you isolate the cause without having to submit a case to us in the first place.
  • Have you listed out the reproduction steps? Do we have to click here first or seek to there before the problem occurs? Or do we have to use a specific browser on a specific OS, like IE11 on Windows 8.1?
  • If your ads are not playing, have you asked your ad network for a sample ad tag that fills 100% of the time? In most of the cases we get about this, our player is doing everything correctly. The only problem is that the ad network is not sending us an ad to play!

 

Here’s another fun tip that might be new to you:

If you are using a single-line embed code from your JW Dashboard on your page and something is not quite right, you can also quickly test that same embed in a JW preview page. “How quick is it, Todd?” Simply copy the script URL ending in .js and paste it into a new browser tab. But before you press Enter to load the page, change the .js at the end to .html and then load that .html page. (This .html page just happens to be the same URL we use for <iframe> embeds.)

Boom, you now have a test page with only that embed code’s player settings and video content. If the problem does not exist on this page, there must be something else on your page conflicting with our Javascript or CSS. If the same problem occurs on the JW preview page, submit a case and tell us what is going on. Sounds like you found a bug in the player or something with that video encode is not quite right.

 

While we’re on the topic of tips and tricks, here are some other hopefully quick fixes:

  • How are you loading the player on the page? If you are using a self-hosted player and you are not using the latest and greatest version from our production channel, the first thing we are going to do is test in the latest version. Perhaps that bug has already been squashed in the latest release!
  • Which player configuration options are you passing in the setup() call? Perhaps you are overriding a player default that was set in the dashboard and you were not even aware it was happening…
  • Who is hosting your content? If your content is encoded and hosted by JW Player, then I would not expect CORS errors, for example. If your video was encoded by someone else, does the same issue occur when you upload the video to your JW Player account and our encoders have a try?

And in the next blog post, we dive headfirst into the wonderful world of why your ads are not playing…

 

Hope this is useful. Please let me know how else I can help,

Todd

Director, Technical Support Team

todd@jwplayer.com

 

For more posts from the Support Team series, click here.

 

To learn more about how JW Player can support your video business, schedule time to talk with a video expert.
 

Contact Us

The post How to Build the Perfect Video Test Page appeared first on JW Player.

Webinar Recap: Per-Title Encoding Netflix-Style Optimization for Quality and CDN Costs

In a recent webinar, Bitmovin Product Manager Daniel Hölbling-Inzko spoke with our Developer Experience Manager, Kieran Farr, about using Per-Title Encoding optimization to achieve 200% better video quality while reducing delivery costs. Publishers and platforms with diverse content libraries have a big challenge – how to encode all this content to optimize for quality without […]

The post Webinar Recap: Per-Title Encoding Netflix-Style Optimization for Quality and CDN Costs appeared first on Bitmovin.

HTML5 Guide for Broadcasters: DRM and Advertising in a Flash-Less World

Steve Jobs was the first to announce Adobe Flash’s impending doom during the reveal of the original iPhone in 2007. Since then, plenty of ink has been spilled about Flash’s impending death, seemingly always just a few years on the horizon as browser makers chipped away at support for the ubiquitous multimedia plugin. Now, finally, […]

The post HTML5 Guide for Broadcasters: DRM and Advertising in a Flash-Less World appeared first on Bitmovin.

A Guide to VAST Errors

Refer to our comprehensive list of VAST error codes if ads don’t run as they should

VAST video error codes enable the JW Player to report more specific details back to the ad servers when ads don’t serve properly.

The player uses the <Error> element to provide this feedback. This element is typically nested within the <InLine> or <Wrapper> element of the VAST response. In turn, an <Error> element includes a URI that provides a tracking resource for the error. This error-tracking resource is called when the video player is unable to display the Ad.

The following example is a sample VAST response that includes the <Error> element for an Inline Ad.

<InLine>

<Error>

<![CDATA[http://adserver.com/error.gif]>

</Error>

</InLine>

An error for an Inline Ad that is part of a chain of wrapper ads will produce an error for each of the wrappers used to serve the Inline Ad. An <Error> element is also provided at the root VAST level and is primarily used to report a “No Ad” response, also known as empty VAST response.

To pull a VAST error report using Google DFP, navigate to the Reports tab and select All Queries. When creating a New Query, click to toggle all Video errors.

Using Google DFP, a video player can trigger some errors but still play the ad (for example, 200-203, 600, 601, 603, 604). It’s important to recognize that not all error codes break the video creative from serving.

 

For a comprehensive list of all VAST error codes please refer to the list below:

Errors with XML document

100 = XML parsing error.

101 = VAST schema validation error.

102 = VAST version of response not supported.

 

Errors with Creative

200 = The video player received an ad type that it was not expecting and/or cannot display.

201 = Video player expecting different linearity.

202 = Video player expecting different duration.

203 = Video player expecting different size.

 

Errors with Wrapper

300 = General Wrapper error.

301 = Timeout of VAST URI provided in Wrapper element, or of VAST URI provided in a subsequent Wrapper element. (URI was either unavailable or reached a timeout as defined by the video player.) This can be caused by HTTP serving to HTTPS.

302 = Wrapper limit reached, as defined by the video player. Too many Wrapper responses have been received with no InLine response. This can be caused by a circular loop of daisy chaining (one network bouncing to another and another).

303 = No Ads VAST response after one or more Wrappers. When working with third-party networks, the fill-rate can be less than 100%. If so, this is an expected error.

 

Errors with linear VAST tag

400 = General Linear error. Video player is unable to display the Linear Ad.

401 = File not found. Unable to find Linear/MediaFile from URI.

402 = Timeout of MediaFile URI. Potential cause could be showing video ads in an autoplay environment, while the window is not in focus or due to low bandwidth, or poor website implementation with competing requests that delay loading of the media file.

403 = Couldn’t find MediaFile that is supported by this video player, based on the attributes of the MediaFile element.

405 = Problem displaying MediaFile. Video player found a MediaFile with supported type but couldn’t display it. MediaFile may include: unsupported codecs, different MIME type than MediaFile@type, unsupported delivery method, etc.

406 = A mezzanine file was required but not provided.

407 = The mezzanine file was downloaded for the first time, so the ad did not serve.

408 = The ad returned in the VAST response was rejected.

409 = The interactive creative defined in the InteractiveCreativeFile node was not executed.

410 = The code referenced in the Verification node was not executed.

 

Errors with nonlinear VAST tag

500 = General NonLinearAds error.

501 = Unable to display NonLinear Ad because creative dimensions do not align with creative display area (i.e. creative dimension is too large).

502 = Unable to fetch NonLinearAds/NonLinear resource.

503 = Couldn’t find NonLinear resource with supported type. This can occur when a creative size is larger than the player size.

 

Errors with Companion banner

600 = General CompanionAds error.

601 = Unable to display Companion because creative dimensions do not fit within Companion display area (i.e. no available space).

602 = Unable to display Required Companion.

603 = Unable to fetch CompanionAds/Companion resource.

604 = Couldn’t find Companion resource with supported type.

 

Errors with VPAID

900 = Undefined Error. Even if you request VAST 3 or your DFP network default is VAST 3, this can occur if you have a VAST redirect that returns a VAST 2 response.

901 = General VPAID Error. This can occur when the “IMA Adapter” tag from Ad Exchange is used with the IMA SDK, and a VPAID ad is returned. You should use the “Direct SDK” tag from Ad Exchange when using the IMA SDK.

 

For more on how JW Player can support your video monetization, schedule time to talk with one of our video experts.

 

Contact Us

 

The post A Guide to VAST Errors appeared first on JW Player.

JW Player 8: Let’s Talk About Speed

We’re proud to introduce JW Player 8 — our fastest, most flexible, and advanced player yet. This release is the culmination of what we’ve learned about publisher needs and optimal viewing behavior since our last major iteration of JW Player nearly two years ago. The improvements we’ve made center around three themes:

  • Player speed
  • User interface customization
  • Industry-leading support

Leading up to the launch of JW Player 8 this fall, we will highlight each theme in detail in a three-post blog series. Today’s post will focus on how our advancements in speed will improve the viewing experience and increase engagement for your audiences.

The End of Buffering

A universal truth: viewers hate buffering

 

Did you know? An Akamai study discovered that video abandonment rate increases by 6% for every second of load time beyond two seconds. A separate study on OTT viewership showed that buffering increases negative emotions by 16% and decreases engagement by 20%. These two studies strongly indicate that poor playback is the biggest barrier to publishers achieving more views and higher engagement.

JW8 was built to tackle poor viewing experiences by improving player speed. Our goal is to provide sub-second load times across all devices and browsers so viewers never see a buffering screen. Our performance enhancements pave the way to  fast and high quality playback for all viewers at all times, so you never have to worry about your content investments going to waste.

Light as a Feather

 

JW8 detects the viewer’s rendering environments and loads only the necessary components required for playback. Based on a combination of the media type contained in playlists and the viewer’s browser, we’ve optimized the player to make fewer network requests for the most common use cases of video playback, reducing latency costs associated with setup times.

Not only is JW8 faster on its own, we’ve also taken your entire website into account by engineering a more lightweight player. Imagine the typical website that has video content. These days, websites also load scripts for analytics, ads, and design elements, each one competing as the browser renders the page. The page ends up taking a long time to load, which increases viewer abandonment. Compared to JW7, JW8’s embed script is more than 50% smaller and makes fewer server requests to better interact with the overall composition of modern webpages. By implementing JW8, you can be rest assured that JW Player is actively reducing its footprint to improve your entire website experience.

More Speed with Less Bandwidth

In JW 7.2, we introduced video preloading, enabling JW Player to fetch media data before playback and as soon as the page loads. The feature was particularly useful in assuring videos started as quickly as possible. Now, JW8 improves preloadingso publishers and viewers can enjoy faster playback with reduced bandwidth.

First, JW8’s backend preloading process is smarter about when it occurs and is more precise with how much is preloaded. Second, we’ve also taken steps to optimize bandwidth consumption for publishers that load multiple video players on a single page by only preloading players when they become more than 50% viewable. Finally, JW8 players are set to load metadata by default so playback starts immediately for click-to-play players once playback is initiated. To reiterate, these preloading changes allows the player to be more intelligent to avoid wasting publisher and audience bandwidth while simultaneously improving start times.

 

We are very excited for you to experience the performance enhancements under the hood of JW Player 8. If you’re interested in taking a test drive, check in on your dashboard on September 6th to take JW8 beta for a spin,  or contact us at sales@jwplayer.com.

The post JW Player 8: Let’s Talk About Speed appeared first on JW Player.