playlists with 'usable' keystatus feature

[BucherTomas]

This is a feedback to the recently added feature of using only playlists with usable keystatus from https://github.com/videojs/http-streaming/pull/1460 in version 3.9.0 so apologies it does not follow the ticket template.

It is a welcome addition to the library, thank you, but it does not appear too robust at the current stage.

Here is a test stream where HD tracks require hardware-backed Widevine decryption, so all-in-all an emulation of somewhat strict real-world stream conditions:

https://videojs-http-streaming.netlify.app/?debug=true&autoplay=false&muted=false&fluid=true&minified=false&sync-workers=false&liveui=true&llhls=true&url=https%3A%2F%2F1798253129.ssl.cdn.cra.cz%2FUHD%2Ffull%2Fhddrm.ism%2Fmpdmod%2F.mpd&type=application%2Fdash%2Bxml&keysystems=%7B%0A%20%20%22com.widevine.alpha%22%3A%20%7B%0A%20%20%20%20%22url%22%3A%20%22https%3A%2F%2Fdrm-widevine-licensing.axtest.net%2FAcquireLicense%3Faxdrmmessage%3DeyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJjb21fa2V5X2lkIjoiNjVGM0JCNjItQUUwMS00MThGLUFCNkUtRTlBNTgwOUU3MEIxIiwibWVzc2FnZSI6eyJjb250ZW50X2tleV91c2FnZV9wb2xpY2llcyI6W3sibmFtZSI6Imhkc2VjIiwicGxheXJlYWR5Ijp7Im1pbl9kZXZpY2Vfc2VjdXJpdHlfbGV2ZWwiOjMwMDAsImFuYWxvZ192aWRlb19vdXRwdXRfcHJvdGVjdGlvbnMiOlt7ImNvbmZpZ19kYXRhIjoiQUFBQUF3PT0iLCJpZCI6IkMzRkQxMUM2LUY4QjctNEQyMC1CMDA4LTFEQjE3RDYxRjJEQSJ9XSwiYW5hbG9nX3ZpZGVvX29wbCI6MTUwLCJjb21wcmVzc2VkX2RpZ2l0YWxfdmlkZW9fb3BsIjo1MDAsInVuY29tcHJlc3NlZF9kaWdpdGFsX3ZpZGVvX29wbCI6MzAwfSwid2lkZXZpbmUiOnsiaGRjcCI6IjEuMCIsImRldmljZV9zZWN1cml0eV9sZXZlbCI6IkhXX1NFQ1VSRV9ERUNPREUifX0seyJuYW1lIjoic2RzZWMiLCJwbGF5cmVhZHkiOnsibWluX2RldmljZV9zZWN1cml0eV9sZXZlbCI6MjAwMCwiYW5hbG9nX3ZpZGVvX291dHB1dF9wcm90ZWN0aW9ucyI6W3siY29uZmlnX2RhdGEiOiJBQUFBQXc9PSIsImlkIjoiQzNGRDExQzYtRjhCNy00RDIwLUIwMDgtMURCMTdENjFGMkRBIn1dLCJhbmFsb2dfdmlkZW9fb3BsIjoxNTAsImNvbXByZXNzZWRfZGlnaXRhbF92aWRlb19vcGwiOjUwMCwidW5jb21wcmVzc2VkX2RpZ2l0YWxfdmlkZW9fb3BsIjoyNTB9LCJ3aWRldmluZSI6eyJkZXZpY2Vfc2VjdXJpdHlfbGV2ZWwiOiJTV19TRUNVUkVfREVDT0RFIn19LHsicGxheXJlYWR5Ijp7Im1pbl9kZXZpY2Vfc2VjdXJpdHlfbGV2ZWwiOjIwMDB9LCJuYW1lIjoiYXVkaW8iLCJ3aWRldmluZSI6eyJkZXZpY2Vfc2VjdXJpdHlfbGV2ZWwiOiJTV19TRUNVUkVfQ1JZUFRPIn19XSwidmVyc2lvbiI6MiwidHlwZSI6ImVudGl0bGVtZW50X21lc3NhZ2UiLCJjb250ZW50X2tleXNfc291cmNlIjp7ImlubGluZSI6W3sidXNhZ2VfcG9saWN5Ijoic2RzZWMiLCJpZCI6ImY1YmYzM2FjLTA4NDQtMGM4MS1kNjIzLTAxOWM4N2ZlMTM2MCIsIml2IjoiVDNIZUw4emIyTExnb2dkVmI5a1h3UT09In0seyJ1c2FnZV9wb2xpY3kiOiJoZHNlYyIsImlkIjoiZjRlYThkYjgtNzZhZS05YzhjLTJhMjEtOTg4MmQ3NjNiYzdkIiwiaXYiOiJpRXVLTEFRMElvYVpzZ3Voc0s1SENRPT0ifSx7InVzYWdlX3BvbGljeSI6ImF1ZGlvIiwiaWQiOiJmZjE0ZmM5Yy1iOGM3LTYwNjctY2Q0Yy1hY2YyOTQzNjU4NWEiLCJpdiI6Im1rUTA2bENFdG45YkVLYStzSUpMUGc9PSJ9XX0sImxpY2Vuc2UiOnsiZHVyYXRpb24iOjYwNDgwMCwid2lkZXZpbmUiOnsiaW5jbHVkZV9hbGxfZW50aXRsZWRfa2V5cyI6dHJ1ZX19fSwidmVyc2lvbiI6MX0.rxbmZ8KWPdqigtrvXhvB76d2NKjSMFuHGBt5U8rsEnM%22%0A%20%20%7D%0A%7D&buffer-water=false&exact-manifest-timings=false&pixel-diff-selector=false&network-info=false&dts-offset=false&override-native=true&preload=auto&mirror-source=false&forced-subtitles=false

The same stream configuration works as expected on desktop Chrome with Widevine L3 in players such as Shaka or Bitmovin and representations with higher resolution than 576p are removed from the stream. By the way, L2 or L1 are also becoming available for desktop Chrome on Windows with "com.widevine.alpha.experiment" keysystem, so this should be also something for you to take into account in the near future, but I digress.

The same stream fails in VHS once HD tracks are selected, because their keyID f4ea8db876ae9c8c2a219882d763bc7d is apparently still used and not filtered out even though according to EME logger extension, the MediaKeyStatusMap includes just video SD keyID f5bf33ac08440c81d623019c87fe1360 and audio track keyID ff14fc9cb8c76067cd4cacf29436585a, both tagged as usable. License server does not provide in this case any response for f4ea8db876ae9c8c2a219882d763bc7d at all, which is recommended, so it is not present even tagged as output-restricted for example. You can see for yourselves with the stream above.

The test stream configuration above is for Widevine. To expand on this implementation also for PlayReady, it behaves differently and if a keyID is unusable in current context (for example requesting SL3000 license for HD tracks from a SL2000 device), the license server may instead return status code 500 for the license associated with HD tracks but all the others will be fine. In current state, this is a fatal failure for the player. Instead the player should continue, attempt to utilize all the remaining usable licenses and again remove unusable representations from the stream for which the license request failed. PlayReady might also already need the com.microsoft.playready.recommendation and com.microsoft.playready.recommendation.3000 keysystems.

Also a question, does the implemented logic react to ad-hoc changes in keystatus? For example:

1. HD tracks require HDCP 2.0
2. The player starts streaming on integrated notebook display which supports HDCP 2.2, so all keyIDs and associated tracks are usable
3. While streaming, an external monitor capable of HDCP 1.0 only is connected, CDM detects that and flags the keyID for HD tracks as output-restricted
4. Player should react to it and switch to remaining available representations for SD tracks only The same should be applicable also in reverse when you disconnect the external monitor which should enable the HD tracks again.