WM Format SDK DRM returns NS_E_DRM_LICENSE_NOTACQUIRED when license is delivered

I ran into an issue using the WM Format SDK DRM Stub Library the other day. When we were trying to decode and playback some DRM encrypted files we saw a “NS_E_DRM_LICENSE_NOTACQUIRED” error when using the “Audio Player” sample SDK application. The issue only occurred from certain license providers. The WM Player application did not have this problem and played back the content as expected.

I could see that the license from the 3rd party provider was getting stored properly in DRM secure store. When spying on the license store, I could also see that the license was actually valid. I used my own license server and set the rights on my server to be identical to the rights that the 3rd party was requiring. I delivered my own license and the content played in the sample application as expected. From what I could tell the licenses matched exactly. I just couldn’t figure out what the difference was between the license I was delivering and the license the 3rd party was delivering.

Finally I did a complete diff of the two licenses. That’s when I noticed that the 3rd party license was specifying various Output Protection Level (OPL) settings.

 <UNCOMPRESSEDDIGITALVIDEO level="100" />
 <COMPRESSEDDIGITALVIDEO level="400" />
 <ANALOGVIDEO level="100" />
 <COMPRESSEDDIGITALAUDIO level="100" />
 <UNCOMPRESSEDDIGITALAUDIO level="100" />

Once I noticed this, it was obvious that the DRM subsystem was not allowing the application to evaluate the license due to the fact that the application was not setup to deal with OPL. Since the application had not communicated to the DRM subsystem that it would be handling OPLs the DRM subsystem refused to validate the license and reported that the license did not exist. Unfortunately the error that was being reported was that the license did not exist. This really caused quite a bit of confusion and I spent most of my time verifying that the license was valid.

To resolve this problem all I had to do was to tell the DRM subsystem that the sample application would be handling the OPL requirements. This only requires a single line of code. All I had to do was call the “IWMDRMReader2::SetEvaluateOutputLevelLicenses” method. Once I added this line of code, the license was evaluated as expected and the content played back as expected. Keep in mind that in your own code you will need to manually evaluate and handle the OPLs required by the license. Failure to do so is a violation of your licensing agreement with Microsoft. How to do this is beyond the scope of this post but I warn you dealing with the OPL subsystem via COPP is not for the faint of heart. I would almost recommend that if you don’t have to support OPL and COPP in your application, don’t. COPP is quite simply the most painful API I have ever had the displeasure to use.

References:

IWMDRMReader2::SetEvaluateOutputLevelLicenses
https://msdn.microsoft.com/en-us/library/aa388092.aspx

You can find the definitions of the OPLs here:

https://download.microsoft.com/download/b/7/a/b7a9aeae-d9f2-435b-a2dc-f3b0909d1d62/A_Technical_Overview_of_WM_DRM_10_for_Devices.doc