Re: [EME] Support for multiple initData values in a single session?

So it can be derived that initData is not unique or used only once, it can
be encoded into multiple media files?
I have some concerns on it, because if this initData is available to some
user, and user can derived the initData from the previous video, and may
use some content replacement technology, so he can use this available
initData to skip the new key negotiation procedure by using existing key
session.

But if we have some  restrict about the initData, that this can only used
in which type of file, a set of content ids, of how many files maximum etc.


On Tue, Jun 19, 2012 at 11:27 PM, Mark Watson <watsonm@netflix.com> wrote:

>  Hi David,
>
>  If we define a session by the rule that different sessions represent CDM
> state that needs a different lifecycle (create/update/delete), then there
> could at least be a one-to-many relationship between initData and sessions.
> i.e. the same initData block could be used to create multiple sessions.
>
>  I don't equate this as being a "single license exchange" - as per the
> other discussion on heartbeat and key rotation, the CDM can ask for a
> message exchange at any time and whether these message exchanges result in
> new 'licenses' inside the session state depends on how you define
> 'license'. Since we're not defining 'license' ourselves it must be up to
> the CDM.
>
>  There are two approaches for the use case where a single session can be
> used to decrypt multiple files (e.g. audio/video).
> 1) we require that all the necessary initData is included in both files,
> so the session can be initialized with one initData and when the other file
> is encountered the CDM will discover that there is a session already
> created with all the necessary state (for example the initData contains the
> key ids and the CDM recognizes it already has those keys).
> 2) we would need to provide multiple initData blocks to a single session
>
>  In (2), it's not certain that providing additional initData to a session
> will result in a new message exchange.
>
>  Also, when new initData is encountered, who should decide whether a new
> session is required or whether this initData can be absorbed into an
> existing session ? Probably the CDM, right ? If we use the object-oriented
> design, do we just overload the method which creates a new session (from
> some initData) so that it can either create a new one or return an existing
> one ?
>
>  …Mark
>
>
>
>
>  On Jun 11, 2012, at 10:34 PM, David Dorwin wrote:
>
> In the current draft, each successful call to generateKeyRequest()
> generates a new session. Since initData is passed to generateKeyRequest(),
> each initData would be in a separate session. I'd like to get feedback on
> whether separating each initData into a separate session or object would be
> a problem.
>
>  Possible issues with only allowing one initData value per session
> include:
>  * Each session is a separate license exchange.
>  * Applications that care about session IDs will need to deal with
> multiple IDs.
>  * In the potential sessions as objects design (
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16613), each session would
> be a separate object.
>
>  The following are some possible scenarios where multiple initData values
> may occur:
>  * Audio and video are in separate files and have different initData.
>  * Different tracks or bitrates have different initData.
>  * A container supports multiple initData values.
>
>  To allow multiple initData values per session, we would either need to
> separate session creation from providing initData or allow an array of
> initData to be provided. Both solutions would work in both the current
> and sessions as objects designs. However, note that since needkey events
> may occur at different times, the application might not know when it has
> all initData values that it needs to send. In addition, initData values
> that are encountered later (i.e. after a stream switch or later in the
> container) could not be added to the session. Addressing that would
> probably require changing the 1:1 license/session ratio.
>
>
>


-- 
Yang
Huawei