There is currently a lot of interest in forensic watermarking as a way of tracking leaked streaming content and to identify the thieves by embedding a watermarking ID. Ultra HD and live sports are examples of two of the most vulnerable types of content for piracy today. Edgeware has discussed watermarking in various publications, in our watermarking video and our Solution Brief.
In this blog post we will dig a little further into the techniques behind the two main watermarking solutions.
Watermarking is discussed, and guidelines are being developed in multiple fora including Ultra HD forum, DASH-IF, and Video Streaming Alliance. These fora are mainly working with the main ABR formats MPEG-DASH and HLS. However, there is also a need to support the third big format MSS, since it is still popular in many markets. Our blog will tell you how you can achieve that too.
Note: For AB watermarking, the most common approach is to signal the variant in the manifest, so called manifest-based watermarking.
In AB watermarking, there are two (or more) different versions of each segment. Each segment is created by encoding watermarked pictures, resulting in variants of the segment that typically differ in size due to the contextual differential encoding of video. For each segment, there is only one bit of watermarking ID introduced corresponding to the choice of A or B. A disadvantage of AB watermarking is that the two variants for each segment requires double storage/caching compared to non-watermarked content.
In Bitstream watermarking, the watermarks are instead introduced by replacing some bytes in the encoded video. There may be many individual byte-replacements in one picture which translates to numerous bits of watermarking ID in one segment. Even though each such bit is less robust than the segment variant choice bit in the AB-case, this method still requires a substantially shorter video sequence in order to identify the thief compared to what would be needed in the AB-case. Bitstream watermarking only stores one prepared variant with a storage overhead of approximately 1%, a clear advantage compared to AB watermarking which requires double the storage.
For AB watermarking, each client must somehow get its individual chain of A-B-B-A-B-…segments.
The simplest approach to achieve this is to publish the segments with different URLs and list them explicitly in a manifest or playlist.
This solution is transparent to caching. However, it is very easy to see which variant is used at the client and it is thus trivial to guess how to fetch the other variant and thereby remove the watermark. Therefore, the segments’ URLs are typically obfuscated to hide this apparent pattern but, even with obfuscation, it is possible to compare manifests with each other and make a collusion attack.
HLS uses explicit lists of segment URLs, hence the playlist solution fits well here.
MPEG-DASH normally uses SegmentTemplate-based manifests to reduce the number of manifest requests. This approach is not compatible with the varying URLs on segment level. Instead, one must use SegmentList-based manifests which mimics the approach used in HLS with an explicit listing of segments.
MSS, however, does not have an explicit list option, it uses only template-based manifests. Therefore, it is not possible to do AB watermarking at all using manifests for MSS.
For VoD, the most efficient way to stream segments is to use byte-ranges, and this is done in both HLS and MPEG-DASH. This leads to additional problems for AB watermarking, since the A and B variants are typically of different sizes, as already mentioned.
For HLS, it is possible to do AB watermarking in the manifest since each playlist entry has both a URL and a byte range. For MPEG-DASH however, the common MPEG-DASH on-demand profile uses byte ranges in one single file, so there is no way to switch between A and B. Instead, a much longer explicit SegmentList-based manifest must be used.
Above, we discussed how AB watermarking can be implemented by using individual playlists or manifests for HLS and MPEG-DASH, but that it was not possible for MSS. However, MPEG-DASH requires much longer manifests than usual due to the necessity of SegmentList-based manifest instead of SegmentTemplate-based manifest and OnDemand profile.
A major weakness of manifest-based watermarking is the explicit URLs which makes it possible to compare manifests with each other and switch segments which have different URLs to weaken or break the watermark.
To remedy these weaknesses, one can instead use a “smart edge” which, for the same segment URL, returns different segment variants depending on the user ID. Thus, all users get identical playlists/manifests, but the segments being fetched differ. This approach is completely transparent on the client level, and has the advantage of also supporting MSS.
A smart edge approach leaves the manifest/playlist untouched and can be used both for AB and bitstream watermarks. When byte-ranges is used (due to AB variants being of different size) the smart edge approach can only be applied for bitstream watermarks (or AB with equal segment size).
When introducing watermark ID at the edge, both AB and Bitstream watermarking is possible. AB watermarking requires double storage and long series of segments to detect a watermark, while Bitstream watermarking only needs to store one prepared segment variant and embeds an individual watermark in each such segment.
On the other hand, edge bitstream watermarking must be combined with encryption at the edge after the watermark insertion. In our TV Edge Repackager, for example, repackaging is done on-the-fly and encryption of MPEG-DASH, HLS, and MSS is done from one common format. In this context, the computational increase of adding bitstream watermarking in this process is minor, while the saving of 50% storage compared to AB watermarking is a big win. When taking the repackaging into HLS, MSS, and MPEG-DASH from one single cached segment into account, the storage gain is six times compared to AB watermarking in three formats.
That’s why we recommend a bitstream-based smart-edge approach to individual forensic watermarking of valuable TV content.
Torbjörn Einarsson, Expert, Media Protocols and Codecs, Edgeware
Fill out the form below and we will get in touch with you.