How live TV and streaming work: broadcast workflows from tape to the cloud

A striker shoots and the ball hits the net. On satellite or cable TV you see it about 6 seconds later. On an app it is often 10 to 30 seconds later. Follow that goal through the drawing.

A big Premier League match can have up to about 25 cameras. They feed an outside broadcast truck at the ground, or a control room miles away. A director cuts between them while replay operators find the best angle. The pictures reach the broadcaster on fibre or satellite. There they are put on air (“played out”), compressed and sent out by satellite, cable, broadband and apps.

The pitch end is fast. Cameras, truck and links add well under a second. The seconds pile up later. Broadcast TV runs 3 to 12 seconds behind live. The satellite is not the problem: even 36,000 km up, up and back down takes about a quarter of a second. Playout, compression and the buffer in your box take the rest.

Apps are slower because of chunks. An app stream is cut into segments, usually 2 to 6 seconds long. Apple’s streaming standard, HLS, tells the player not to start closer to live than three segments, because “doing so can trigger playback stalls”. With 6-second segments, that is 18 seconds before anything else is added.

So the delay sits at the end of the drawing, not the start. Low-latency streaming cuts segments into small parts, for example 200 milliseconds each. Apple says that brings delay “into the range of standard television broadcasts”.

The last arrow, out to the apps, was my world at Amazon: I was a streaming manager, including live music streams for Amazon Music.

Every version of that drawing has the same five boxes: capture, edit, check, move, publish. When I started, the boxes were edit suites and tape machines, and many of the arrows were tapes in boxes.

At Lime Pictures I worked on Geordie Shore for MTV, on location in the UK, Mexico and Australia. I also wrote the workflow for The Valleys, another MTV show. I was the DIT: I owned every card from the moment it left the camera to the moment it reached the edit.

There was no tape. Reality TV cannot reshoot, so a card wiped before it was copied meant a scene lost for good. Sony PMW-500 cameras recorded to numbered memory cards, with a small preview copy beside every clip. Each camera had its own letter, so clip names matched the logs and the edit. Every card was copied and logged: reel AD101 meant crew A, day 1, card 01. The footage went onto RAIDs and rugged Thunderbolt drives, and numbered shuttle drives went by courier to the edit in London.

At Sky I was a technical manager, drawing edit workflows for productions. A colleague and I drew the one below.

At Sky Deutschland I built workflows in IBM Aspera Orchestrator, the automation tool on top of Aspera’s fast file transfer.

Normal transfers crawl over long distances. Classic TCP, the protocol under FTP and most of the web, treats every lost packet as a traffic jam and cuts its speed sharply. On a long link the replies take a long time to come back, so it is slow to recover. Take a link where a message takes a tenth of a second there and back, and one packet in a hundred goes missing. One classic TCP transfer then tops out at about 1.4 Mbit/s, however big the pipe. A one-hour master takes about 83 hours. Newer TCP versions do much better, but still struggle to fill a long pipe.

Aspera’s protocol, FASP, runs over UDP. It sends at a steady rate and repairs lost packets on the side, so one loss does not slow the whole transfer. If it fills a 100 Mbit/s link, the same master takes about 71 minutes, not 83 hours.

Speed was half the job. The other half was Orchestrator: workflows built from inputs, actions and outputs. My master workflow queued on-demand files, encrypted them for the streaming service’s copy protection and delivered them. It also spread jobs across the encryption servers, retried failures and reported every file back to the scheduling system. Each box did one job. Arrows carried the file to the next box, with one path for success and another for failure.

That canvas comes back at the end.

Files like those end up in apps, and every app has to pass the check box in the drawing.

Years later I came back to Channel 4, as product owner of its on-demand service, with a team of 12. A product owner decides what gets built next and when it is ready. On a broadcaster’s app, ready means the programme plays on every screen, for every viewer allowed to watch it. BBC iPlayer alone has run on more than 10,000 devices.

Some gates test the app. Others test each programme before it goes live. On a service like this, the gates look like these:

• Devices and copy protection. Smart TVs, set-top boxes, consoles, phones and browsers each play video their own way, and each unlocks protected streams its own way.
• Start time and rebuffering. In one study of 6.7 million viewers, people began to give up after two seconds of waiting. Each extra second raised the share who gave up by about 5.8%.
• Subtitles and audio description. They switch on, stay in sync and stay on from one episode to the next.
• Rights. A programme plays only where and when its rights allow, and comes down when its window expires. Services check where you are from your IP address.
• Ad breaks. Ads land in the break, and each one must report that it played, because billing depends on it.
• Regression and sign-off. Old tests are re-run to prove nothing broke. Then each area owner signs, and the release gets a go or a no-go.
• Platform approval. On smart TVs such as Samsung’s, the maker tests every new version and launches it only when it passes, so a fix takes longer than on a website.

We followed standard practice for a broadcaster’s app: a release that failed a gate did not go out until it passed.

We tracked every release in Jira, which is boxes and arrows too: a status is a box, a transition is an arrow, and a transition can carry a check that stops the ticket moving on.

Nothing shipped until everything passed.

Sky put live 3D football into pubs. It showed Arsenal v Manchester United live in 3D to nine pubs, and more than 1,000 pubs and clubs signed up before the Sky 3D channel launched.

Two eyes had to fit in one normal HD picture. Sky squeezed the left and right images side by side into its existing HD format, and the 3D TV stretched them back out. Each eye got half the detail across.

Comfort is a budget. Sky’s limits kept the two images of most shots no more than 2% of the screen width apart behind the screen, and 1% in front of it.

My part in Sky 3D was the workflow: bringing it all together so the 3D kept people watching without hurting their eyes.

3D still faded. The BBC’s head of 3D said viewers found it “quite hassly”, and LG and Sony stopped making 3D TVs.

My guide covered two ideas:

• Edit while recording. Replay servers record every feed, and an editor can cut a clip while it is still being recorded.
• Edit in HD, finish in 4K. The proxy trick from the Sky edit chain, at Olympic scale.

Today the cameras stay at the ground, and the production and replay teams work from a control room far away. That is remote production. EMG built its Premier League remote centre in about three weeks, and saved an estimated 28,000 to 30,000 miles of crew travel in six weeks. F1 now produces races from its UK centre, with a worst delay of 160 ms from Melbourne. As one report put it, “the track is the remote bit now”.

That works because the cable changed. For most of my career it was SDI, a coax cable. Inside the building, an IP network now carries video, audio and data as separate streams, under SMPTE ST 2110. OBS’s CTO says the cloud has essentially replaced satellite for getting live sport to broadcasters.

The newest boxes in the drawing are AI. At the Paris Games, OBS’s AI made more than 100,000 clips for 14 broadcasters. OBS’s CTO says AI will extend logging to far more feeds, not replace its live loggers. When Red Bee built automatic live subtitles, speech recognition was about 95% accurate against about 99% for people, so people stayed in the loop.

Today I ship whole products with AI, and AI agents are drawn the same way. OpenAI’s Agent Builder is a visual canvas where you drag nodes for agents, tools, guardrails and approvals, and connect them into workflows.

Put it next to my Orchestrator canvas. Inputs on the left. Actions in the middle. Outputs on the right. One branch for when it works, one for when it fails.