fix(isobmff): exclude zero-filled keyId from the init segment parsing

[el-gringo]

• A zero-filled keyId makes all streams undecipherable.

fix #1458

[lfaureyt]

It seems this code returns the keyId value only if all its bytes are non-zero, which is wrong.

Suggested change

	return keyId.every(value => value !== 0)
	return ! keyId.every(value => value == 0)

[el-gringo]

right !
Thanks, I changed my code last minute.

[peaBerberian]

Cool thanks!

Very small nitpick but I find that here:

return keyId.every(...) ? null : keyId

easier to reason about than potentially having to think about what the negative of every means like here (or at least going through a supplementary step):

return !keyId.every(...) ? keyId : null;

But other than that, LGTM

[el-gringo]

alright. I test the build then push the update.
By the way. what would trigger the ISOBMFF parsing ? For testing the fix, I have to seek randomly in the stream until it triggers the error, so I know the issue happens at that specific time in the stream, then I apply the patch and seek at that time to check if there is any change in representations.

[peaBerberian]

By the way. what would trigger the ISOBMFF parsing ?

We do it as soon as we have loaded the corresponding initialization segment (this code is called by our DASH "segment parser" - which extracts metadata from a segment - and which is called just after our DASH "segment loader" - which just performs the segment request - succeeds). And we only do that request when we start to buffer the related media.

Here I don't know if the corresponding init segment is linked to a different DASH <Period> (e.g. like it could be for an ad or a specific live program for example) or if it's another Representation (quality). Because you wrote that it happens at specific times, the most probable is that it's linked to a Period.

Then the logic is that as the init segment contains all the encryption metadata we need anyway, we can parse it to handle cases where the MPD did not have all the information (which is not just theoretical, we worked with partners that did not put the key id in their MPD).
So if we detect supplementary encryption metadata in there, we update the Representation and signals through our "segment parser"'s return that we did so (through a protectionData property). This then triggers some checks in our central logic to be sure the added encryption metadata is properly handled.