Why this matters

If you stream anything a studio or a league cares about — recent films, 4K originals, live sport — your distribution contract almost certainly names forensic watermarking as a condition of carrying the content, especially at the highest resolutions and in early release windows. The reason is money at industrial scale: pirate streaming is estimated to cost U.S. video providers around $30 billion a year, and live sports piracy alone drains roughly $28 billion from the global sports economy, with illegal streams of a big match often appearing within ninety seconds of kickoff. Encryption and digital rights management keep honest devices honest, but they cannot stop a determined subscriber from pointing a capture card or a phone at a screen — and the moment that happens, the only question that matters is whose stream this was. This article is for the founder, product manager, or streaming engineer who needs to understand what watermarking actually buys, what it costs to run at scale, and how to talk to content owners and vendors about it without being sold magic.

First, the one distinction that prevents every misconception

Start by separating two jobs that sound the same and are not. The system that keeps premium content from being accessed without permission, called digital rights management (DRM) — the software that encrypts the video and hands out decryption keys under rules, the subject of Why DRM Exists and What It Actually Protects — works before the leak. It is a locked door. Forensic watermarking works after the leak: it is an invisible serial number stamped into the picture so that a copy found in the wild can be traced to its source. One prevents; the other attributes. They are complementary layers, and neither does the other's job.

That boundary is the whole point, because DRM has a hard edge it cannot cross. Encryption protects the video up to the instant it is decrypted and shown on a screen. A camera pointed at that screen, or a capture device on the cable, sees fully decrypted, DRM-free pixels — and re-records them. At that moment DRM has done everything it can and lost. A forensic watermark, because it lives inside the picture itself, rides along through the camera, through the re-encode, through the upload to a pirate site, and is still there when an investigator pulls the stream down. The mark survives exactly where the lock fails.

So the honest one-sentence pitch is this: watermarking does not reduce the number of leaks, it changes the consequence of a leak from anonymous to attributable. That shift is what makes a subscriber think twice, and what gives a rights holder the evidence to terminate an account or cut off a re-streamer.

DRM and encryption prevent access; the forensic watermark traces the leak; monitoring finds the copy in the wild. Figure 1. DRM stops where the screen begins. The forensic watermark lives inside the picture, so it survives the camera and the re-encode — and points back at the session that leaked.

What a forensic watermark actually is

A forensic watermark is a small amount of information — in the simplest case a number — woven into the video signal in a way designed to be two things at once: invisible to a viewer, and hard to remove. "Invisible" means the change to the picture is below the threshold a human eye notices at normal viewing. "Hard to remove" means the mark is spread through the image in a way that survives the ordinary abuse a pirated copy goes through: re-compression to a smaller file, scaling to a different resolution, a crop, a screen recording, even a conversion from high dynamic range to standard range.

The information the mark carries is usually an identifier that your system can map back to a person or a session. It might encode the subscriber account, the specific device, a timestamp, or — most powerfully — a unique session identifier minted for that one act of watching. The mark itself does not contain the viewer's name; it contains a reference number, and your back-end holds the table that turns that number into "account 88431, watching at 21:04 on this TV." Keeping the meaning in your database, not in the mark, is both a privacy feature and a security one.

It helps to name the two things people constantly confuse with each other. A forensic watermark is something you deliberately add to trace a leak. A fingerprint, in this field, is the opposite direction: a signature computed from the content as it already exists — a compact summary of what the video looks or sounds like — used to recognize that content when it appears somewhere. Monitoring services use fingerprints to spot "this is the Cup final" on a pirate site; they then read the watermark to learn "and it leaked from this session." Fingerprint to find it, watermark to blame it. The two work together and are not interchangeable.

One more pairing matters. A visible watermark — a broadcaster's logo in the corner, or a viewer's email burned across a screener — deters by being seen, but a pirate can crop or blur it in minutes. A forensic watermark is the invisible cousin: nothing on screen to find, nothing obvious to remove. This article is about the invisible, robust, traceable kind, because that is what content owners require.

Where you can embed the mark: three places, three trade-offs

The single biggest architectural decision is where in the delivery chain you stamp the mark. There are three honest answers, and they trade security, cost, and device reach against each other. Walk them in order, because the modern default sits in the middle.

Client-side: mark it on the device. The viewer's app or player embeds the watermark as it plays. This sounds elegant — every device naturally produces its own unique stream — but it has a structural weakness. To stamp the mark, the device must handle the video after it has been decrypted, and it must carry the secret logic of how the mark is applied. That puts the most sensitive part of the system inside the least trustworthy place: an open consumer device that an attacker fully controls. It also means building and maintaining watermarking code on every platform you support — web, iOS, Android, each smart-TV operating system, each streaming stick. Client-side marking still has its uses, but as a primary scheme it inverts the security model.

Server-side: mark it in the network, before the device. Here the sensitive work happens on infrastructure you control, and the device receives an already-marked stream with no special code and nothing secret to leak. This is the scheme studios favour, because it keeps the watermarking logic out of the open device entirely and works across the widest range of players without per-platform integration. The challenge server-side marking has to solve is scale: you cannot encode a separate, fully unique copy of a two-hour film for every one of a million viewers. The answer to that scaling problem is the A/B variant pattern, which gets its own section below because it is the heart of how this works in practice.

Edge: mark it at the CDN edge, per request. A refinement of server-side, this embeds the mark at the content delivery network's edge — the layer of servers close to viewers, the subject of How a CDN Delivers Video — at the moment a specific subscriber requests a segment. Pushing the mark further down the chain lowers cost, because you can avoid storing two full copies of everything, and it can pack more identifying bits into each segment, which makes the mark sturdier against certain attacks. The price is a more capable, watermarking-aware edge.

The rule of thumb the vendors converge on is simple: the further down the chain you embed, the lower the storage and delivery cost, but the more capability you need in the network. Most platforms that serve premium content at scale land on server-side A/B, often with an edge-assisted variant, precisely because it keeps the secret out of the device while staying affordable.

Approach Where the mark is applied Device integration needed? Decrypted content exposed on device? Storage / cache cost Best fit
Client-side In the player on the device Yes — on every platform Yes — a structural weakness Low Niche; when no network marking is possible
Server-side (A/B) In the network, pre-delivery No No ~2× for marked content Premium VOD, studio catalogues, broad device reach
Edge At the CDN edge, per request No No Lower than A/B Live sport, scale-sensitive, watermark-aware CDN

Read the two middle columns together: they are why server-side and edge win for premium content. Neither asks the device to hold a secret or to touch decrypted video, and neither needs you to ship watermarking code to a dozen platforms. The cost column is where they differ, and that difference is the subject of the worked example later.

How server-side A/B watermarking actually works

This is the mechanism most premium platforms run, so it is worth building slowly, one idea at a time. The goal is a unique stream for every viewer without encoding a unique copy for every viewer — and the trick is to do it with just two pre-made versions.

Recall from The Encoding Ladder Explained that streaming video is already chopped into short segments, typically a few seconds each, so the player can switch quality on the fly. A/B watermarking piggybacks on that existing structure. During encoding, a component called a watermark pre-processor produces two versions of every segment: an A variant and a B variant, each carrying the same picture but a slightly different, invisible embedded bit. Think of them as two pressings of the same record that sound identical to you but differ in a groove only a machine can read.

Both variants are packaged and pushed out to the origin and the CDN, so the network can serve either the A or the B version of any given segment. Now the magic: when a particular viewer's player asks for segment after segment, the network hands that viewer a specific pattern of A's and B's — say A-A-B-A-B-B for the first six segments. That pattern is a binary number, and that number is the viewer's identifier. A different viewer gets a different pattern, so a different number. Stitch enough segments together and you have millions of unique sequences from just two physical copies of each segment.

The neat part is who decides the pattern. In the standardized design, the player carries a small watermark token — a credential that contains, or lets the edge derive, the unique identifier for this session. When the edge server receives a request for a segment, it works out which bit of the identifier this segment represents, reads that bit from the token, and serves the A variant for a 0 or the B variant for a 1. The viewer's device never knows any of this is happening; it just plays video. The selection logic lives in the network, exactly where you want the secret to be.

Server-side A/B watermarking: a pre-processor makes A and B variants; the edge serves a per-session A/B pattern as the ID. Figure 2. Two variants per segment, one unique A/B sequence per viewer. The session token tells the CDN edge which variant to serve, so the pattern itself becomes the traceable identifier.

The standard that made this interoperable

For years, A/B watermarking worked but was a custom integration every time, because the encoder, the packager, the CDN, and the watermarking vendor all had to agree on private conventions. That changed in 2023. The DASH Industry Forum — the body that shepherds the MPEG-DASH streaming standard — published a Forensic A/B Watermarking specification, and in August 2023 it was republished by the European Telecommunications Standards Institute as ETSI TS 104 002, a formal, openly available standard. It defines the common interfaces so that any compliant encoder, packager, CDN, and watermark vendor can interoperate, and it deliberately works for both major streaming formats, HTTP Live Streaming (HLS) and MPEG-DASH.

Two design choices in that standard are worth knowing because they explain why it is robust. First, instead of having the edge guess which bit a segment carries by parsing its filename — fragile, because every packager names files differently — the standard carries that "which bit goes where" information in a dedicated metadata channel (named WMPaceInfo, compactly encoded) that flows alongside the content. The system no longer depends on file-naming conventions. Second, it standardizes the watermark token, in a "direct" mode that carries the identifier outright and an "indirect" mode that carries parameters to derive it, plus the exact sequencing logic the edge must run. The result is that the security-sensitive operations stay in the network, the device stays dumb, and vendors become swappable.

It is worth stressing one accuracy point that the standard preserves: the A and B variants are still encrypted with Common Encryption, the ISO scheme that lets one protected file feed every DRM, covered in CENC, CTR, and CBCS: Common Encryption Explained. The watermarking does not break the secure path or require decrypting the video on the device to mark it. Encryption and watermarking ride together: the stream stays locked, and the A/B pattern threaded through it is the invisible signature.

Tracing a leak: the detection loop, on the clock

Embedding the mark is only half the system. The other half is the loop that turns a mark into an action, and for live content that loop runs against a stopwatch.

It works like this. A monitoring service continuously crawls pirate sites, social platforms, and illegal streaming apps, using content fingerprints to recognize your title when it appears. When it finds your stream being redistributed, it captures a sample and runs extraction — the reverse of embedding — to recover the hidden identifier from the pixels. That identifier maps, in your back-end, to a session and a subscriber. Now you can act: terminate the session, suspend the account, and, for a re-streamer, hand the evidence to the takedown and legal process described in Anti-Piracy Operations: Monitoring and Takedown.

For on-demand catalogues, this loop can run at a relaxed pace — a leaked film is a days-or-weeks problem, and the studio's goal is often intelligence: which part of the distribution chain is leaking, so it can be fixed. For live sport it is a sprint. Illegal streams of a marquee match frequently appear within about ninety seconds of the first whistle, and the whole value of the content evaporates at the final whistle. So the live pipeline is engineered for speed: the mark is embedded within a few hundred milliseconds, extraction from a captured pirate stream takes seconds rather than minutes, and the aim is to identify and cut the leaking source within roughly the first fifteen minutes — fast enough to make the pirate stream unreliable while the match still matters.

That timing requirement is the real reason live and on-demand often use different watermarking configurations even on the same platform. The on-demand side optimizes for the strongest possible mark and the lowest cost; the live side optimizes for the shortest possible embed-and-extract time. Both are "forensic watermarking," tuned to opposite ends of the clock.

Forensic detection loop: monitor finds the stream, extract the ID, map it to a session, cut the session, on the live clock. Figure 3. From pirate stream to terminated session. For live sport the whole loop is racing a roughly fifteen-minute window before the content loses its value.

A worked example: what A/B costs you

Numbers make the trade-off concrete, so price out the storage side of server-side A/B for a mid-sized catalogue. The arithmetic is simple; the lesson is in which line moves.

Start with the catalogue. Say you hold 5,000 hours of content, and your encoding ladder produces an average of 8 quality variants per title — the rungs the player switches between. Suppose your encoded, packaged library averages 3 gigabytes per hour across all those rungs. Your baseline storage is:

baseline = 5,000 hours × 3 GB/hour = 15,000 GB ≈ 15 TB

Now turn on server-side A/B watermarking for the premium slice of the catalogue. A/B means every watermarked segment exists in two variants, so the watermarked content roughly doubles in storage. If you mark the whole library, the marked footprint is:

A/B marked = 15 TB × 2 = 30 TB   (an extra 15 TB)

But you rarely mark everything, because only some content carries a contract that demands it. Say 30% of the catalogue is premium enough to require watermarking. Then only that slice doubles:

marked slice      = 15 TB × 30% = 4.5 TB  → ×2 = 9.0 TB
unmarked slice    = 15 TB × 70% = 10.5 TB → ×1 = 10.5 TB
total storage     = 9.0 + 10.5 = 19.5 TB   (an extra 4.5 TB, +30%)

Storage is cheap, so a few extra terabytes is not the headline. The line that actually moves is delivery. Because both A and B variants of marked content travel through the CDN, the cache footprint of that content doubles too — and a content delivery network earns its keep by serving most requests from cache instead of fetching from your origin. Double the variants and you halve the chance that any one variant is already cached, which lowers the cache-hit ratio on marked content and pushes more traffic back to origin. On a platform where the recurring CDN egress bill — the charge for bytes sent out to viewers, the subject of CDN Cost Engineering: Egress, Commits, and the 95th Percentile — is already the largest running cost, a worse hit ratio on your most valuable titles is the expense that matters, not the disk. This is precisely why edge watermarking, which avoids storing and caching two full copies, exists: it trades a smarter edge for a smaller delivery penalty.

The takeaway from the math: budget watermarking as a delivery cost, not a storage cost, and mark only the content whose contract requires it.

When content owners actually require it

Watermarking is not a "nice to have" you add for peace of mind; for premium content it is usually contractual, and it helps to know the two forces that put it in the contract.

The first is the studio requirement for high-value movies and series. The major Hollywood studios coordinate their security expectations through a technical body, MovieLabs, whose Specification for Enhanced Content Protection (ECP) — the latest published version is 1.4, from 2024 — is the common target a platform must meet to be licensed premium content. That specification calls for forensic watermarking as part of protecting the most valuable material: 4K and ultra-high-definition resolutions, high dynamic range, and especially early-window content — a film that reaches streaming while it is still in or near its theatrical run, when a single leak is most damaging. If you want the new releases at the top resolution, watermarking is on the checklist next to hardware-backed DRM.

The second force is live sport and other short-lived premium events. Here the driver is not a studio specification but the economics of the event itself: the content is worth the most during the ninety minutes it is live and nearly worthless afterward, so a league's contract pushes for the ability to find and cut a pirate re-stream fast. That is the use case the live detection loop above is built for, and it is increasingly written directly into rights deals.

Both forces have teeth behind them. Enforcement coalitions now dismantle large piracy operations and use session-level evidence to do it — in August 2025, the operation widely reported as the largest live-sports piracy network, with roughly 1.6 billion visits in a year, was taken down. Watermark evidence is part of what turns "someone is leaking" into "this account is leaking," which is what makes both account action and legal action possible.

Common mistakes

The failures we see cluster into a short list, and each maps to a decision above.

  • Treating watermarking as a substitute for DRM. It is not. Watermarking traces a leak; it does not prevent one. Ship it with encryption and DRM, never instead of them.
  • Marking on the open device as the primary scheme. Client-side embedding puts the secret and the decrypted video in the least trustworthy place. Prefer server-side or edge for premium content.
  • Budgeting it as a storage cost. The disk is cheap; the doubled cache footprint and the lower CDN hit ratio on your best content are the real bill. Plan delivery, not just storage.
  • Marking the entire catalogue by reflex. Mark what the contract requires. Doubling variants on content nobody is required to protect spends egress for nothing.
  • Forgetting the session-to-identity table is yours to protect. The mark is just a number; the database that maps it to a person is sensitive and must be secured and privacy-reviewed.
  • Assuming one mark survives everything. Robustness, invisibility, and how many bits you can carry are in tension — a mark tuned to be utterly invisible may not survive heavy re-encoding, and a heavy mark may show. Match the configuration to the threat, and test extraction against the abuse a real pirate applies.
  • Ignoring collusion. Several subscribers can compare their copies to locate and attack the differences. Serious systems defend with anti-collusion codes; ask any vendor how they handle multiple colluders.

Watermarking trade-off triangle: robustness, invisibility and payload trade off; collusion targets the differences. Figure 4. You cannot maximize invisibility, robustness, and payload at once. Forensic marks favour invisibility and robustness, then use coding to stretch the identifying payload and resist collusion.

A note on robustness, payload, and collusion

Three properties of a watermark pull against each other, and understanding the tension keeps you from believing a vendor who claims to maximize all three. Invisibility is how hidden the mark is from a viewer. Robustness is how well it survives processing — re-compression, scaling, cropping, screen capture, format conversion. Payload (or capacity) is how many bits of identifier it can carry. Push invisibility to the extreme and you have fewer, fainter changes to hide information in, which costs robustness or payload. Push robustness up and the mark gets stronger, which threatens invisibility. Every real system picks a point in that triangle for a given threat.

Payload matters more than it first appears because of collusion attacks. If two or three subscribers each get a uniquely marked copy and they compare them side by side, the places where their copies differ are exactly the watermark, and averaging or splicing their streams can weaken or scramble it. The defense is a layer of mathematics on top of the raw mark: anti-collusion fingerprint codes — the best known are called Tardos codes — that are specifically designed so that even when several colluders combine their copies, at least one of them can still be identified. The catch is that these codes need a longer identifier, hundreds to thousands of bits, which raises the payload the watermark must carry — and pulls again on that same triangle. This is the real engineering of forensic watermarking, and it is why "just add a watermark" is never the whole story.

Where Fora Soft fits in

The platforms that need this most are the ones serving a studio catalogue or live rights to a large, multi-device audience, where the watermarking layer has to satisfy a content owner's security specification and survive the realities of CDN economics without quietly inflating the egress bill. Fora Soft has built video streaming, OTT and Internet-TV, live sport, video surveillance, and other protected-video systems since 2005 — more than 625 projects for 400-plus clients across 20-plus years — and the work that matters here is the integration, not a logo: wiring a watermark pre-processor into the encoding ladder, propagating the A/B variants and their metadata through the packager and CDN, fitting the edge selection logic to a real delivery topology, and closing the detection loop into your account and anti-piracy operations. We are vendor-neutral about which watermarking technology you license; the engineering value is a traceable platform that meets the contract and that viewers never notice.

What to read next

Download the Forensic Watermarking Decision Sheet (PDF)

Call to action

References

  1. ETSI TS 104 002 V1.1.1 — "DASH-IF Forensic A/B Watermarking" (2023-08). The controlling interoperability standard for server-side A/B watermarking, republished by ETSI from the DASH-IF specification under a Publicly Available Specification agreement. Defines the end-to-end architecture (watermark pre-processor → packager → origin → CDN edge), the WMPaceInfo auxiliary-metadata channel that removes any dependency on segment file-naming, the CBOR-encoded watermark token in direct and indirect modes, the edge sequencing logic, and applicability to both HLS and MPEG-DASH. Tier 1 (official standard). https://www.etsi.org/deliver/etsi_ts/104000_104099/104002/01.01.01_60/ts_104002v010101p.pdf — accessed 2026-06-17.
  2. ISO/IEC 23001-7 — Common Encryption (CENC) in ISO base media file format files. The official standard defining the cenc (AES-CTR) and cbcs (AES-CBC) protection schemes and the principle that one encrypted file can feed multiple DRMs. Cited for the accuracy point that A/B variants remain Common-Encryption-protected and the watermark does not break the secure data path. Tier 1 (official standard). https://www.iso.org/standard/84637.html — accessed 2026-06-17.
  3. ISO/IEC 23000-19 — Common Media Application Format (CMAF). The official container standard defining the fragmented, segmented media structure that A/B watermarking piggybacks on — the same short segments the player switches between are the unit the A/B pattern is built from. Tier 1 (official standard). https://www.iso.org/standard/85623.html — accessed 2026-06-17.
  4. DASH Industry Forum — "DASH-IF Publishes Forensic A/B Watermarking Specification as ETSI TS 104 002" (2023). The issuing body's own description of the standard: the motivation (OTT's open-device trust model favours network-side marking), the three-step edge logic (derive bit position, read the token bit, serve A or B), the preservation of CDN caching, CPIX integration for watermark-metadata management, and the reference to the UHD Forum encoder-integration API. Tier 2 (issuing-body guideline). https://dashif.org/news/watermarking-final/ — accessed 2026-06-17.
  5. Ultra HD Forum — "Watermarking API for Encoder Integration," v1.0.1. The alliance specification defining the Watermark Pre-Processor (WMP) interface that an encoder embeds to generate the A and B variants per representation, referenced normatively by the DASH-IF / ETSI architecture. Tier 2 (industry-alliance specification). https://ultrahdforum.org/wp-content/uploads/watermarking-API-for-encoder-integration.1.0.1.pdf — accessed 2026-06-17.
  6. MovieLabs — "Specification for Enhanced Content Protection," Version 1.4 (2024). The major studios' common content-protection target, which calls for forensic watermarking as part of protecting 4K/UHD, HDR, and early-window content, alongside hardware-backed DRM and output protection. The source of the "studios require it" claim. Tier 2 (industry requirement specification). https://movielabs.com/ngvideo/MovieLabs_ECP_Spec_v1.4.pdf — accessed 2026-06-17.
  7. castLabs — "Forensic watermarking: Why and how?" (engineering blog, with ContentArmor). First-party engineering source for the prevent-vs-trace framing (watermarking complements DRM/CAS), the client-side vs server-side trade-off and why server-side keeps the secret off the open device, the robustness/invisibility ratio, the A/B switcher mechanics, operator vs session watermarking, and bitstream (post- vs pre-encode) marking. Tier 4 (vendor engineering). https://castlabs.com/blog/forensic-watermarking-why-and-how/ — accessed 2026-06-17.
  8. Synamedia — "Why watermark insertion matters and when to do it?" and "Edge Watermarking" (engineering blog). Vendor engineering source for the three insertion points (server, edge, client), the principle that embedding further down the chain lowers cost and that edge embedding eliminates the A/B duplicate-storage penalty and can pack more bits per segment against temporal collusion. Tier 4 (vendor engineering). https://www.synamedia.com/blog/where-to-insert-content-watermarking/ — accessed 2026-06-17.
  9. ExpressPlay / Intertrust — "Video watermarking: a key anti-piracy tool for live sports content." Vendor source for the live-sports detection timings — pirate streams appearing within ~90 seconds of kickoff, embed in a few hundred milliseconds, extraction in seconds, and acting within the early-minutes window — and the session-based watermarking + monitoring loop. Tier 4 (vendor engineering). https://www.expressplay.com/blog/video-watermarking-a-key-anti-piracy-tool-for-live-sports-content/ — accessed 2026-06-17.
  10. The Wrap — "Pirated Video Sites Cost Streamers $30 Billion a Year in Lost Revenue" (2025), and GlobalData on sports piracy. Institutional reporting for the market-scale figures: ~$30B/year U.S. streaming-piracy losses and ~$28B/year sports-piracy impact, the context that makes watermarking contractual. Tier 5 (institutional/analyst). https://www.thewrap.com/piracy-streamers-cost-lost-revenue/ — accessed 2026-06-17.
  11. Piracy Monitor / The Wrap — coverage of the August 2025 Streameast takedown. Institutional reporting on the dismantling of the largest live-sports piracy network (~1.6 billion visits in a year), illustrating the enforcement context in which session-level watermark evidence is used. Tier 5 (institutional/news). https://piracymonitor.org/ — accessed 2026-06-17.

Per the section's source hierarchy: the A/B watermarking architecture traces to the tier-1 ETSI TS 104 002 standard (ref. 1), read alongside the DASH-IF issuing-body description (ref. 4) and the UHD Forum encoder API it references (ref. 5); the "stays encrypted" and "segmented unit" accuracy points trace to tier-1 ISO/IEC 23001-7 (ref. 2) and ISO/IEC 23000-19 (ref. 3). The studio requirement is MovieLabs ECP (ref. 6). Insertion-point and live-timing engineering is corroborated by vendor sources (refs. 7–9), and market scale by institutional reporting (refs. 10–11). One common error is corrected against the standards and primaries: "watermarking stops piracy" — it does not; per refs. 1, 7 it traces a leak after the fact and is deployed alongside, not instead of, encryption and DRM.