v0.1 of the proposal says "Initialization Data is... container-specific data" . To help ensure implementations that choose to support a given format are interoperable and provide examples for the reader, we should define Initialization Data along with its use and behavior for common formats. This is similar to how the Media Source proposal has provided guidance for containers .
This bug tracks this task for the WebM Container .
Below is a non-exhaustive list of items to address:
* Files should specify encryption parameters per  or its successor.
* What are the contents of initData? Likely the key ID for the current Track.
* Such initData would result in a license containing a single key.
* A needkey event would be fired for each key encountered/needed.
* Are the contents of the needkey event fired when an encrypted block is encountered and no key is available  the same as the initial needkey event?
* Are needkey events fired for each Track even if they use the same key in the same file/stream/source?
Note: As currently written, the proposal would result in each key ID being a separate session and possibly a separate object (bug 16613). This applies to different keys for audio and video as well as more complex scenarios.
If the initialization data contains multiple keys, is that means one initData will trigger to setup multiple sessions?
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?
And it says the initData will contain encryption parameters, will that be common for all encryption algorithm?
(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.