What forensic watermarking is
Forensic watermarking is a content-protection technique that hides a unique identifier inside the video itself. The identifier maps to a single session, account, device or token, and it is designed to be two things at once: imperceptible to a viewer under normal playback, and robust enough to be recovered from a degraded, re-encoded or screen-captured copy under stated conditions. When a sufficient sample of an unauthorised copy is available, an analyst runs it through the detector, and if a usable identifier is recovered, the sample can be associated with the specific source it came from.
The word “forensic” is doing real work here. Unlike a visible broadcaster logo, the mark is not there to deter casually; it is there to support post-leak attribution as evidence. That is why the two properties that matter most are imperceptibility, so it does not degrade the product you are selling, and robustness, designed to resist defined transformations under stated validation conditions.
How A/B watermarking works, in practice
A widely used server-side technique for live and OTT is A/B watermarking. For each segment of the stream, two perceptually identical variants are prepared, conventionally labelled A and B. For each individual session, a selection logic, running at the origin or at the CDN edge, picks a specific sequence of A and B segments. That sequence is the identifier. One viewer might receive A-B-B-A-B, another B-A-B-A-A, and from a captured sample the detector reads the sequence back and, when the sequence is sufficiently intact, maps it to a single entitlement in your system. An interoperable integration schema for this pattern has been standardised by DASH-IF and published as ETSI TS 104 002[1][2].
Two viewers receive perceptually identical segments in a different A/B order. The order itself is the invisible, per-session identifier.
Because the two variants are visually equivalent and differ only in the embedded watermark symbol, the viewer does not perceive a difference, and because the selection happens server-side, there is usually no need to change the player. This is what lets watermarking sit inside an existing encoder, packager, origin and CDN chain rather than requiring a rebuild.
Why the hard case is collusion
The attack that defeats naive watermarking is collusion: several people with different copies compare them, spot where the segments differ, and splice together a version that scrambles the identifier. A simple A/B scheme falls apart here. Serious systems use probabilistic collusion-resistant codes of the Tardos class[3], designed so that even when multiple sessions are mixed, the probability of identifying at least one contributing source can be bounded under stated assumptions. If a watermarking conversation never mentions collusion, that is the question to ask.
Where it fits next to DRM
Forensic watermarking does not replace DRM, and understanding why is the whole point. DRM controls who is allowed to open the content in compliant clients. Watermarking supports post-leak attribution when a usable identifier survives. The two address different halves of the problem, which is why a complete posture uses both. We cover the distinction in depth in the DRM vs forensic watermarking guide.
Forensic watermarking supports attribution when a sufficient sample is captured and a usable identifier is recovered. On its own it does not stop access; combined with enforcement, it can shorten the window in which an unauthorised copy is monetised.
What it does
- Associates a recovered identifier with a specific session, account, device or token under defined sample and test conditions.
- Is designed and tested to survive defined transformations such as re-encoding, downscaling, cropping and camera capture — not universal survival in every attack.
- Runs server-side, so it fits inside an existing encoder, packager, origin and CDN chain when an interoperable integration schema is followed.
What it does not do
- It does not control access — a legitimate account can still redistribute what it is allowed to watch.
- It does not act on its own — revocation and takedown are executed by the systems that own the session or by external platforms.
- It does not promise attribution to an exact source in every case — attribution requires a sufficient sample and a surviving identifier.
