Re: Bug#17470 Example code

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

>
>  Joe Steele
> 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?


> 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-closecurrently 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.

>
>
>
> David
>
> On Tue, Oct 16, 2012 at 11:44 PM, Joe Steele <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
>>
>> 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
>>
>>
>>
>
>