CMAF HLS cbcs

[nibredy]

Hi @barbibulle ,

I have some feedback on using mp4dash to create HLS multi-DRM with cbcs encryption:

When using a command such as the following: mp4dash --encryption-key=43215678123412341234123412341234:12341234123412341234123412341234 --encryption-cenc-scheme=cbcs --hls --fairplay-key-uri=skd://43215678123412341234123412341234 --widevine --widevine-header=provider:intertrust#content_id:2a ToS-360_keyint_24_frag_4s_wk.mp4 ToS-540_keyint_24_frag_4s_wk.mp4 ToS-720_keyint_24_frag_4s_wk.mp4

Although it creates Widevine and FairPlay signaling, it can only playback properly with Widevine, and not FairPlay

1. FairPlay documentation state that FPS does not support the IVs listed in EXT-X-KEY tags, FPS does not support using IVs as media sequence numbers All segments must be encrypted with the same IV The license server must deliver the IV in the CKC response, hence has to know the IV upfront

   The option I found to set the IV is to use --encryption-key option such as the following undocumented way: --encryption-key=<KID>:<KEY>:<IV>

   Could you add that in mp4dash documentation maybe ? Also, since that is the only supported option with FPS, it would be good to restrict to only this encryption-key setting when hls and FairPlay are set. What do you think ?

2. As for Widevine signaling, an example of such signaling is AAAASXBzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAACkIARIQQyFWeBI0EjQSNBI0EjQSNBoKaW50ZXJ0cnVzdCIBKkjzxombBg== which decodes into { "algorithm":"AESCTR", "keyIds":["QyFWeBI0EjQSNBI0EjQSNA=="], "provider":"intertrust", "contentId":"Kg==", "protectionScheme":1667392371 } per Widevine UAT Diagnostic console https://integration.uat.widevine.com/diagnostics

   In order to be consistent, I think it will be better to have the Widevine PSSH to signal CBCS instead of CTR encryption

[barbibulle]

Hi @nibredy,

thanks for the feedback. The built-in help for mp4dash does document the option:

--encryption-key=<key-spec>
                        Encrypt some or all tracks with MPEG CENC (AES-128),
                        where <key-spec> specifies the KID(s) and Key(s) to
                        use, using one of the following forms: (1) <KID>:<key>
                        or <KID>:<key>:<IV> with <KID> (and <IV> if
                        specififed) as a 32-character hex string and <key>
                        either a 32-character hex string or the character '#'
                        followed by a base64-encoded key seed; or (2) @<key-
                        locator> where <key-locator> is an expression of one
                        of the supported key locator schemes. Each entry may
                        be prefixed with an optional track filter, and
                        multiple <key-spec> entries can be used, separated by
                        ','. (see online docs for details)

About the Widevine signaling, which version of Bento4 are you using? I just checked with the latest version, the signaling seems to be correct. With the example you have here, I get this: AAAAR3Bzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAACcSEEMhVngSNBI0EjQSNBI0EjQaCmludGVydHJ1c3QiASpI88aJmwY= which decodes to:

{
    "keyIds":["QyFWeBI0EjQSNBI0EjQSNA=="],
    "provider":"intertrust",
    "contentId":"Kg==",
    "protectionScheme":1667392371
}

[nibredy]

Thanks for your response. I missed the built-in help indeed, I was looking at the online doc only.

My mp4dash is giving "Version 2.0.0 r633", which I believe is in "Bento4-SDK-1-6-0-633.universal-apple-macosx" Yes, your header seems to be correct indeed, so I guess it should be OK with the newest version of bento4. (In my version, the protectionScheme is the same although there is an additional "algorithm":"AESCTR" which got me confused)

Hence, the only remaining feedback is about restricting the encryption-key setting to explicitly set the IV when hls and FairPlay are set.

Thanks a lot