AI in Live Broadcast — Engineering Playbook

Published 2026-06-03 · 29 min read · By Nikolay Sapunov, CEO at Fora Soft

Why this matters

Live broadcast is where AI has the least room to fail and the most to gain. The audience for a single live sports final or breaking-news block can dwarf a month of on-demand views, the content is perishable — a missed goal cannot be re-shot — and the whole pipeline runs against a clock measured in milliseconds per frame. At the same time, the economics are brutal: a traditional outside-broadcast production needs trucks, crews, and camera operators, which is why an estimated 99% of the world's sporting events have never been broadcast at all. AI changes that calculus on both ends — it makes a one-camera school match look like a produced show, and it gives a tier-one broadcaster instant highlights, captions in forty languages, and translated commentary that no human crew could deliver in real time. This playbook is written so a product manager can plan the feature and its risk posture without a broadcast-engineering degree, and so an engineer can see exactly where each model taps the live signal, what latency it is allowed to add, and where it goes wrong. The deeper lessons in this section are the per-component manuals — streaming ASR, real-time translation, generative video, content moderation; this is the vertical map that tells you which one to open and what the live clock will let you get away with.

What "AI in live broadcast" actually means

Strip away the trade-show gloss and AI in live broadcast is software that watches, listens to, or adds to a live signal and produces a result fast enough to go out on air. The catalog is large, but it sorts into three groups, and the groups matter because the live clock, the hardware, and the law all treat them differently.

It helps to see the whole catalog before reasoning about any one feature.

Figure 1. The AI-in-live-broadcast feature catalog, grouped by the job the AI does. Each group answers to a different master: the clock, accessibility law, and synthetic-content disclosure law.

The first group is capturing and directing the show. The camera, or a bank of cameras, runs object detection and tracking — the technology that finds the ball, the player, or the presenter in the frame and follows it — and from that you get auto-tracking pan-tilt-zoom cameras that frame the action with no operator, automated switching that cuts between cameras the way a director would, real-time graphics and augmented-reality virtual sets that composite scoreboards and 3D objects into the live picture, and automatic instant replay. This is the group that races the clock hardest, because everything it does has to land inside the time it takes to push one frame through the pipeline.

The second group is making the show understood and reaching everyone who wants it. Here the AI listens rather than looks: automatic speech recognition turns the commentary into live captions and subtitles, machine translation turns those captions into other languages, and speech synthesis turns the translation back into spoken dubbing — all in real time. Audio description, the spoken narration of on-screen action for blind viewers, is moving the same way. This group looks optional but frequently is not: in many countries captioning live television is a legal requirement, not a courtesy.

The third group is repackaging, moderating, and synthesising the live content as it airs. Some of this is defensive and editorial: AI detects the goal or the game-winning moment and cuts a highlight clip within seconds, flags profanity or a brand-safety problem inside the broadcast delay, and logs the output for compliance. But this group also contains the features that generate what the audience sees and hears — an AI-cloned commentator voice, a synthetic news anchor, a digitally altered shot. Those features look like just more automation. They are not. The moment a broadcast presents content that AI generated or manipulated rather than captured, it crosses a transparency line that the law now draws explicitly, and the rest of this playbook keeps coming back to that line.

The one constraint that rules everything: the live clock

Before the topology and the law, it is worth being concrete about why live AI is harder than the same AI applied to a recorded file, because the reason is a single property the whole industry organises around: a live broadcast cannot wait. A video-on-demand pipeline can take a model that needs three seconds per frame and simply run it slower than real time; nobody notices. A live broadcast has no such luxury. The show is happening now, the frame is leaving now, and whatever the AI is going to contribute, it has to contribute before that frame goes out.

The clock has two hands, and engineers track both. The first is glass-to-glass latency — the total delay from light hitting the camera lens ("glass") to the picture appearing on the viewer's screen ("glass"). The second is the per-frame budget — how much time you have to touch a single frame before the next one arrives.

Put numbers on the per-frame budget, because it is unforgiving. Broadcast video runs at a fixed frame rate — commonly 50 or 59.94 frames per second. At 50 frames per second, the time between two frames is:

1 second ÷ 50 frames = 0.02 seconds = 20 milliseconds per frame

So an AI feature that must act on every frame in lock-step with the picture — an auto-tracking crop, a real-time graphic locked to a moving player — has roughly 20 milliseconds to look at the frame and produce its answer, and at 59.94 frames per second only about 16.7 milliseconds. That is less time than a single round-trip to a typical cloud region. It is the reason the heaviest real-time AI in broadcast runs on a graphics processor sitting next to the video, not in a distant data center, and why a purpose-built path like NVIDIA's Holoscan Sensor Bridge advertises glass-to-glass latency as low as 17 milliseconds by moving sensor data straight into GPU memory.

Not every feature has to live inside one frame, though, and that distinction is the most useful planning tool in this whole article. Features sort onto a latency ladder.

Figure 2. The latency ladder. Before you decide anything else about a live-AI feature, decide which rung it sits on — that single choice constrains where the model can physically run.

At the top rung, in-frame real time (≈ 20 ms or less), live anything that must be visually locked to the moving picture: auto-tracking crops, AR graphics pinned to a player, AI keying that replaces a green screen frame-by-frame. These have to run on hardware next to the signal.

On the second rung, near real time (a second or a few), live the features that can ride inside the production's natural delay: live captions and translation, content moderation that runs inside the few-second broadcast delay every live channel already has, and instant-highlight detection that publishes a clip "within seconds" rather than within a frame.

On the third rung, broadcast and low-latency streaming (≈ 2–6 seconds), live the encoding-and-delivery jobs: live encoders, Low-Latency HLS and Low-Latency DASH (the streaming formats that close most of the gap to traditional television, getting to roughly five seconds behind live), and ad insertion keyed off SCTE-35 markers.

The bottom rung is the one everyone is trying to climb off: legacy over-the-top streaming, where naive segmented delivery left online viewers 30–45 seconds behind the broadcast — long enough to hear the neighbours cheer a goal before seeing it. Putting an AI feature on the wrong rung is the most common planning mistake in the field: a model that needs 200 milliseconds cannot drive an in-frame graphic, but it is perfectly happy generating a highlight clip. The latency budget that underlies this whole ladder is worked through in the sub-100ms real-time latency budget lesson; the deployment trade-off behind it is in the latency and deployment-topology lesson.

There is a second half to the live clock that recorded AI never faces: there is no second take. If a model produces a wrong caption, a bad crop, or a nonsense translation on a file, you fix it and re-render. On air, the mistake is already in front of the audience. That is why every well-built live-AI feature is designed to degrade gracefully — to fall back to a safe default (the wide shot, the previous caption, silence) when its confidence drops, rather than confidently emitting garbage — and why a human director or editor stays in the loop on anything consequential. "AI proposes, a human stays in control" is the same rule that governs the rest of this section; the live clock just makes it non-negotiable.

Where the AI actually runs

Here is the structural decision that ties "AI" to "broadcast" specifically, and it is the part most round-ups skip. Once you know a feature's rung on the latency ladder, the next question is where the analytics physically execute, because in broadcast that one choice sets your latency floor, your bandwidth bill, and what happens when something fails. There are three answers, and serious productions use more than one.

The first place is on-premises or in the outside-broadcast truck — the AI runs on hardware inside the facility or the production vehicle parked at the stadium, on the same network as the cameras. Modern broadcast facilities increasingly carry that signal not over traditional SDI cabling but over SMPTE ST 2110, the standards suite that sends uncompressed video, audio, and metadata as separate, synchronised streams over a managed IP network, timed by a shared precision clock. Running the AI here gives the lowest possible latency — the model sits microseconds from an uncompressed feed — and the most control, which is why in-frame features (auto-tracking, AR, keying) almost always live on-prem. The cost is capital: real GPUs, real engineering, and an IP plant to build and run.

The second place is the cloud, in what broadcasters call remote production or REMI ("remote integration"). Instead of sending a full crew and a truck, the venue sends compressed camera feeds over the public internet to a cloud or a central facility, where the switching, graphics, AI, and packaging all happen, and the finished program comes back. The feeds travel over reliability protocols built for exactly this — SRT and RIST, which add error recovery on top of ordinary internet so a contribution feed survives the public network. The appeal is operational and economic: no truck, capacity that scales with a slider, and access to cloud GPUs on demand. The cost is latency and dependence on a link — every hop to the cloud and back adds delay, and a flaky uplink at the venue becomes your single point of failure.

The third pattern is hybrid, and in 2026 it is the honest default. The in-frame, can't-wait work runs at the edge on the truck or on-prem; the heavier or more elastic work — instant highlights, translation, archive-grade analytics — runs in the cloud; and the two talk over standardised transport. Industry surveys bear this out: a majority of broadcasters now report a hybrid infrastructure that mixes SDI, IP, and cloud, rather than betting the plant on any one. Software-defined broadcast platforms such as NVIDIA's Holoscan for Media exist precisely to orchestrate multi-vendor AI inference on these uncompressed live feeds with minimal latency, blurring the line between "on-prem" and "cloud" into one programmable fabric.

Figure 3. The three places the AI can run. On-prem and the OB truck win on latency and control; cloud REMI wins on cost and elasticity; most real productions blend them.

The interoperability glue matters here the way ONVIF matters in surveillance. ST 2110 productions are managed by NMOS — a set of open specifications from the Advanced Media Workflow Association for discovering devices, registering them, and connecting streams — so an AI processor from one vendor can find and tap the right feed on a multi-vendor network without custom wiring. When a feature has to leave the building, NDI (a lightly compressed IP video format, roughly 100 megabits per second per stream) carries it around a facility or campus, and SRT or RIST carry it across the open internet. Picking the transport is part of picking where the AI runs.

The bandwidth reality that shapes the choice

The place-the-AI decision is not aesthetic; it is partly arithmetic, and the arithmetic is what makes uncompressed on-prem AI expensive and cloud REMI attractive. An uncompressed 1080p broadcast feed over SMPTE ST 2110 is roughly 3 gigabits per second — for a single camera. A modest live production with eight cameras is therefore on the order of:

8 cameras × ~3 Gbps = ~24 Gbps of uncompressed video on the production network

That is why ST 2110 plants are built on 25- and 100-gigabit switches and why running AI on those feeds means hardware that can ingest them. Send those same eight feeds to the cloud uncompressed and you would need 24 gigabits of internet uplink from the venue, which essentially no venue has. So REMI compresses first: a contribution-grade SRT feed of a 1080p camera is more like 10–50 megabits per second, turning that 24 Gbps into a few hundred megabits the public internet can actually carry:

8 cameras × ~25 Mbps SRT contribution ≈ 200 Mbps uplink — feasible over the internet

The trade is written into those two numbers. On-prem keeps the feeds uncompressed and pristine for the AI but demands a heavy local network and local GPUs. Cloud REMI fits down an ordinary internet pipe but pays in compression artefacts, encode/decode latency, and a dependence on the link staying up. There is no free lunch; there is a budget, and the latency ladder tells you which side of it each feature belongs on.

The line that decides everything: real footage vs synthetic content

In the latency section the binding constraint was time; in the topology section it was bandwidth; in the law it is whether the AI is showing the audience something that happened or something it generated, and the rule that follows is now explicit. Using AI to find, caption, translate, or re-frame real footage is ordinary production. Using AI to generate or manipulate what the audience sees or hears — a synthetic anchor, a cloned voice, an altered shot — is a different category that the EU AI Act regulates with a transparency duty, because the EU AI Act (Regulation (EU) 2024/1689) applies to any system whose output is used in the EU, it sets the floor for almost any broadcaster with European viewers.

The relevant rule is Article 50, whose transparency obligations apply from 2 August 2026, and it sorts live-broadcast content into three cases.

Figure 4. The transparency line for live-broadcast AI. Assistive AI over real footage sits in the light-touch top band; synthetic or manipulated content shown to viewers triggers Article 50 disclosure; AI-written news text gets a carve-out only when a human holds editorial responsibility.

The top tier is real footage with assistive AI, and it holds most of what broadcasters actually want to ship. Auto-tracking a camera, switching between real cameras, compositing a graphic over real play, captioning the real commentary, translating it, cutting a highlight of a real goal — all of these find, frame, or describe events that happened. Article 50 explicitly exempts AI that "performs an assistive function for standard editing" or does not substantially alter the input, so this bucket carries no new AI-Act disclosure burden. It is the bucket to plan first and deploy fast.

The middle tier is synthetic or manipulated content shown to the audience. The moment the broadcast presents an AI-cloned commentator voice, a synthetic on-air anchor, an AI avatar, or footage that has been digitally altered into something that did not happen, Article 50(4) applies: the deployer must disclose that the content is artificially generated or manipulated, in a way that is clear and distinguishable, at the latest at the first moment the viewer is exposed to it. Regulators have been blunt that for broadcast this means the disclosure has to be persistent — because a viewer can tune in halfway through — not a one-second caption at the top of the hour. Content that is evidently artistic, creative, or satirical gets a lighter version of the duty (disclose that synthetic content exists, without spoiling the work), but no broadcast use is fully exempt.

The bottom tier is AI-generated text that informs the public. Article 50(4) has a separate sentence for it: AI-generated or AI-manipulated text "published with the purpose of informing the public on matters of public interest" — an AI-written news bulletin, ticker, or summary — must be disclosed unless the content went through human review and a person or organisation holds editorial responsibility for it. This is the newsroom carve-out, and it is the single most important sentence in the article for any broadcaster automating news: keep a human editor accountable for AI-drafted on-air text and the disclosure duty lifts; ship unreviewed machine-written news and it does not. The broader disclosure-and-provenance engineering, including the C2PA content-credentials standard for proving where a piece of media came from, is in the quality, C2PA, and EU AI Act disclosure lesson; the generative models that create this synthetic content are surveyed in the generative video landscape lesson and the AI avatars and lip-sync lesson.

The same logic holds outside Europe even where the statute differs: an audience that is shown a synthetic anchor without being told has been misled, and that carries consequences — reputational and increasingly legal — that captioning a real broadcast never does. The EU AI Act simply makes the line explicit and enforceable. The full regulatory picture is in the EU AI Act regulatory-engineering lesson.

The accessibility bucket: where AI earns its keep, and where the rules bite

Take the second feature group — captions, subtitles, translation, dubbing — on its own, because it is where AI delivers the clearest win and where a separate body of law applies whether or not AI is involved. The defining property is that these features widen the audience: a live caption serves deaf and hard-of-hearing viewers, a subtitle and a dub serve speakers of other languages, and audio description serves blind viewers.

The AI case here is strong and current. Real-time automatic captioning now reports accuracy in the 98–99.5% range on clear broadcast audio, good enough that broadcasters and venues deploy it for live sports, and platforms generate synchronised captions in 40-plus languages live. Real-time translation and dubbing have crossed the same threshold: systems built for broadcast now deliver multilingual live dubbing with sub-second latency, to the point that a 2026 European football fixture carried live AI-dubbed commentary as a first. The economics are stark. A human real-time captioner (a stenographer providing CART, "communication access real-time translation") is a skilled, scarce, and expensive resource. Compare a year of an 18-hour-a-day channel:

18 hours/day × 365 days = 6,570 hours of live programming a year
Human realtime captioner at ~$150/hour:  6,570 × $150  ≈ $985,000/year
AI captioning at a low per-hour rate:    illustratively 1–2% of that

The numbers are illustrative and move with vendor and language, but the shape is why AI captioning spread so fast: it makes captioning every hour of every channel affordable, where human captioning forced hard choices about which programming got covered.

What AI does not do is repeal the rules. In the United States, the Federal Communications Commission requires closed captioning of television programming under 47 CFR § 79.1, with quality standards covering accuracy, synchronicity, completeness, and on-screen placement, and with explicit recognition that live and near-live programming is harder than pre-recorded — a lower bar, not a free pass. A 2026 compliance deadline additionally requires that caption display settings be readily accessible to viewers. So the engineering target is not "good enough to look smart in a demo" but "good enough to meet a regulator's quality standard on live audio, in real time, every hour." That bar is why human oversight and broadcaster-specific dictionaries (team names, player names, local terminology) still wrap the AI even at 99% accuracy. The component manuals are the streaming ASR lesson, the live-captions fan-out lesson, the real-time speech-translation lesson, and the AI dubbing and subtitle-pipeline lesson.

Common pitfall: putting a cloud model on an in-frame job. A team demos a slick AI graphic or auto-crop running against a recorded clip in the cloud, it looks great, and they plan to ship it driving the live picture. On air it falls apart, because a round-trip to the cloud and back is tens to hundreds of milliseconds and the in-frame budget at 50 fps is 20 milliseconds — the graphic arrives one, two, three frames late and visibly lags the action. The same model is perfectly fine one rung down, generating a highlight or a lower-third that does not have to lock to motion. The fix is to put every feature on the latency ladder before choosing where it runs: in-frame work goes on a GPU next to the signal on the truck or on-prem; only near-real-time and slower work may go to the cloud. Designing the architecture around the demo instead of the budget is the single most expensive mistake in live AI.

The repackaging bucket: instant value, with a human on the trigger

The third group — instant highlights, moderation, compliance, and synthesis — is where live AI turns the broadcast into many products at once, and where the "no second take" rule needs the most discipline.

Instant highlights are the clearest commercial win. An AI engine ingests the live feed and uses both video cues (the ball hitting the net, players celebrating) and audio cues (the commentator's pitch spiking, the crowd roaring) to detect a key moment, then cuts and captions a clip in multiple aspect ratios — ready for the broadcaster's app, website, and social feeds — within seconds of it happening. The market has voted: highlight-automation platforms serve hundreds of leagues and broadcasters and publish clips while the play is still fresh, which is the difference between owning the social moment and missing it. The detection-and-tracking machinery underneath is the multi-object tracking lesson.

Moderation and compliance are the defensive half. Every live channel already runs a few seconds behind real life — the broadcast delay — originally so a human could bleep profanity. AI now rides inside that same delay to flag profanity, nudity, brand-safety problems, and prohibited content faster and more consistently than a person watching a wall of monitors, and to log every output automatically for the compliance record regulators expect. The real-time-moderation engineering is in the content-moderation lesson. Loudness is part of the same compliance gate: in the US the CALM Act requires commercials to match the average loudness of the programming around them, and automated loudness management enforces it.

Synthesis is the part that earns the most scrutiny, because it is exactly the content the transparency line governs. A cloned commentator voice that calls a game in a language the original commentator does not speak, a synthetic presenter who reads overnight headlines, an AI-generated explainer graphic — each can be a real product, and each is precisely the Article 50(4) "artificially generated or manipulated" content that must be disclosed to the audience. The discipline is the same one that runs through this whole article: AI proposes the clip, the voice, the headline; a human stays on the trigger for anything consequential, and anything synthetic carries its disclosure. Treat an AI-generated on-air element as a separate product with its own sign-off, not as a toggle on an editing tool.

Three ways to add AI to a live broadcast

If you are building or integrating the production itself, "add AI" resolves to one of three routes, and they trade speed against control the way platform decisions always do.

The first route is to embed a specialist vendor. Live broadcast has a deep bench of them: automated-production systems that film, track, switch, and stream a game from a single multi-camera unit; highlight engines that plug into the feed and emit clips; caption-and-translation platforms that take an audio feed and return compliant captions in dozens of languages; graphics engines that add AI keying and AR. Through a vendor you can stand up a polished AI capability in days to weeks, inheriting their models and their compliance posture. The cost is that the analytics quality and roadmap live with the vendor, and you fit within the features and the latency they expose.

The second route is to assemble a computer-vision and speech stack — wire detection, tracking, ASR, translation, and your own production logic together on your own infrastructure, on-prem or in the cloud. This is a step up in effort, weeks to a few months, and it buys control: you decide which models run, on which rung of the latency ladder, and where the signal flows. The trade is that the models, the tuning, the latency engineering, and the compliance design are now yours to own.

The third route, and the only one that gives you full control of latency and data, is to build on open models at the edge — run open detectors, trackers, and speech models on your own GPUs next to the signal on the truck or on-prem. This takes the most engineering up front, typically months, but it puts the in-frame features inside your own 20-millisecond budget, keeps your feeds and any sensitive content on your own hardware, and frees you from a per-stream vendor fee. It is the route for a broadcaster whose latency, independence, or content security is the whole point. Shrinking models to hit a real-time budget on local hardware is its own craft, covered in the distillation and quantization for edge lesson.

Table 1. The three routes to AI in a live broadcast, by what each trades. Most broadcasters embed the accessibility and highlight layers, assemble the production logic, and build only the in-frame features they cannot afford to send off-box.

The per-feature cost method behind all three routes is in the real cost of AI in video lesson, and the broader streaming-delivery decisions that wrap a live AI feature — encoding ladders, protocols, packaging — are in the OTT platform development playbook.

The gate every live-AI deployment passes: accessibility, loudness, disclosure

This is where a live-broadcast roadmap quietly becomes a compliance one. Treat what follows as engineering-relevant context, not legal advice — confirm specifics with a qualified lawyer for the jurisdictions and licences you operate under.

Accessibility comes first, because it applies regardless of AI. If you broadcast in a regulated market you likely owe captions on live programming to a quality standard — in the US, FCC rules under 47 CFR § 79.1 — and you may owe audio description and accessible caption controls too. AI is a means to meet that duty cheaply and at scale, not a reason the duty changes. Build human oversight and broadcaster-specific dictionaries around the captioning model so it clears the regulator's accuracy bar on live audio, every hour.

Loudness and broadcast compliance come second. The CALM Act and its international equivalents require consistent loudness, especially across the program-to-commercial boundary; automated loudness control is table stakes. The same compliance layer logs the output — what aired, with what captions, with what moderation flags — because "show me the record" is a routine regulator and rights-holder request.

Synthetic-content disclosure comes third, and it is new. From 2 August 2026, EU AI Act Article 50 requires that AI systems generating synthetic audio, image, or video mark their output as machine-readable AI-generated, and that deployers disclose deepfake and manipulated content to the audience clearly and persistently. AI-generated on-air text that informs the public must be disclosed unless a human held editorial responsibility for it. Engineer the disclosure in from the start — a persistent on-screen marker for synthetic segments, machine-readable provenance via C2PA, and a newsroom workflow that records human editorial sign-off — rather than bolting it on after a regulator asks.

The rule across all three gates is the one that governs the whole article: a human stays in control of anything that reaches the audience, and anything the AI generated is labelled as such. Accessibility is your duty to the audience that needs help following; loudness and logging are your discipline about what you put out and can prove; disclosure is your honesty about what is real. A live-AI deployment that respects all three is an asset; one that skips any of them is a liability waiting for a regulator or a viewer backlash.

The playbook: from "put AI in the broadcast" to a deployed feature

Put the pieces together and adding AI to a live broadcast reduces to four questions, asked in order.

Figure 5. The playbook in one path. Put the feature on the latency ladder, place the AI where that rung allows, design graceful degradation with a human in control, and pass every deployment through the accessibility-loudness-disclosure gate.

First, put the feature on the latency ladder: does it need to lock to the picture (in-frame, ≈ 20 ms), can it ride the production's natural delay (near real time, seconds), or is it an encode-and-deliver job (a few seconds)? That rung is the most important fact about the feature. Second, place the AI where the rung allows: in-frame work on a GPU next to the signal on the truck or on-prem over SMPTE ST 2110; elastic or heavy work in the cloud via REMI over SRT or RIST; hybrid as the default, and expect to blend. Third, design for no second take: make the feature fall back to a safe default when its confidence drops, and keep a human director or editor on anything that reaches air — never let an AI flag drive an irreversible on-air action alone. Fourth, and without exception, the compliance gate: meet captioning quality rules on live audio, manage loudness and log the output, and for any AI-generated or manipulated content build in Article 50 disclosure and C2PA provenance — keeping the news-text carve-out only where a human holds editorial responsibility.

That is the entire playbook. The deeper lessons in this section are the manuals for each box — streaming ASR and real-time translation for the accessibility group, multi-object tracking for the auto-production group, content moderation for the compliance group, the generative video landscape and AI avatars for the synthesis group you should approach with the most disclosure discipline, and the OTT platform playbook for the streaming delivery that carries it all.

Where Fora Soft fits in

We build the video-streaming, WebRTC, and OTT platforms that live broadcasts flow through, so we run this playbook with clients regularly. When a client wants to ship fast, we integrate specialist AI — captioning, translation, highlight, and graphics engines — into a streaming workflow and wire the accessibility, loudness, and disclosure decisions in first. When latency or content control is the point, we build on owned pipelines — running detection, tracking, and speech models close to the signal so in-frame work stays inside the frame budget, and designing graceful degradation and the human-in-control pattern into the flow from the first sprint. When a client raises a synthetic anchor or an AI-cloned voice, we treat it as the disclosure-bound product it is, with Article 50 transparency and C2PA provenance built in. The four questions in this playbook are the same ones we weigh in scoping calls when a broadcast client asks where AI belongs in their live signal.

What to read next

• Streaming ASR in production — Deepgram, Whisper, AssemblyAI
• OTT platform development — AI engineering playbook
• Quality, cost, C2PA, and EU AI Act disclosure engineering

Talk to us / See our work / Download

• Talk to a video engineer — scope AI into your live-broadcast or streaming workflow: book a 30-minute call.
• See our work — streaming, WebRTC, and OTT platforms we have shipped: video streaming development.
• Download the AI in Live Broadcast Engineering & Compliance Decision Sheet — the feature catalog, the latency ladder, the three places the AI runs, the synthetic-content disclosure line, and the accessibility-loudness-disclosure gate on one page: AI in Live Broadcast — Engineering & Compliance Decision Sheet.

References

1. SMPTE ST 2110 — Professional Media Over Managed IP Networks (suite: ST 2110-10 system/timing, -20 uncompressed video, -30 PCM audio, -40 ancillary data). Defines sending uncompressed video, audio, and metadata as separate, synchronised IP streams over a managed network, timed by PTP (SMPTE ST 2059 / IEEE 1588), as the IP replacement for SDI. Read from the SMPTE standards page. Tier 1 (official standards body). https://www.smpte.org/standards/st2110
2. Regulation (EU) 2024/1689 (EU AI Act) — Article 50 (Transparency obligations). §50(2): providers of AI generating synthetic audio/image/video/text must mark outputs as machine-readable AI-generated (assistive/standard-editing exemption). §50(4): deployers of deepfake/manipulated image-audio-video content must disclose it; artistic/creative/satirical works get limited disclosure; AI-generated text informing the public must be disclosed unless human-reviewed under editorial responsibility. Clear and distinguishable at first exposure. In force 2 Aug 2026. Read directly from the consolidated Article 50 text. Tier 1 (official EU regulation). https://artificialintelligenceact.eu/article/50/
3. US FCC — 47 CFR § 79.1 (Closed captioning of televised video programming) + caption quality standards. Requires closed captioning of TV programming with quality standards (accuracy, synchronicity, completeness, placement) and explicit live / near-live / pre-recorded distinctions; a 2026 deadline requires readily accessible caption display settings. The accessibility floor for US broadcast. Tier 1 (official US regulation). https://www.law.cornell.edu/cfr/text/47/79.1
4. US FCC — CALM Act (Commercial Advertisement Loudness Mitigation), in force 13 Dec 2012, incorporating ATSC A/85 RP. Requires commercials to match the average loudness of the programming they accompany; the basis for automated loudness compliance in broadcast. Tier 1 (official US statute/rule). https://www.fcc.gov/enforcement/areas/sound-volume-commercials-calm-act
5. AMWA NMOS (Networked Media Open Specifications) — IS-04 (discovery & registration) + IS-05 (connection management). Open specs that manage SMPTE ST 2110 networks — device discovery, registration, and stream connection — so multi-vendor IP (and AI) devices interoperate without custom wiring. Tier 6 (industry standards body / open spec). https://specs.amwa.tv/nmos/
6. NVIDIA — Holoscan for Media + Holoscan Sensor Bridge (Technical Blog, 2025). Software-defined broadcast platform orchestrating multi-vendor live production and AI inference on uncompressed ST 2110 feeds with minimal latency; Sensor Bridge moves sensor data straight into GPU memory for glass-to-glass latency as low as 17 ms; integrates TensorRT / Triton and Maxine. Tier 4 (vendor / deployer). https://developer.nvidia.com/blog/software-defined-broadcast-with-nvidia-holoscan-for-media/
7. Haivision — 2025 Broadcast Transformation Report (cited via SMPTE ST 2110 / SRT live-production analysis). ~51% of broadcasters report a hybrid SDI+IP+cloud infrastructure; ~37% use SMPTE ST 2110; SRT carries low-latency contribution from OB trucks to remote production for live sports/events. Evidence that hybrid is the 2026 default. Tier 4 (vendor / deployer). https://www.haivision.com/blog/all/smpte-st-2110-haivision-live-production-workflows/
8. Pixellot — automated sports production technology (company + SVG interview, 2025). AI multi-camera units auto-track, switch, stream, and generate highlights without an operator; 25,000+ systems deployed; founded 2013; premised on the fact that ~99% of sporting events were never broadcast due to production cost. The auto-production reference deployer. Tier 4 (vendor / deployer). https://www.pixellot.tv/
9. WSC Sports — real-time AI highlights platform. Analyses live sports feeds with video + audio cues to detect key moments and publish customised, multi-aspect-ratio clips within seconds; 525+ clients across 250+ leagues and broadcasters (NBA, PGA Tour, NHL). The instant-highlights reference deployer. Tier 4 (vendor / deployer). https://wsc-sports.com/
10. AWS Elemental — Low-Latency HLS live workflow (AWS for M&E). LL-HLS with MediaLive + MediaPackage reduces end-to-end latency to as low as ~5 seconds behind live — matching the traditional broadcast range — while retaining SCTE-35 ad insertion and DRM; 1–2 second segments trade latency against encoding efficiency. The low-latency-streaming reference. Tier 4 (vendor / deployer). https://aws.amazon.com/blogs/media/how-to-configure-a-low-latency-hls-workflow-using-aws-media-services/
11. SyncWords / CAMB.AI / AI-Media — live AI captioning, translation, and dubbing (2026 deployments). Live AI captioning at ~98–99.5% accuracy in 40+ languages; sub-second live AI dubbing deployed on a 2026 European football fixture as a broadcast first. The accessibility/localization reference deployers. Tier 4 (vendor / deployer). https://www.syncwords.com/solutions/live-sports
12. European Commission — Draft Guidelines on AI Transparency under Article 50 (2025–2026). Clarify that broadcast deepfake disclosure must be clear, distinguishable, and persistent (because viewers join midway), and detail the editorial-responsibility carve-out for AI-generated public-interest text. Tier 1 (official EU guidance). https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai