When using hardware-backed CDMs, it's common that there's a limit on how many sessions the CDM can open, mostly because each session is backed by some hardware resource (e.g. in TEE), and there's a limit on such resource. The limit is often global for the device, so a JS player can hit this issue even if it only opens a few sessions, e.g. if other native applications or other sites on the same browser have outstanding sessions open.
Currently the spec doesn't say what the user agent should do for this case. The closest one is in generateRequest(), step 10.10.1:
If any of the preceding steps failed, reject promise with a new DOMException whose name is the appropriate error name.
In practice, implementations could choose any exception it chooses. For example, Chromium on Android chooses NOT_SUPPORTED_ERROR, and on Windows it could return INVALID_STATE_ERROR.
I propose that we add an explicit step for generateRequest() in the spec:
If generateRequest() failed due to lack of resources, return a promise rejected with a newly created QuotaExceededError.
Also update QuotaExceededError under 6.5 Exceptions to include this case.
Note that the CDM implementation could choose to actively evict older sessions as an alternative solution to this issue. In that case, generateRequest() on new session will succeed, but an older session will be closed automatically. This is covered under 6.4.4 Session Closed algorithm:
The CDM may close a session at any point, such as when the session is no longer needed or when system resources are lost. In that case, the Monitor for CDM Changes algorithm detects the change and runs this algorithm.
Issue 473 further proposes to add a Reason to the closed attribute so the exact reason for the closure can be returned.
When using hardware-backed CDMs, it's common that there's a limit on how many sessions the CDM can open, mostly because each session is backed by some hardware resource (e.g. in TEE), and there's a limit on such resource. The limit is often global for the device, so a JS player can hit this issue even if it only opens a few sessions, e.g. if other native applications or other sites on the same browser have outstanding sessions open.
Currently the spec doesn't say what the user agent should do for this case. The closest one is in
generateRequest()
, step 10.10.1:In practice, implementations could choose any exception it chooses. For example, Chromium on Android chooses
NOT_SUPPORTED_ERROR
, and on Windows it could returnINVALID_STATE_ERROR
.I propose that we add an explicit step for
generateRequest()
in the spec:generateRequest()
failed due to lack of resources, return a promise rejected with a newly created QuotaExceededError.Note that the CDM implementation could choose to actively evict older sessions as an alternative solution to this issue. In that case,
generateRequest()
on new session will succeed, but an older session will be closed automatically. This is covered under 6.4.4 Session Closed algorithm:Issue 473 further proposes to add a
Reason
to theclosed
attribute so the exact reason for the closure can be returned.