The category Vindral was recognised in at the 2026 Technology & Engineering Emmy® Awards is called Web-Based Frame-Accurate Remote Monitoring Systems for Distributed Broadcast Production. It is a long name for a short idea, and the word carrying the weight is frame-accurate. Getting live video into a browser quickly has been possible for years. Getting every browser to agree on which frame counts as now is the part that took the work.
The other recipients in the category are SipRadius, NBCU, Grass Valley, CBS Sports, Disney, Game Creek and Amazon.
Two numbers
Two numbers matter in remote production. The first is how far behind live the video is. The second is how far apart two screens are.
The second number gets less attention. Consider two operators on the same production, one running 200 ms behind live and the other 1.1 seconds behind. The gap between them is a separate problem: neither operator can reliably talk to the other about what just happened on screen, because they are looking at different moments.
Frame-accurate remote monitoring means everyone in a distributed production sees the same frame at the same time, wherever they are, in an ordinary browser. A director in one city and an engineer in another can then treat that browser as a production monitor rather than a rough preview.
The same requirement exists on the audience side, which is where our work on it started. If thousands of people are watching the same event, one viewer should never be several seconds ahead of another. At a venue, where people can see the action in front of them and a large screen a few metres away, even a small offset becomes impossible to ignore.
How each one fails
An operator adjusting a camera or changing colour settings from another location needs to see the result practically immediately. If the return video is two or three seconds behind, you turn a control, wait, see what happened, correct it, and wait again. Simple adjustments become slow and frustrating. Bring the latency down far enough and it feels like operating equipment in the room.
Synchronisation fails differently. Picture an online auction where one bidder sees the current bid a second before another. Both streams are individually low latency, and the auction is still unfair. In multi-camera production, feeds sitting at different points in time mean a camera switch can jump backwards or forwards in the event.
The buffer trade-off
Low latency and stability pull in opposite directions.
The straightforward way to make internet video stable is to buffer more of it. If packets arrive late, or the network has a bad moment, there is spare video waiting. Every millisecond held in that buffer is a millisecond of latency. Remote production asks for close to the opposite: keep the buffer very small, and survive jitter, packet loss, bandwidth changes, browser scheduling, decoder behaviour and differences between devices anyway.
Then comes synchronisation, the second half of the problem. The system has to work out continuously how far each player has drifted from the live timeline and correct it in small steps, without the operator ever seeing a pause, a jump or an artefact.
Latency on our platform is configured per use case and per network:
- around 100 to 150 ms for contribution and monitoring on the controlled networks used in remote production
- around a second glass to glass for typical viewer-side delivery over the public internet
- several seconds where a stream has to stay in step with a slower path, such as a satellite feed
The range exists because the same trade-off gets settled differently in different places. Hostile public networks need more buffer to absorb variation. Controlled networks do not.
RTMP to MoQ
The work is keeping a few hundred milliseconds stable for hours in a real environment, while networks jitter, bandwidth shifts, browsers behave differently and machines occasionally stall.
We have rebuilt parts of the transport and playback stack several times as the web changed underneath it:
Each generation solved something and exposed something new. The requirement stayed the same throughout: carry live media fast enough for interactive use, and keep control over timing and playback while doing it.
MoQ is the most recent chapter of that work and builds on the same foundations. Today it is the default transport, with a WebSocket fallback.
What the browser changed
Before frame-accurate monitoring in a browser existed, a distributed production had two options, each with its trade-offs.
The traditional broadcast approach brings the production team together around dedicated infrastructure: OB trucks, control rooms, SDI and baseband video, specialist monitoring hardware and managed contribution networks. It works well. It is also expensive, hardware-heavy and tied to a place.
The cheap internet approach sends people streams over consumer streaming or video conferencing tools. It is accessible and easy to set up, and it gives up predictable latency, synchronisation, quality or reliability, often several at once. Different people see different points in time, and nobody can tell by how much.
What changed is that the second approach started behaving like the first. If a producer can open a URL on a laptop instead of having a rack of equipment installed at their location, you have changed where a television production can happen and what it costs to set one up.
The pandemic pushed a problem we were already working on to the front. Our starting point was betting and other interactive live video, where a viewer being two seconds behind another viewer has consequences. The pandemic made the browser something a production had to be able to trust. NATAS describes the recognised work as technology developed during the pandemic “to enable high-quality, real-time production from remote locations”, evolving through early 2024. That matches how it felt from the inside.
ATG, SailGP and SVT
The technology runs in many places now. Three deployments mark how it got here.
ATG, the Swedish horse racing operator, was our first commercial customer in 2015. Racing viewers are bettors. They need to be as close to live as possible, and all at the same point in the race.
SailGP was our first multiview customer, from 2021, and remains one of the larger deployments. By the 2024 New York Sail Grand Prix that meant 28 synchronised feeds, covering the onboard cameras on every boat plus the helicopter and the world feed, with viewers switching between them without drift. The SailGP production team runs its own multiview on the same feeds.
SVT is the newest of the three. The award covers work done up to early 2024, and the SVT deployment shows what that work is used for now. For the 2026 Winter Games, SVT produced ten additional live productions from a datacentre in Stockholm, alongside its main broadcast, with no specialist engineering presence on the ground in Italy:
- venue signals travelled roughly 1,800 km over SRT, from Italy to Stockholm
- production staff monitored the feeds in a browser-based multiviewer instead of dedicated hardware
- broadcast output was 1080p50 at 25 Mbit/s, on primary and backup paths
- each output carried 16 audio channels
SVT’s Games coverage reached 7.4 million viewers in Sweden, its largest Olympic audience since 2012.
If you are working on remote production, multiview monitoring or anything where different screens have to show the same moment, we are happy to talk about how Vindral Live handles it in browser-based multiviewers and contribution feeds, and where the limits are.
Per Mafrost, CTO at Vindral