This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
now, the needkey is only for 1 key. But it is common the file will contain multiple keys used to decrypt multiple video/audio tracks. If we fire needkey for each key, it is not optimistic and can we combine them together, to generate the key request?
(In reply to comment #0) > now, the needkey is only for 1 key. > But it is common the file will contain multiple keys used to decrypt multiple > video/audio tracks. The needkey event is always fired with a single initData value. The number of keys currently depends on the container: * WebM (bug 17672) - 1 key per initData * ISO BMFF/CENC (bug 17673) - 1 or more keys per initData > If we fire needkey for each key, it is not optimistic and can we combine them > together, to generate the key request? It seems this would be difficult to implement for containers that do not already group keys. Also, if multiple files/streams are used, those will generate separate needkey events, so this is already an issue applications may need to deal with. For such changes, we should consider the complexity of optimizing vs. the performance or other gain for these relatively rare events.
Whether one or more keys are acquired in a session is an implementation detail for the container/CDM. This is supported with the current initData/message exchange.