Signal planning begins with a question that sounds simple: what must reach the audience? A professional esports show may combine game clients, observer views, player cameras, talent microphones, remote contributions, replay, graphics, music and commentary. Each source can have a different owner, format and arrival time. The production map connects them to the programme output and identifies the person responsible at each handoff.
Start at the source and follow the whole chain
Build an inventory before drawing a polished diagram. For every source, record its origin, format, expected availability, receiving input, monitoring point and destination. Include whether it is clean or already carries graphics, how audio is embedded or separately routed, and what signal indicates that the source is healthy. A name like “game feed” is not enough if several observer clients or language versions exist. Use labels that match the rundown, patch sheets and operator language.
Trace the route through capture, transport, processing, switching, encoding and delivery. Mark points where a signal is converted, delayed, mixed or duplicated. A route from a game client to a production switcher may pass through capture hardware and a local network; a remote player camera may arrive through a contribution service. Identify the boundary between production-owned and externally supplied infrastructure, then agree who raises an issue at that boundary. Documenting the path is useful only if the people involved can find the right contact.
Example programme route
At each boundary, assign an owner, a check and a recovery action. The diagram is conceptual; document actual paths for each event.
Make technical agreements understandable
Agree formats at the point of exchange. Frame rate, resolution, aspect ratio, audio channel layout, colour handling and latency expectations should be written in terms the receiving operator can verify. SMPTE standards provide useful references for professional media formats and interfaces; AES67 describes interoperability for networked audio, while Dante is a widely used ecosystem for audio routing. These are not interchangeable promises of compatibility: confirm the specific devices, versions and network design in use.
For internet contribution, SRT and NDI may be part of a workflow, but each requires the right configuration, network capacity and tested receiver. RIST is another open specification used for reliable media transport. Name the protocol and its settings, not merely “IP feed.” For programme delivery, check the destination platform's current ingest and encoding requirements directly. YouTube Live, Twitch and other services update technical guidance; a previous tournament's profile is not proof that today's encoder is configured correctly.
Measure and record the end-to-end delay where timing matters. A producer may be coordinating commentary, live game action and a remote interview. A delayed return can make natural conversation feel broken or cause a cue to land late. Use a common reference when comparing sources, and document any intentional delay so the director, talent and technical team are operating from the same expectation.
Build checks into the route
Monitoring should follow responsibility. A source operator checks that a feed exists and is stable; the switcher confirms that the intended source is selectable; the audio lead checks the relevant channel and mix; and the output owner verifies what the platform is actually receiving. A green indicator on one device is not a complete end-to-end check. Include picture, sound, sync, captions where applicable, graphics keying, programme return and a clean recording or archive path if the show requires one.
Use a preflight checklist with named owners and explicit pass criteria. For example, the team can confirm that the game feed is moving, the right observer view is selected, commentary is audible at a safe level, the backup source is available, and the encoded programme is visible at the destination. A checklist should help people notice missing work, not replace their judgement. If a check fails, pause to identify whether the problem is at the source, transport, processing or output before changing several things at once.
Keep a useful source-of-truth map
One current map is better than several partially updated diagrams. Date and version it, show the active show configuration, and keep a copy accessible to the people who must use it during a fault. Avoid hiding essential details in a spreadsheet with unexplained abbreviations. Pair the visual route with a short table describing source, owner, destination, primary check and fallback. When a feed is renamed, a remote path changes or an additional language is added, update both the diagram and the rundown references.
| Stage | Question to settle | Evidence of readiness |
|---|---|---|
| Source | Who supplies the feed and in what format? | Named owner and verified source check |
| Transport | How does it reach the room, and who monitors the path? | Tested route and known fault contact |
| Programme | Where is the feed selected, mixed or delayed? | Operator confirmation on programme return |
| Delivery | What does the audience platform receive? | Destination-side picture and audio check |
The objective is not to draw every cable on one page. It is to make the path and its ownership clear enough that a producer can ask the right question, an operator can isolate a fault, and the next person receives a usable update. This is how signal documentation supports show decisions rather than becoming shelfware.