A studio finishes a licensed character video and hands it over. Two parties hold rights in that file — the rights holder who owns the character, and the producer who made the work. Then it goes to a platform, the platform re-encodes it, and every piece of metadata naming either party is gone. This is the problem we built an offline protection service to solve. The interesting part turned out not to be the watermarking. It was discovering that the obvious approach cannot work at all. Why you cannot watermark a video twice The intuitive solution to "two parties, one file" is to run the watermarker twice — once per party. It does not work, and the failure is worse than doing nothing. A video watermark detector recovers exactly one message per asset . The mark lives as a residual signal spread across the pixels. Run a second embed pass and it writes over the first one's residual; what you get back is a blend that decodes to neither party. You have not created two marks. You have destroyed the one you had. So running it twice is strictly worse than running it once. Any scheme that binds two parties has to do it in a single pass. The fix: split the payload, not the pass The payload is 256 bits. Instead of treating it as one message, we split it into two independent halves: Bits Slot Carries 0–127 Slot A Rights holder binding key 128–255 Slot B Producer / licensee binding key Each half is a fresh 128-bit key issued for that party on that asset. On detection the recovered payload is split and each half matched against its own slot independently — so either half alone identifies its party and the asset, even if the other half is damaged beyond recovery. One embed pass. No extra quality cost. Two marks that survive separately. A 128-bit half accepted at a bit error rate of 0.25 or below has a random-collision probability of roughly 6×10⁻⁸ per candidate. If there is no producer to name, slot B carries a second independent rights-holder binding instead — pure redundancy rather than a wasted half. Three layers, and what each one survives No single technique survives everything, so the service writes three, each with a different failure mode: Layer What it is Survives Role C2PA manifest Signed record naming both parties Until a platform transcodes The official, non-repudiable record Watermark The dual-party payload, in the pixels Re-encode, re-upload, downscale, compression The durable mark — what enforcement decodes Fingerprint Perceptual frame hashes held server-side Everything — nothing is in the file Last-resort visual match The layer ordering matters. C2PA is the layer a court or a platform rights team reads, and it is also the first to die. The watermark is what actually survives distribution. The fingerprint survives even a file that has been stripped of everything, because it was never in the file — it lives in our registry. Licence terms and binding keys never travel in the file either. The manifest carries only an opaque content ID, the party names, and a cryptographic commitment to the payload. What happens under a realistic platform attack A delivered file at 720×1280 was put through what a platform re-upload actually does: metadata stripped, downscaled to 406×722, re-encoded at CRF 30 — 87% smaller than the original. Clean delivery After the attack C2PA manifest valid destroyed — expected Watermark slot A (rights holder) BER 0.000 BER 0.016 → matched Watermark slot B (producer) BER 0.000 BER 0.016 → matched Fingerprint distance 0 distance 2 → matched Both parties resolved independently with the metadata gone, at roughly one fifteenth of the match threshold. Imperceptibility measured 44.2 dB PSNR with a peak deviation of 11/255. The full job on that asset took 43 seconds on CPU. One tuning note worth stating plainly: the stock watermark strength in this class of tool is tuned for pure invisibility and only survives mild transcodes. We run it higher — still below the threshold of visible difference, but high enough to survive the attack above. Invisibility that does not survive distribution is not protection. How do you show a client something invisible? This is the practical problem nobody warns you about. A client has paid for a mark they cannot see, in a file that looks identical to the one they handed over. "Trust us, it's in there" is not a deliverable. So every job renders an evidence pack: An invisibility proof — original, delivered, and the difference between them amplified thirty times. That structured pattern is the watermark. Both frames come straight off the embed tensors, so the residual shown is the mark alone with no codec noise mixed in. A bit card per party — each 128-bit key rendered as a bit field: what was embedded on top, what was recovered from the delivered file underneath, flipped bits boxed in red, with the error rate against threshold. A machine-readable job record for the client's own files. A client can look at the amplified residual and see the thing they bought. Tracing which copy leaked The highest-value use of the second slot is not naming the producer. It is naming the recipient. Keep slot A on the rights holder and vary slot B per recipient — mark one copy of the same master for each distributor, festival, or platform you hand it to. Each run produces a separate file bound to that recipient. When a copy surfaces where it should not be, slot B says which recipient's copy leaked. We validated this against the same attack: one distributor's copy, re-encoded past the point where slot A had already failed, still decoded to that distributor specifically. The corollary is a workflow rule, not a technical one: hand the same marked file to everyone and this traceability is gone. Per-recipient marking is the whole mechanism. Registration readiness across jurisdictions Provenance evidence is only useful if you can act on it, which means knowing where the character is registered and which platform programmes will accept a claim. The service includes a checklist of 17 verified items across the US, China, Hong Kong, the EU, Japan, Korea and the UK, plus the five major platform rights programmes — YouTube Content ID, TikTok's IP Protection Centre, Douyin, Kuaishou and Bilibili. Each row carries a link to check status and a link to file, verified reachable on the date of the report. We check and point; we do not file. Several of these jurisdictions require a licensed local representative to file on another party's behalf, so the deliverable is a registration- readiness audit rather than a filing service. Two findings from building that checklist are worth knowing even if you never use the service. Hong Kong has no copyright register at all — protection is automatic, which means a provenance pack is your evidence. And US registration is the one filing that materially changes what a lawsuit can recover. What this does not do The watermark travels in these pixels . It proves a file originated from a protected asset and names the parties bound to it. It does not catch someone who regenerates a lookalike character from scratch. That file never carried the mark, and no amount of watermark strength changes that. Catching imitation rather than redistribution requires character and face similarity matching — a different build with its own privacy considerations. Those are two different problems, and a rights holder should know which one they actually have before buying a solution to the other. Redistribution of your own delivered files is a provenance problem. Imitation is a similarity-search problem. Frequently asked questions Can you watermark a video twice, once for each party? No. The detector recovers one message per asset, and a second embed pass overwrites the first one's residual, producing a blend that decodes to neither party. Binding two parties requires splitting a single payload into independently-matchable halves in one pass. Does the watermark survive being uploaded to a platform? Yes. In testing against metadata stripping, downscaling to 406×722 and re-encoding at CRF 30, both party slots matched at a bit error rate of 0.016 against a 0.25 threshold. Is the watermark visible? No. Imperceptibility measured 44.2 dB PSNR with a peak pixel deviation of 11/255. The evidence pack shows the residual amplified thirty times so a client can see what was embedded. What happens to the C2PA manifest? It is destroyed the first time a platform transcodes the file. That is expected and is why the manifest is one layer of three rather than the whole approach. Can you tell which distributor leaked a file? Yes, if each recipient received their own marked copy. Slot B varies per recipient, so a recovered payload names whose copy it was. Will this catch someone who copies my character with their own AI model? No. A regenerated lookalike never carried the mark. That is a similarity-matching problem, not a provenance one. Figures above are measured results from validation runs on a delivered asset, not vendor specifications. This is an offline service run from a local console — it does not connect to any generation API. Platform monitoring is in development: the identification bridge and dashboard are built, the collectors are not.
