[v4] Remove decipherabilityUpdate event #1168
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a proposal for removing the
decipherabilityUpdaate
event from the future v4, which was an event indicating that some Representation(s) became un-decipherable or decipherable, for the following reasons:It exposed some properties we may still want to make evolutions to. The main example is the
decipherable
property, typed as aboolean | undefined
, where it could make sense in the future to set it to a fourth-"unknown" value (which would be different to the "not handled yet" case - thus just setting both toundefined
would not be sufficient).This fourth case has for now only be encountered in our key-expiration-handling work.
As far as we know, this event has never been handled. Its original point was to let applications listen to it so they can filter out the corresponding qualities for subsequent playback of similar contents.
But, as we know, applications usually take another (usually better) route - when they do: They mostly poll capabilities before playback, hence knowing even before the first loaded content what quality may be playable.
Here also handling decipherability updates at play time may not be as straightforward, as you may have to also have to consider WHY the current quality was being refused, whether it was for HDCP, CDM-level or perhaps just a temporary license server error etc.
To be clear, the event removed DO NOT remove the RxPlayer's ability to fallback during playback, it just removes the main event signalling to the application that a
Representation
's decryption key is not usable.The most useful indication of this event, that some quality was fallbacked from due to a present but unusable key, can be mostly replicated by listening to the corresponding
warning
event sending an error with aKEY_STATUSES_CHANGE_ERROR
code. The corresponding key status AND key id should become part of that error very soon.