Common Encryption and MS PlayReady

[Greg Rutz]

I'm doing some experimenting with using MP4Box to encrypt DASH content using Common Encryption and Microsoft PlayReady DRM. I have developed some tools that will generate keys that can be used against a test license server that MS provides. I am trying to encrypt some of the content in this dataset using the following command line:

MP4Box -crypt playready_enc.xml mp4-onDemand-h264bl_low.mp4 -out mp4-onDemand-h264bl_low-enc.mp4

Here is playready_enc.xml:

<GPACDRM type="CENC AES-CTR">
  <DRMInfo type="pssh" version="0">
    <BS ID128="9a04f07998404286ab92e65be0885f95" />  <!-- PlayReady SystemID -->
    <BS bits="32" value="385" />  <!-- PlayReady Header Object Size -->
    <BS bits="16" value="1" />    <!-- Number of records -->

    <!-- First record -->
    <BS bits="16" value="1" />    <!-- Rights Management record type -->
    <BS bits="16" value="379" />  <!-- Record length -->
    <BS dataFile="playready_wrm.xml" dataLength="379" /> <!-- WRM in external file -->
  </DRMInfo>
  <CrypTrack trackID="1" IsEncrypted="1"
             IV_size="8" first_IV="0x7DF7C12E832F9726"
             saiSavedBox="uuid_psec">
    <key KID="0x10000000100010001000100000000001" value="0x04714BD8D7E1F3815FC47D0A834F0E17" />
  </CrypTrack>
</GPACDRM>

And here is playready_wrm.xml:

<WRMHEADER version="4.1.0.0" xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader">
  <DATA>
    <KID value="EAAAABAAEAAQABAAAAAAAQ==" ALGID="AESCTR" CHECKSUM="VOzq8ggEl1A=" />
    <LA_URL>http://playready.directtaps.net/pr/svc/rightsmanager.asmx?PlayRight=1&UseSimpleNonPersistentLicense=1</LA_URL>
    <DS_ID>EAAAABAAEAAQABAAAAAAAQ==</DS_ID>
  </DATA>
</WRMHEADHER>

In the output file, I expected a 'pssh' box to show up in the first 'moov', but it is buried down in the file about 400Kb in (and it is not properly formed -- there are some non-ascii characters in the middle of the WRMHEADER element name). Also, the entire MP4 file doesn't look properly formed when parsing it with something like isoviewer. Can anyone see a problem with my GPACDRM? Anyone care to try to reproduce this to see if you can verify my results?

G

[Greg Rutz]

From what I have learned, I think MP4Box always merges fragmented MP4 input files (unless they are being opened for debug/dump purposes). So, it doesn't look to me like it is possible to encrypt a DASH'd media file. Please correct me if I am wrong.

If I wanted to add this feature to MP4Box, would you recommend updating "-crypt" to support fragmented MP4 files? Or would you recommend updating "-dash" to also accept "-crypt"-like parameters? Any other suggestions?

G

[Romain Bouqueau]

From what I have learned, I think MP4Box always merges fragmented MP4 input files (unless they are being opened for debug/dump purposes). So, it doesn't look to me like it is possible to encrypt a DASH'd media file. Please correct me if I am wrong.

Right. ATM you need to re-dash your content to add CENC.

Adding segment-based addition of CENC requires quite some work for some really technical reasons. If you work for a company and wish to contribute, please use this contact form: http://www.gpac-licensing.com/Contact/

If you have specific questions, please let us know.

Romain

[Greg Rutz]

So, are you saying that it should be possible to encrypt a piece of content and then DASH it? Seems like that would not be possible since you need to be able to inspect the coded video to find proper places to segment. (and that is what I'm seeing -- when I try it, MP4Box says that the file is not a proper ISO BMFF file.

G

[Jean Le Feuvre]

The DASH'ing process does not involve any video header inspection. The following works out of the (MP4)box :

MP4Box -crypt drm_file.xml src.mp4 -out test.mp4
MP4Box -dash 1000 -profile live test.mp4 

[Greg Rutz]

Excellent! Thank you for your reply. I will investigate my particular situation further to see what is going wrong.

G

[Greg Rutz]

OK, here is what I have found. As indicated in my crypt.xml file, I chose "uuid_psec" as my SAI box type. When MP4Box encrypts that content it adds a box of FOURCC type 'uuid' that contains the sample encryption information. However, when reading the encrypted input file for dashing, the following code is not getting called:

src/isomedia/box_code_base.c -- stbl_AddBox()

    case GF_ISOM_BOX_UUID_PSEC:
        ptr->piff_psec = a;
        return gf_isom_box_add_default((GF_Box *)ptr, a);

GF_ISOM_BOX_UUID_PSEC has a FOURCC of 'PSEC'. If I change this code to read:

    case GF_ISOM_BOX_TYPE_UUID:
    case GF_ISOM_BOX_UUID_PSEC:
        ptr->piff_psec = a;
        return gf_isom_box_add_default((GF_Box *)ptr, a);

...things start working for me. Now, I doubt this is right fix, since GF_ISOM_BOX_TYPE_UUID is already defined and used elsewhere, but this change allows my DASHing to proceed to completion. The encrypted DASH content does not play in my player, but that is the next step in my investigation.

G

[Greg Rutz]

One other question regarding DASH'd encrypted files. I notice that the "codecs" attribute of the Representation (RFC 6381 codec name) is "cenc" when DASHing my encrypted files. I see that the code is setting the codecs parameter to the scheme type field of the 'sinf' box. Is this correct? I wonder if the original codecs attribute should be maintained since the ecrypted status of the track is communicated by the ContentProtection element in the MPD. The client may be able to decrypt the media, but if it doesn't know what codecs are in use, the player application can't reject the representation before trying to actually play it.

G

[Jean Le Feuvre]

Thanks for your testing and feedback !

1- For the PIFF bug, it's now fixed on SVN
2- For your DRM sample file, the data length you provide is in text mode, not binary mode, which truncated the end of the file ... You can now (SVN) use either 0 for the size (whole file imported), or set the attribute textmode="yes" to change the file open mode.
3- For DASH it was indeed not supported, now fixed on SVN (using ContentProtection).

happy testing !

[Greg Rutz]

Thank you! All your fixes are working wonderfully now!

[Matt Stevens]

Hi Greg / Jean,

I'm trying to create a playready encrypted dash stream based on the example in this thread. I'm using the same playready_enc.xml, playready_wrm.xml and test mp4 video above against the latest trunk of gpac, but I'm currently unable to play back the stream.

I'm using IE11 on Windows 8.1 in Virtualbox using the following EME compatible test player: http://dash-mse-test.appspot.com/dash-player.html?autoplay=on&adapt=auto&flavor=playready

As per Jean's suggestion I added textmode="yes" attribute to data length, but wondered if anything else should be changed? (Are the settings for the MS PlayReady license server correct?)

I'm running the following 2 commands to encrypt and convert the source mp4 file MPEG dash:

MP4Box -crypt enc_playready.xml mp4-onDemand-h264bl_low.mp4 -out mp4-onDemand-h264bl_low_playready.mp4

MP4Box -frag 10000 -dash 30000 -profile live -segment-name segment_file mp4-onDemand-h264bl_low_playready.mp4

I'm able to successfully play back the dash stream if its not encrypted, albeit using a wowzer dash test player.

Any help would be greatly appreciated.

Thanks,

Matt

[Greg Rutz]

Matt -- I still do not have PlayReady content playing in IE11 either. However, here are the things I have found already.

1. Do not use VirtualBox. Microsoft requires that protected content be protected "to the glass". This means you must have WHQL signed display drivers (look for the program "dxdiag" to determine if you are using signed drivers). We had to move to native Windows 8.1 installs for our testing. Try to play the protected content at this site. Once you can play that stuff, you are good to go.
2. Microsoft PlayReady Header Objects must be UTF-16 little-endian encoded as per the documentation. This means that you must use something like "iconv" on linux (or maybe Cygwin if you are Windows) to convert your PlayReady XML file to UTF16-LE.
3. Not only does the XML portion have to be little-endian, but the bytes before that in the PlayReady header need to be as well. I have filed a new feature request and submitted a patch to provide the support we need in the MP4Box crypt XML files. [feature-requests:#57]
4. MS PlayRead only supports 8-byte IVs. But when MP4Box is writing the 'senc' box, it always writes 16-byte IVs. I have written my own fix for this, but Jean submitted a fix of his own before I could provide a patch. I haven't tried his patch yet, so comment on the bug if it doesn't work for you. [bugs:#301]
5. The ISO BMFF spec requires that SampleToGroup ('sbgp') box reference indices start at 0x1 when referencing SampleGroupDescription boxes in the sample table in the 'trak', but must start at 0x10001 when referencing ones in the 'traf'. I proposed an incorrect solution for this, but I don't think Jean has had time to create a real fix. My fix works for me for now. [bugs:#300]
6. IE11 requires that MP4 files conform to the DECE/UltraViolet Common File Format specification (a subset of ISO BMFF). According to Microsoft, this means that SampleToGroup ('sbgp') and SampleGroupDescription ('sgpd') boxes must exist together in the 'traf' box. [feature-requests:#56]
7. See this thread [fd74a7d0] with respect to my question about "cypherOffset". I don't quite understand what this is, but I believe that it inserts an extra byte into my 'pssh' private data.

[Greg Rutz]

Here is my crypt XML file now...

<GPACDRM type="CENC AES-CTR">
  <DRMInfo type="pssh" version="0">
    <BS ID128="9a04f07998404286ab92e65be0885f95" />  <!-- PlayReady SystemID -->
    <BS bits="32" value="764" endian="little" />  <!-- PlayReady Header Object Size -->
    <BS bits="16" value="1" endian="little" />    <!-- Number of records -->

    <!-- First record -->
    <BS bits="16" value="1" endian="little" />    <!-- Rights Management record type -->
    <BS bits="16" value="758" endian="little" />  <!-- Record length -->
    <BS dataFile="playready_wrm_v4100_utf16.xml" dataLength="0" /> <!-- WRM in external file -->

  </DRMInfo>

  <CrypTrack trackID="1" IsEncrypted="1" IV_size="8" first_IV="0x7DF7C12E832F9726" saiSavedBox="senc" >
    <key KID="0x10000000100010001000100000000001" value="0x04714BD8D7E1F3815FC47D0A834F0E17" />
  </CrypTrack>
</GPACDRM>

[Andrew Sinclair]

Greg,

Were you able to get this play anywhere? Even if packaged as Smooth instead of DASH?

[Francesco Giuffrida]

I found this thread very interesting as I'm playing to use GPAC for Dashinga and encrypting content using CENC, with the objective to play on Android.
In my tests I have 2 issues:
1) the only content that result playable on android when dashed is limited to the initial Greg's dataset: http://download.tsi.telecom-paristech.fr/gpac/DASH_CONFORMANCE/TelecomParisTech/mp4-onDemand any other content I tried result not playable on android (h264/aac)
2) I then tried to first encrypt and dash the content. The Intermediate encrypted file looks ok and contain the pssh atom with the playready header. I customized the stream.mpd to include the PRO header, but when playing from android I never get a license request from the license server (as it was a non encrypted file)

Any Ideas?
Thanks