Re: [EME] reuse of session

On Wed, Jun 11, 2014 at 8:22 PM, Maruyama, Shinya <
Shinya.Maruyama@jp.sony.com> wrote:

>
>
> *From:* David Dorwin [mailto:ddorwin@google.com]
> *Sent:* Saturday, June 07, 2014 8:02 AM
>
>
>
> On Thu, May 29, 2014 at 2:17 AM, Maruyama, Shinya <
> Shinya.Maruyama@jp.sony.com> wrote:
>
>
>
> 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.
>
I don't see how it is *better* and thus why we should add special behavior
for one format (CENC) or a dependency on CENC second edition. (Actually,
WebM would work fine because the initData *is* a KID.)

If, for example, audio and video streams are encrypted with different keys,
they will have different PSSH boxes with different KID values. *If* the
first session results in a license for *both* keys, the application and
user agent will not know this. Only the CDM knows that it already has keys
for both KIDs. Thus, the user agent can't do anything with knowledge of the
KIDs in the initData. It would still create multiple sessions because the
KIDs are different just as the entire initData is different.

The one case where this might not be true is if there was fake initData
(i.e. from a manifest) that contained both KIDs. Maybe this is what you are
referring to below. However, this can probably be addressed by using a real
PSSH box from one of the streams. If the license server is capable of
returning a license for all KIDs based on a PSSH box containing just one of
them, there is no reason to include all the KIDs in the manifest (if you
are concerned about duplicate sessions in the key rotation case).

>
>
> 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.
>
That's interesting - why are they different?

Is it because, as you said above, that the PSSH box from the manifest? What
does the PSSH box in the moov contain? Why does the moov need a PSSH box?