- From: David Dorwin <ddorwin@google.com>
- Date: Mon, 11 Jun 2012 22:34:45 -0700
- To: public-html-media@w3.org
- Message-ID: <CAHD2rsjGU4fUn=hzaew4qCv4EHrsqLLSgHC7VZx76C5f=i2bVA@mail.gmail.com>
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.
Received on Tuesday, 12 June 2012 05:35:35 UTC