Re: [EME] reuse of session

Your proposal seems to be to design the CDM for one specific use case
(application). For other use cases, including the one without step 2, the
CDM would cause an unnecessary delay before the session is created. Even if
this was "allowed", that doesn't solve the identified problem for most
implementations or applications. It would be much better if we could solve
this in a general way, possibly even changing the APIs. Do existing systems
have solutions for this or do they avoid it because they are tied to a
specific application or application model?


On Thu, May 22, 2014 at 8:49 PM, Maruyama, Shinya <
Shinya.Maruyama@jp.sony.com> wrote:

>  To what extent optimization is made is up to CDM but one possible
> solution is to implement the pending state of license.
>
>
>
> In the step 4, createSession resolves with a new media key session and add
> the pending license in the session.
>
> In the step 7, createSession waits until the pending license becomes
> available and then resolves with null upon receiving the license.
>
>
>
> In your scenario, as step 4 is initiated by initData containing only audio
> key id, step 7 need to wait the pending license in which it is not sure key
> id for video is delivered. Thus, step 7 may observe that the license does
> not contain the video key after the license made available. Then, CDM need
> to resolve it with a new session. Some CDM may or may not accept such a
> undesirable blocking in preference to license duplications. However, at
> least, CDM can implement the pending state with key-id-basis without
> supporting unsure waiting. I think this would be sufficient in practice as
> long as movie presentation is well designed. For the reason, I had the step
> 2 in my scenario. Actually, DASH-IF is creating a profile to make necessary
> key ids available to client at MPD processing time. That encourage us to
> have the step 2.
>
>
>
> I understand we cannot resolve all the possibilities (at least on current
> EME model) but my concern is currently some very likely cases are not
> supported.
>
>
>
> Do you have any major concern to allow CDM to implement this kind of
> optimization?
>
>
>
> Thanks,
>
> Shinya
>
>
>
> *From:* David Dorwin [mailto:ddorwin@google.com]
> *Sent:* Friday, May 23, 2014 11:50 AM
>
> *To:* Maruyama, Shinya
> *Cc:* public-html-media@w3.org
> *Subject:* Re: [EME] reuse of session
>
>
>
> There might be options for addressing this if events actually occurred in
> the order you presented. However, I think the following (reordered and with
> slight modifications highlighted) is much more likely (and will happen at
> the beginning of most playbacks):
>
> 3.     Application fetches the audio media segment containing an
> initData-a for audio key
>
> 6.     Application fetches the video media segment containing an
> initData-v for video key
>
> 4.     createSession is resolved with a new media key session because the
> raw initData-a is **new**
>
> 7.     createSession is resolved with a new media key session because the
> raw initData-v is different from raw initData-**a**
>
> 5.     Application acquires **first** license!
>
> 8.     Application acquires **duplicate license**!!
>
>
>
> Even if you wanted to look at the available keys in the CDM, they wouldn't
> be available for any stream (audio or video) at the beginning of playback
> because the license wouldn't have been obtained yet (as shown above). Any
> solution for automatically avoiding "duplicate" sessions in the user
> agent would need to address this scenario.
>
>
>
> For now, the application is responsible for handling this, and things get
> complex when key rotation is involved.
>
>
>
> Note: It's also possible that you *do* need a new session even if you
> already have a key for the key ID(s) in the initData.
>
>
>
> On Thu, May 22, 2014 at 5:33 PM, Maruyama, Shinya <
> Shinya.Maruyama@jp.sony.com> wrote:
>
> In case of live content with key rotation, applications cannot know
> whether to ignore each needkey event in general unless application supports
> a way to know a key rotation, for instance, by using MPD update mechanism
> etc.
>
>
>
> How about the application only supporting reactive license acquisition?
> Such an application does not support proactive license acquisition in step
> 2. Thus, the application need to respond all the needkey events because it
> is not aware of the characteristic of the presentation.
>
>
>
> *From:* David Dorwin [mailto:ddorwin@google.com]
> *Sent:* Friday, May 23, 2014 2:27 AM
>
>
> *To:* Maruyama, Shinya
> *Cc:* public-html-media@w3.org
> *Subject:* Re: [EME] reuse of session
>
>
>
> (It's important to note that step 2 includes a createSession() call - I
> think that makes the following clearer.)
>
>
>
> If prefetching the license, as in step 2, there is no reason to call
> createSession() in response to the needkey event. Such applications can
> either ignore needkey or use it to track something else.
>
>
>
> P.S.
>
> While writing that last sentence, it became clear that "needkey" is a bad
> name for this event because we don't really know if a key is needed. I'll
> filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=25866 to rename it.
>
>
>
> On Wed, May 14, 2014 at 9:19 PM, Maruyama, Shinya <
> Shinya.Maruyama@jp.sony.com> wrote:
>
> Correct my wrong descriptions. Please take a look at following corrected.
>
>
>
> *From:* Maruyama, Shinya [mailto:Shinya.Maruyama@jp.sony.com]
> *Sent:* Thursday, May 15, 2014 12:54 PM
>
>
> *To:* David Dorwin
> *Cc:* public-html-media@w3.org
> *Subject:* RE: [EME] reuse of session
>
>
>
> Let me clarify the problem of raw initData comparison.
>
>
>
> Let’s walk through the case of MPD adaptive streaming with following
> assumptions:
>
> - each Representation contain a single track; video, audio or subtitle
>
> - each initialization/media segment contain a pssh box which contains a
> single KID for corresponding track
>
> (pssh in each media segment causes duplication but is useful to facilitate
> random access for live or trick play)
>
> - each track is encrypted with different key
>
> - MPD delivers the list of KIDs which cover the entire movie presentation
>
> - all tracks are protected by a single license; i.e. all keys can be
> derived by the license
>
> - acquire a license before fetching media segment for performance reason
>
>
>
> 1.     Application acquires and parses MPD
>
> 2.     Application initiates EME using initData-avs including all the
> KIDs ; e.g. container-independent initData (Bug 25269<https://www.w3.org/Bugs/Public/show_bug.cgi?id=25269>)
> constructed by the info in ContentProtection or pssh in ContentProtection
>
> 3.     Application fetches the audio media segment containing an
> initData-a for audio key
>
> 4.     createSession is resolved with a new media key session because the
> raw initData-a is different from raw initData-avs
>
> 5.     Application acquires duplicated license!
>
> 6.     Application fetches the video media segment containing an
> initData-v for video key
>
> 7.     createSession is resolved with a new media key session because the
> raw initData-v is different from raw initData-avs
>
> 8.     Application acquires duplicated license again!!
>
> (The same for subtitle…)
>
>
>
> initData-avs : contains pssh which delivers the DRM specific information
> for audio, video and subtitle keys
>
> initData-a : contains pssh which delivers the DRM specific information
>  for audio key
>
> initData-v : contains pssh which delivers the DRM specific information
>  for video key
>
>
>
> I believe this is likely case because assumptions above is not special
> case but based on common concept:
>
> - Constraint of single track in representation is specified in DASH-IF IOP
>
> - Separate key for each track and multi-tracks in a single license is
> supported by major DRM
>
>   - Acquire a license in MPD time is important aspect for the performance
>
>
>
> Your opinion?
>
>
>
> *From:* Maruyama, Shinya [mailto:Shinya.Maruyama@jp.sony.com<Shinya.Maruyama@jp.sony.com>]
>
> *Sent:* Friday, April 25, 2014 11:11 AM
> *To:* David Dorwin
> *Cc:* public-html-media@w3.org
> *Subject:* RE: [EME] reuse of session
>
>
>
> Thanks for your comments.
>
> Please find replies inline.
>
>
>
> *From:* David Dorwin [mailto:ddorwin@google.com <ddorwin@google.com>]
> *Sent:* Friday, April 25, 2014 4:58 AM
> *To:* Maruyama, Shinya
> *Cc:* public-html-media@w3.org
> *Subject:* Re: [EME] reuse of session
>
>
>
>
>
>
>
> On Wed, Apr 23, 2014 at 10:14 PM, Maruyama, Shinya <
> Shinya.Maruyama@jp.sony.com> wrote:
>
> As to the reuse of session by promise, would it be better that CDM
> determines whether to create a new media key session?
>
>
>
> Where possible, it is better to keep logic in the user agent. This helps
> ensure more consistent behavior, enables reuse and OSS implementation, and
> is more consistent with other specs.
>
>
>
> I understand that perspective.
>
>
>
> According to createSession algorithm step 6-1, a user agent determines it
> by checking *list of active session Initialization Data*.
>
> As the user agent is not aware of the DRM specific part of initData
> (except for container-independent initData *Bug 25269*<https://www.w3.org/Bugs/Public/show_bug.cgi?id=25269>),
> the user agent can compare the entire of initData but it is impossible to
> look into the content of initData to see if requesting keyIds are available
> in active sessions.
>
>
>
> The current text is intentionally comparing the raw initData and not the
> contents. In the case of CENC, this ensures the same number of sessions
> will be created regardless of which PSSH box (or key system) is used.
>
>
>
> The current text is *not* intended to prevent all duplicate sessions -
> it's intended to prevent potentially hundreds of sessions from being
> created for the same initData during adaptive streaming, etc. and reduce
> the overall amount of work the application must do. Checking whether the
> CDM already has the appropriate keys would not address all such scenarios
> and could lead to inconsistent behavior. Specifically, there will often be
> two needkey events when playback starts as the audio and video streams are
> parsed. At that point, the CDM does not have any keys, and it can't know
> whether the first session that gets created will return a key for the
> second initData.
>
>
>
> I understand the intention of current text.
>
> From my viewpoint, I believe the usecase I showed below would be likely
> case.
>
>
>
>  .
>
> This means, an application suffers unnecessary creating media key sessions
> as follows, for instance;
>
>
>
> 1. Prefetch license(s) by media key session initiated by
> container-independent initData including superset keyIds; e.g. KIDs for
> audio and video tracks, for a subsequent media presentation (at MPD fetch
> time)
>
> 2. When each initialization Data contains a pssh, it causes unnecessary
> media key session because the cenc-formatted initData is not identical to
> the preceding initData at step1; i.e. container-independent pssh, pssh for
> audio and pssh for video are all distinct.
>
>
>
> Do I understand correctly that #1 uses initData from a manifest while #2
> uses data from needkey events? If so, what is the use case? I expect that
> such an application would be rare and would need to either ensure the
> initData is consistent or handle session creation differently.
>
>
>
> Yes, I mean #1 is a manifest; e.g. MPD for DASH.
>
> MPD may carry sufficient information to trigger a license acquisition
> which includes the keys necessary to decrypt all the subsequent media
> streams; audio, video, subtitle, etc (unless key rotation happens).
>
> To prefetch the license allows to acquire and process the license in
> advance of (or simultaneously) the Initialization/Media Segment being made
> available. I think this kind of advanced license request is a topic a lot
> of people have concern about.
>
>
>
>
>
> Key rotation may be a another usecase. Reusing a media key session by just
> updating available keys within the session maybe provide some benefit but
> it is not possible because the pssh that requires new key(s) is most
> probably distinct from other active initData.
>
>
>
> initData cannot be added to an existing session, so key rotation using the
> same session would need to be handled in some other way. Thus, step 6-1
> does not affect this scenario.
>
>
>
> OK. Probably we need to discuss the key rotation matter comprehensively
> instead of looking into current text one by one.
>
>
>
>
>