The previous method was overall fine, but assumed only one PlayReadyHeader was in the PlayReadyObject. It also incorrectly assumed the start data to be garbage data when it's actually the header for the PlayReadyObject.
Previously it would load PlayReadyHeader data under Widevine's SystemId breaking all PlayReady checks.
The actual PlayReadyHeader init_data still needs code to parse it into an object.
OEM Crypto API v16 changed slightly how the Signature algorithm was calculated. The `oemcrypto_core_message` field is now basically prefixed to the full license message for the signature.
This fixes support for devices like Roku OS 11.5.0, among others.
Currently, even though self.version would be 0, it would dump as a version=1 box with key_IDs set to data (where possible).
This is because pymp4 sets the version to 1 if key_IDs is set with data, as that would make it a v1 PSSH box. So effectively .dump() and .dumps() forces a v1 box as output even if you loaded or created a v0 box.
Fixes#16
It seems 16 is the more common limit on moderm OEM Crypto API systems (at least L1). It's also a more reasonable limit.
This also encourages people to .close() their session more. It also makes it quicker to notice if a codebase is forgetting to do a .close() call somewhere as you will reach the limit faster and easier now.
In normal use cases, a limit of 16 sessions will not be a problem as long as the sessions are being closed correctly.
This is for less effort to use the Service Certificate later on. We have no reason to keep the SignedMessage shell as it's just a way to send it as a message from License Acquisition APIs.
The logic of parsing the session's stored service cert to get the provider_id was wrong. It assumed it was a SignedDrmCertificate, when in reality it was a SignedMessage containing a SignedDrmCertificate.
It would also panic if you try to remove a certificate when none was set.
This is so you don't have to do e.g., `from pywidevine.pssh import PSSH` and instead can do `from pywidevine import PSSH`. You can still do it the other way, but now you have the choice.
This is required for cases like Google's testing DASH manifests, e.g., 'tears' MPD. It assumes the Key ID as a number, which can support up to 16 bytes in this fashion (therefore technically 15 in our scenario as 16 byte Key_IDs can load normally).
Fixes#13
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.
