Re: [EME] reuse of session

In this case, isn't the application aware that it is getting the necessary
initData from the MPD and so can safely ignore the needkey events ?

...Mark


On Mon, Jun 16, 2014 at 4:02 PM, Maruyama, Shinya <
Shinya.Maruyama@jp.sony.com> wrote:

>  I should have added steps of needkey events.
>
> Those steps are triggered because application receives the needkey.
>
> For example, 1 to 8 is the case of VOD content playback and 1 to 16 is the
> case of live streaming requiring key rotation.
>
>
>
> Currently steps 5, 8, 12, 13 and 16 causes creating extra sessions and
> then result in acquiring duplicated license because raw intiData comparison
> cannot detect the subset of KIDs being supplied.
>
>
>
> 1) Fetch MPD1
>
> 2) createSession(KIDv1, KIDa1 in MPD1) -> Resolved with session1 and KIDv1
> and KIDa1 is stored in UA  // this session is created proactively without
> receiving needkey
>
> 3) Fetch video1(KIDv1) segment
>
> 4) needkey(KIDv1 in moof) is fired // In the case of MSE, typically KIDv1
> is delivered by initialization segment containing pssh in moov
>
> 5) createSession(KIDv1) -> Resolved with null // because KIDv1 is already
> included in active session list
>
> 6) Fetch audio1 segment
>
> 7) needkey(KIDa1 in moof) is fired // In the case of MSE, typically KIDa1
> is delivered by initialization segment containing pssh in moov
>
> 8) createSession(KIDa1 in moof) -> Resolved with null
>
> -------------- if key rotation happens --------------
>
> 9) Fetch MPD2
>
> 10) createSession(KIDv2, KIDa2 in MPD2) -> Resolved with session2 // this
> session is created proactively without receiving needkey
>
> 11) Fetch video2 segment
>
> 12) needkey(KIDv2 in moof) is fired // In the case of MSE, typically KIDv2
> is delivered by initialization segment containing pssh in moov
>
> 13) createSession(KIDv2 in moof) -> Resolved with null
>
> 14) Fetch audio2 segment
>
> 15) needkey(KIDa2 in moof) is fired // In the case of MSE, typically KIDa2
> is delivered by initialization segment containing pssh in moov
>
> 16) createSession(KIDa2 in moof) -> Resolved with null
>
>
>
>
>
> *From:* Mark Watson [mailto:watsonm@netflix.com]
> *Sent:* Monday, June 16, 2014 11:57 PM
> *To:* Maruyama, Shinya
> *Cc:* David Dorwin; public-html-media@w3.org
>
> *Subject:* Re: [EME] reuse of session
>
>
>
> I'm afraid I have not been following this whole thread, but why do you
> have steps 4, 6, 10 and 12 at all below ?
>
>
>
> ...Mark
>
> Sent from my iPhone
>
>
> On Jun 15, 2014, at 7:33 PM, "Maruyama, Shinya" <
> Shinya.Maruyama@jp.sony.com> wrote:
>
>  Please see replies inline.
>
>
>
> *From:* David Dorwin [mailto:ddorwin@google.com <ddorwin@google.com>]
> *Sent:* Saturday, June 14, 2014 3:31 AM
> *To:* Maruyama, Shinya
> *Cc:* public-html-media@w3.org
> *Subject:* Re: [EME] reuse of session
>
>
>
>
>
>
>
> On Thu, Jun 12, 2014 at 8:34 PM, Maruyama, Shinya <
> Shinya.Maruyama@jp.sony.com> wrote:
>
>     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 case above is a bad practice we cannot de-dup licenses.
>
>
>
> What specifically is a bad practice? That all seems pretty standard.
>
>
>
> I just compared it to the best practice below.
>
>
>
>
>
>
>
>
>
> 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 best practice I mentioned below is the case KID comparison in user
> agents gives much help.
>
> Actually, DASH-IF and common encryption 2nd edition are addressing the
> delivery of all the KIDs in the manifest.
>
>
>
>
>
> 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?
>
>
>
> Yes, the first pssh extracted from the manifest contains all the KID for
> the presentation because the manifest is a something to cover the entire
> streams.
>
> Subsequent pssh may come from either moov or moof to support random access
> or trick play. Typically, as media segment contains a single track, those
> pssh’s are not the same unless the particular constraint is
> specified/operated like HbbTV restricting the Initialization Segment to
> being the common among all representations.
>
>
>
> Are you still talking about a key rotation scenario? When you say "the
> manifest contains all the KID for the presentation", are you referring to
> all rotation periods or just for all streams in the current period? In the
> former case, you can ignore the needkey events. In the latter, you are
> still going to have problems for subsequent periods (see below).
>
>
>
> It’s not limited to key rotation scenario. This sort of best practice
> would be generally useful for single track based media segment with
> different key encryption.
>
> As to "the manifest contains all the KID for the presentation", I was
> referring to the case where a manifest contains KIDs for audio, video
> streams (irrespective of VoD or live streaming).
>
>
>
>
>
> The PSSH box in the moof only contains key ID(s) for that specific track
> (e.g. video), right? If so, you'll have the same problem of different KIDs
> in the needkey events in a future rotation period.
>
>
>
> In the case of DASH live streaming, MPD update mechanism can be used to
> create a new session with using updated MPD before key rotation happens.
>
>
>
>
>
> I must be missing something. In addition to answering the questions above,
> it might help to provide an explicit example - what KID(s) are in the
> manifest, each PSSH box, each license, etc.
>
>
>
> 1)      Fetch MPD1
>
> 2)      createSession(KIDv1, KIDa1 in MPD1) -> Resolved with session1
>
> 3)      Fetch video1 segment
>
> 4)      createSession(KIDv1 in moof) -> Resolved with null
>
> 5)      Fetch audio1 segment
>
> 6)      createSession(KIDa1 in moof) -> Resolved with null
>
> 7)      Fetch MPD2
>
> 8)      createSession(KIDv2, KIDa2 in MPD2) -> Resolved with session2
>
> 9)      Fetch vieo2 segment
>
> 10)  createSession(KIDv2 in moof) -> Resolved with null
>
> 11)  Fetch audio2 segment
>
> 12)  createSession(KIDa2 in moof) -> Resolved with null
>
> …
>
>
>
>