DRM encryption content (CENC, CBCS, Playready, Widevine)

[Murmur]

Do LiveSim2 supports CENC and CBCS segments? It does not care too much about the scheme or target system (Playready, Widevine, Fairplay, ClearKey)? Livesim2 keeps an existing <ContentProtection> elements in vod-to-live manifest?

Playready CENC https://refapp.hbbtv.org/videos/00_llama_h264_v8/cenc/manifest_prcenc_1080p.mpd
laurl: https://test.playready.microsoft.com/service/rightsmanager.asmx?cfg=(kid:header,sl:2000,persist:false,contentkey:EjQSNBI0EjQSNBI0EjQSNg==)

Playready CBCS(1:9) https://refapp.hbbtv.org/videos/00_llama_h264_v8/cbcs/manifest_prcenc_1080p.mpd
laurl: https://test.playready.microsoft.com/service/rightsmanager.asmx?cfg=(kid:header,sl:2000,persist:false,contentkey:EjQSNBI0EjQSNBI0EjQSNg==,ckt:aescbc)

[tobbee]

I haven't tested yet but an encrypted VoD asset should be possible to use and should result in an encrypted live asset.
This assumes that

1. The MPD elements for DRM are not changed when converting from static to dynamic MPD (could happen if name-space is not supported)
2. All encryption element are kept in the segments. This should be fine, since mp4ff propagates both known and unknown boxes, and timing information is not encrypted. Low latency may possibly cause an issue.

In any case, encrypted content is pretty high up on the priority list, so it is likely that some test content will be generated a bit later.

[tobbee]

I've started to look into this and adding actual cenc/cbcs encryption to the mp4ff library.
An extra thing is dynamic low-latency chunking where segments are dynamically chunked to a desired duration. With encryption, the saiz, said, and sent boxes also needs to be created for each fragment.

Hopefully I can get something ready for 1.0 at the end of the month.

[Murmur]

@tobbee LiveSim2 does not return an init segment of ready-to-use DRM content. Livesim2 should not do anything extra at runtime but just serve files and do segnum+timestamp manipulation only.

Is there problems if vod content is using subfolders? I have a content root for non-drm files and /cenc/ | /cbcs/ subfolders for drm files.

DRM manifest, init and segment
OK https://refapp.hbbtv.org/livesim2/tsbd_99999/mup_4/spd_8/utc_keep/00_llama_h264_v9/cenc/manifest_prwvcenc_1080p.mpd
NOT_FOUND https://refapp.hbbtv.org/livesim2/tsbd_99999/mup_4/spd_8/utc_keep/00_llama_h264_v9/cenc/v1/i_prwvcenc.mp4
OK https://refapp.hbbtv.org/livesim2/tsbd_99999/mup_4/spd_8/utc_keep/00_llama_h264_v9/cenc/v1/443060898.m4s

Non-DRM manifest, init and segment
OK https://refapp.hbbtv.org/livesim2/tsbd_99999/mup_4/spd_8/utc_keep/00_llama_h264_v9/manifest_1080p.mpd
OK https://refapp.hbbtv.org/livesim2/tsbd_99999/mup_4/spd_8/utc_keep/00_llama_h264_v9/v1/i.mp4
OK https://refapp.hbbtv.org/livesim2/tsbd_99999/mup_4/spd_8/utc_keep/00_llama_h264_v9/v1/443060898.m4s

[tobbee]

I don't know if having MPDs at different levels is working properly. livesim2 is trying to map things into "assets" and an asset is a directory with one or more MPDs. It will list imported assets as it starts up, so you should see there if it is fine or not.

[Murmur]

NonDrm mpd+initmp4+segm4s works fine. Drm mpd+segm4sworks fine but initmp4 failed.
See urls in a previous comment I added OK/NOT_FOUND tag.

Livesim2 does almost support a nested manifests. No need to support this nested url pattern. I can copy the original files to a separate nodrm+drmcenc+drmcbcs asset folders. My original plan was to reuse an existing refapp vod folders as-is.

[tobbee]

There is some work to be done to support pre-encrypted segments, since all segments are re-fragmented and that process currently doesn't look at the encryption boxes saio, saiz, senc etc. If some organisation is in need of this functionality, it would be good if it could sponsor the work so that I can put some time on implementing it.

[Murmur]

Ok so LiveSIM1(python app) does more simple straightforward processing by not trying to understand input segments too much. All it really does is this so makes more suitable for "take ready-to-use segments and write responses":

• map input url $Number,$Time to the original segment filenames (roll wrap 1..VODMAX.m4s to 1..N infinite live numbering)
• modify vod.mpd to live.mpd manifest.
• write MOOF.MFHD.SequenceNumber=0..N number as if it was a continuous live numbering.
• write MOOF.TRAF.TFDT.DecodeTimeTime=0..N timestamp as if it was a continuous live timeline.
• anything else inside the segments is left untouched (emsg, drm etc.. atom tables).

[tobbee]

Yes, livesim1 does less changes to the segments and is therefore dependent on content being perfectly loopable as it is with no difference in total duration between audio and video. It does some changes in emsg in some cases (scte-markers), and also some changes to the duration in the init segment. It also changes the subtitle payload for stpp since the internal timestamps are global. The CTA-WAVE test content has an MP4 fragment for each frame, which may not work with livesim1.
For low-latency (chunkdur set), livesim1 becomes closer to livesim2 by doing on-the-fly refragmentation of the input segments to appropriate fragment durations, so in that case encryption would not work without modifying more boxes.
The standard live case with full encrypted segments should probably work fine.

One could consider a mode in livesim2, where it doesn't resegment the segments, but modifies them more similar to livesim1., but one then needs to assert that a number of restrictions are fulfilled, so I'd rather make the encryption case with full segment processing working.

[tobbee]

I got the impression that this works for pre-encrypted segments as long as the segments are not rewritten sample-wise.
So, for example, single-fragmented segments where the audio duration is the same as video (like 1.92s) will go through the system and senc, saio and saiz boxes should still be valid. However, if the segments are refragmented to become low-latency or if the audio duration does not match video, things will not work.

There is no warning for this behaviour, so that may be another ticket, but at least I think the basic use case is working.
Do you agree @Murmur?

For low-latency encryption, the on-the-fly encryption with ECCP works for the test streams with AVC video and AAC audio (PR #150).

[Murmur]

@tobbee What we do for Hbbtv Refapp is always using 100% aligned video+audio segments using the following magic number principals for segment duration:

25fps or 50fps AAC 48Khz -> 3840ms with 1920ms gop (2x 1.92s moofmdat chunks)
30fps or 60fps AAC 48Khz -> 3200ms with 1600ms gop (2x 1.60s moofmdat chunks)
failsafe to 8000ms with 2000ms gop (4x 2s moofmdat chunks)

This will allow an easy smooth vod-to-live simulation without timeline drifting on vod cycles, manifest SegmentTimeline.S list is compact, dash players and the entire "random ecosystem pipeline" like 100% aligned segments.

Also what you describe it should work fine on Livesim2's segment refragment manipulator even with our multiple fragments in a segment file (all chunks use 100% identical duration)?
This comment >> single-fragmented segments means a single moofmdat chunk in a segment file?

Is the latest drm changes merged to master branch already? we have a manually triggered build script for easy deployment on a production server.

See LIVE tabsheet using livesim2(nodrm) and livesim1(playready and widevine cenc cbcs). We would like to use our ready-to-run 3.84s drm content on livesim2 as well.
https://refapp.hbbtv.org/staging/catalogue/

[rbouqueau]

the entire "random ecosystem pipeline" like 100% aligned segments.

This is certainly a great way to validate your progress. However reference streams shouldn't be more restrictive than the specifications. Otherwise it may defeat the purpose of interoperability.

This has been discussed numerous times in standardization groups. The general feeling is that we may want to lean toward more restrictive specifications (up to the point where there may be only one way to package a compliant stream).

[juhajoki]

One of the goals of the HbbTV DASH DRM Reference App was to find out the best practices and "recipes" that would work on the widest variety of devices. So kind of being "more restrictive" was the natural progression of things in the project and in Aki's work.

[tobbee]

@Murmur Yes, an encrypted segments with just one fragment covering all the samples should be possible to run through the system. The only new thing needed for that was the ContentProtection elements and their corresponding name spaces, and that has been merged to the main branch. The update with on-the-fly encryption and DASH-IF ECCP has also been merged. That version will also report that some representations are pre-encrypted when starting up.

I plan to make a new release of livesim2 (v.1.2.0) next week which will include these changes. If you want, you may try
out the system before that and report any things that may need an update.

[Murmur]

@tobbee We currently have a deployment pipeline from the github/livesim2@main branch so thats what is installed on our server. We do not read PullRequest versions or adhoc feature branches at the moment.
Current reply header says Dash-If-Livesim2: v1.1.1-7-ga6fba5f, date: 2024-01-30

[Murmur]

@tobbee Latest master deployed on a production. Not working read-to-use encoding at least on dashjs. Video frame flashes few times on dashjs then playback failed.

Segments, init and manifest file is returned from the livesim2 this time.

Manifest and LaUrl(playready)
https://refapp.hbbtv.org/livesim2/tsbd_240/mup_4/spd_8/utc_keep/00_llama_h264_v9_cenc/manifest_prcenc_1080p.mpd
https://test.playready.microsoft.com/service/rightsmanager.asmx?cfg=(kid:header,sl:2000,persist:false,contentkey:EjQSNBI0EjQSNBI0EjQSNg==)

Dashjs: https://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html

[tobbee]

@Murmur I don't have any device that can play PlayReady so you need to do some more trouble shooting yourself.
If you use the cached representation data mechanism for faster setup, it may be worth recreating the files by running livesim2 once with the --writerepdata option.

For the rest, I recommend that you check the input and output segment and check if they differ beyond timestamps and sequence numbers.