GateTrue

What each generator documents about marking its output

Double label: two marks arriving on one frame

A double label is what happens when a tool's own mark and a destination's label both land on one frame. It is named on exactly one page in this register, as an argument for allowing the first to be turned off. As of 2026-09-22.

What collides on a frame, and what does notTwo burned-in marks compete for finite screen area and can overlap or make a frame look broken. Two invisible signals in one file do not interact at all, which is why the only published argument for removing a mark in this register concerns a visible one.Two visible marksTwo invisible signalsCompete forFinite screen areaNothingPossible outcomeOverlap, or a frame that looks brokenTwo readable signalsFix at the publisher's endSwitch one off, if a switch existsNot neededNamed in this registerAs a reason for a switchNot raised anywhereThe clearest practical consequence of the visible and invisible split
Fig. 1 The right setting depends on where a file is going, which is information the generating tool does not have.
How this register uses the term, and what it excludes. Written 2026-09-22.
The termDouble label
What it namesA tool's mark and a destination's label on the same frame
What it is notTwo provenance signals inside one file, which do not collide
Where the register uses itThe stated reason on one control-column value

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 visible marks collide and invisible ones do not

Two burned-in marks occupy screen area, and screen area is finite. A corner badge from the tool and an overlay from the platform can overlap, fight for the same safe region, or simply make a frame look broken. That is a real production problem with no technical fix at the publisher's end.

Two invisible signals in one file are just two signals. Nothing competes, nothing overlaps, and no reader has to choose between them. This is the clearest practical consequence of the visible and invisible distinction, and it explains why the only published argument for removing a mark concerns a visible one.

2An argument that is not about money

Every other condition attached to removal in this register is a price. This one is not: the case made is that a destination adding its own label would otherwise put two labels on one frame, so the switch exists to avoid a bad frame rather than to sell an upgrade.

That distinction is worth recording because it predicts behaviour. A switch justified operationally has a reason to keep existing through a repackaging; a removal feature justified by nothing moves whenever a grid is redrawn. The register records that a reason was given and by whom, without auditing it.

3What it implies for a workflow

If a destination labels uploads, marking at the tool adds nothing a viewer needs and costs frame area. If it does not, the tool's mark may be the only disclosure the file ever carries. The right setting therefore depends on where a file is going, which is information the tool does not have.

That is an argument for per-delivery control and against plan-gated removal, and it is the reverse of the argument for auditability. The register records both mechanisms and neither preference, because the trade depends on facts no vendor page contains.

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: detection signal, feature grid, cumulative grid.