Brightcove Player v7.0.0-2

Brightcove Player 7.0.0-2 is available as a pre-release for manual update.

No existing players have been auto-updated to this version. Customers eager for a feature or fix that is only available in this version may manually update via the Studio Players JSON Editor or the Player Management API.

NOTE: There is currently an issue with v7.0.0-2 that renders most Brightcove Player plugins incompatible. These incompatibilities are being addressed and we intend to have fully compatible versions of all plugins available on launch of v7.0.0!

Also, the new Title Bar is not correctly populated in this version, but will be in the next pre-release.

Brightcove Player 7 is coming!

For additional details about the changes coming in Brightcove Player 7, please refer to the release notes for Brightcove Player 7.0.0-0

All Changes in This Release

There will be additional notes on Video.js 8.0.0 and Video.js HTTP Streaming 3.0.0 changes in those projects' release notes when they are finalized. The notes here focus mainly on Brightcove Player changes.

Migration Notes

More complete migration notes and documentation for new features will be available upon full release of v7.0.0.

MN1

Sending the play_request event to the Data Collection API will occur only once for each new media source. Previously, the play_request was sent each time playback was requested; whether the initial user request or autoplay or resuming from pause.

This change makes the play_request event more meaningful - particularly in understanding the impact of autoplay - in Brightcove Analytics and aligns the Brightcove Player with our SDKs.

Adjust your expectations on the frequency of this event. Any code that assumes it will occur with any playback request should probably use the play event instead.

MN2

The "graphite" skin was an older style skin that was a holdover from the earliest versions of the Brightcove Player. It is removed.

No migration needed: "skin": "graphite" in a player configuration will simply be ignored.

This configuration may still be used to disable the default skin using "skin": false. This advanced capability is for customers who want to write their own player skin from scratch. All other values will be treated as the default skin (which will be the equivalent of "skin": "sapphire" in 6.x).

MN3

The not-hover class name was added in the earliest versions of the Brightcove Player 6.x to indicate when the controls should hide.

This class is replaced by vjs-hide-controls, which is more descriptive and better matches Video.js naming conventions.

Change any uses of .not-hover to .vjs-hide-controls in your stylesheets or scripts.

MN4

IE11 and Flash will no longer function with the Brightcove Player. No migration is needed.

MN5

Most of Brightcove Player 7 is no longer transpiled into ES5 code - including Video.js and VHS. Most code is now transpiled to target modern browser engines.

Code that attempts to inherit native ES6 classes, but is ultimately transpiled to ES5 will no longer work with Video.js 8 and Brightcove Player 7. This incompatibility will generally be surfaced by an error being thrown with a message like:

TypeError: Class constructor ___ cannot be invoked without 'new'

This is because transpilation tools like Babel will convert classes into plain JavaScript functions and attempt to call apply() or call() on them. These methods exist on functions, but not ES6 classes.

The only solution is to not transpile ES6 classes to ES5 for use with Video.js 8 and Brightcove Player 7.

MN6

Prior to 7, the Player would trigger analytics_request events and analytics_request_* events where * stood for the analytics beacon event name. For example, when the player sent a beacon representing a video_engagement event, the player would trigger both analytics_request and analytics_request_video_engagement.

In general, we want to be consistent in our naming and, for events, this means (most of the time) that we want lower-case-hyphenated event names. Further, when we discuss the small HTTP requests we send to our Data Collection API, we tend to refer to them as “beacons”, so we are using that terminology as well.

We’ve renamed these events to be analytics-beacon and analytics-beacon-* where the * stands for the analytics beacon event name with _ replaced by -.

For example, if you wanted to know when the player sent a video_engagement event beacon, you could do something like this:

player.on('analytics-beacon-video-engagement', (e) => {
  // The event object in the callback contains a `params` object, which
  // has a JavaScript object representataion of the query params that
  // were sent to the Data Collection API.
  player.log('video_engagement beacon sent!', e.params);
});

MN7

Migration necessary only if integration code interacts with the player “dock” components. This is unlikely to impact the vast majority of Brightcove customers!

We removed the internal videojs-dock plugin and re-implemented similar functionality in a new core component for Video.js: the TitleBar component.

The new TitleBar component will show a UI element across the top of the player which displays the title and/or description of the current media in the player. The TitleBar will not show if no title or description is provided.

Brightcove Player 7 will populate the title bar using data from the Playback API.

MN8

Brightcove Player 7 when embedded in-page no longer recognizes the autoplay query parameter or t query parameter (or any other query parameter for that matter).

Query parameters are an ideal way to provide data at the embed code level for iframe embeds, but for in-page embeds, they would need to exist in the embedding website’s URL.

These two parameters were previously supported because older versions of Internet Explorer required workarounds for the Fullscreen API, which was not adequately supported. However, they caused several customers some confusion when their own web page URLs included these parameters, generally for other purposes, but they impacted the behavior of the their embedded Brightcove Player!

If you were relying on this support in some way, we recommend switching to the autoplay attribute, option, or player configuration or the data-start-time attribute for your in-page embeds - or implementing this functionality via JavaScript.

MN9

Migration necessary if using legacy playlist implementations, controlled by top-level JSON configurations - i.e. not through Studio or the plugins array in JSON configuration.

With the earlier Player versions, there were multiple legacy playlist plugins/implementations and methods of configuration. Maintaining multiple playlist implementations caused a significant amount of confusion and complexity, so we’ve simplified and clarified playlist implementation by removing all the legacy playlist code.

In short, all top-level playlist-related configurations are no longer supported in JSON configuration for Brightcove Player 7.

These include:

The top-level playlist configuration could be used in two ways:

However, it had no impact on the modern Brightcove Playlist UI plugin that people use today in the Studio.

The migration path for playlists is to always use the Brightcove Playlist UI plugin, which is configurable through Studio (or the Player Management API). The old top-level configurations have never been exposed through Studio.

MN10

Migration necessary if currently using the firstplay event.

The firstplay event was removed. This was a deprecated, legacy event that was fired by Video.js the first time a play event was fired. However, there’s a better way to hook into the first play event for a given media source, using the one() method:

// Each time the source is about to change, listen for the first play event.
// Listening for loadstart is another option.
player.on('sourceset', () => {
  player.one('play', callback);
});

MN11

Migration necessary if currently using this function to extend Video.js classes.

The extend() function was previously used to extend Video.js components and advanced plugins.

We are now using native ES6 classes everywhere and the old videojs.extend() function only works with plain function prototypes, making it unusable with the native ES6 classes that make up Video.js 8. So, it has been removed.

For example, the old way to create a component using extend() was:

const Component = videojs.getComponent('Component');

const MyComponent = videojs.extend(Component, {
  constructor: function(player, options) {
    Component.call(this, player, options);
  }
});

videojs.registerComponent('MyComponent', MyComponent);

Going forward, only ES6 classes are supported. The equivalent would be:

const Component = videojs.getComponent('Component');

class MyComponent extends Component {
  constructor(player, options) {
    super(player, options);
  }
}

videojs.registerComponent('MyComponent', MyComponent);

Users whose integration code depends on videojs.extend() will need to update their implementations before updating to Brightcove Player 7.