I ask for help with doubt about DASH + HLS with DRM

[ghost]

Hello, I would like to implement the script mentioned in the following thread: https://github.com/axiomatic-systems/Bento4/issues/259 but I have several doubts:

KID=18E93B2068ACAECBF142EF0266A23383 KEY=FF434A8474BD63EC1456E812F18424B7 CID=01af1718424ae08b

mp4fragment video.mp4 video_frag.mp4

mp4dash \ --force \ --subtitles \ --use-segment-timeline \ --profiles='on-demand' \ --marlin \ --widevine \ --widevine-header=provider:intertrust#content_id:${CID}#kid:${KID} \ --encryption-key=${KID}:${KEY} \ --encryption-cenc-scheme=cbcs \ --hls \ --hls-master-playlist-name=pl.m3u8 \ video_frag.mp4

1. content_id, is it provided by a third-party drm service, or is it an arbitrary hexadecimal value?

2. this: --encryption-cenc-scheme = cbcs refers to samples aes encryption? If the answer is yes, I want to know when playing the content, just pass the widevine url to activate for the contracted drm service?

In addition, a key.bin file is not necessary to reproduce the content? Well, I don't see any option in mp4dash to create that file as in mp4hls.

I appreciate your answers

[barbibulle]

For Widevine, the value of the content_id parameter is something that must be understood by the Widevine server you use. If you use a server provided by a DRM service (I see here you're probably using Intertrust's ExpressPlay service), then the value you put there should be documented by that service. Note that there is no kid field for the --widevine-header parameter, so you don't need #kid:${KID} at the end of your parameter string here.

cbcs does indeed refer to AES Sample Encryption. How the Widevine license acquisition is performed by the player depends entirely on how the player is implemented. The Bento4 packager does the encryption, and associated signaling in the content, then it is up to the player, when streaming the content, to extract that information and connect to a Widevine server to obtain a compatible license. The URL of the license server isn't included in the content metadata, that is something you need to supply to your player at the time of playback.

You don't need a key.bin file. For local testing, you can create a local key file, and refer to it from the HLS manifest, when you're not using DRM. With DRM, you actually don't want to expose that file, since it would make it possible to an end user to obtain the key directly without going through the DRM client, which is definitely something to avoid.

[ghost]

For Widevine, the value of the content_id parameter is something that must be understood by the Widevine server you use. If you use a server provided by a DRM service (I see here you're probably using Intertrust's ExpressPlay service), then the value you put there should be documented by that service. Note that there is no kid field for the --widevine-header parameter, so you don't need #kid:${KID} at the end of your parameter string here.

cbcs does indeed refer to AES Sample Encryption. How the Widevine license acquisition is performed by the player depends entirely on how the player is implemented. The Bento4 packager does the encryption, and associated signaling in the content, then it is up to the player, when streaming the content, to extract that information and connect to a Widevine server to obtain a compatible license. The URL of the license server isn't included in the content metadata, that is something you need to supply to your player at the time of playback.

You don't need a key.bin file. For local testing, you can create a local key file, and refer to it from the HLS manifest, when you're not using DRM. With DRM, you actually don't want to expose that file, since it would make it possible to an end user to obtain the key directly without going through the DRM client, which is definitely something to avoid.

Thanks for answering.

1. I am using ezdrm, for testing and I saw that script in the thread mentioned above, but I have seen that ezdrm does not provide a content_id whose value is hexadecimal, so I still do not understand that part, now you have clarified that it is only necessary to use the license server url in this case of ezdrm to play the content.

but in the case of ezdrm I don't know what content_id to use, because the only thing I see is something in base64 apparently.

ezdrm also recommends using this: --widevine-header = # PSSH DATA

at the time of packaging with bento4, so I'm stuck on this.

2. As you said, no key.bin is needed for sample aes decryption, just the widevine license url for ezdrm is enough?

Thanks sorry for my lack of knowledge.

[barbibulle]

Looking at the ezdrm docs, it looks like the service provides you with a base-64 encoded widevine header, so with the Bento4 packager, you'd pass: --widevine-header=#<header-data> where <header-data> is the data returned to you by the ezdrm service. ex: --widevine-header=#EhXXXXXXXXXXXXXXXXX6skGLGXXXXXXXXQ6IebXXXZ8kSYMXXXXXXXXXXXXXXXXj3JXXXX== (not a real value here, this is from the ezdrm example). (ezdrm has a doc about how to use Bento4 with their service, here: https://www.ezdrm.com/Documentation/EZDRM%20Bento%204%20Open%20Source%20v1.0.pdf)

[ghost]

Looking at the ezdrm docs, it looks like the service provides you with a base-64 encoded widevine header, so with the Bento4 packager, you'd pass: --widevine-header=#<header-data> where <header-data> is the data returned to you by the ezdrm service. ex: --widevine-header=#EhXXXXXXXXXXXXXXXXX6skGLGXXXXXXXXQ6IebXXXZ8kSYMXXXXXXXXXXXXXXXXj3JXXXX== (not a real value here, this is from the ezdrm example). (ezdrm has a doc about how to use Bento4 with their service, here: https://www.ezdrm.com/Documentation/EZDRM%20Bento%204%20Open%20Source%20v1.0.pdf)

Thanks for the response, I reviewed the document you named, but as I said I want to use cbs + drm in hls, and when trying to use the push you name me, the following error is skipped:

---

with --hls, only the pair syntax is supported: for the --widevine-header option

so in ezdrm, they give a content identity but I think it's in base64, try to see if I can become hexadecimal

that header mode for widevine is compatible only with dash, and not hls, you would also have to test if in dash you would accept cbs encryption

[haridarshan]

I had same requirement DASH+HLS with DRM, so I had to modify the mp4dash.py script to merge mp4dash and mp4hls changes into one to avoid packaging twice (one for hls and one fro dash) as SAMPLE_AES is not supported by non-IOS devices

@barbibulle is there any chance to have single packaging script for both dash and hls

[barbibulle]

I'll work on an update to mp4dash so that it can support all the same options as mp4hls

[krzemienski]

Hey all I also have a similar need! I’d love to have cbcs dash play where we use both widevine and Pr.

Currently my cbcs works for FairPlay, but when I go ahead and just try and feed the cbcs dash to any supported player no luck.

Here is the cbcs command and then the cenc that both do infact work.

I’m seeing above I might need to make another call to with cbcs, are you able to then get away with —no-media on the second cbcs command?

Here is what I currently run

pkg_commands = []

`package_cmd_hls_all_codecs = f”mp4dash —hls —no-split —use-segment-timeline \
    —encryption-cenc-scheme=cbcs —encryption-key=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX \
    —fairplay-key-uri skd://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX \
    —playready —playready-header=LA_URL=http://pr-keyos.licensekeyserver.com/core/rightsmanager.asmx \
    —widevine —widevine-header=provider:widevine_buydrm#content_id:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX \
    —output-dir {output_dir} —mpd-name master-cbcs.mpd \
    —language-map=und:eng —rename-media —media-prefix cbcs-target —verbose —subtitles —debug -f \
    —profiles on-demand {video_avc_for_packaging} {video_hevc_for_packaging} {audio_for_packaging}”
pkg_commands.append(package_cmd_hls_all_codecs)

package_cmd_dash_all_codecs = f”mp4dash —no-split —use-segment-timeline \
—encryption-cenc-scheme=cenc —encryption-key=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY \
—playready —playready-header=LA_URL=http://pr-keyos.licensekeyserver.com/core/rightsmanager.asmx \
—widevine —widevine-header=provider:widevine_buydrm#content_id:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX \
—output-dir {output_dir} —mpd-name master-avc-hevc.mpd \
—language-map=und:eng —rename-media —media-prefix cenc-target —verbose —subtitles —debug -f \
—profiles on-demand {video_avc_for_packaging} {video_hevc_for_packaging} {audio_for_packaging}”`

Also to note we use buydrm will this potentially be another factor as I see you guys are on ezdrm

Thanks for all the efforts here!

[krzemienski]

I had same requirement DASH+HLS with DRM, so I had to modify the mp4dash.py script to merge mp4dash and mp4hls changes into one to avoid packaging twice (one for hls and one fro dash) as SAMPLE_AES is not supported by non-IOS devices

@barbibulle is there any chance to have single packaging script for both dash and hls

So do you have a fork avail with this? I mean If my issue is to just use the the different format I’m sure I can merge them together like you did!

[barbibulle]

I have just pushed some small modifications that should fix issues seen with Widevine/CBCS mode with HLS. So you should be able to use mp4dash with the --hls options to produce an output that contains both DASH and HLS manifests, with cbcs encryption and Widevine DRM signaling. Let me know if solves your issues.

[barbibulle]

I had same requirement DASH+HLS with DRM, so I had to modify the mp4dash.py script to merge mp4dash and mp4hls changes into one to avoid packaging twice (one for hls and one fro dash) as SAMPLE_AES is not supported by non-IOS devices

@barbibulle is there any chance to have single packaging script for both dash and hls

The latest release now allows you to pass a pre-made base64-encoded header for Widevine when using mp4hls (that's still for "legacy" HLS/MPEG2-TS). For "CMAF" HLS (with a single output supporting both DASH and HLS, the updated mp4dash should allow you to do what you want now. Let me know if you get a chance to try it out.

[krzemienski]

@barbibulle i noticed https://github.com/axiomatic-systems/Bento4/issues/503 relative to cbc1 dash that was just opened. Could this causing some weirdness when trying to test the new header option you have noted above? When you have that fixed I’ll go ahead and give this a run and confirm for you if you believe so.

[barbibulle]

Issue #503 is something different (and unlikely to cause any practical issues, since cbc1 mode is probably never used in the field, and even then, the issue would probably not be noticed, unless you were trying to validate against the spec). Regarding the issue you were having, have you been able to try with the latest version? Are you still having the issue?

[krzemienski]

Issue #503 is something different (and unlikely to cause any practical issues, since cbc1 mode is probably never used in the field, and even then, the issue would probably not be noticed, unless you were trying to validate against the spec). Regarding the issue you were having, have you been able to try with the latest version? Are you still having the issue?

@barbibulle The issue im seeing recently i have narrowed down i believe actually to cenc. It seems in the mp4encrypt call with a given a key and key_id it uses

--method MPEG-CENC --global-option mpeg-cenc.piff-compatible:true --key 1:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:random --property 1:KID:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX --pssh XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:/local/encoded_160128_2976248_The_Penelope_Papers_1589157080/manifests/tmpfnkuywzl

Now to note when using the identical keys and Shaka packager for widevine playback does work. I went ahead and compare the manifests and the pssh generated seem to be a delta. Is the random after key by design?

Here is the call mp4dash -

package_cmd_dash_all_codecs = f”mp4dash —no-split —use-segment-timeline \
    —encryption-cenc-scheme=cenc —encryption-key=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY \
    —playready —playready-header=LA_URL=http://pr-keyos.licensekeyserver.com/core/rightsmanager.asmx \
    —widevine —widevine-header=provider:widevine_buydrm#content_id:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX \
    —output-dir {output_dir} —mpd-name master-avc-hevc.mpd \
    —language-map=und:eng —rename-media —media-prefix cenc-target —verbose —subtitles —debug -f \
    —profiles on-demand {video_avc_for_packaging} {video_hevc_for_packaging} {audio_for_packaging}”`

And yes I am cloning from master for my above outputs

[barbibulle]

The random suffix here is for the IV, it uses a randomly generated IV. If you have a version that works, and one that doesn't, would it be possible to send me a link to the files for both examples, so that I can compare and see what may be causing the issue?

[krzemienski]

The random suffix here is for the IV, it uses a randomly generated IV. If you have a version that works, and one that doesn't, would it be possible to send me a link to the files for both examples, so that I can compare and see what may be causing the issue?

@barbibulle here are two sets of cenc dash manifests. The names of the files describe wether I was able to ensure playback with widevine. These two mpds have identical key and key_id. I believe in Shaka when you do not provide an iv it will just use your key_id then. I’m going to try defining an iv for bento with cenc to replicate and see what might happen. Another thing I tried was to copy the widevine base 64 data header that I see in the Shaka packaged master and defined it as the header with the option we are referring too and that did not work either. dash-cenc-bento4-shaka-widevine-compare.zip

[barbibulle]

The issue here is that it looks like you passed the entire PSSH content as an argument to the —widevine-header (in the example you give here, you use the --widevine-header syntax where you pass a set of properties, but looking at the MPD in the zip file, it looks like that's not the case). When you pass a pre-computed widevine header to --widevine-header option (with a '#' prefix), it should be just the header, not the entire PSSH, because the tool already encapsulates the header in a PSSH box. As a result, the resulting PSSH in your MPD is doubly encapsulated. I am pushing an update to the code where if you happen to pass a full PSSH, instead of just the header content, that will be automatically detected. Until then, can you try passing just the PSSH payload? (from the full PSSH data, you just skip the first 32 bytes).

[krzemienski]

Interesting, and great catch! @barbibulle i see the change is on master and ill also try my current flow too! Will follow back shortly!

[qchroman]

Hello all. Just in case, I have just tried encrypting dash by passing the PR and WV headers as PSSH data and ended up with the valid PSSH and PRO inside the manifest, but with malformed PSSH for the WV inside the init chunk.

python ../utils/mp4-dash.py -f --widevine-header=#CAESEBmacxVVs0kKsbytfRqO04EaC2J1eWRybWtleW9zIhAZmnMVVbNJCrG8rX0ajtOBKgJIRA== --playready-header=#wgMAAAEAAQC4AzwAVwBSAE0ASABFAEEARABFAFIAIAB4AG0AbABuAHMAPQAiAGgAdAB0AHAAOgAvAC8AcwBjAGgAZQBtAGEAcwAuAG0AaQBjAHIAbwBzAG8AZgB0AC4AYwBvAG0ALwBEAFIATQAvADIAMAAwADcALwAwADMALwBQAGwAYQB5AFIAZQBhAGQAeQBIAGUAYQBkAGUAcgAiACAAdgBlAHIAcwBpAG8AbgA9ACIANAAuADAALgAwAC4AMAAiAD4APABEAEEAVABBAD4APABQAFIATwBUAEUAQwBUAEkATgBGAE8APgA8AEsARQBZAEwARQBOAD4AMQA2ADwALwBLAEUAWQBMAEUATgA+ADwAQQBMAEcASQBEAD4AQQBFAFMAQwBUAFIAPAAvAEEATABHAEkARAA+ADwALwBQAFIATwBUAEUAQwBUAEkATgBGAE8APgA8AEsASQBEAD4ARgBYAE8AYQBHAGIATgBWAEMAawBtAHgAdgBLADEAOQBHAG8ANwBUAGcAUQA9AD0APAAvAEsASQBEAD4APABMAEEAXwBVAFIATAA+AGgAdAB0AHAAOgAvAC8AcAByAC0AawBlAHkAbwBzAC4AbABpAGMAZQBuAHMAZQBrAGUAeQBzAGUAcgB2AGUAcgAuAGMAbwBtAC8AYwBvAHIAZQAvAHIAaQBnAGgAdABzAG0AYQBuAGEAZwBlAHIALgBhAHMAbQB4ADwALwBMAEEAXwBVAFIATAA+ADwARABTAF8ASQBEAD4AVgBsAFIANwBJAGQAcwBJAEoARQB1AFIAZAAwADYATABhAHEAcwAyAGoAdwA9AD0APAAvAEQAUwBfAEkARAA+ADwAQwBVAFMAVABPAE0AQQBUAFQAUgBJAEIAVQBUAEUAUwAgAHgAbQBsAG4AcwA9ACIAIgA+ADwAQwBJAEQAPgBGAFgATwBhAEcAYgBOAFYAQwBrAG0AeAB2AEsAMQA5AEcAbwA3AFQAZwBRAD0APQA8AC8AQwBJAEQAPgA8AEQAUgBNAFQAWQBQAEUAPgBzAG0AbwBvAHQAaAA8AC8ARABSAE0AVABZAFAARQA+ADwALwBDAFUAUwBUAE8ATQBBAFQAVABSAEkAQgBVAFQARQBTAD4APABDAEgARQBDAEsAUwBVAE0APgBnAHgAKwA2AEIAdQBMAEcAZABSADgAPQA8AC8AQwBIAEUAQwBLAFMAVQBNAD4APAAvAEQAQQBUAEEAPgA8AC8AVwBSAE0ASABFAEEARABFAFIAPgA= --encryption-key=199a731xxx:aefdf14886xxx --playready --widevine --output-dir="../_media/out" ../_media/sintel_trailer-480p.frag.mp4 ../_media/sintel_trailer-720p.frag.mp4

The manifest: `

AAAAV3Bzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAADcIARIQGZpzFVWzSQqxvK19Go7TgRoLYnV5ZHJta2V5b3MiEBmacxVVs0kKsbytfRqO04EqAkhE ` The init chunk: `00 00 00 6B 70 73 73 68 00 00 00 00 ED EF 8B A9 79 D6 4A CE A3 C8 27 DC D5 1D 21 ED 00 00 00 4B ED EF 8B A9 79 D6 4A CE A3 C8 27 DC D5 1D 21 ED 00 00 00 37 08 01 12 10 19 9A 73 15 55 B3 49 0A B1 BC AD 7D 1A 8E D3 81 1A 0B 62 75 79 64 72 6D 6B 65 79 6F 73 22 10 19 9A 73 15 55 B3 49 0A B1 BC AD 7D 1A 8E D3 81 2A 02 48 44` See how the box size and the systemid is repeated `...ED EF 8B A9 79 D6 4A CE A3 C8 27 DC D5 1D 21 ED 00 00 00 4B...`. The valid pssh box should be: `00 00 00 6B 70 73 73 68 00 00 00 00 ED EF 8B A9 79 D6 4A CE A3 C8 27 DC D5 1D 21 ED 00 00 00 37 08 01 12 10 19 9A 73 15 55 B3 49 0A B1 BC AD 7D 1A 8E D3 81 1A 0B 62 75 79 64 72 6D 6B 65 79 6F 73 22 10 19 9A 73 15 55 B3 49 0A B1 BC AD 7D 1A 8E D3 81 2A 02 48 44`

[krzemienski]

@barbibulle see above I havnt been able to have the produced dash playback in either widevine or pr and I can confirm i see the same behavior as @qchroman is noting

[krzemienski]

@barbibulle bumping if you have some time to take a look. I’d love to try and figure out what’s going on with cenc and widevine / pr. I’m willing to work through other examples too if what above also then turns out to not be the issue.

[barbibulle]

Indeed, I introduced a bug when adding support for passing a complete PSSH (and not just the payload) as input to the --widevine-header option. This is now fixed on the master branch, and I have published a new pre-compiled package.

[barbibulle]

For a simple example with Widevine with cbcs mode in a way that's compatible with DASH and HLS:

#  Key  = 07551a633e47ebf903a2d81fd903b9fe
#  KID  = 9d2f8cfe72e05c5ab895f8a030deb0a0
#  PSSH = IgQAESIzSOPclZsG [22040011223348e3dc959b06]

mp4dash -f --hls --encryption-key=9d2f8cfe72e05c5ab895f8a030deb0a0:07551a633e47ebf903a2d81fd903b9fe:random --encryption-cenc-scheme=cbcs video.mp4 --widevine-header=#IgQAESIzSOPclZsG

DASH URL: https://www.bok.net/tmp/widevine_cbcs3/stream.mpd HLS URL: https://www.bok.net/tmp/widevine_cbcs3/master.m3u8

I verified that this plays on Chrome with the Shaka player demo app: https://shaka-player-demo.appspot.com/demo

(use https://cwip-shaka-proxy.appspot.com/no_auth as the "custom license server URL")

[krzemienski]

@barbibulle This is great! And so I wasn’t having any issues with cbcs as we do not use hls and widevine, it does seem that the bug would have also effected cenc widevine with dash correct? I’ll give the latest master for cenc widevine and dash this week and report back. Thanks again for your support!

[barbibulle]

This will work just as well with plain DASH and cenc instead of cbcs.

[krzemienski]

@barbibulle just following back and here that as of latest release and master I no longer have issues with widevine and CENC. Thanks for all your help!

[ghost]

For a simple example with Widevine with cbcs mode in a way that's compatible with DASH and HLS:

#  Key  = 07551a633e47ebf903a2d81fd903b9fe
#  KID  = 9d2f8cfe72e05c5ab895f8a030deb0a0
#  PSSH = IgQAESIzSOPclZsG [22040011223348e3dc959b06]

mp4dash -f --hls --encryption-key=9d2f8cfe72e05c5ab895f8a030deb0a0:07551a633e47ebf903a2d81fd903b9fe:random --encryption-cenc-scheme=cbcs video.mp4 --widevine-header=#IgQAESIzSOPclZsG

DASH URL: https://www.bok.net/tmp/widevine_cbcs3/stream.mpd HLS URL: https://www.bok.net/tmp/widevine_cbcs3/master.m3u8

I verified that this plays on Chrome with the Shaka player demo app: https://shaka-player-demo.appspot.com/demo

(use https://cwip-shaka-proxy.appspot.com/no_auth as the "custom license server URL")

hi again, i have a question would this work for using sample-aes with dash and hls without widevine?

As I understand it, the key for sample aes should be 32 and it would generate:

(for the key) openssl rand -hex 16 (for KID)

correct me if I am in error?

or can't you use sample-aes encryption with dash and hls at the same time?

I have tried with the same commands but the key.bin file is not generated, which should contain the keys used for encryption, any suggestions?

mp4dash -f --hls --encryption-key=9d2f8cfe72e05c5ab895f8a030deb0a0:07551a633e47ebf903a2d81fd903b9fe:random --encryption-cenc-scheme=cbcs test.mp4

[barbibulle]

This would work with SAMPLE_AES, when using --encryption-cenc-scheme=cbcs as an option. If you want to have the key delivered simply over HTTP (instead of Widevine), you'll need to make sure the key value is available as a binary file at the key URL location (use --hls-key-url=<url> if you want a specific URL, othewise, by default, the URL is just key.bin, which means the client will be looking for the key at the same location as the media.m3u8 for each stream. The mp4dash tool doesn't have the equivalent of the --output-encryption-key available in the mp4hls tool, so you'll have to write the key file yourself. If you want the same non-DRM key delivery for dash, you'll need to specify the --clearkey option. Delivery of the key data for Clear Key is a bit more complicated, as it depends on the DASH client you use.

[ghost]

Esto funcionaría con SAMPLE_AES, cuando se usa --encryption-cenc-scheme=cbcscomo una opción. Si desea que la clave se entregue simplemente a través de HTTP (en lugar de Widevine), deberá asegurarse de que el valor de la clave esté disponible como un archivo binario en la ubicación de la URL de la clave (use --hls-key-url=<url>si desea una URL específica, de lo contrario, por predeterminado, la URL es solo key.bin, lo que significa que el cliente buscará la clave en la misma ubicación que media.m3u8para cada flujo. La mp4dashherramienta no tiene el equivalente de la --output-encryption-keydisponible en la mp4hlsherramienta, por lo que tendrá que escribir el archivo de clave usted mismo. Si desea la misma entrega de clave no DRM para el tablero, deberá especificar la --clearkeyopción. La entrega de los datos clave para Clear Key es un poco más complicada, ya que depende del cliente DASH que utilice.

thanks for your previous answer, but I need other clarifications

if I type the command: openssl rand -hex 16> key.bin when reading the key.bin file I get the following key "63323834313865343066336435323064363032613163363932323666616666620a" so the generated key is not 32 characters long like the one generated with this same command: openssl rand -hex 16 "e86dbd92fb6ccb4b70538a4d4f721db8" here the key is shown in the terminal but the key.bin file is not created If I use this command: openssl rand 16> key.bin, then the key.bin file is created and when reading it I get a 32-character key like the following: "2dfb0fb0bd2d3a86e4abea9b8c4a1815", I also saw in a tutorial that for sample-aes with bento they used mp4hls they used a 64 character key generated with the following command: openssl rand 32> key.bin and when reading it in the terminal it shows the following key: "f7d3559f97f97b3d48e2b1da01e43b01dd83a3b1ccec4c6816690fee95970b7e", so one of my questions is:

• Which command is the correct one of the aforementioned to generate the key.bin file that will be used with mp4dash?

-The key.bin file should only contain the key or should it also contain the kid in the same .bin file? If the answer is yes, what command would be used to generate both keys inside that key.bin file?

-The manually generated key.bin file must be included in the audio folder and in the video folder, where is media.m3u8?

-I have reproduced hls generated with mp4hls and sample-aes encryption, but I am new to dash, my other question is, when trying to reproduce the presentation in a player should I tell it that it is in front of drm as it would if it was using widevine or not? because I'm only interested in using sample-aes, I don't know what way I can play the video here:

https://shaka-player-demo.appspot.com/demo/#audiolang=es;textlang=es;uilang=es;panel=CUSTOM%20CONTENT;build=uncompiled

If you have to indicate the license url or not, if this demo of shaka-player would only reproduce dash with drm or also encrypted with sample-aes, also once I tried to reproduce here hls but I couldn't do it.

Is there any command to save a key "57f4acd7f50ee5555f4b6d2982cc31be" in a key.bin file? since there is one or more commands to read the key.bin file

And I have this doubt because if I want to use drm widevine example with ezdrm, they provide me the keys but in 32 character format not as key.bin file or when performing cbs encryption with widevine it is not necessary to have the key file. bin?

[qchroman]

Hello all. @barbibulle , I just wanted to thank you for solving the issue with the PSSH box. And I wanted to mention that command produces the output that is playable in Chrome and Safari with WV and FP. Great stuff.

python ./1.6.0.637/utils/mp4-dash.py -f ^
--widevine-header=#CAESEKHfoShxxx ^
--widevine ^
--encryption-key=a1dfa1286a3849xxx:682860eb2d3ba5xxx:a1dfa1286axxx ^
--fairplay-key-uri=skd://a1dfa128xxx ^
--encryption-cenc-scheme=cbcs ^
--hls ^
--no-split --profiles on-demand ^
--output-dir=./output/dash-hls-wv-nosplit ^
./input/sintel_trailer-480p.frag.mp4 ./input/sintel_trailer-720p.frag.mp4

[ghost]

Hi, I have a question about --widevine-header = # CAESEKHfoShxxx

I have an account with ezdrm and try to use the command like show, but according to ezdrm you have to use the PSSH (this is in base64): #CAESEJA1GVFoa14boiJDns7B8SoaDXdpZGV2aW5lX3Rlc3QiASo==, the problem here is that I have used the following command as an example with real data but there is no playback in shaka player.

so my question is what data are you using in the --widevine-header =? Why do I see that for you it is different, and with what drm company do you use for this?

[deisenbacher01]

If you are trying to use Bento4 with EZDRM. Contact EZDRM and they can assist you.

---

From: theosdark notifications@github.com Sent: Wednesday, August 12, 2020 3:07:27 PM To: axiomatic-systems/Bento4 Bento4@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [axiomatic-systems/Bento4] I ask for help with doubt about DASH + HLS with DRM (#470)

Hi, I have a question about --widevine-header = # CAESEKHfoShxxx

I have an account with ezdrm and try to use the command like show, but according to ezdrm you have to use the PSSH (this is in base64):

CAESEJA1GVFoa14boiJDns7B8SoaDXdpZGV2aW5lX3Rlc3QiASo =

the problem here is that I have used the following command as an example with real data but there is no playback in shaka player.

so my question is what data are you using in the --widevine-header =? Why do I see that for you it is different, and with what drm company do you use for this?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/axiomatic-systems/Bento4/issues/470#issuecomment-673056171, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADDOMLFCNJQQNQ7SKZJD5ZLSALR67ANCNFSM4KOW3JDQ.

[ghost]

Si está intentando utilizar Bento4 con EZDRM. Comuníquese con EZDRM y ellos pueden ayudarlo. ... ____ De: theosdark Notifications@github.com Enviado: Miércoles 12 de agosto de 2020 3:07:27 PM A: axiomatic-systems / Bento4 Bento4@noreply.github.com Cc: Subscrito <subscrito@noreply.github .com> Asunto: Re: [axiomatic-systems / Bento4] Pido ayuda con dudas sobre DASH + HLS con DRM ( # 470) Hola, tengo una pregunta sobre --widevine-header = # CAESEKHfoShxxx Tengo una cuenta con ezdrm y trato de usar el comando como show, pero de acuerdo con ezdrm tienes que usar el PSSH (esto está en base64): CAESEJA1GVFoa14boiJDns7B8SoaDXdpZGV3aW = el problema aquí es que he usado el siguiente comando como ejemplo con datos reales, pero no hay reproducción en el reproductor shaka. entonces mi pregunta es ¿qué datos estás usando en --widevine-header =? ¿Por qué veo que para ti es diferente, y con qué empresa de drm usas para esto? - Recibes esto porque estás suscrito a este hilo. Responda a este correo electrónico directamente, véalo en GitHub < # 470 (comentario) > o cancele la suscripción < https://github.com/notifications/unsubscribe-auth/ADDOMLFCNJQQNQ7SKZJD5ZLSALR67ANCNFSM4KOW3JDQ>.

which drm company are you using? I followed the tutorials that ezdrm has to pack dash with bento, but the result does not reproduce in shaka player, I suspect that the problem may be the --widevine-header that in ezdrm the pssh data is provided as base64

[krzemienski]

https://github.com/google/shaka-packager/tree/master/packager/tools/pssh you can also use this to generate your pssh boxes

[ghost]

https://github.com/google/shaka-packager/tree/master/packager/tools/pssh you can also use this to generate your pssh boxes

Hello, thanks for your answers and your good encouragement to help, I can say that I have managed to make the drm widevine of ezdrm + cbs encryption work. I did it by changing the order of the commands. I don't know why it didn't work before, no way.

but I have tried to do only the cbs encryption for hls, but when playing in shaka player it shows me an error: Shaka Error MANIFEST.HLS_REQUIRED_ATTRIBUTE_MISSING (KEYFORMAT)

the command to generate hls is this:

mp4dash -f --hls --encryption-key=000102030405060708090a0b0c0d0e0f:00112233445566778899aabbccddeeff:1122334411223344112233441122334411223344 --encryption-cenc-scheme=cbcs video.mp4

at the end of the encoding and encryption process, I have placed the key.bin file in each folder containing media.m3u8, both in the audio folder and the video folder.

then put url manifest in: https://shaka-player-demo.appspot.com/demo/ without adding url of the license server, but it has generated an error, so I read in a git post that shaka player did not support cbs encryption, it is a post from 2019.

So do you know of any other player where you can test online that is compatible? or is it a problem in the process with bento4?

[deisenbacher01]

Hello I would suggest you contact EZDRM as they will assist you in this matter.

They can outline how to use Widevine an FPS over HLS with CBC encryption

Thank you

On Fri, Aug 14, 2020 at 8:54 PM theosdark notifications@github.com wrote:

https://github.com/google/shaka-packager/tree/master/packager/tools/pssh you can also use this to generate your pssh boxes

Hello, thanks for your answers and your good encouragement to help, I can say that I have managed to make the drm widevine of ezdrm + cbs encryption work. I did it by changing the order of the commands. I don't know why it didn't work before, no way.

but I have tried to do only the cbs encryption for hls, but when playing in shaka player it shows me an error: Shaka Error MANIFEST.HLS_REQUIRED_ATTRIBUTE_MISSING (KEYFORMAT)

the command to generate hls is this:

mp4dash -f --hls --encryption-key=000102030405060708090a0b0c0d0e0f:00112233445566778899aabbccddeeff:1122334411223344112233441122334411223344 --encryption-cenc-scheme=cbcs video.mp4

at the end of the encoding and encryption process, I have placed the key.bin file in each folder containing media.m3u8, both in the audio folder and the video folder.

then put url manifest in: https://shaka-player-demo.appspot.com/demo/ without adding url of the license server, but it has generated an error, so I read in a git post that shaka player did not support cbs encryption, it is a post from 2019.

So do you know of any other player where you can test online that is compatible? or is it a problem in the process with bento4?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/axiomatic-systems/Bento4/issues/470#issuecomment-674324760, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDOMLAXZW4AYBWCRWNVSA3SAXMD5ANCNFSM4KOW3JDQ .

-- David Eisenbacher

[ghost]

Hello I would suggest you contact EZDRM as they will assist you in this matter. They can outline how to use Widevine an FPS over HLS with CBC encryption Thank you … On Fri, Aug 14, 2020 at 8:54 PM theosdark @.***> wrote: https://github.com/google/shaka-packager/tree/master/packager/tools/pssh you can also use this to generate your pssh boxes Hello, thanks for your answers and your good encouragement to help, I can say that I have managed to make the drm widevine of ezdrm + cbs encryption work. I did it by changing the order of the commands. I don't know why it didn't work before, no way. but I have tried to do only the cbs encryption for hls, but when playing in shaka player it shows me an error: Shaka Error MANIFEST.HLS_REQUIRED_ATTRIBUTE_MISSING (KEYFORMAT) the command to generate hls is this: mp4dash -f --hls --encryption-key=000102030405060708090a0b0c0d0e0f:00112233445566778899aabbccddeeff:1122334411223344112233441122334411223344 --encryption-cenc-scheme=cbcs video.mp4 at the end of the encoding and encryption process, I have placed the key.bin file in each folder containing media.m3u8, both in the audio folder and the video folder. then put url manifest in: https://shaka-player-demo.appspot.com/demo/ without adding url of the license server, but it has generated an error, so I read in a git post that shaka player did not support cbs encryption, it is a post from 2019. So do you know of any other player where you can test online that is compatible? or is it a problem in the process with bento4? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#470 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDOMLAXZW4AYBWCRWNVSA3SAXMD5ANCNFSM4KOW3JDQ . -- David Eisenbacher

If you read my previous post, I managed to do drm widevine + cbs encryption with bento4 and ezdrm, I just had to try changing the order of the commands, and it worked. I managed to reproduce the presentation in shaka player.

but what I have not achieved is to reproduce the presentation when I only do the cbs encryption for hls without using widevine. it is in the latter case that saka player presents an error

[barbibulle]

Hi @theosdark. The issue here, I think, is that Shaka Player doesn't support clearkey (i.e encrypted content where the key is delivered in the clear instead of via a DRM system). See this reported issue: https://github.com/google/shaka-player/issues/2146 That explains the Shaka Error MANIFEST.HLS_REQUIRED_ATTRIBUTE_MISSING (KEYFORMAT) error you get when trying to play such content with Shaka Player.

[ghost]

Hola @theosdark . El problema aquí, creo, es que Shaka Player no es compatible con clearkey (es decir, contenido encriptado donde la clave se entrega en claro en lugar de a través de un sistema DRM). Vea este problema informado: google / shaka-player # 2146 Eso explica el Shaka Error MANIFEST.HLS_REQUIRED_ATTRIBUTE_MISSING (KEYFORMAT)error que aparece al intentar reproducir dicho contenido con Shaka Player.

Thanks for your answers, could you tell me which player is compatible to play a hls presentation encrypted with cbs and that the key is delivered through a key.bin file?

[barbibulle]

The Apple HLS clients support it. For example, on a mac, you can open the master.m3u8 manifest generated by mp4dash, and if you have put the key files in the right place (one per media directory, where each of the media.m3u8 files live), the stream will play just fine. It should also with within Safari on iOS, or any app that uses Apple's media playback framework.