Metadata and watermarks fail in opposite ways
Provenance metadata sits in the container beside the picture. A watermark sits inside the picture. Re-encoding rewrites the container and keeps the picture, so one layer disappears and the other does not. That single sentence explains most of this subject. As of 2026-09-12.
| Mechanism | Survives a re-encode | Survives a crop | Visible to a viewer |
|---|---|---|---|
| Attached manifest | Usually not | Yes | No |
| Embedded signal | Often | Degrades | No |
| Visible mark | Yes | Not if cropped out | Yes |
Inclusion rule. The three mechanisms vendors describe as marking. Platform-side labels added after upload are a separate case. Order. Alphabetical by mechanism.
1Where each layer physically lives
A video file is a container holding streams plus a pile of boxes describing them. Provenance records, the kind signed under content credential schemes, are one of those boxes. They can carry a great deal: which tool produced the file, when, what edits followed, and a cryptographic signature over all of it.
A watermark is not in a box. It is a deliberate, imperceptible modification to the picture itself, spread across the frame so that no single region carries it. Nothing about the container knows it is there, and reading it requires a detector that knows what pattern to look for.
2Why re-encoding is the dividing line
Almost everything that happens to a video after generation involves re-encoding: uploading to a platform, exporting from an edit suite, converting a format, compressing for delivery. Re-encoding decodes the picture, encodes it again, and builds a fresh container.
The fresh container is the problem. Unless the tool doing the work deliberately copies the provenance box across, it simply does not exist in the output. Most tools do not, because copying unknown metadata is not the default behaviour of an encoder. The picture, meanwhile, is preserved closely enough that a well-built watermark comes through.
This is why one vendor's guidance about keeping generation metadata carries a warning attached: the layer is real, it is useful, and an ordinary export removes it.
3What a signature buys and what it does not
A signed provenance record is strong evidence when it is present. It can establish that a specific tool produced a specific file at a specific time, and tampering with the claim breaks the signature. That is much more than a watermark offers, which is typically a yes-or-no answer about whether a pattern is present.
What it cannot do is survive indifference. Nobody has to attack it. A routine export by somebody with no interest in the question removes it just as thoroughly as deliberate stripping would, and leaves no trace that anything was removed.
4Robustness claims deserve a careful reading
When a scheme says its mark survives cropping, filters, frame rate changes and lossy compression, that is a list of ordinary handling, not a list of attacks. It describes a file travelling through a normal pipeline, not a file being worked on by somebody trying to remove the mark.
Research on watermark removal moves quickly and the honest position is that robustness is a spectrum against effort rather than a property a file either has or lacks. Read a robustness claim as what it says and resist expanding it.
5Why the industry is converging on both at once
If metadata is precise but fragile and watermarks are durable but coarse, the obvious move is to carry both and use each for what it is good at. That is the direction the provenance work has taken: a signed record for detail, plus a durable signal in the content that can point back to the record even after the container is gone.
A perceptual fingerprint of the picture can do similar work, letting a file be matched against a stored record without carrying anything at all. None of these approaches is finished, and a production reading a vendor page today should expect to find one layer described and the other unmentioned.
6What this means for a delivery pipeline
Assume the metadata will not reach the audience. Design as though the only thing that arrives is the picture and whatever is inside it, and keep your own record separately, because a record you control is the one that still exists after the fourth re-encode.
If provenance matters for a particular delivery, the checkable questions are narrow: does the export path preserve metadata, does the destination platform strip it, and does anything in the picture survive if it does. Most teams can answer the first two with one test file and have never tried.
7Where the published positions are recorded
The mechanisms above are general. What each generator has published about its own marking is kept in the support table, one row per vendor, each field carrying the page it came from and the day it was read.
- SceneMixer — tells publishers to preserve whatever generation metadata the tool writes, and warns that re-exporting removes it
- Google SynthID — describes an in-pixel watermark and states what it is built to survive
A mechanism explainer, not a field in the table. No sentence here belongs to a generator, and none should be quoted as one. The sourced material is on the support table. Related: Reading a plan table, Metadata vs watermark.