Retain DrmEngine/MediaKeys across detach()/unload() instead of always renegotiating on reload

FAQ

• I have read the FAQ and checked for duplicate open issues

Is your feature request related to a problem? Please describe.

We have a use case whereby we hand the video element off to a companion ad SDK mid-stream so it can render its own media. On some memory constrained devices (e.g. Tizen/WebOS) where the device can't find the resources to run two decoders at once, the memory used for the parked decode path with DRM decryption gets reclaimed for the clear interstitial content's new decode path. The flow is: unload/detach the main asset, let the ad play on the element, then attach/load the same asset again to resume.

Right now in Shaka Player that resume always tears down and renegotiates the DrmEngine from nothing, even though it's the exact same asset that was playing seconds earlier. That's a real problem for us because our license server only allows new-session requests to come from a direct user gesture - programmatic requests are banned by our backend team to prevent accidental spamming. Renewal on an already-alive session is fine, and constant for us since our content rotates keys every few seconds.

Describe the solution you'd like

We have been experimenting with a solution based off the latest version of Shaka Player (5.2.8 - main) which takes a similar approach to what we've observed in hls,js (happens automatically) and dash.js (config flag streaming.protection.keepProtectionMediaKeys), whereby the EMEController keeps MediaKeys alive across detachMedia()/attachMedia(), so a resume is just a resume. This logic is behind a config flag drm.keepDrmEngineOnDetach that keeps the live DrmEngine around across unload()/detach() and reuses it on the next load()/attach() if the asset URI matches, leaving anything loaded in between (the ad itself) alone.

Describe alternatives you've considered

We looked at possibly using EME persistent sessions, but this would only work if licences are marked as "persistable" which in our case they can't be, otherwise that would defeat the purpose of the short TTL.

Additional context

No response

Are you planning to send a PR to add it?

Yes