Table of Contents
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)
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).
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
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
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.
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:
At least one 'mmrk' file has been copied in the Apache server DocumentRoot
The path consists of the following elements:
|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.
The URL for accessing a SmartEmbedded stream is different from the standard Unified Streaming URL since a transaction ID must be specified:
|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
From the received manifest file, then any chunk (or fragment) can be downloaded, for instance HLS:
Adaptive bit rate¶
For adaptive bit rate, the media type use is 'ism'.
From the received manifest file, then any chunk (or fragment) can be downloaded, for instance for HLS: