You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
https://dashif.org/docs/IOP-Guidelines/DASH-IF-IOP-Part6-v5.0.0.pdf Section 9.3 does not mention that init-data needs to be updated at each key-rotation. Some content packaging providers interpret this to mean that they do not need to update the init-data for each key-rotation.
As per section 9.3 - "The initialisation segment has one PSSH box per DRM allowing to access content and a default_KID value
in the tenc box" - this means that a) content packager cannot omit the PSSH in the moov and default_KID in tenc and b) that it is for "allowing to access content" which means it always needs to fetch a valid license.
If the content packaging providers do not update the init-data, it will have a PSSH for a key that has long since rotated. One particular packaging provider is adding PSSH to every moof, and their expectation was that since the default_KID/PSSH in moof overrides the one in the init-data/moov, the stream should play fine.
For the players/parsers - they have no way of knowing after downloading the init-data that they can or should ignore the PSSH in the init-data. Players will send out the license request as soon as they see the PSSH. A player cannot distinguish easily if the key resulting from the PSSH in the init-data may still be required (for example it may be required to decrypt content until the first in-band key rotation) or not (when the init-data is not updated by the packaging provider). Due to this, it will always issue a license request.
If packaging providers do not update the init-data for each key-rotation this will result in a request for a license that will never be used (which is inefficent and wasteful) and there is also burden on the license provider to provide a valid license response for a key that has already been rotated and no longer active, otherwise playback might fail.
DASH-IOP spec should provide some clarifications that the init-data needs to be updated at key-rotation, and that the same PSSH could be added to the moof segments that follow (until the next key rotation)
The text was updated successfully, but these errors were encountered:
https://dashif.org/docs/IOP-Guidelines/DASH-IF-IOP-Part6-v5.0.0.pdf Section 9.3 does not mention that init-data needs to be updated at each key-rotation. Some content packaging providers interpret this to mean that they do not need to update the init-data for each key-rotation.
As per section 9.3 - "The initialisation segment has one PSSH box per DRM allowing to access content and a default_KID value
in the tenc box" - this means that a) content packager cannot omit the PSSH in the moov and default_KID in tenc and b) that it is for "allowing to access content" which means it always needs to fetch a valid license.
If the content packaging providers do not update the init-data, it will have a PSSH for a key that has long since rotated. One particular packaging provider is adding PSSH to every moof, and their expectation was that since the default_KID/PSSH in moof overrides the one in the init-data/moov, the stream should play fine.
For the players/parsers - they have no way of knowing after downloading the init-data that they can or should ignore the PSSH in the init-data. Players will send out the license request as soon as they see the PSSH. A player cannot distinguish easily if the key resulting from the PSSH in the init-data may still be required (for example it may be required to decrypt content until the first in-band key rotation) or not (when the init-data is not updated by the packaging provider). Due to this, it will always issue a license request.
If packaging providers do not update the init-data for each key-rotation this will result in a request for a license that will never be used (which is inefficent and wasteful) and there is also burden on the license provider to provide a valid license response for a key that has already been rotated and no longer active, otherwise playback might fail.
DASH-IOP spec should provide some clarifications that the init-data needs to be updated at key-rotation, and that the same PSSH could be added to the moof segments that follow (until the next key rotation)
The text was updated successfully, but these errors were encountered: