Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release/v3.33.0 #1363

Merged
merged 10 commits into from
Jan 24, 2024
Merged

Release/v3.33.0 #1363

merged 10 commits into from
Jan 24, 2024

Conversation

peaBerberian
Copy link
Collaborator

Changelog

Features

Bug fixes

Other improvements

peaBerberian and others added 10 commits October 13, 2023 11:50
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.
Add the possibility to set a new `keySystems` option on the `reload` API
[WIP] Add getLivePosition API and better handle availabilityTimeOffset for DASH
@peaBerberian peaBerberian merged commit fe46689 into master Jan 24, 2024
3 checks passed
@peaBerberian peaBerberian added this to the 3.33.0 milestone Feb 5, 2024
@peaBerberian peaBerberian deleted the release/v3.33.0 branch February 7, 2024 17:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants