Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add the possibility to set a new
keySystems
option on the reload
API
A majority of the bigger issues we encounter in production is DRM-related, leading us to either work-around those in the RxPlayer, or to facilitate a work-around on the application-side through a better DRM-related API. Recently, we've seen that many Windows/Edge users (but still a minority of them) could encounter an issue on the `generateRequest` EME call when relying on PlayReady SL3000 (hardware-backed decryption and playback, seen as one the most secure DRM mechanism for OTT contents) which would lead to a failure to play the content. When this happens, fallbacking to a different key system like PlayReady SL2000 (where decryption happens in software) or Widevine usually (though not always) seems to avoid the issue, even if it might lead to less protection and thus might lead generally to only lower video qualities (as higher security requirements are in practice generally just enforced for the higher video qualities, depending on license policies). After brainstorming whether this fallback should be done on the RxPlayer-side, or on the application-side, we're for now implementing the easier way (for us :p) of just providing here an API allowing to just let the application replay the last loaded content (whose loading may have failed due to the aforementioned `generateRequest` error) with a different `keySystems` configuration, thus allowing an application to reload the last loaded content after blacklisting the current key system if the error appears to be linked to that issue.
- Loading branch information