[encrypted-media] Revisit the requirement to continuously run the "Monitor for CDM State Changes" algorithm (#499)

xhwang-chromium has just created a new issue for https://github.com/w3c/encrypted-media:

== Revisit the requirement to continuously run the "Monitor for CDM State Changes" algorithm ==
Currently there is a [Monitor for CDM State Changes](https://www.w3.org/TR/encrypted-media/#monitor-cdm) algorithm in the spec.

In [MediaKeySession](https://www.w3.org/TR/encrypted-media/#mediakeysession-interface), it says

> The User Agent shall **execute the [Monitor for CDM Changes](https://www.w3.org/TR/encrypted-media/#monitor-cdm) algorithm continuously** for each [MediaKeySession](https://www.w3.org/TR/encrypted-media/#dom-mediakeysession) object that is not [closed](https://www.w3.org/TR/encrypted-media/#media-key-session-closed). The [Monitor for CDM Changes](https://www.w3.org/TR/encrypted-media/#monitor-cdm) algorithm must be run in parallel to the main event loop but not in parallel to other procedures defined in this specification that are also defined to be run in parallel.

This requirement ensures the CDM state changes are populated to the user agent promptly. However, it's causing some implementation complexity and the benefit might not worth the cost.

To implement this feature, the CDM must keep a loop separate from the main event loop. Even worse, when the CDM is idle, i.e. no license exchange or decryption is happening, the CDM must keep running this loop to check internal of device states periodically, e.g. to check the time against the expiration time, or to check the devices' HDCP state against the output protection requirements. This not only adds more complexity, but also prevents power optimizations like put a process/thread in sleep while not playing (e.g. paused video in a background tab).

One alternative is not to execute the [Monitor for CDM Changes](https://www.w3.org/TR/encrypted-media/#monitor-cdm) algorithm continuously for each [MediaKeySession](https://www.w3.org/TR/encrypted-media/#dom-mediakeysession) object that is not [closed]. Instead, it only execute the algorithm when something is happening in the CDM:
- For key status and expiration changes, only run this algorithm at time of decryption, and potentially other CDM events.
- For tasks regarding the `message` event, the closed or unavailable sessions, the task should be queued directly when said event happens.

This way, the CDM (and the process/thread) can idle when there's no license exchange or decryption activities happening in the CDM, providing more freedom for optimization, and can potentially reduce the complexity of the CDM. The downside is that the CDM will not be able to report key status or expiration changes at real time, but that seems to be an acceptable tradeoff. When decryption is not happening, it's less interesting to know the key statuses or expiration.

Please view or discuss this issue at https://github.com/w3c/encrypted-media/issues/499 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 29 June 2022 22:41:49 UTC