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

[v4] Remove decipherabilityUpdate event #1168

Merged
merged 1 commit into from
Oct 12, 2022

Conversation

peaBerberian
Copy link
Collaborator

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 a boolean | 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 to undefined 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 a KEY_STATUSES_CHANGE_ERROR code. The corresponding key status AND key id should become part of that error very soon.

@peaBerberian peaBerberian added v4.0.0 Candidate PR/issue for a v4.0.0 release Priority: 3 (Low) This issue or PR has a low priority. labels Oct 4, 2022
@peaBerberian peaBerberian changed the title [v4] Remove decipherabilityUpdaate event [v4] Remove decipherabilityUpdate event Oct 4, 2022
@peaBerberian peaBerberian mentioned this pull request Oct 5, 2022
87 tasks
@peaBerberian peaBerberian added this to the 4.0.0 milestone Oct 5, 2022
@peaBerberian peaBerberian force-pushed the misc/remove-decipherability-update-event branch from 866d469 to cfb48e0 Compare October 5, 2022 13:55
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 a
    `boolean | undefined`, where it could make sense in the future to
    set to a fourth-"unknown" value (which would be different to
    the "not handled yet" case - thus just setting both to `undefined`
    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 account for the current
    quality being refused, whether it was for HDCP, CDM 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, can be mostly replicated by listening to the
    corresponding `warning` event sending an error with a
    `KEY_STATUSES_CHANGE_ERROR` code.
    The corresponding key status AND key id should become part of that
    error very soon.
@peaBerberian peaBerberian force-pushed the misc/remove-decipherability-update-event branch from cfb48e0 to 2925530 Compare October 6, 2022 14:59
@peaBerberian peaBerberian merged commit e4a0766 into next-v4 Oct 12, 2022
peaBerberian added a commit that referenced this pull request Oct 28, 2022
…pdate-event

[v4] Remove decipherabilityUpdate event
@peaBerberian peaBerberian deleted the misc/remove-decipherability-update-event branch July 6, 2023 12:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority: 3 (Low) This issue or PR has a low priority. v4.0.0 Candidate PR/issue for a v4.0.0 release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant