[MSS] Widevine pssh generation

[bbert]

This goal of this PR is to synthesize the Widevine pssh for MSS+PR streams on-the-fly with KID value extracted from PlayReady manifest's ProtectionHeader field.

With the help of this PR, this is no more required to provide pssh as an input parameter in protectionData.

The source code to build the Widevine pssh according to Google Protocol Buffer has been generated using the protobuf.js project (https://github.com/dcodeIO/ProtoBuf.js).

The source for manipulating/generating Widevine pssh has been introduced only in MSS package, to avoid increasing the build/minified file size of dash.js (dash.all). Only the MSS package (dash.mss) is increased about around 18kB (due to protobufjs package dependency).

If afterwards there is some need for adding the option to override some field values of original pssh for any stream, we could then integrate this protobufjs library into protection package. This could be generalized for all key systems.

[sandersaares]

Nice! This simplifies life. Do I understand it right that this feature activates automatically for any MSS stream with a ProtectionHeader? No activation needed by app developer?

I imagine hand-rolling the Widevine header object using byte manipulation (as is done for the PSSH box) would enable the size increase to be avoided. It is a rather tiny structure, so as long as nothing more involved is needed, perhaps this enables the feature to reach a wider set of users?

[bbert]

Yes, I confirm no activation needed by app developer, except of course providing license url.
By default, a Widevine ContentProtection node is added with a minimal pssh containing KID, algorithm (AES-CTR) and track type ('SD').

2 options:
1 - we provide a default pssh using byte manipulation to set KID value, then no possibility to custom the pssh at application level, but no increase in build file size
2 - we provide a mean to custom the pssh fields, using protobufjs library, but then inscrease the build file size

Personally, for the time being, option 1 is sufficient and acceptable.
Either we anticipate further needs, either wo do it as simple as possible for now, and keep in mind this solution for future needs.

[sandersaares]

What is the rationale behind the "SD" track type? Will hardcoding this value satisfy all expected use cases?

I guess the same question can be raised for the algorithm but this can likely be deferred until DASH-IF IOP defines something that talks about how to properly signal non-CTR content (I think there is no such signaling defined there now).

[robertbryer]

Should this probably be '>>> 24;' ? Move three bytes right and fill with zeros?

[bbert]

Yes of course! Thanks for pointing out. I will correct.

[bbert]

Hi @sandersaares,
Yes you're right about track type. I have removed it.
And for algorithm, we can also remove setting the value since the default value is assumed to be AESCTR.

[bbert]

Now the question is: do we inlude protobufjs dependency of do we simply provide the Widevine header with byte manipulation?

I am in favor of the simplest solution without increasing file, as long as nobody expresses the need for manipulating/overrinding the pssh.

[epiclabsDASH]

"+ 1" for the simplest solution. I also prefer keeping the solution as simpler as possible and don't add complexity because something that is still not a real use case.

[bbert]

OK. I have committed changes for simplest solution.