• DeployingSecurePlayerSDKs_BlogDesktopSlider_1920x450.png
  • BuyDRM_DeployingSecurePlayers_BlogTabletSlider_763x430.png
  • BuyDRM_DeployingSecurePlayers_BlogMobileSlider_378x300.png

Deploying Secure Player SDKs for Premium Video Content

Posted by Roman K. on Feb 6, 2019 10:00:00 AM


Secure Player Considerations in Today’s Market

  • Identify your needs and the playback platforms you are targeting.
  • Identify the feature set and user experience that you wish to support.
  • Identify your budget and decide which is more valuable money or time.
  • Realize that if you “go it alone” you may end up with a substantially longer time to market with a smaller feature set and a user experience that is left wanting.

Platforms you wish to cover

Before you start designing your premium apps that will use a secure player in it for premium content playback, think about the platforms you wish to cover and what different variants you have on them. When it comes to DRM, it may be a bit different than if we would talk about clear content as you may experience playback of DRM protected assets on some platforms because of lack of specific DRM scheme you wish to use or DRM support on the platform. For more information about this please visit the KeyOS Compatibility Matrix here.

“KeyOS Compatibility Matrix”


Some Windows desktops are covered with native Windows Applications that come from the Windows store and support  Microsoft’s PlayReady DRM, for example. Today, most desktops are covered via browsers and HTML5 web applications. Thankfully, in 2017, the W3C introduced the Encrypted Media Extensions API which baked DRM into all consumer browsers via a Content Decryption Module ensuring that DRM technology will continue to be a vital part of premium content playback.

Safari and HLS + FairPlay

If you decided to cover MacOS, be ready to write your HTML5 secure player primarily for Safari which will support HLS + FairPlay in tandem. Why primarily for Safari? Well, the first and most obvious reason is that it comes pre-installed with  MacOS and is the standard browser for MacOS users. Secondly, it is impossible to predict if and for how long it will be possible to use Chrome and other browsers that support Widevine on MacOS. One only needs to go back to last year to see that Apple deprecated support for Widevine on iOS.

Chrome, Firefox and Widevine

As I have mentioned above, it is possible to play back assets protected with Widevine on MacOS . So, you are not only bound to Safari and HLS + FairPlay, you can also use MPEG-DASH and Widevine.  However, in order to do so you will need a secure player solution that supports DASH + Widevine in Safari.

Mobile devices

When it comes to mobile devices you have a little bit more choices in terms of what to use to write your applications. You have native applications that are based on OS APIs and you have HTML5 web applications that will use the device browser, in one way or another to run.

“KeyOS Compatibility Matrix”

Native vs. Web Applications

These days, companies are moving towards an “appless" user experience which means that the end-user doesn’t need to install a specific native application from the app store to be able to reach the content your media platform provides. 

And, if you think about it, its only logical. Why do you as developer need to write native apps for different platforms when you could use a single HTML5 app, which can run on different platforms and not have the pain of managing multiple projects in your repositories?

It is also less headache from end user’s stand point. Why would a user need native apps installed from stores when they can use browsers on their device instead? Additional apps take space and may compromise data on their device. They also don’t want to download dedicated apps when they board a plane or a bus, or take a cruise. It is only logical that I must use a browser and HTML5 written rich web apps with players embedded to watch my favorite series and listen to my favorite podcasts during my short 20 minute ride from home to work, right?

As Gabe Elton mentioned in his recent post "App-less" DRM - Nirvana or Pitfall, there are pros and cons of using web apps instead of native applications. If you really think about it, little has changed since fifteen or twenty years ago in terms of what kind of application must be used for what purpose. Yes, modern browsers and devices allow you to use web pages to compose music, draw pictures even play games but those are not yet close to native applications when it comes to productivity and feature richness.

Appless DRM Image


When using web applications you get:

  • Cross platform applications. You write code once and use it everywhere.
  • Faster roll out to the market.
  • Appless approach when end users are not asked to install separate native application on their devices just to be able to access media library on your plane.

But you also lose something:

  • You get lower performance and may experience lags during content playback.
  • You drain your battery faster;
  • You are not safe against changes that companies behind your favorite browsers may make. As an example: Widevine support in Safari on MacOS which was removed shortly after it was discovered. Another example: early release of FairPlay support on iOS in Safari which was also removed shortly after it was found.
  • Not all Widevine devices support Widevine L1 when browsers are used. This means you won’t get access to UHD and HD content as studios require L1 level licenses to be used for that.
  • Your offline user experience is limited to browser’s internal storage which may allow you to get limitless quota today, but who knows how it will change.
  • Not all browsers support persistent licenses  and not all HTML5 players implement this feature.
  • You won’t be able to allow users to download content and play it offline

So, what to do? Each way has its advantages, and it may be a good idea to do both – Web applications for some cases like quick media library browsing while online, or listening to podcasts and use native apps for other cases like allowing end users to download their favorite assets in background for later offline playback while browsing through other content in your online video store, for example.

Smart TVs, STBs, Game consoles and so on

Most of these platforms either come with a native solution for video playback with DRM support, or support HTML5 web applications. You can go in either direction with these and sometimes you won’t have a choice and will just have to go one way or another.

Investigate what media formats are supported, what DRMs are supported and make a decision on based on your target playback platforms. You may find out that some older Smart TVs support Smooth Streaming + PlayReady only and you simply don’t want to go that way and wish to have single MPEG-DASH format with CENC simply because it covers more platforms w/o adding to your storage bill for additional set of files stored to support legacy devices.

“KeyOS Compatibility Matrix”

iOS devices

When using web applications on iOS devices, you can support HLS + FairPlay using Safari. Safari is the ONLY browser that offers FairPlay support on iOS so, as of today, there are no other choices.

If we talk about native apps, you can utilize AVPlayer from the AVFoundation. You get your HLS + FairPlay out of the box support, but you lack some features premium SDKs like the BuyDRM KeyOS MultiPlay SDKs may offer.

Android devices

Similar to iOS, you can use web applications and in this case you can use MPEG-DASH + CENC. Chrome and Firefox on Android both support DRM on Android devices and as for the players, there are plenty to choose from including our own HTML5 Player - WebPlay.  You could also choose from one of our many partners like Bitmovin player, THEOPlayer, JW Player, as well as open source ones like dash.js, video.js and Shaka. 

If you go with native apps, you can use ExoPlayer which works closely with Android OS APIs and gives you MPEG-DASH + CENC support out of the box. But you are again missing something premium SDKs may offer.

Oh My Gosh, just tell me already what am I missing when doing native from scratch?

Well, when doing everything from scratch you would need to worry about things someone already did for you and implemented in the secure player SDK that you can use in your native applications.

  • You would need to implement a download manager yourself. Even if the OS already provides you with download functionality, you need to think about errors and how to overcome them, how to fine tune the download manager to work in the background, to handle network switches and glitches.
  • You would need to think about secure storage of licenses and sensitive information;
  • You would need to think about device individualization in the case of PlayReady DRM.
  • Not all native players come tuned out of the box when it comes to the content playback either. You may end up in a situation when your device won’t be able to playback some asset just because the wrong codec was used by a native player or the correct codec was used wrongly and your asset simply fails to playback.

Therefore, we highly recommend using premium Secure Player SDKs like the KeyOS MultiPlay SDK’s to provide the feature set and user experience both you and your customers desire.  BuyDRM and companies like ours provide their SDKs on the market.  In our case, our SDK’s have been installed on Billions of devices around the world.  Such an undertaking results in a fine tuned and mature feature set that our customers and their users have come to expect.

DRMs to use

In most cases the DRMs to use are dictated by the platforms you cover.

Based on statistics we collect, you will most likely be using Widevine and FairPlay these days. Yes, of course, feature rich PlayReady didn’t go away, it is still used on Microsoft powered devices, older and latest Smart TVs, game consoles, but Widevine and FairPlay are clearly the dominant DRMs in the marketplace now.

Here again you have a choice whether to start using time proven DRM provider and services they offer or go your own way and use the free, unmanaged Widevine service through Google’s proxy. However, if you use a DRM provider like BuyDRM, for example, you get 24/7/365 hands-on support, globally deployed licensing infrastructure, support for Multi-DRM and a very large partner ecosystem integrated with the KeyOS Multi-DRM Platform. If you fly solo, you deal with all the license service related issues.

A Few more things that you should consider:

  • When choosing FairPlay, be ready to request the FPS certificate from Apple as you will need to provide it to your DRM provider along with Application Secret Key (ASK) and the Private Key you used to create the Certificate Signing Request (CSR). Do not forget about this as this will require time to acquire and may break your deadline if forgotten.

When choosing PlayReady especially for devices where you either directly or indirectly work with the PlayReady Porting Kit, please do not forget that you must either be a PlayReady Intermediary Licensee to be able to develop applications based on the PlayReady Porting Kit, or a PlayReady Final Licensee to be able to develop and distribute them.

"BuyDRM KeyOS MultiKey Service for Apple FairPlay DRM”

Streaming formats to use

Unfortunately, when it comes to DRM protected content, we still don’t have single format that would be supported on different platforms. Yes, there is CMAF that allows you having a single set of mp4 files and the ability to use different manifests for different platforms. You can also do HLS + Widevine (in CBC mode) to support iOS and Android and other devices that do CBC. But I would call it an exotic approach as there are either little to no clients to support these scenarios, or a very limited number of encoders that can create such type of assets for you.

We still recommend sticking with the widely used and agreed on formats like HLS + FairPlay to cover Apple products like iOS powered devices and Apple TV (TVOS) while using MPEG-DASH + Widevine/PlayReady (CENC) for everything else. There are also some devices that only support Smooth Streaming + PlayReady. If you want to cover those (old Smart TVs, for example), consider using this format as well.

Different license acquisition scenarios

There are different use cases when it comes to license acquisition. Despite the fact all license acquisition requests are based on different specifications from each DRM provider, there may be different ways to deliver requested licenses to a device from the license service. For example, you can setup your player to acquire licenses from license services directly, or you can use a proxy to do so.

Choose the license acquisition scenario that works best for your business. When you select a   DRM provider be sure to determine if your business model is supported by your DRM provider.  This is usually tied to the type of rights that you are able to enforce in the actual license and if that license can be persisted or not.  For more info on this topic please check out BuyDRM’s Whitepaper: “Creating DRM Workflows”

When it comes to SDK’s for apps it is important to determine the feature set that you want to support.  For example, the KeyOS MultiPlay SDK supports download and offline playback.  MultiPlay allows you to acquire a license prior to the download starting, or after it has finished. It also allows for license refresh if the license has expired.  You are also free to implement your own license acquisition logic which may include license acquisition retries, as well as URL rotation in the case of an error.  These are just a few of the features available with the KeyOS MultiPlay SDK’s that aren’t available natively on either platform.

Another important consideration is flexibility.  You will want to be sure the secure player SDK you are going to use for your app is flexible, or you may end up altering your infrastructure just to be able to use the selected SDK because it doesn’t support the approach you need.


“BuyDRM KeyOS MultiKey Service Licensing Workflow”

Premium SDKs for Premium Secure Applications

Hopefully the information I have provided above answers some of your questions you may have had around deploying Secure Player SDK’s on iOS and Android.

To recap:

The KeyOS MultiPlay SDKs offer:

  • Security. The KeyOS MultiPlay SDK passes 3rd party security audits every 6 months
  • Flexibility. The SDKs are flexible and don’tput any constraints on you in terms of styling, for example. It also allows for multiple license acquisition scenarios that you may find useful when implementing something exotic that suits your business model.
  • Feature rich. It provides you with advertisement plugins, analytics plugins, multitrack-audio, multi-language support, multi caption format support and more.
  • Offline support. You not only get a stable streaming experience, but you also can download offline those same assets you just watched. Most used formats are supported like MPEG-DASH, MSS or HLS protected with Widevine, PlayReady or FairPlay.
  • Chromecast and AirPlay. The KeyOS MultiPlay SDKs arecompatible with both technologies. Although the Chromecasting doesn’t come with the SDK out of the box, it can be easily added into your application without our SDK standing in your way. As for AirPlay; it is supported with HLS + FairPlay. But you will also be pleased to hear that you can AirPlay Microsoft Smooth Streaming and MPEG-DASH assets. Yes, those won’t support true AirPlay, but you can do AirPlay mirroring w/o any issues.

Covering Android and iOS

The KeyOS MultiPlay SDKs cover both theAndroid and iOS platforms. You can use Android Studio for your Android development and xCode for iOS. Both SDKs come with ready to build sample app which shows some simple use cases like stream-to-play and download-to-play.

Evaluation/Debug and Production Application Keys

One last thing you may want to know about the KeyOS MultiPlay SDKs - they are delivered to your evaluation account with an eval application key. It not only defines whether your application is ready for production or must only be used for development, it also contains different policies allowing you to use rooted devices, for example, or allowing you to do AirPlay or display your content on external monitors.

The APP Keys are divided into two groups: evaluative/debug keys and production keys. The difference between the evaluation/debug key and the production key is that the evaluation/debug key:

  • expires making you request a fresh one to continue your evaluation/development;
  • allows you to work with debug versions of the SDK enabling more verbose logging.

When you are done developing your application and ready to go into production, all you need to do is contact BuyDRM support and ask for a production key. After answering some questions to finetune the application key for your application, a production application key with no expiration will be delivered to you.

When the production key is acquired, you are ready to upload your application into Google Play, Apple App Store and even Amazon store, if you wish. A workflow diagram of this is shown below:

“BuyDRM KeyOS MultiPlay SDKs Workflow”

Hopefully you have learned some valuable information about the critical considerations necessary to successfully deploy premium apps with secure player SDKs. In our efforts to continue to be thought leaders on DRM, we publish these blogs for your review and consideration. Thank you for your time and I look forward to our next installment. If you have any questions feel free to reach out at info@keyos.com.


    Subscribe for Instant Notifications

    New call-to-action

    Posts by Topic

    see all