Learn More

BuyDRM as an Effective and Inexpensive Training Tool

Luke DeWitt
Jun 22

At REDspace, one of our key focus areas is video, and we make sure our developers understand it thoroughly. DRM is an important piece of video delivery. BuyDRM allows our developers to ramp up on DRM in their general knowledge.

We’re lucky to deal with clients in a variety of industries who have a number of very different approaches and needs. Our job is to make their lives easier by being able to adapt to whatever technology, workflow, or language. Ensuring that our developers understand the underlying ideology behind the approaches we take, and having a solid understanding at the low level of what we’re doing is very important and helps our developers stand out. One of our key areas of focus is video, and it’s a fundamental area of expertise we make sure our developers understand thoroughly.

DRM is an important piece of video delivery, but isn’t used by all of our clients in their day-to-day. This is what made BuyDRM such an intriguing service when we stumbled across it while searching for a way to test different DRM schemes. BuyDRM allows our developers, like myself, to ramp up on DRM in their general knowledge, but because of their attractive pricing model, it also allows us to have people not only implement DRM playback, but also get experience encrypting a video with DRM attached.

First, we needed our video content. This was simple enough, I downloaded Big Buck Bunny (classic!) and then ran them through FFMPEG to add a watermark for the DRM flavor, a simple, yet elegant approach to visually differentiate the videos during playback. I created one for each of PlayReady and WideVine using the following:

ffmpeg -i bbb.mp4 -i [FLAVOR-LOGO].png \
-filter_complex "overlay=(main_w-overlay_w)/2:main_h-overlay_h" \

We decided that the best (read: simplest) solution would be to make use of open source tooling that we had familiarity with from past projects. We knew the Shaka player had great DRM support, and it would be much easier to simply use what already existed in order to get encrypted playback. The decision was also made to use the Shaka Packager, because, while not all of us are as familiar with encrypting content, the consensus was that the Shaka Packager would again let us get the encryption done quickly and correctly.

We generated a public / private keypair using the openssl tool. From there we submitted the key to BuyDRM, and downloaded their sample code that could be used to generate keys that could be used by Shaka to encrypt the actual video content. Thanks to this sample code, this process was about as painless as one could imagine. However, the fact that it spit out a key ID with dashes in it and the packager wouldn’t accept dashes certainly threw me for a bit of a loop. 

After that roadbump, it was as simple as downloading the Shaka Packager Docker image and I was off to the races. I mounted a directory with the video content to the docker container and ran the following command:

packager in=bbb-pr.mp4,stream=audio,output=./bbb-pr-enc-audio.mp4,drm_label=AUDIO in=bbb-pr.mp4,stream=video,output=./bbb-pr-enc-video.mp4,drm_label=SD --enable_raw_key_encryption --protection_scheme cbcs --protection_systems PlayReady --hls_master_playlist_output=./bbb-pre.m3u8 --keys key_id=[KEY_ID_WITHOUT_DASHES]:key=[KEY]

The process ran faster than I’d expected, and I was left with the following output:

[0420/172442:INFO:demuxer.cc(88)] Demuxer::Run() on file 'bbb-pr.mp4'.
[0420/172442:INFO:demuxer.cc(160)] Initialize Demuxer for file 'bbb-pr.mp4'.
[0420/172446:INFO:single_segment_segmenter.cc(107)] Update media header (moov) and rewrite the file to './bbb-pr-enc-video.mp4'.
[0420/172451:WARNING:simple_hls_notifier.cc(494)] HLS: Ignore unknown or unsupported system ID: 9A04F07998404286AB92E65BE0885F95
[0420/172451:INFO:mp4_muxer.cc(177)] MP4 file './bbb-pr-enc-video.mp4' finalized.
[0420/172451:INFO:single_segment_segmenter.cc(107)] Update media header (moov) and rewrite the file to './bbb-pr-enc-audio.mp4'.
[0420/172451:WARNING:simple_hls_notifier.cc(494)] HLS: Ignore unknown or unsupported system ID: 9A04F07998404286AB92E65BE0885F95
[0420/172451:INFO:mp4_muxer.cc(177)] MP4 file './bbb-pr-enc-audio.mp4' finalized.
Packaging completed successfully.

The first thing I did was open up the encrypted video MP4 file. Immediately the video started playing. I wondered what I had done wrong, but then realized that the video actually stopped working after 5 seconds of playback. This was what I would come to learn is expected and known as “the clear lead”, where the video will play back without any encryption attached while the player can retrieve a valid licence key from the provider, BuyDRM in this case, to decrypt the video.

We repeated the process above for the Widevine content, and again, the content played back flawlessly for the first 5 seconds, then locked up on.

As I mentioned, we were familiar with how easily integrating encrypted playback with Shaka player was, and we had recently built a very simple Lightning Proof Of Concept application that played back three different videos—Live, VOD, and AVOD. It made sense to simply repurpose this to play the three videos that we were creating, the unencrypted Big Buck Bunny, along with the PlayReady, and Widevine versions. Swapping the player was accomplished quickly.

We needed to configure the Shaka player to support the encrypted content playback. By adding the URLs of the BuyDRM license server to the Shaka config, our application would be ready to play our encrypted Bunny video.

  drm: {
    servers: {
      'com.microsoft.playready': 'https://pr-keyos.licensekeyserver.com/core/rightsmanager.asmx',
'com.widevine.alpha': 'https://wv-keyos.licensekeyserver.com/'

Next, we needed to make our request to BuyDRM to send us back the license key that would allow for the encrypted content to be played back. For the purpose of learning how this all worked, I simply used a hardcoded authentication XML that I generated with help from the BuyDRM documentation. The auth was good for a month, so it was fine for the purposes of learning, in reality (and in the demo that is linked at the top and bottom of the post) we’ve set up a simple Lambda function that is responsible for generating the authentication XML. This code looks as follows and uses the response from the aforementioned function in place of the placeholder:

player.getNetworkingEngine().registerRequestFilter((type, request) => {
  if (type == shaka.net.NetworkingEngine.RequestType.LICENSE) {
    request.headers['customdata'] = '[AUTHXML_GOES_HERE]';

When we send this authXML to the BuyDRM server, it will send us back a license key that will be consumed by the Shaka player and decrypt the encrypted content. Content played back as expected.

So while it seems like there’s a lot going on here, what we now have is a very simple application that plays content that is unencrypted, as well as content that is encrypted by PlayReady and Widevine. While it doesn’t teach us absolutely everything about how DRM works, it’s a very nice introduction to not only working with encrypted content, but shows us how to encrypt the content ourselves, and understand some of the flow that needs to happen for this to work.

Because BuyDRM allows us to do all of this at a much more reasonable price than what we’ve seen with other content encryption services, we’re working on some updates to some of our onboarding/training documentation at REDspace to ensure that all of our new hires get some experience running through this process.

Check out the DRM demo here!

Disclaimer: REDspace is pleased to partner with BuyDRM.

Job Opportunities

Check current job openings

Find Us

  • 1595 Bedford Hwy, Suite 168
  • Bedford, NS B4A 3Y4
  • Canada

Located in Sunnyside Mall, near Pete's.

View on Google Maps

Business Inquiries

Media & Entertainment