Burn-in & slate
Burn-in renders identification into the picture, so a reference deliverable is self-describing wherever it is viewed.
A supervisor reviewing a QuickTime deliverable needs the shot code, the version and the on-screen frame number without returning to the web console. Burn-in places that identification in the picture itself.
Burn-in applies to the ProRes reference deliverable a studio ingest profile produces from a sequence — not to the master or the dailies. It is opt-in: a project receives overlays only if its profile names a template, and leaving both templates unset renders the reference exactly as it would be otherwise.
Rendered elements#
Burn-in produces two separate elements, rendered in different places.
A burn-in strip is composited onto every frame — a translucent bar across the top and bottom carrying the fields the template defines. These are typically the shot code and version, an absolute frame counter, source timecode and, for shots with handles, a marker that appears only on handle frames to indicate which frames sit outside the editorial cut.
A slate frame is prepended to the head of the file— one rendered frame carrying the shot code, version and, on the fuller template, a date stamp and the frame range. It is written in the deliverable's own codec, so it plays back as an ordinary frame.
Frame counter#
The counter counts from the shot's true starting frame across the whole deliverable — including across the seams where the distributed encode stitched chunks together.
A counter that reset at each chunk boundary would display plausible but incorrect frame numbers. A supervisor reporting a note against frame 240 would then reference a frame that no one else could locate. The counter carries the true absolute number through every seam.
Available templates#
| Template | Carries |
|---|---|
vfx-standard | Shot and version on the top strip; source timecode and an absolute frame counter on the bottom; the handle marker; a slate with date and frame range. |
editorial-minimal | Shot and version only. No handle marker, no date or range on the slate — for reference cuts where the burn-in only needs to say what it is. |
Burn-in is not a general watermarking tool. The field set is fixed per template, and there is no operator-authored template surface. Burn-in layouts beyond these two templates are not currently configurable.
Template selection#
Templates are set once on the ingest profile, not per job. The pickers are catalogue-backed rather than free text, so a template id cannot be mistyped into a profile; every selectable value is a template the system can render.
Leaving a picker unset is a supported configuration for profiles whose reference deliverable should carry no overlay. Once a profile names a template, every reference job it compiles receives the shot code, version and handle range automatically. No per-shot configuration is required.
Font requirements#
Burn-in text requires an explicit font file. A dependency on host-installed fonts would succeed on a workstation and fail silently on a minimal worker, so a font ships inside the master executable. A single-host install requires no font installation or configuration.
Burn-in composites on the worker, not the master. The master chooses the font and writes its path into the command it dispatches, but the filter runs on whichever machine picks up the chunk. If that worker cannot open the font at that path, the frame cannot be burned in.
On a distributed fleet, point TRNSCODE_BURNIN_FONT_PATH at a font on storage every worker reaches, and use the same value in the master and worker environment files.
One case is detected automatically: a font that resolves only inside the master's own executable temp directory cannot be reached from another machine, and dispatching that path is refused rather than attempted.
When the font is not worker-reachable, burn-in is skipped for that job and the reason is logged. The condition never fails the job and never blocks the encode; the deliverable is produced without the overlay.
The slate is unaffected by font reachability. It renders once, on the master, in a process that already has the font resolved. A distributed fleet has no equivalent precondition for the slate; only the per-frame burn-in depends on worker reachability.