fix: handle all keys statuses

[Florent-Bouisset]

The spec https://w3c.github.io/encrypted-media/#dom-mediakeystatus
defines 8 MediaKeyStatuses. In the RxPlayer, we didn't handle every one of them.
This PR add an appropriate behavior for the missing keys.

[peaBerberian]

I don't know if "output-downscaled" should be considered an error, for resiliency.

If it is output-downscaled, it's theoretically playing, just at a lower quality, isn't that semi-OK (like a warning-type of scenario?)

[lfaureyt]

I agree with @peaBerberian : some platforms thoretically support usage rules that require the device to force the downscale of video frames before outputting them to an uncompressed digital video output interface that is insufficiently protected.
Typical use is a usage rule requiring "downscale video output to SD if HDCP 1.4 or higher cannot be established on HDMI output". When processing a key associated with such usage rule and an unprotected HDMI output:

• a platform that doesn't support downscaling is expected to fail to decrypt content and to issue an OUTPUT_RESTRICTED error.
• a platform that does support downscaling is expected to decrypt, downscale, output content, and, I guess, to notify an OUTPUT_DOWNSCALED key status

Playready's uncompressed_digital_video_output_protection_level=270 usage rule is the typical example of such usage rule.

[Florent-Bouisset]

Thanks I have updated the behavior to authorized to use a key that is "output-downscaled".

I'm wondering if we should take in consideration that the key status is "output-downscaled" to select the appropriate track.
For example a content with 2 representations:

• Representation 1: FHD (1080p) with key status usable.
• Representation 2: UHD (4K) with key status output-downscaled.

Currently the player will select the highest quality (UHD) if the client has the required bandwidth.

But which representation has a better perceived quality between the downscaled UHD and the FHD ?

Could it be possible that the downscaled UHD representation would be at a worse quality than the FHD representation ? In it's case we don't want to select the highest quality because it has been downscaled.

[peaBerberian]

output-downscaled doesn't seem to indicate details about the downscaling it performs, so I'm not sure if we could be able to compare it with other Representations (if there even is other Representations).

Treating "output-downscaled" as a "whitelisted" case seems ok to me in the meantime, as we've never yet even encountered that key status, but we might have to set a more complex logic in the future if we do observe some unwanted situation with it.

[peaBerberian]

As discussed while drafting things after #1427 for what I would call support of "accidental multi-key responses" scenarios where the license server would respond with multiple keys despite a keySystems[].singleLicensePer: "init-data" RxPlayer option, we may have (due to a very subtle fallbacking edge case) to handle the "pending" MediaKeyStatus as neither a blacklisted key status nor as an unknown one (which could in that scenario be wrongly interpreted as unsupported if the license request was for that key id).

So the question is whether we whitelist that key in the meantime (yet that would be kind of weird to consider corresponding Representations "decipherable") or if a special "pending" status should be added, kind of like unknown but for which no fallback would be triggered (at least until we do know the real status).

[peaBerberian]

I'm writing about a pretty rare scenario but now that I think of it, I don't see how the same cases couldn't arise in the other singleLicensePer scenario. We could be fallbacking due to "pending" key statuses in any case if we treat it as if the key wasn't in the license.