Finalise Tests related to encrypted content

[louaybassbouss]

• DPCTF Tests:

  • 8.12 Playback of Encrypted Content
  • 8.13 Restricted Splicing of Encrypted Content
  • 8.14 Sequential Playback of Encrypted and Non-Encrypted Baseline Content

• Consider Clear Key encryption only

• keyId and contentKey can provided through the test-config.json

• ClearKey Content still missing

[rbouqueau]

NB: call Jan 19 2020: one content available with Clear Key would help. We may need to analyze cta-wave/Test-Content-Generation#13 first. Keeping track here.

[rbouqueau]

Would a handmade stream already help? Automatizing the process still shows some limitations (listed at cta-wave/Test-Content-Generation#21 (comment)).

Also when generating the content, what is the procedure to check it is ok? (e.g. plays back in a specific player, ... ?)

[jpiesing]

I don't know if it would help but the HbbTV DASH-DRM reference app has a Java program called 'dasher' which builds on ffmpeg and mp4box and fills in the gaps to generate encrypted content and MPDs including PlayReady and ClearKey. Source code is here. https://github.com/HbbTV-Association/ReferenceApplication/tree/master/tools

[louaybassbouss]

Would a handmade stream already help? Automatizing the process still shows some limitations (listed at cta-wave/Test-Content-Generation#21 (comment)).

Also when generating the content, what is the procedure to check it is ok? (e.g. plays back in a specific player, ... ?)

Handmade is fine for us. How the stream is generated, is not relevant for the test implementation. You can check if stream plays in dash.js reference player.

[louaybassbouss]

I don't know if it would help but the HbbTV DASH-DRM reference app has a Java program called 'dasher' which builds on ffmpeg and mp4box and fills in the gaps to generate encrypted content and MPDs including PlayReady and ClearKey. Source code is here. https://github.com/HbbTV-Association/ReferenceApplication/tree/master/tools

@FritzHeiden @mlasak FYI

[jpiesing]

I realised the cloud hosted instance of the HbbTV DASH-DRM reference app obviously includes encrypted streams with PlayReady, Marlin and ClearKey. You probably need to look at it with a debugger to get the URL for the MPDs. If you would use it a lot, it might be better to copy the MPD and the media onto your own server rather than running it off the HbbTV one all the time. It will run on a PC using dash.js.

[rbouqueau]

Thanks for the links and ideas.

For the record I initially planned to take the first clear content and make some forward encryption with GPAC: gpac -i MANIFEST_URL:forward=mani cecrypt:cfile=DRM.xml @ -o encrypted/live.mpd:pssh=mv as a first try.

I hope to make a first try before Tuesday eod.

[rbouqueau]

I have a first version but how do we plan to get the keys?

I see two ways. Both are quite easy to set up:

1. https://reference.dashif.org/dash.js/v3.2.0/samples/drm/clearkey.html =>we need to provide a custom page for our dash.js player with the protData.
2. Use a clearkey server (Support in-manifest LAURL for ClearKey playback Dash-Industry-Forum/dash.js#3343). A partner (e.g. Akamai or Axinom) could provide us with a pair of keys and allow us to make these requests for test purposes.

Do you see other options? What do we prefer?

[louaybassbouss]

I have a first version but how do we plan to get the keys?

I see two ways. Both are quite easy to set up:

1. https://reference.dashif.org/dash.js/v3.2.0/samples/drm/clearkey.html =>we need to provide a custom page for our dash.js player with the protData.
2. Use a clearkey server (Dash-Industry-Forum/dash.js#3343). A partner (e.g. Akamai or Axinom) could provide us with a pair of keys and allow us to make these requests for test purposes.

Do you see other options? What do we prefer?

Thanks @rbouqueau can you put the keys in a json file in the same folder e.g. keys.json? If you see an option to put the key in the MPD feel free to it as well. We decided in earlier meetings to keep it very simple without the need for a clearkey server (when the content is downloaded locally, there is no need to call external server). @jpiesing wdyt?

[jpiesing]

Thanks @rbouqueau can you put the keys in a json file in the same folder e.g. keys.json? If you see an option to put the key in the MPD feel free to it as well. We decided in earlier meetings to keep it very simple without the need for a clearkey server (when the content is downloaded locally, there is no need to call external server). @jpiesing wdyt?

Avoiding an external server would be better if we can. We want to keep this simple to setup. If putting them in a json file doesn't work then can we have an HTML page hosted on the PC running the test control UI?

[rbouqueau]

Let me know if any decision is taken regarding this AP. Once again it should be quite straightforward to implement once we make a decision.

[louaybassbouss]

Let me know if any decision is taken regarding this AP. Once again it should be quite straightforward to implement once we make a decision.

@rbouqueau if we can put the keys in a json file (e.g. keys.json) in the same folder of the MPD file? If yes, let's go for this option.

[rbouqueau]

@louaybassbouss Yes it is possible by adding some js (which I can do).

Auto-quote:

we need to provide a custom page for our dash.js player with the protData.

@ALL Do you have any preference or can I rely on this player page for encrypted content? If your tests depends on URL parameters or some feedback/logs from the sample player (e.g. dropped frames...) then a discussion should occur first about the integration (and maybe we should ask Daniel for advice).

Let me know.

[FritzHeiden]

Implementation of encrypted content support is done. I generated a test with encrypted content based on test 8.12 in the cenc sub folder. The keys are specified in the test-config.json

[louaybassbouss]

Implementation of encrypted content support is done. I generated a test with encrypted content based on test 8.12 in the cenc sub folder. The keys are specified in the test-config.json

Thanks @FritzHeiden 👍 . @rbouqueau FYI the content we used is the same you provided in this example. @FritzHeiden copied the required parameters in the test-config.json file manually. This means you can still provide the parameters in a JSON file as discussed above and will take care that these parameters are copied to the right place (this will be done in the test generation script).

[rbouqueau]

Ok I packaged this.

The parameters are: "J5kmSWp_XSXaafKzsnmafw": "ABEiM0RVZneImaq7zN3u_w".

There is more to do to make this automatic.

[louaybassbouss]

Ok I packaged this.

The parameters are: "J5kmSWp_XSXaafKzsnmafw": "ABEiM0RVZneImaq7zN3u_w".

There is more to do to make this automatic.

Thanks @rbouqueau this is great we will test and let you know

[FritzHeiden]

Ok I packaged this.

Just tried to use it in a test and it seems to work just fine.

[yanj-github]

Sorry that if I have missed anything here, but I have found that the current content that is played back doesn't have any annotated QR codes. This will be a blocker for us to implement observations.

[rbouqueau]

@yanj-github I said I would try to integrate my work inside the current script, ideally before next Tuesday's call. If so we'll be able to regenerate the content. Let me know if it is blocker and I can see to repackage it manually.

[yanj-github]

@yanj-github I said I would try to integrate my work inside the current script, ideally before next Tuesday's call. If so we'll be able to regenerate the content. Let me know if it is blocker and I can see to repackage it manually.

Thanks, I was wanted to raise just in case if this might get forgotten.
We will carry on and implement the observation for this test, so it wont be a massive blocker. But it means that we cannot test and verify the observation until we get this unblocked.
We can leave verification for now. I think the timeline is fine for us.

[louaybassbouss]

thanks @rbouqueau can you also generate the content with 2 representations the first one is encrypted and the second one is the same content but not encrypted. This is required for 8.14 Sequential Playback of Encrypted and Non-Encrypted Baseline Content (pages 51-52).

[rbouqueau]

New content uploaded with the -senc suffix e.g. https://dash.akamaized.net/WAVE/vectors/avc_sets/t1-cenc/stream.mpd or https://dash.akamaized.net/WAVE/vectors/avc_sets/ss1-cenc/stream.mpd

[louaybassbouss]

New content uploaded with the -senc suffix e.g. https://dash.akamaized.net/WAVE/vectors/avc_sets/t1-cenc/stream.mpd or https://dash.akamaized.net/WAVE/vectors/avc_sets/ss1-cenc/stream.mpd

Thanks a lot @rbouqueau great work 👍 we will start testing beginning of next week and keep you updated

[jpiesing]

@louaybassbouss Where is this in your backlog? (This is a just a request for understanding, not a suggestion to change your priorities).

[louaybassbouss]

Thanks a lot @rbouqueau we will test the new content and let you know

[FritzHeiden]

I put a local copy (so that you see) here: http://www.gpac-licensing.com/downloads/CTA-Wave/Test-Content/. Don't use it for production.

@rbouqueau Could you post a link to an MPD file here? I can't seem to find any cenc content on the page you provided.

[rbouqueau]

ss1: https://dash-large-files.akamaized.net/WAVE/vectors/avc_sets/15_30_60/ss1-cenc/stream.mpd

t1: https://dash-large-files.akamaized.net/WAVE/vectors/avc_sets/15_30_60/t1-cenc/stream.mpd

[FritzHeiden]

ss1: https://dash-large-files.akamaized.net/WAVE/vectors/avc_sets/15_30_60/ss1-cenc/stream.mpd

t1: https://dash-large-files.akamaized.net/WAVE/vectors/avc_sets/15_30_60/t1-cenc/stream.mpd

From these links I derived the links for the other content. I have the following issues:

Content hosted on dash-large-files.akamaized.net domain could not be played due to CORS policies. Additionally, t15, t30 still had XML parsing errors.

As the CORS errors prevented me from further testing, I tried content hosted on dash.akamaized.net:

• t3, t15, t17, t20, t23, t24, t30, t33, ss1 had XML parsing errors.
• dash reference play couldn't play any content due to missing PSSH box
• I could play most of the content in the tests, except for t2, t14, t16
  • firefox it plays a little, then freezes without error
  • chromium showed the following error: CHUNK_DEMUXER_ERROR_APPEND_FAILED: Append: stream parsing failed. Data size=131072 append_window_start=0 append_window_end=inf

[rbouqueau]

Let's discuss tomorrow about how to work around the caching issues. We are all losing time here because we are not certain to be working on the latest content.

[jpiesing]

See cta-wave/Test-Content#15

[FritzHeiden]

I tested the new encrypted content with the timestamp. There still seems to be some content with the aforementioned error CHUNK_DEMUXER_ERROR_APPEND_FAILED: Append: stream parsing failed. Data size=131072 append_window_start=0 append_window_end=inf: t1, t2, t3, t14, t15, t16

Same error occurs in dash.js reference player. Therefore our player implementation doesn't seem to cause the issue.

[rbouqueau]

I confirm that encrypting + audio&video causes an issue (a crash in the ClearKey CDM module after 14 seconds, in Windows and Linux, in Chrome/Chromium and Firefox). I need to better understand that.

Video only (encrypted) is ok.

Video encrypted + audio in clear is not ok.

[jpiesing]

I confirm that encrypting + audio&video causes an issue (a crash in the ClearKey CDM module after 14 seconds, in Windows and Linux, in Chrome/Chromium and Firefox). I need to better understand that.

Video only (encrypted) is ok.

Video encrypted + audio in clear is not ok.

@rbouqueau Is there anything I can do to help you? Is there someone I could chase?

[rbouqueau]

@jpiesing Thanks, we are waiting for Daniel's insights at the moment.

[dsilhavy]

We checked the content. I think the issue is not the encryption but rather a minor mistake in the MPD. In the audio AdaptationSet the timeline looks like this:

    <SegmentTimeline>
     <S t="0" d="88064" r="6"/>
     <S t="0" d="89088"/>
     <S t="0" d="88064" r="6"/>
     <S t="0" d="89088"/>
     <S t="0" d="88064" r="5"/>
     <S t="0" d="89088"/>
     <S t="0" d="88064" r="5"/>
     <S t="0" d="89072"/>
    </SegmentTimeline>

S@t is set to 0 for all of the entries which is not correct. It should look like this:

    <SegmentTimeline>
     <S t="0" d="88064" r="6"/>
     <S d="89088"/>
     <S d="88064" r="6"/>
     <S d="89088"/>
     <S d="88064" r="5"/>
     <S d="89088"/>
     <S d="88064" r="5"/>
     <S d="89072"/>
    </SegmentTimeline>

Otherwise it breaks the time calculation in dash.js. Additional question: Any reasons to not use the aligned segment length here (1.92 seconds) ?

Best
Daniel

[rbouqueau]

It should work. Would you please validate the fix?

[FritzHeiden]

I just ran a test and it looks good

[jpiesing]

If you're both OK then please close the issue. I can't run the test for a different reason.

[louaybassbouss]

LGTM as well closing this issue