This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
If media element’s source attribute has a keySystem attribute then we use this as selected keySystem, this is OK. If no selected KeySystem, the specification says “jump to Key Presence” The question is : At “jump to Key Presence” is a else if of “selected key system”, so here we have no idea about key system, but in "jump to Key Presence", we are handling key already exist, so why before key system selected, we can have key? We may need let app or CDM to analyze the initData to find the KeySystem, but I have not seen any text for Analyzing initData to generate key system here, or I miss something? So where we select the Key System if no selected key system in media element?
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).
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).
The application always chooses the key system to use; the media element does not choose the key system. The only case where the UA "sets" the current key system is when a <source> element is used to select the source and the selected element specifies a "keySystem" attribute. Even in this case, though, the key system to use for a particular source was specified by the application and the UA is just processing the options. (In reply to comment #2) > 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 "key system" is a variable that is set to null in step 1. Thus, it will be null in the case you described. > 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 > > there are 3, say, is already a challenge). Yes, the keySystem parameter is required for generateKeyRequest(). Whether this method has been successfully called before the needkey event is fired may affect which of the three options for setting the keySystem attribute is used.
By design, the API expects the application to try key systems in the order of preference until it finds one that works.