canalplus/rx-player

DRM: Zero filled TENC KID cause a NO_PLAYABLE_REPRESENTATION error

el-gringo opened this issue · 4 comments

I've upgraded RxPlayer from 3.26 to 4.0.0. It is mostly working fine, excepted a fatal error NO_PLAYABLE_REPRESENTATION randomly while playing the streams.

After further investigation, I found that in our MP4 initialization segment, the TENC box has a zero filled KID. This Key ID is added to the one found in the manifest ContentProtection cenc and disable the decipher ability of the streams.

Error from the console :
Screenshot from 2024-06-14 08-44-52

Our MP4 Fragment :
Screenshot from 2024-06-14 08-50-47

Is there a way to disable RxPlayer to parse the init segment ?

For now I have patched getKeyIdFromInitSegment in parsers/containers/isobmff/utils.ts to return null if the keyId is zero and it works.

This issue is related to #1183
I've managed to correctly manage the DRM sessions by setting singleLicensePer to content.

Hi,

Is a full-0 key id documented somewhere as not valid (or maybe it means here that the following media is unencrypted)?
I'll have to check specs and what others are doing here.

I don't think the zero key is not valid, but it's more about the fact that the key in TENC is not present in the ContentProtection makes all streams undecipherable. I've digged a bit on the key update algorithm when I posted the issue #1183 but the other errors I was facing made it hard to get further.

All of our media are encrypted, it is just the TENC key which filled with zero.

Turns out after checking around that a key id set to all 0 indicate that the stream is unencrypted IF the "Is encrypted" value is also set to 0 (it is set to 1 in your case) and IV size to 0 (it is set to 8 in your case).

Anyway, tenc parsing was added to improve our player's compatibility as some streams "forget" to add ContentProtection in their MPD or more frequently do not communicate the key id inside it, which is a central information in our strategy of only avoiding undecipherable contents when some Representations are decipherable and some not.

Because it was added for resilience, and because a 0x0 key id is fishy anyway, I guess we can ignore it when found in a tenc like you did.
You may do a Pull request with your modification (maybe with a comment added), or I can do it instead if you're OK with it.