- From: <bugzilla@jessica.w3.org>
- Date: Wed, 04 Jul 2012 05:15:56 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17658 --- Comment #2 from Yang Sun <eric.sun@huawei.com> 2012-07-04 05:15:56 UTC --- Thanks for your reply. I guess you misunderstand my question. My question is when encrypted block is detected by media element during resource fetch algorithm , how to choose the key system. >From specification, In step 6 of section 5.1 encrypted block encounted It is said if the media element has a selected key system, then use it, If not, jump to key presence, there is no key system selection text in step 9 Key Presence. Step 9 only mentioned 3 choices: 1 key is available, 2 fire needKey event with “keySystem”,3 abort resource fetch procedure What’s more, I think before the generateKeyRequest(KeySystem, initData) is called, the KeySystem is already Selected, and the specification mentioned if KeySystem is null, it will throw a SYNTAX_ERROR. http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#dom-generatekeyrequest (In reply to comment #1) > The key system is selected with the call to generateKeyRequest(). If that > keysystem is not supported (by the browser, or by the file) then the call will > fail and the app can try a different keysystem. > > Note that all three of the app, the file and the browser may support multiple > keysystems. Only a keysystem in the intersection of these three sets may be > used. There may still be more than one. The app needs to choose its favorite > from that set, as there may be commercial implications of the choice for the > app. > > The way we chose to implement that was by allowing the app to attempt > generateKeyRequest with different key systems, in preference order, until one > succeeded. > > That seems acceptable given that the set of keysystems in the intersection I > describe above is likely to be very small (coming up with an example where > there are 3, say, is already a challenge). -- 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 Wednesday, 4 July 2012 05:15:57 UTC