GateTrue

What each generator documents about marking its output

Provenance manifest: the block a re-encode drops

A provenance manifest is the block in a file's container that carries a provenance record. Where it sits decides everything about its behaviour: easy to read, easy to lose, and never visible. As of 2026-09-22.

Where a manifest sits in a file, and what reaches itA manifest is a block in the container rather than part of any picture, so operations on the picture do not touch it and operations on the container decide its fate. A re-encode rebuilds the container and carries forward only what the encoder was told to keep.One fileThe containerHolds the streams and the blocks of information about them,including a manifest.The video streamWhere a burned-in mark and an in-picture signal live. Untouchedby container changes.A re-encodeRebuilds the container, carrying forward only what the encoderwas told to keep.A crop or a filterAlters the picture and leaves the container's blocks alone.Two operations, two different casualties
Fig. 1 Neither reading it nor losing it is unusual. Both are routine media operations behaving exactly as designed.
How this register uses the term, and what it excludes. Written 2026-09-22.
The termProvenance manifest
What it namesThe container-level block carrying a provenance record
What it is notThe record's contents, or a signal in the picture
Where the register uses itExplaining why one column's claims are fragile

Inclusion rule. Words this site uses in a narrow sense, where the ordinary sense would lead a reader to misread a cell. No vendor statement appears on this page. Order. Fixed order: what the word names, what it excludes, then where it is used here.

1Location explains the whole behaviour

A video file is a container holding streams and blocks of information about them. A manifest is one of those blocks. It is not part of any picture, so nothing that preserves a picture preserves it and nothing that alters a picture damages it. Its fate is decided entirely by what happens to the container.

That single fact predicts the rest. Ordinary readers can parse it, because parsing containers is what media tools do. Ordinary re-encodes rebuild the container and drop anything the encoder was not told to carry forward. Neither outcome is an attack on the mark; both are routine operations behaving normally.

2Why this makes a cell in the register asymmetric

A vendor's claim that its output carries a manifest is a claim about the file as delivered, not about the file three steps later. The register records the claim as made, and the readings note that one vendor publishes the limit and the others do not.

That asymmetry is worth carrying into any policy built on credentials. A workflow that expects a manifest to arrive intact has to control the handling in between, which is a different problem from choosing a vendor that writes one.

3What it is not responsible for

A manifest is a carrier, not a claim. What the record inside it says, and whether that is signed and by whom, belongs to the standard rather than to the block. This register records which entries name a standard and leaves the specification to the organisations that publish it.

It is also not the only provenance layer a file can have. One entry here names both a manifest and an invisible signal in the picture, and the two have opposite durability. Reading either alone gives a misleading picture of what the file will still say after delivery.

Nothing on this page is a vendor statement; the values it helps read are on the support table, with the page and the date each one was read from. See also the free tier column, metadata against watermark. Nearby terms: generation metadata, platform label, double label.