sports_broadcast_production v1.0.0

name: sports_broadcast_production description: "Producing a live sports broadcast or stream: camera plan for the field of play, score bug and lower-third graphics with a cue sheet, replay timing and rules, commentary sync, halftime segments, and a post-game highlights cut. Triggers when planning, directing, or reviewing coverage of a match or game, building a sports graphics package, assigning cameras or a replay operator, or cutting post-game highlights."

Sports Broadcast Production

Purpose

Run a live sports broadcast that a viewer can follow without effort: the right camera is on the play, the score and clock are always right, replays explain the big moments without stealing live action, and commentary and pictures tell the same story. Covers a one camera school stream and a multi camera outside broadcast with the same logic, scaled.

Workflow

1. Lock the match facts first. Sport, format and period structure, venue, kickoff time, rights or permission to stream, and the delivery platform. Get the confirmed team sheets, correct name spellings, and the competition clock rules (count up or count down, stoppage handling) in writing. A misspelled name or a wrong clock direction built into the graphics package will repeat all match.

1. Build the camera plan by role, not by count. Every plan needs a game camera: high, central, on the halfway or centre line, wide enough to show play developing. Then add in this order as crew allows: a tight camera beside it, a high behind goal or basket camera, a pitchside or handheld camera, a second behind goal camera, a reverse angle, and a beauty shot. One sentence per camera states its job. Full tier plans for 1, 2, 4, and 8 plus cameras, plus per sport notes, are in references/camera-plans.md. UEFA's published plan is the reference shape: main and close-up cameras in the main stand on the halfway line, a pitchside halfway camera, high and low behind goal cameras, and a high beauty shot.

1. Build the graphics package and the cue sheet together. Minimum package: persistent score bug (teams, score, clock, period), lineup graphic, player and coach lower thirds, event lower thirds for the sport, halftime and full time stats, and a results graphic. Bind graphics to match data where the system supports it so names and crests come from the record, not from typing under pressure. Write one cue sheet row per graphic with its trigger event, in point, hold, out point, data source, and the commentary line that runs under it. Placement, safe area, and readability rules are in references/graphics-and-replay.md.

1. Assign replay as a named job. One named operator, one named system (EVS, vMix Replay, or equivalent), and a list of recorded ISO cameras in the plan. Replay records continuously from before kickoff: a replay system that starts recording after a big play has no replay of it. Apply the replay rules in references/graphics-and-replay.md: never cover a live scoring chance in a continuous sport, mark in and out points immediately, lead with the one best angle, show the decisive moment at full speed before slow motion, and log every clip with match clock, event, angles, and duration as it airs.

1. Set the commentary sync. The standard booth pairs a play by play announcer, who describes the action as it happens, with an analyst or color commentator, usually a former player or coach, who adds explanation. The working split: play by play owns live action, the analyst speaks when the ball or puck is out of play or no significant action is running, and the analyst defers the moment a big event starts. Agree three mechanics before air: who talks over a replay (usually the analyst, while play by play resets), who reads graphics aloud (the person not describing live play), and the talkback cues the director uses to call replays, graphics, and breaks so the booth is never surprised by a picture change. Add a rules analyst only when the sport and the crew support one: the role was popularised in NFL coverage in the 2010s to explain officiating calls.

1. Script the segments around the game. Pregame: beauty shot open, lineups, one story per team, and the key matchup, timed to hand over to kickoff clean. Halftime: a fixed short running order, usually a recap of the scoring plays from the replay log, one stats graphic, one analyst point, and a reset for the second half. Do not let halftime become unstructured chat: give it segments and durations in the cue sheet like any other part of the show. Postgame: results graphic, the decisive plays, and interviews or a booth recap, then straight into the highlights cut.

1. Validate the plan before match day. Write the plan as JSON in the shape shown by scripts/cue_sheet.py --example and run python3 scripts/cue_sheet.py plan.json --out cue_sheet.csv. The check fails a plan with no game camera, no score bug, a timed graphic holding under 4 seconds, an unnamed replay operator or system, no recorded ISO camera, or no halftime segment for a sport that has one. Fix every failure before air. Then do a full rehearsal pass: switch every camera, fire every graphic from its trigger, run one replay end to end, and check the score bug and lower thirds inside the real player on a phone.

1. Cut the post-game highlights from the log, not from memory. Work the replay log in match order. A tight default cut: open on the best moment, then scoring plays in order, then the decisive non scoring moments (saves, stops, turning points), then the final score graphic. Keep each clip's original full speed action before any slow motion replay of it. Export a clean version with the score bug and a vertical or short version only after the main cut is approved.

Output Contract

• A camera plan: each camera with position, role in one sentence, and operator, scaled from references/camera-plans.md.
• A graphics cue sheet (CSV from scripts/cue_sheet.py plus the per graphic rows from references/graphics-and-replay.md): trigger, in point, hold, out point, data source, commentary tie.
• A segment running order: pregame, each period, halftime, and postgame, each with duration, cameras, graphics, and who is talking.
• A replay assignment: operator, system, ISO cameras, storage check, and the live replay log format.
• A post-game highlights list built from the replay log: match clock, event, angles, clip duration, in running order.

Operating Rules

1. The game camera never leaves live play for a reaction, a replay, or a graphic. If the viewer can lose the ball, the plan is wrong.
2. The score bug stays in one place with one operator owning score and clock. Verify both against the official scorekeeper at every break.
3. Replay never covers live action that matters. Bank the clip and play it at the next stoppage.
4. Graphics hold long enough to be read or they do not air. Timed graphics under a 4 second hold fail the cue sheet check.
5. Commentary and pictures change together. The director calls every replay, graphic, and break on talkback before it airs.
6. Keep all graphics inside safe areas and test them in the actual viewing player, on a phone, before match day. Streaming interface elements cover the edges broadcast safe areas were designed around.
7. Name spellings, pronunciations, and clock rules come from the confirmed team sheet and competition rules, checked before air, never from memory or a previous match.
8. If a camera, the replay system, or the graphics system fails live, fall back in this order: game camera plus score bug, then add tight camera, then replay. State the fallback in the plan so the crew does not improvise it under pressure.