W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > July 2012

[Bug 17672] Define Initialization Data for implementations that choose to support the WebM Container

From: <bugzilla@jessica.w3.org>
Date: Tue, 03 Jul 2012 16:58:00 +0000
Message-Id: <E1Sm6QK-0001MR-LU@jessica.w3.org>
To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17672

--- Comment #3 from David Dorwin <ddorwin@google.com> 2012-07-03 16:58:00 UTC ---
(In reply to comment #2)
> If the initialization data contains multiple keys, is that means one initData
> will trigger to setup multiple sessions?

The original description says that for WebM, the initData will likely be the
key ID for the current Track section. See
http://matroska.org/technical/diagram/index.html. Thus, for WebM, there can be
only one key per initData. For ISO BMFF (bug 17673), multiple keys may be
represented by a single initData.

In all cases, each initData value/block will be a single session (as agreed on
by the group).
So, for WebM there would be one key per session, and for ISO BMFF there might
be multiple keys per session.

> So if we want to decode a file with multiple keys, I have to construct multiple
> MediaKeySession objects, it may be a little complex, can we have a umbrella
> concept for a media file to manipulate multiple keys scenario?

According to the current plans, It depends on the container, number of files,
etc.
We have to consider the tradeoffs between multiple sessions/licenses and API
complexity. If you have an alternate proposal, please send it to
public-html-media.

> And it says the initData will contain encryption parameters, will that be
> common for all encryption algorithm?

For both WebM and ISO BMFF, the encryption parameters involve more than the
initData. For example, the IV is not part of the initData for either container.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 3 July 2012 16:58:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2012 16:58:05 GMT