w3c / encrypted-media

Encrypted Media Extensions
https://w3c.github.io/encrypted-media/
Other
180 stars 80 forks source link

Identify a message by which payload was provided to generateRequest #446

Closed estobbart closed 5 years ago

estobbart commented 5 years ago

It appears that the spec allows an application to have a key per track. If EME's generateRequest was called with two different PSSH boxes, and it returns two different message events, it doesn't appear that you can identify which message came from which generateRequest call. Can it be assumed that they are returned in order? Or is there another way to pair them up? Else the request's have to be done one at a time waiting for each message event to return before making a second request. Or is the original assumption about a key per track incorrect?

jrummell-chromium commented 5 years ago

The spec does allow having a key per track. The sample code in section 13.2 demonstrates the possibility of multiple keys. Each request happens on a different MediaKeySession object, so you can use the session to keep track of the requests (although I'm not sure why you need to do so).

mwatson2 commented 5 years ago

There is no assumption of one key per track. There can be zero or more keys and each track can use zero of more of them.

A generateRequest / update exchange can result in zero, one or more keys being made available. A MediaKeySession can have one generateRequest / update exchange in progress at a time, so if you want multiple exchanges to proceed in parallel you need multiple MediaKeySessions as @jrummell-chromium says.

estobbart commented 5 years ago

Got it, so n-number of MediaKeySessions each with their own generate & message pair if they need to be done in parallel.

Q: I'm not sure why you need to do so A : Not sure if there is a valid technical reason, just the way we wire it all up I guess.

Thanks!