keystatuses provide keyId's.. but there's no real way to track them earlier than when they appear in that status. In DASH they appear in the ContentProtection, and they're also in the initializationSegment either in the pssh or the tenc. But if the pssh isn't in the manifest it's difficult to use the encryptedinitData to track the KeyId, unless the browser was responsible for upgrading v.0 pssh boxes to v.1 boxes with the tencdefault_KID, or some other way to include a KeyID in the encrypted payload. This makes platforms with multiple CDM implementations difficult, because two encrypted event's could occur, each event with it's own systemId (that you have to parse from the initData) for the same keyId. Unless the requirement was that only one encrypted event occurred per keyId, and the initData was an array of array buffers.
keystatusesprovide keyId's.. but there's no real way to track them earlier than when they appear in that status. In DASH they appear in the ContentProtection, and they're also in the initializationSegment either in thepsshor thetenc. But if thepsshisn't in the manifest it's difficult to use theencryptedinitDatato track the KeyId, unless the browser was responsible for upgrading v.0 pssh boxes to v.1 boxes with thetencdefault_KID, or some other way to include a KeyID in the encrypted payload. This makes platforms with multiple CDM implementations difficult, because two encrypted event's could occur, each event with it's own systemId (that you have to parse from the initData) for the same keyId. Unless the requirement was that only one encrypted event occurred per keyId, and the initData was an array of array buffers.