RE: [EME] reuse of session

Replies inline.

From: David Dorwin [mailto:ddorwin@google.com]
Sent: Saturday, June 07, 2014 8:02 AM
To: Maruyama, Shinya
Cc: public-html-media@w3.org
Subject: Re: [EME] reuse of session



On Thu, May 29, 2014 at 2:17 AM, Maruyama, Shinya <Shinya.Maruyama@jp.sony.com<mailto:Shinya.Maruyama@jp.sony.com>> wrote:
I believe current solution which can reduce the number of duplications but cannot deduplicate completely does not make sense.

The current solution addresses many use cases in a simple way. Most importantly, it avoids creating potentially hundreds of sessions (or having the application de-dupe initData hundreds of times) during a single movie (depending on how much adaptive streaming there is and/or how the streams are packaged).

The problematic fact is that application cannot know which needkey should be handle (if unnecessary needkey remains).
Live streaming is most likely problematic case.

It still causes unnecessary resource consumption. In addition it maybe cause undesirable user experience. For example, in the case of the content with the limitation on the number of concurrent streaming, the unnecessary license acquisition might cause waste of the count or unexpected error response etc. (I’m not sure this is good example though. The maximum number of streaming might not be the matter of DRM depending on DRM system).

Where a simple "ignore all subsequent needkey events" solution doesn't work, the application must be smarter. However, I don't think this is any worse than before this partial solution was implemented. In addition, it avoids creating unnecessary MediaKeySession objects as noted above.

Agreed. The application should be smarter (probably depending on several implicit things specific to each service).
In general, however, a goal we should try to reach for is to specify the application models/best practices which we can rely on to ensure that no unnecessary session happens as long as all the requirements for the best practices are met. In the case of deviant models, we may have to accept failing to de-dup license


The following is my thought. Hopefully, this might be helpful to move forward for this issue.

* UA/CDM level
- Given that only CDM/DRM which is aware of the initData format;i.e Data part of pssh, can determine whether to need another license, deduplication is impossible without using CDM
- Even the CDM cannot resolve the pending license case unless it waits for the license
- Common encryption 2nd edition will solve some of the problems; i.e. user agent can implement KIDs comparison instead of raw initData comparison

Does the KID array really help? The user agent would still need to (asynchronously) ask the CDM if it has each key ID. Even if it did, this only addresses a subset of content in one particular format.


I’m not sure why you think the user agent needs to ask the CDM.
Current model does not take care of “active session Initialization Data“ delivering what set of KIDs to CDM () or does not  ensure the preceding session have completed successfully. It just relies on the same initData will result in the same license and don’t care the result of pending license (createSession is resolved with null even though the preceding session may fails to acquire the license).
KID-granular comparison is basically the same. The initData should result in the license delivering all the KIDs contained in the initData (maybe it delivers extra KIDs though). It just ensures that the KIDs listed in UA will be or have been made available to CDM. This is the same assumption which the current model relies on. If a preceding license delivers extra KIDs, unnecessary session may be created. However it is not worse than current model, either.

The biggest advantage on introducing KID-granular comparison is that it helps to realize a best practice. For example, if manifest file delivers the pssh containing all KIDs for the presentation, the application can first call createSession with the pssh. Then, the subsequent media segment does not cause unnecessary sessions even though pssh is contained in moov or moof box.
Raw initData comparison cannot make it because pssh is different among manifest, moov and moof.


Should EME at least support common encryption 2nd edition?

* App level
- If no solution in UA/CDM level, should we specify some Application Models: (as best practice profiles or something)??

Yes, if we can't find a robust user agent-based solution, hopefully there will be some best practices that can be documented somewhere. One advantage of handling this at the application level is that different solutions can be used depending on the application model - something that is not possible if we bake a solution into (some) CDMs.

Agreed.