AES-128, AES-256, SAMPLE-AES HLS decryption support

AES-128, AES-256, SAMPLE-AES HLS Content Protection

Radiant Media Player supports AES content decryption with HLS as described in Apple HLS specification and documentation. This is supported for on-demand, live or DVR streaming. We support the following AES features:

• AES-128, AES-256 and AES-256-CTR support on browsers with Web Crypto API support
• SAMPLE-AES and SAMPLE-AES-CTR (identity) support on browsers with ClearKey support

The player will automatically detect and start decoding an HLS AES encrypted stream based on the information provided in the manifest.

For instructions on how to support AES-128, AES-256 or SAMPLE-AES HLS for your streaming server, please refer to the documentation of your streaming server.

Player code example

<!-- Include Radiant Media Player - here we use the optimised build for hls.js -->
<script src="https://cdn.radiantmediatechs.com/rmp/10.1.4/js/rmp-hlsjs.min.js"></script>
<!-- Player container element -->
<div id="rmp"></div>
<!-- Set up player configuration options -->
<script>
// Passing our test HLS AES-128 stream
  const src = {
    hls: 'https://www.radiantmediaplayer.com/media/rmp-segment/bbb-abr-aes/playlist.m3u8'
  };
  // Player settings
  const settings = {
    licenseKey: 'your-license-key',
    src,
    width: 640,
    height: 360,
    contentMetadata: {
      poster: [
        'https://your-poster-url.jpg'
      ]
    }
  };
  const rmp = new RadiantMP('rmp');
  // Initialization ... and done!
  async function initRmpPlayer() {
    try {
      await rmp.init(settings);
    } catch(error) {
      console.error('Radiant Media Player failed to initialize', error);
    }
  }
  initRmpPlayer();
</script>

Advanced use cases

More information on HLS can be found here (this page includes link to up-to-date HLS specification). More information on content protection can be found here.

An additional layer of security can be provided through the use of secure token. This implementation requires a server-side component in order to be efficient. We have published a guide on how to achieve this with Wowza Streaming Engine here.

If you want to secure the key file delivery over HTTPS please refer to this Apple guide.

For added security please consider the following: "Key files require an initialization vector (IV) to decode encrypted media. The IVs can be changed periodically, just as the keys can. Current recommendations for encrypting media while minimizing overhead is to change the key every 3-4 hours and change the IV after every 50 Mb of data."

Any of the above additional security layers needs to be implemented on your side, please refer to the documentation of your streaming solution for more information on how to best implement the needed AES features for your project.