Embedding the Headend Watermark: When to Do it… and Why?

Rinat Burdo

Rinat Burdo

Principal Product Manager

Category:

In the previous two blogs of our three-part series on watermarking, we described various ways that pirates attack watermarks, as well as the criteria for choosing a solution that best counters such attacks. We also explained why headend watermarking is far superior to client watermarking for OTT service providers.

With all that under our belt, let’s address in greater depth the critical aspect of deployment and maintenance, which leads us to the question: Is it best to insert your headend watermark in the compressed or uncompressed domain?

Pre- or Post-Encoding?

Before cutting to the chase, let’s clarify the question to make sure we’re on the same page. The compressed domain refers to content that’s already been encoded for delivery, while the uncompressed domain refers to content that has yet to be encoded. In other words, our question actually is: Should we insert the watermark before encoding (in the uncompressed domain) or after encoding (in the compressed domain)?

Making this pre-/post-encoding distinction is important because encoding content demands significant computing resources. And this is a key factor in determining the right timing for your watermark insertion.

Compressed and Uncompressed Domain Watermarking

Now that we’ve established the right question, the best way to come up with the right answer is to compare the two primary watermark insertion flows – the compressed and uncompressed domains. 

uncompressed v compressed domain graphic

Uncompressed domain

Flow #1 illustrates insertion of the headend watermark into the uncompressed video, that is, before the content is encoded. When you implement A/B sequencing (for further explanation, see our previous blog), the uncompressed video stream is duplicated and the A watermark and B watermark are inserted into separate copies of the video, each one encoded separately. In other words, when you embed a watermark on uncompressed content, the encoder needs to compress two separate streams (one with an A watermark and one with a B watermark) in a frame-accurate manner. In this case, the encoder resources have to be doubled. And that doubles your operational costs.

Compressed domain

In flow #2, the watermark is inserted after content is encoded in the OTT media backend. Again, this creates A and B copies for each segment. But unlike flow #1, here the compressed stream is duplicated at a later stage in the process. The encoder resources are not doubled. And neither are your operational costs. Some deployment options in the compressed domain even allow for “late” watermark embedding, as we’ll see later, which defers duplication further down the chain, leading to significant storage savings that go beyond encoding resource savings.

Comparing the Two Domains

In our previous blog, we looked at several factors in deciding whether to opt for a client or headend watermark. Most of those factors – including robustness, user experience, and video duration extraction – are not relevant to the compressed versus uncompressed domain debate. Both options comply with market standards, there is no trade-off with visibility, latency is not tied to the selected domain type, and video duration does not factor into the equation.

So what factors are important in the decision-making process?

Operational Costs

When it comes to deployment and maintenance issues, embedding the watermark in the compressed domain has a clear advantage. And the reason is simple. As mentioned earlier, uncompressed domain watermarking requires processing two copies of the video – A and B – which requires double the resources compared to the compressed domain.

Integration Architecture

If you use just-in-time (JIT) packaging and time-shifting scenarios (e.g. cloud DVR, pause/resume), inserting the watermark in the compressed domain offers additional advantages. It enables you to keep a single intermediary format and to insert the watermark further down the delivery pipeline, leading to significant resource savings. In contrast, if you insert the watermark in the uncompressed domain, you need to store both A and B copies of the intermediary format, thereby doubling storage and delivery resources straight from the encoder.

Next-Gen Edge Watermark Embedding

As a rule, the further down the road you embed your watermark, the lower your costs. So if you embed the watermark at the edge for a specific OTT subscriber request, then you eliminate the need for A/B copies altogether. Lowering your costs, however, is not the only benefit of the edge embedding approach. It also improves your security. You can embed multiple bits of the watermarked ID in a single adaptive bit rate (ABR) segment to increase your service’s robustness against temporal collusion attacks and shorten video extraction duration. This is an improvement over the A/B approach, which relies on a single bit per ABR segment. As such, it’s no surprise that the industry is working hard to enable compressed domain watermarking with encrypted content in the CDN or 5G edge.

And if you thought this approach is complex, think again. Once your A/B headend watermarking deployment is in the compressed domain, the transition to embedding at the edge will be smooth. Stay tuned for more information on this next-gen option as it gets closer to reality.

Encoder Synchronization, Boundary Complexity

There are additional benefits to inserting the watermark in the compressed domain. Frame boundaries never change in the compressed domain. In the uncompressed domain, however, the A and B variants may not be identically frame-accurate, and therefore, require encoder synchronization throughout OTT delivery. In addition, segment boundaries in the compressed domain are simpler than those in the uncompressed domain.

This is just part of the watermarking discussion

Our three-part watermarking blog series has helped establish:

  • How pirates counter watermarking
  • What criteria are key for evaluating a watermarking solution
  • Why headend watermarking is preferable to client watermarking
  • Why the watermark should be inserted in the compressed domain (i.e. after encoding)

While these are the key factors to consider in choosing a watermarking solution, there are other relevant issues to take into account, such as: Should you go with content-unaware or content-aware watermarking technology? How do you protect A/B sequencing from anti-collusion attacks? What should you be looking for in end-to-end system capabilities?

For the full discussion…

As we’ve shown, choosing the right watermark is an important and complex decision. That’s why, in early 2022, we’ll be publishing an in-depth guide on everything you need to know when looking for a watermarking solution. In addition to examining the issues raised in this blog series more deeply, the guide will look at where the market is heading to help you make the correct long-term choice for your streaming video business.

Watch this space…

 

About the Author

Rinat Burdo, Principal Product Manager,  is responsible for Synamedia’s Streaming Piracy Disruption solution. She has 14 years experience in product management and market intelligence, working for Fortune 500 companies and start-ups.

Sign up to Synamedia events and news