Embedding Player V4: General Recommendations

This article offers a breakdown of some general best practice recommendations when you are embedding Ooyala Player V4.

Always use OO.ready when creating a new player

Player V4 requires all of its critical resources to be loaded before player initialization. While the use of the OO.ready API does not provide any performance benefits, player creation is not guaranteed to succeed if not executed within the context of the OO.ready callback.
Note: Initializing the player after the DOMContentLoaded event is not a substitute for OO.ready. You are free to use DOMContentLoaded, but it’s still necessary to use OO.ready when initializing the player from within the DOMContentLoaded handler, otherwise initialization might fail depending on the timing.
Example:
var player;
var playerParams = {}; 
                    
OO.ready(function() {
  player = OO.Player.create('oo-container', 
'5kbmU5MzE6ivgWkobhscmQwGuD7fyNIa', playerParams);
});

Use standard embed

Standard embed allows loading most of the player resources (player core script, plugin scripts and stylesheets) using a single http request. Reducing the number of requests going out to the player.ooyala.com domain will free up connection resources in the browser which can be used to download other resources in the page.

Parsing a large JavaScript file is still a resource-intensive operation, so unless the standard embed script is loaded asynchronously, the performance gains of using it will be mostly network-related.

Another common downside of downloading a single large file is that caching will be less effective since a small change in one of the file’s components will require invalidating the cache of the whole file. This downside is less relevant in the case of the Ooyala player since every new player release results in the invalidation of the all the cached player resources.

Note: This suggestion will become less relevant when using http2 since multiplexing will reduce the latency involved with requesting multiple files at once. At the time this was written, Ooyala-hosted player resources still use http, so the recommendation still applies. Remember that multiplexing is not a silver bullet, so bundling resources might still apply in some cases (see http://engineering.khanacademy.org/posts/js-packaging-http2.htm.
Example:
<script src="//player.ooyala.com/core/player_branding_id"></script>
<script>
var player;
var playerParams = {};
                    
OO.ready(function() {
  player = OO.Player.create('oo-container', 'embed_code', playerParams);
});
</script>

PCODE - What it is and Why it is Important

First, what is a PCODE? Abbreviation for partner code, provider code, or publisher ID. An Ooyala-assigned API credential that is required when embedding the Ooyala Player when using the Advanced Player embed. If you are using the Standard embed, it is not a required parameter., as well as some of the Ooyala APIs.

The PCode is used for API requests. Generally, you should use the one that is assigned in the embed code for Advanced Embed or the one automatically used in Advanced Embed. The only time you may want to use a different PCode value is for Master/Sub-account setups where you want IQ data rolling up to the master account (by default, it will go to the sub account). However, using a different PCode than what is provided automatically should only be done with guidance from Ooyala Technical support to ensure your setup is correct, as incorrect setups can result in IQ data loss. For more on the PCODE page-level parameter, please see here.

Additional info about PCODEs and IQ Data and Master/Sub-Account Setups

  • If accessing Master account Backlot, data for master and subs will be shown (it rolls up), granted that the master-sub relationship exists in the database. All player and content names are resolved correctly in the UI/API (no 'Unknown' names). One thing to note here is that currently there is no way to separate the data per account, so using player-id's particular to each account is strongly recommended to be able to use player as a proxy to account.
  • If accessing Sub Account Backlot, data collected using this account's pcode will be shown. If for some reason, the player-id or asset played belongs to another account (from the master, or a sibling account), the UI/API will resolve those names to 'Unknown' since they are unknown to this particular account.

Always specify plugins when using the standard embed code

The standard embed code script url accepts a “plugins” query string parameter which allows specifying which plugins to bundle inside the script. By default the script contains several plugins which aren’t needed in all cases, so it is recommended to always specify only the necessary plugins.

Example:
<script src="https://player.ooyala.com/core/<playerid>?plugins=main,bm,ima,disc"></script>

Use inline Skin overrides instead of skin.json customizations

The more recent Player V4 versions allow customizing the skin by specifying only the subset of properties that the user wants to change. It is no longer necessary to provide a full skin.json file that contains all of the default values along with user customizations. It is also recommended to avoid using a skin.json file altogether and instead provide any overrides inline in order to avoid the extra network request.

Example:
var player;
var playerParams = {
  pcode: '1tZ2YyOrJS54quNwfWyNWCYUoNex',
  playerBrandingId: 'a931ae1f41d849acbbeee7cea03afcf6',
  skin: {
     inline: {
        skipControls: {
          enabled: true // This will enable skip controls and use default values for all other skin settings
        }
      }
    }
 };
                    
OO.ready(function() {
 player = OO.Player.create('oo-container', 
'5kbmU5MzE6ivgWkobhscmQwGuD7fyNIa', playerParams);
});

Use minified, Ooyala-hosted player resources

It is not recommended for customers to build or host their own player scripts unless strictly necessary due to the need for specific customization. Using Ooyala-hosted player resources will provide the following benefits:
  • Leverage Ooyala CDN for faster access to scripts and other resources across different regions.
  • Leverage the pre-existing caching policy of Ooyala-hosted resources.
  • Leverage automatic gzipping of Ooyala-hosted assets
  • Since browsers limit the number of concurrent requests per domain, offloading some requests to player.ooyala.com will free up some network resources for the rest of the page.
Note: Make sure to always use the .min.js or .min.css extension of the files instead of the .js or .css extensions.

Use https when loading player resources

This recommendation is not necessarily performance-related, but worth mentioning. It’s best practice for web development in general to use https whenever possible. Loading player resources over https will avoid mixed-content issues if your site itself is being hosted using https. Https is also a requirement for DRM playback on Chrome.

Example:
<script src="https://player.ooyala.com/core/<playerid>?plugins=main,bm,ima,disc"></script>
https://help.ooyala.com/sites/all/libraries/dita/en/video-platform/reference/pbv4_embed_general_recommendations.html

Was this article helpful?