GateTrue

What each generator documents about marking its output

Re-encode: the ordinary step that drops a manifest

A re-encode compresses a video again and writes a new container. Anything attached to the old container survives only if the tool was told to carry it forward, and most tools are not told. As of 2026-09-22.

What one re-encode does to each layer of a fileAn encoder writes a new container holding the streams and blocks it was configured to carry. The picture comes through, degraded and recognisable, so anything in the picture survives. A manifest nobody mentioned in the configuration is not in the output at all.Survives a re-encodeMay not survive itWhat it isAnything in the pictureAnything attached around itExamplesA burned-in mark, an in-picture signalA credential manifest, metadata keysWhyThe picture is what gets encodedBlocks are carried only if configuredMentioned in this registerAs a robustness claimAs a caveat, onceThe single most common thing that happens to a delivered file
Fig. 1 Two mentions of this operation exist in the whole register: one vendor caveat and one line of advice to publishers.
How this register uses the term, and what it excludes. Written 2026-09-22.
The termRe-encode
What it namesCompressing a video again and writing a new container
What it is notCopying a file, which changes nothing inside it
Where the register uses itThe one published durability caveat, and one warning

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.

1Why it is the operation that matters most

Nearly every delivered video is re-encoded at least once: an editor exports, a platform transcodes on upload, a review copy is made smaller. It is the single most common thing that happens to a file after it leaves a generator, and it is the operation an attached provenance record is least likely to survive.

Nothing about that is an attack. An encoder builds the container it was asked for and carries forward the streams and blocks it was configured to carry. A manifest nobody mentioned in the configuration is simply not in the output.

2What it leaves alone

The picture, recognisably. A burned-in mark is made of the same pixels as everything else in frame, so it comes through a re-encode degraded and present. An in-picture signal is designed to come through too, which is what its publisher claims for it.

So one operation sorts the layers cleanly: what is in the picture stays, what is attached around it may not. That single fact explains most of the difference between the two kinds of mark this register records.

3Where it appears in the register

Once as a vendor's own caveat, saying a credentials check should indicate a file was generated unless the metadata has been removed. Once as advice, telling publishers to keep whatever a tool writes and warning that re-encoding can strip it. Nowhere else does any page mention it.

That is worth knowing before building a policy 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.

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 machine-readable column, what survives an export. Nearby terms: transcode, metadata strip, container.