Commits on Nov 14, 2023

1. 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.

   

   peaBerberian committed Nov 14, 2023
   Configuration menu

   • View commit details
   • Copy full SHA for 6ee2433
   • Browse repository at this point

   Copy the full SHA

   6ee2433 View commit details

   Browse the repository at this point in the history