There's no need for it. The image isn't even done particularly well. It's too specific to a browser scenario with some information not properly reflected/explained in the legend.
I have no reason to try make my own or look for an alternative. If someone is particularly interested they can look online for more or less broad explanations as they see fit.
This is to fix some security vulnerabilities. The main dependency locking this to 4.8.0 for so long was pycaption, which was updated to support 4.9.1 in v2.1.0.
This ensures that a partially parsing input (because of optional flags in the proto) does not get past any verification checks.
This prevents issues like an invalid License Challenging from getting an exception later down the line, as well as possibility of it also passing that check by pure luck, resulting in hard to debug issues.
The main change is that it isn't stored as 16-bytes. Effectively not stored like it realistically probably meant to be. It's instead stored as a hex string that was then encoded to bytes (32 data is now taken up).
But I've also improved the comments about my research for the first half of the request ID. This research is likely still incomplete as I'm just not fully sure about the randomness of bytes 5-8.
This is now possible because everything relating to an underlying session is now finally fully remote thanks to the changes surrounding the new get_keys() method.
Any client code still getting keys by accessing `_sessions` manually should be updated to use the get_keys() method.
We shouldn't really provide the derived context keys. There isn't any use to them outside of that specific license request and license response for which it was derived from. The only use to them would be to allow the client to decrypt the keys manually, which wont be necessary nor secure.
This is actually possible and in some cases necessary. While v0 boxes do not use key_IDs field of the PSSH Box, we can store the provided key_ids in the init data. E.g., Apple Music.
A by product of this change is dropped support for providing a PSSH or init data directly in any form, that includes base64.
You must now provide it as a PSSH object, e.g., `cdm.get_license_challenge(session_id, PSSH("AAAAW3Bzc2...CSEQyAA=="))`
The idea behind this is to simplify the amount of places where parsing of PSSH and Init Data to a minimal amount. The codebase is getting quite annoying with the constant jumps and places where it needs to test for base64 strings, hex strings, bytes, and direct parsed PSSH boxes or WidevinePsshData. That's a ridiculous amount of code just to take in a pssh/init data, especially when the full pssh box will eventually be discarded/unused by the Cdm, as it just cares about the init data.
Client code should pass any PSSH value they get into a PSSH object appropriately, and then store it as such, instead of as a string or bytes. This makes it overall more powerful thanks to the ability to also access the underlying PSSH data more easily with this change.
It also helps to increase contrast between a compliant Widevine Cenc Header or PSSH Box, and arbitrary data (e.g., Netflix WidevineExchange's init data) because of how you initialize the PSSH.
It also allows the user to more accurately trace the underlying final parse of the PSSH value, instead of looking at it being pinged between multiple functions.
RemoteCdm now also sends the PSSH/init_data in full box form now, the serve API will be able to handle both scenarios but in edge cases providing the full box may be the difference between a working License Request and not.
We can clear a repeated field with `del field[:]` and overwrite an entire field with `field[:] = [b"123", b"456"]`. So we can reduce this down to a single call operation.
