Render
In plain words: Broadcast: reproducible render
How Broadcast renders a reproducible, accessible local candidate by pinning every input and setting, then probing the output.
- 1Fonts, codecs, filters, colour, loudness and caption formats are all pinned.
- 2Captions keep script and timing lineage; accessibility review is part of the candidate.
- 3A lost write acknowledgement stays unknown until destination and checksum reconcile.
A missing font or changed codec can alter what the audience receives even when the timeline is untouched. Render freezes the dependencies that make one local candidate reproducible and inspectable.
Before rendering, pin every input digest and the settings that can change the result: renderer, font, codec, filter, colour setting, channel layout, loudness target, caption format, command/project revision, and target profile. After rendering, probes retain duration, dimensions, frame rate, codec, color/audio facts, caption presence, checksum, and tolerances so the candidate can be checked against that target.
Accessibility travels with the candidate. Captions retain script and timing lineage. Review contrast, legibility, flashing/motion hazards, intelligibility, language, and channel alternatives for the declared audience. Automated measurements support that judgment without certifying lived accessibility.
A completed write may precede a lost acknowledgement. Keep it unknown until destination and checksum reconcile; blind repetition can create competing outputs or conceal a partial write. Stale inputs, missing fonts, nondeterministic dependencies, unsupported targets, failed probes, and accessibility findings return failed render or correction requests.
Once accepted, the rendered bytes join the script, timeline, claims, sources, and asset manifests in EditorialPackage@2 and PublicationCandidate@2. Muxing must preserve each independent semantic-facet receipt and compound-parent relation. This completes the local candidate; Release separately handles the effect at a destination.