Watermarking

Forensic watermarking provides an efficient deterrent against pirated copies of content.

It is the means by which a unique identifying code is inserted into a media asset. By adding a unique identity disseminated throughout a piece of media, that content, along with its owner, becomes identifiable.

Digital watermarks are used to enforce contractual compliance between a content owner and the intended recipient. It provides proof of misuse and a link back to the source of a leakage. It is one of the most powerful means to protect media content.

If you want to deliver a watermarked stream at scale, the recommended approach is to rely on Origin creating the A/B sets and do the switching at the CDN, perhaps even at the network's edges.

This way, you deliver the same client manifest to all viewers, with those viewers making requests with a unique identifier based on which the watermarking solution will route the request to version A or B of the stream, both of which are hosted by Origin (each using a separate server manifest).

This has two distinct advantages:

• Viewers don't see the watermarking pattern reflected in the client manifest (which they would if the client manifest would have been manipulated by a proxy downstream from Origin but upstream from a CDN)

• Both A and B versions of each segment can be easily cached by the CDN because from the CDN's point of view the A and B versions come from different sources (the A and B versions of the stream hosted by Origin)

Irdeto TraceMark

With TraceMark, Irdeto provides a watermarking service that can be integrated into a content distribution workflow with Unified Origin. It enables segment switching to deliver customers a personalized video stream in DASH, HLS TS or HLS fMP4. To learn more about its specifics, please contact Irdeto.

The sections below explain how to configure Origin when setting up Irdeto TraceMark for Live and VOD. Note that when using encryption (and DRM protection) in combination with TraceMark, sub-sample encryption should be used (i.e., not HLS AES-128, which employs full sample encryption).

Live

For Live, the setup requires one publishing point that will ingest two identical but uniquely watermarked streams. This works by having a Live encoder output a livestream to Irdeto's Live Embedder, which will add A/B watermarking to certain samples and output A/B versions of the stream to Origin. Irdeto's Live will make sure that Origin is able to differentiate the A/B streams based on track names. In addition, Irdeto's Live Embedder will add padding to watermarked samples when necessary to ensure that samples with the same timestamp from both streams will always be identical in size.

As for the configuration of Origin it is required to ensure that the output segments are of the same length as the segments sent by the Live encoder. For DASH, this is default behavior. For HLS, please ensure that your Live encoder sends segments that are equal in length (for both audio and video) and use hls.minimum_fragment_length to configure Origin to use this length for its HLS output (the below example doesn't take into account any DRM options):

mp4split -o channel1.isml \
  --restart_on_encoder_reconnect \
  --archiving=1 \
  --archive_segment_length=60 \
  --dvr_window_length=30 \
  --archive_length=600 \
  --fixed_gop=2 \
  --hls.minimum_fragment_length=2

VOD

For VOD, you will first have to watermark your content with Irdeto's OTT Embedder to create A/B versions. Then you will have repackage these A/B versions with Unified Packager to ensure compatibility. When repackaging the content you should use ISMV as the output format and make sure you do not change the fragment length (i.e., do not use --fragment_duration):

mp4split -o example_1500k_a.ismv example_1500k_a.fmp4
mp4split -o example_1500k_b.ismv example_1500k_b.fmp4
mp4split -o example_750k_a.ismv example_750k_a.fmp4
mp4split -o example_750k_b.ismv example_750k_b.fmp4

After you have repackaged your A/B versions, you need to configure the stream by creating a server manifest. While doing this it is important to specify a track name for all video tracks and ensure that the names for the A/B versions are identical to those configured in Irdeto's OTT Personalizer (default: 'video_irwm_yan' and 'video_irwm_yin'):

mp4split -o stream.ism \
  example_1500k_a.ismv --track_type=video --track_name=video_irwm_yin \
  example_1500k_b.ismv --track_type=video --track_name=video_irwm_yan \
  example_1500k_a.ismv --track_type=audio \
  example_1500k_b.ismv --track_type=audio \
  example_750k_a.ismv --track_type=video --track_name=video_irwm_yin \
  example_750k_b.ismv --track_type=video --track_name=video_irwm_yan \
  example_750k_a.ismv --track_type=audio \
  example_750k_b.ismv --track_type=audio

Assuming you have also set up the rest of your Irdeto TraceMark setup for VOD, you are now ready to deliver dynamically packaged and personalized streams to your customers.

Nagra NexGuard

Apache SmartEmbedder

The Apache SmartEmbedder (ASE) is a module that allows the integration of the NexGuard-Streaming technology into a content distribution workflow. It is intended to organize per-session water- marking for MP4 file download mode and ABR streaming mode.

It is available on Red Hat 6 & 7 and Ubuntu 14.

For installation and configuration please refer to the NexGuard-Streaming Apache SmartEmbedder documentation.

The input to ASE is content prepared with the NexGuard-Streaming Preprocessor (which includes H.264 encoding) and is stored on disk as a .mmrk preprocessed file. The output from ASE is byte range of watermarked MP4 with a unique ID. The NexGuard video watermark is imperceptible. The solution enables forensic tracking and is a deterrent against content theft.

Watermarked MP4 progressive files (a.k.a. 'mmrk' files) with multiple bit rate renditions can be grouped in a manifest file with the extension 'smil' or 'ism'. Thus, customers can identify which files have been encoded at the same time with different bit rates. Here is an example with 2 bit rate renditions:

<?xml version="1.0" encoding="utf-8"?>
<smil xmlns="http://www.w3.org/2001/SMIL20/Language">
  <body>
    <switch>
      <video src="myFile__750kbps.mp4" systemBitrate="750000"/>
      <video src="myFile_1500kbps.mp4" systemBitrate="1500000"/>
    </switch>
  </body>
</smil>

Using USP and NexGuard ASE

The Apache server is started and its home page is accessible from any web browser:

http://ase-hostname

At least one 'mmrk' file has been copied in the Apache server DocumentRoot (sub)folder (e.g. /var/www/html/myFile_750kbps.mmrk):

http://ase-hostname/streampath.txid.manifest-ext

The path consists of the following elements:

Value	Description
streampath	stream path without the extension (e.g. 'myFolder/myStream-1000Kbps')
txid	payload value to smart embed (in hexadecimal)
manifest-ext	manifest extension ('smil' or 'ism')

Unified Origin configuration

The Unified Origin is configured following Dynamic Manifests, so using the IsmProxyPass directive, e.g.:

<Directory /var/www/ase>
  IsmProxyPass http://ase-hostname/
</Directory>

The IsmProxyPass directive will map a request containing 'ase' in it's patch to the apache-smart-embedder. There should be no 'ase' directory on disk.

Url Description

The URL for accessing a SmartEmbedded stream is different from the standard Unified Streaming URL since a transaction ID must be specified:

http://usp-hostname/ase/strname.txID.ext/post-fix

Value	Description
strname	stream name without extension (folder and stream path, e.g. myFolder/myStream)
txID	unique transaction identifier for each client (hexadecimal value)
ext	media extension ('mp4' or 'smil')
post-fix	option information specific to player technology (e.g. 'Manifest' for Smooth Streaming, '.m3u8' for HLS)

Single bit rate

For single bit rate, the media type use is 'mp4'. The myID parameter is a per-session identifier as a hexadecimal number without the 0x prefix.

Value	Description
HLS	http://usp-hostname/ase/myStream.A1B2.mp4/.m3u8
Smooth Streaming	http://usp-hostname/ase/myStream.mp4/Manifest

From the received manifest file, then any chunk (or fragment) can be downloaded, for instance HLS:

http://usp-hostname/ase/myStream.A1B2.mp4/myStream-400k-video=407000-89.ts

Adaptive bit rate

For adaptive bit rate, the media type use is 'ism'.

Value	Description
HLS	http://usp-hostname/myStream.A1B2.ism/.m3u8
Smooth Streaming	http://usp-hostname/myStream.A1B2.ism/Manifest

From the received manifest file, then any chunk (or fragment) can be downloaded, for instance for HLS:

http://usp-hostname/ase/myStream.A1B2.ism/myStream-400k-video=407000-89.ts