If you are using the Brightcove Native Player SDK for Android, it is very likely you are currently using the Google ExoPlayer framework for your video playback. In 2016, the Google ExoPlayer team released the second major version of the player, doing some major refactoring in the code. We then decided to give it some time before jumping onto the ExoPlayer 2 ship, so that the code would be more stable by the time of the upgrade.

In 2017 we evaluated ExoPlayer 2 and concluded it was time to make the upgrade, which will make it a great addition to the Brightcove SDK and its users.

Upgrading to ExoPlayer 2

When upgrading to ExoPlayer 2, we made a decision to keep both ExoPlayer versions in the Brightcove Native Player SDK for Android, so that you can upgrade to the SDK v6.0.1+ with minimal effort while keeping the legacy player. You can start exploring ExoPlayer 2 by modifying your build.gradle file to replace

compile project(':players:exoplayer')

with

compile project(':players:exoplayer2')

in the dependencies block. You can learn more about the migration process in the Migrating to ExoPlayer 2 Framework document.

You might be already familiar with the architectural changes made by the Google ExoPlayer team in the second version of their player, but if not, you should know the refactoring was significant with respect to the first version and there were a lot of breaking changes. Some public facing classes were renamed, some others were removed and there were several additions. You can check ExoPlayer 2 – New package and class names to know more about this.

A lot of effort has been taken to manage these architectural changes in the Brightcove Native Player SDK for Android, in order make the upgrade process to ExoPlayer 2 as effortless as possible. If your application is using only the Brightcove classes, the effort to upgrade should be minimal. However, if you are using any exposed ExoPlayer legacy classes, or some of the ExoPlayerVideoDisplayComponent internal listeners, which depend on ExoPlayer callbacks, it is likely you will encounter some breaking changes . If you encounter any errors, please check the breaking changes section of the Migrating to ExoPlayer 2 Framework document. If you have a different error or have further questions, feel free to make a post in the Brightcove Native Player SDKs forum and we will more than happy to assist.

Benefits of upgrading to ExoPlayer 2

The ExoPlayer 2 in the Brightcove Native SDK for Android offers the same features as with the legacy ExoPlayer. That includes easy Video On-Demand (VOD) playback with support for multiple audio tracks and closed captions such us WebVTT and EIA-608, Widevine Modular protected content playback, client-side advertising with Google Interactive Media Ads (IMA) and FreeWheel, support for Android TV and Fire TV, Video 360 and Offline playback. It also includes full integration with Brightcove Services like VideoCloud and Dynamic Delivery.

With ExoPlayer 2, the Google ExoPlayer team has added newer features to their framework, improved support for existing features and fixed a lot of bugs, making ExoPlayer 2 more robust and reliable. This enabled us to move away from our forked ExoPlayer version used in the legacy player, where we had a lot of custom code, especially around HTTP Live Streaming (HLS) for VOD and Live playback. Our goal is to keep using the Google ExoPlayer directly, rather than a fork, so that future updates can be applied faster and more frequently.

There have been many improvements and additions in important areas of the ExoPlayer 2 framework:

• Full support for DASH multi-periods.
• Additional crypto schemes for DRM and support for offline licensing.
• Better handling for ID3 malformed metadata is included.
• Better support for WebVTT and EIA608 captions.
• Improvement when seeking forward within buffered content, making it really fast and efficient.

By using the Brightcove Native SDK for Android with ExoPlayer 2, your app will be automatically making use of all these enhancements.

As mentioned above, ExoPlayer has also improved substantially its support for HLS:

• Adding or improving support for HLS tags such as EXT-X-DISCONTINUITY, EXT-X-START, EXT-X-DISCONTINUITY-SEQUENCE and EXT-X-PROGRAM-DATE-TIME.
• Added support for the usage of average bandwidth when available in the HLS master playlist.
• Better support for MPEG-TS in several aspects.
• Several utility methods to identify and work with live content.
• Better handling of the BehindLiveWindowException, an enhancement which has been leveraged by the Brightcove Native Player SDK for Android to provide a better experience with HLS Live.

You can check the full list of additions and fixes in the ExoPlayer 2 library in its release notes .

There are certain other features that you can take advantage of by accessing the ExoPlayer 2 Player object directly. However, you must be aware that when working directly with ExoPlayer 2 classes, the chances of introducing breaking changes to your code increases when new ExoPlayer versions are released. You can access the ExoPlayer instance through the getExoPlayer() method in the ExoPlayerVideoDisplayComponent class. We are currently using the SimpleExoplayerInstance, so you can cast it to this object and use its utility methods, as shown below.

ExoPlayerVideoDisplayComponent displayComponent = (ExoPlayerVideoDisplayComponent) brightcoveVideoView.getVideoDisplay();
ExoPlayer exoPlayer = displayComponent.getExoPlayer();
if (exoPlayer instanceof SimpleExoPlayer) {
   SimpleExoPlayer simpleExoPlayer = (SimpleExoPlayer) exoPlayer;
}

One example of a feature you might be interested in could be setting a variable speed playback with ExoPlayer .

If you have not already done so, we strongly suggest that you consider upgrading to ExoPlayer 2, as we have deprecated our support for the legacy ExoPlayer framework.

To view our Partner blog, click here

One of the innovations we talked about at Brightcove PLAY was an exciting feature we’ll be adding to Dynamic Delivery over the rest of 2018 — Delivery Rules. We gave you a quick preview during the keynote, but we wanted to give you a bit more insight into why we think Delivery Rules will be important and some of the wide range of options that will be enabled as we roll it out.

Solving Fragmentation Challenges

One of the main challenges we embarked to solve with Dynamic Delivery was fragmentation. Consumer devices have many different operating systems, firmware, and chipsets. Because of that, they support various different codecs, package formats, and DRM schemes. Dynamic Delivery allows us to simplify supporting all these devices because it can repackage content to multiple different formats, all from a single intermediate format.

But that’s only part of the equation. Some devices only support a particular version or particular features of HLS; others don’t like it when you include more than one audio track. To fully address the needs of users, we need to customize the delivery for each device. To deal with this, we’ve built intelligence into Dynamic Delivery to know about the differences between these platforms and automatically modify the content as it’s being delivered. This has been incredibly powerful as it’s allowed us to ensure that content will play back seamlessly across many different devices, despite all the fragmentation.

What we announced at PLAY is that we will be opening up many of these capabilities to our customers so you can directly modify the content being delivered based on your business goals and needs.

What Controls are Available and What Can They Do?

With Delivery Rules, you will be able to configure a set of if-then statements that control the user experience. The “ifs” are the triggers for behaviors and will include things such as device type, user location, or a signal from your application. The “thens” are the behaviors that are triggered and will include things such as the characteristics of the renditions returned and which CDN to utilize to deliver the media.

Let’s look at some examples of what Delivery Rules will enable you to do:

Example One: Multiple Subscription Tiers – A common model in SVOD services is to offer two subscription tiers — SD and HD. Based on a signal from your application (the “if”), you could tell Dynamic Delivery to return a manifest that only contains SD renditions for your standard users and the full set of HD renditions for your premium providers (the “then”).

Example Two: Geography Optimized CDNs – While most CDNs are optimized for worldwide distribution, there are certain areas that are better served by a region-specific CDN. China is particularly unique in that, for optimal delivery, an in-country CDN must be used. With Delivery Rules you can create a rule that automatically detects if the viewer is located in China (the “if”) and utilizes a China-specific CDN for those requests and a global CDN for all others (the “then”).

Example Three: Device Optimized Renditions – With consumers viewing media from a variety of screen sizes it’s less than ideal to deliver the same set of renditions to each device. With device rules you could create a rule that detects if the device is a phone (the “if”) and excludes 1080p renditions (the “then”). You could then have a complimentary rule that detects if the device is an OTT device (the “if) and excludes renditions below 360p (the “then”).

As you can imagine, the combinations are endless.

We’re excited to be giving you access to even more of the power in Dynamic Delivery to allow you to customize delivery behavior to meet your unique business objectives. We’ll be releasing Delivery Rules in phases over the rest of this year and can’t wait to see what you do with it. In the meantime, if you’d like to learn more, talk to your Account Manager for more details.

To view our Partner blog, click here