Re: Bug#17470 Example code

Joe Steele
steele@adobe.com<mailto:steele@adobe.com>

On Oct 30, 2012, at 11:06 AM, David Dorwin wrote:



On Tue, Oct 30, 2012 at 4:52 PM, Joe Steele <steele@adobe.com<mailto:steele@adobe.com>> wrote:

Joe Steele
steele@adobe.com<mailto:steele@adobe.com>

On Oct 29, 2012, at 2:16 AM, David Dorwin wrote:

My understanding from reading the bug is that you want to be able to call addKey() with a predetermined blob without needing to specify type or initData. This is possible and is essentially what is shown in Example 8.1

I see what you mean. I think the text for the title should be changed to remove the reference to ClearKey - this will make it more clear that this technique can be used by other key systems. However I don't think this fully captures my use case. See my next comment.


Regarding the example below, I don't think you would need the second session. You only ever need to specify type and initData if you want to use the initData in generating a license request.

I do want to specify the type and initData in generating the license request. And I want to specify additional keys as well. In my use case, the keys are in a hierarchy where some keys are specified by the content and thus would be referenced by the initData and some keys are specified by the app and thus are not referenced by the content. In that scenario, I need two sessions as the first session is merely establishing those app-specific keys as a performance measure, while the second session uses the previously provided keys along with the initData to generate the license request. Since I don't have the initData when the first session is created, I have to provide it later in a second session.

Okay, I didn't understand the use case from the example. I have some questions to help me better understand. What file format are you using? What does it mean to be an "app-specific key"? Why is adding this key a performance issue? Do I understand correctly that this key is somehow used in generateKeyRequest() to generate the keymessage containing a license request?

[steele] Taking the questions in order --
* Assuming by file format you mean the media file - we would probably be using CFF and DASH. Not sure why that is relevant?
* An example of an app-specific key would be a domain key that is issued to a particular application or for a particular set of devices.
* Adding the key is a performance issue because the initial consumption could require expensive decryption operations (e.g. RSA-2048 whitebox decryption) which take a perceptible amount of time even on desktop machines.
* Yes -- that key could then be used in generating the license request, for example being used to sign the request prior to sending. It could instead (or also) be used to consume the response license.



Given this -- I still think the example I provided is necessary.


Note that http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#dom-close currently says the keys are cleared, so I don't think you would want to call close().

I don't think this behavior is correct in all cases. There are two classes of keys - transient and persistent (or cached). I think transient keys are associated with a session and should be cleared as described. However there are other keys which are not associated with a single session and the CDM should have the option of retaining them in persistent storage. I think it would be more appropriate for the reference you pointed at to say -- "and all transient keys associated with the session to be released". Otherwise this conflicts with the note above it in Section 2 referring to maintaining cached keys and licenses.

Are you referring to "cached keys/licenses" in the addKey() algorithm? This is referring to an in-memory cache of transient keys that are known to the media element when decrypting frames. (An earlier version specified a FIFO to handle the case where the CDMs key storage might be exhausted.)

Regardless of persistence, I don't think you should close a key if you want to continue to use it with the current media element.

[steele] That's a good point. So I will still require two sessions to be created, but the second session must be retained in order to keep that key alive in the CDM cache. Since it is not associated with a media element, I will have to clean it up when the app closes. That works for me.




David

On Tue, Oct 16, 2012 at 11:44 PM, Joe Steele <steele@adobe.com<mailto:steele@adobe.com>> wrote:
If no-one has any comments on this example code -- would the editors please take an action to add this to the spec in the appropriate place?

I think adding this as section 8.5 with a title of "Pre-loading keys during page-load" would work well.

Joe Steele
steele@adobe.com<mailto:steele@adobe.com>

On Oct 15, 2012, at 11:54 AM, Joe Steele wrote:

I had an request from two meetings ago to produce some example code for pre-loading a MediaKeys instance independent of the HTMLMediaElements that the MediaKeys object may later be attached to.

Here is the example I propose:
--------
<script>

var cdm;

// Preload some keys when page loads
function load()
{
  // Create a MediaKeys instance for the desired CDM not associated with an HTMLMediaElement
  cdm = new MediaKeys("com.example.somesystem");
  if (!cdm)
      throw "Could not create MediaKeys";

  // Create a new key session using the MediaKeys instance
  var keySession = cdm.createSession(NULL, NULL);
  if (!keySession)
      throw "Could not create MediaKeySession";
  keySession.onkeymessage="handleMessage(event)";

  // Load an application defined key package into the key session
  // The key package can be hard-coded into the page or loaded as a resource
  // Loading the key package may cause additional key messages to be sent
  var Uint8Array keyToPreload;
  keySession.addKey(keyToPreload);
  keySession.close();
}

// Respond to key message
function handleMessage(event)
{
    var keySession = event.target;
    var message = event.message;

    var xmlhttp = new XMLHttpRequest();
    xmlhttp.open("POST", "http://.../getkey", false);
    xmlhttp.send(message);

    var key = new Uint8Array(xmlhttp.response);
    keySession.addKey(key);
}

// Attach pre-initialized MediaKeys to an HTMLMediaElement
function setMediaKeys()
{
  var video = event.target;
  var initData = event.initData;

  if (!cdm)
throw "MediaKeys was not already created!";
  if (!video.keys)
video.keys = cdm;

  // Create a new key session using the mimeType and initData
  var keySession = video.keys.createSession(mimeType, initData);
  if (!keySession)
throw "Could not create MediaKeySession";
  keySession.onkeymessage="handleMessage(event)";
}

<body onload="load()">
  <video src="foo.dash" autoplay onneedkey="setMediaKeys(event)" onkeymessage="handleMessage(event)"></video>
</body>

</script>
--------

I believe this should all work within the confines of the current draft. I am intentionally leaving how the preloaded key package is derived as an exercise for the application developer, since there are many possible ways to handle that.

Joe Steele
steele@adobe.com<mailto:steele@adobe.com>