"CTO in Focus" Per Mafrost, Vindral
In this CTO in Focus, Per Mafrost, CTO of Vindral, explains what live casino streaming has to get right: predictable latency, synchronised playout, a clear source of truth when computer vision meets a physical wheel, and where studios should build or buy.
In live casino, the video is the product. The wheel, the cards and the dealer are physical, but every player bets against a stream, so latency, synchronisation and the integrity of what each player sees are commercial and compliance questions as much as engineering ones. Those questions get harder as studios add computer vision and digital graphics to physical tables, because the studio then needs a clear answer to which record decides the result.
Vindral, part of Umeå-based RealSprint AB, supplies that layer to studios and operators. Vindral Live handles low-latency, synchronised delivery, and Vindral Composer handles studio production, including V-Track Roulette, the computer vision module RAW iGaming has run in production since summer 2024 and Creedroomz used to launch Inferno Roulette in September 2026. Over the past year Vindral has announced partnerships with Imagine Live, Wildz Group and Amusnet, along with a Green Wheel built on GLI-certified hardware from Gaming Support and validated for its V-Track Money Wheel.
Vindral also works outside gambling. Its technology formed part of Swedish Television's remote production workflow during the Milano Cortina 2026 Winter Games, and in September the National Academy of Television Arts & Sciences named Vindral a recipient of a 2026 Technology & Engineering Emmy® Award for web-based, frame-accurate remote monitoring in distributed broadcast production, with co-recipients including NBCUniversal, Grass Valley, CBS Sports, Disney and Amazon.
Vindral sells the streaming, production and computer vision tools discussed in this interview, so the performance figures Per cites, including latency ranges, synchronisation spreads and deployment data, are his own claims and have not been independently verified.
Gaming Eminence: You built CDNs before leading development at Vindral, which now works across broadcast, sport, racing and live casino. What does a live casino stream have to get right that a broadcast stream does not?
Per Mafrost: "A live casino stream has to fit the timing of the game. The video, the interface and the dealer all need to feel like parts of the same live event.
Broadcast has demanding timing requirements too, especially in remote production. But compared with conventional, one-way television, live casino leaves much less room for the picture to drift away from what the player is doing.
For me, predictability is crucial. A stream that holds 1.5 seconds of delay can be easier to design a game around than one that usually runs at 800 milliseconds but occasionally jumps to three seconds. The average only tells you part of the story.
Viewers also need to stay close to the same point in the action, and the game interface needs to agree with the video. If a blackjack card appears in the interface before the dealer has turned it over on screen, the experience feels wrong even if each component is working correctly on its own. Timed metadata lets us associate those updates with the relevant point in the stream.
That changes how I would evaluate a CDN. Picture quality, capacity and cost still matter, but I also want to know how well it holds its timing through a long session, across different devices and when the network gets difficult."
Gaming Eminence: Latency can be configured anywhere from around 100 milliseconds to several seconds. How should studios decide where to set it for a given game, and what does going lower cost them?
Per Mafrost: "Start with the point at which the player has to act, then work backwards.
The right latency is not automatically the lowest latency. It depends on the game design. In roulette, betting closes before the ball drops, so the player usually has a window of several seconds. In that environment, one to two seconds can work perfectly well. In a game show where the host is reacting to chat or a player needs to make a decision mid-round, every additional 500 ms is much more noticeable. Most of the deployments we see today operate below one second.
The second factor is network quality. Studios should test on the weakest 10% of their real audience, particularly on mobile and in their most difficult markets. A result from office Wi-Fi tells you very little about what happens on a congested connection.
The trade-off is buffer. A larger buffer absorbs more jitter and packet loss, so playback stays stable when the network fluctuates. In our player, that buffer can be configured from roughly 100 ms to five seconds or more. Pushing it down gives you less room to recover, which can mean more stalls or more frequent switches to a lower-quality rendition.
The biggest mistake is treating latency as an isolated technical metric. If your betting window remains 15 seconds, cutting stream latency from two seconds to 500 ms barely changes the game. The real benefit comes when product, game design and streaming are redesigned together around the new number."
Gaming Eminence: When every player sees the same frame at the same moment, what changes for bet acceptance and disputes?
Per Mafrost: "Synchronised playout turns the betting window into one timestamp for everyone, and that has a direct impact on both fairness and operations.
Without synchronisation, different players can be watching the same table at materially different points in time. Standard HLS can introduce 20 to 40 seconds of delay, while even low-latency HLS can leave a spread of around two to eight seconds. An operator then faces an awkward choice: close betting early enough for the slowest viewer, which shortens the experience for everyone else, or leave it open longer and risk faster viewers seeing information that slower viewers have not yet received. That second case is where past-posting risk appears.
With synchronised playout, the aim is to keep players within a very narrow window of one another. In our deployments, that spread can be kept within about 100 ms regardless of device. That means the same betting-close moment applies to a player on fibre in Stockholm and another on 4G in São Paulo.
It also changes how disputes are handled. A common complaint is, "Betting was still open on my screen." If you know that player's latency and game events are tied to frames, you can reconstruct what they actually saw when they clicked. The issue becomes a timestamped record rather than one person's word against another's.
I would encourage operators to measure the spread between their fastest and slowest viewers today. If that spread is larger than the safety margin built into the betting window, synchronisation is not just a video-quality issue. It is already a fairness and risk-management issue."
Gaming Eminence: If V-Track Roulette's reading of the wheel and the physical result ever disagree, which one counts, and how does a studio prove that to a regulator?
Per Mafrost: "The physical result counts. Always.
That principle needs to be decided before computer vision is added to a live table. V-Track Roulette uses a standard studio camera to read the wheel frame by frame, tracking rotation and pocket positions so that digital graphics, such as multipliers, remain aligned with the physical wheel. But that is a presentation layer. Settlement still comes from the studio's certified result system and game server.
If the overlay ever disagreed with the physical result, the graphic would be wrong and the underlying result would stand. The important part is making that hierarchy explicit in the game design and operating procedures.
For a regulator, the audit trail should allow three records to be placed on the same timeline: the recorded studio camera feed with timecode, the game server's result log for the round, and the event log showing what was displayed to players, including any overlays tied to specific frames.
When all three agree, the round is straightforward to verify and close. If they do not, the same records show exactly where the discrepancy occurred and which system was authoritative. Regulators are comfortable with that structure because it is the same one they already accept for physical tables.
The broader lesson for operators is that computer vision should never blur the source of truth. Decide which system governs the outcome first, then design every visual layer and audit record around it. I would go as far as saying that the audit trail should be designed before the graphics. The technology can make a game more engaging, but it should never make the result harder to explain."
Gaming Eminence: You moved early on AV1 and Media over QUIC. What is your test for deciding a new standard is ready for production when downtime costs real revenue?
Per Mafrost: "I use four tests, and a new standard has to pass all of them before I am comfortable putting it into a revenue-critical environment.
First, it has to solve a real problem. AV1 did because it can deliver comparable picture quality at a lower bitrate, which matters when an operator is paying for every gigabyte and a large share of players are on mobile networks. We launched AV1 at ultra-low latency in 2022 with NETINT and Oracle.
Second, there must be a fallback or compatibility path. A new standard should never be a one-way door. If a device, browser or network cannot support it, the session should continue on a proven path.
Third, we test on the devices and networks people actually use. A specification is only the starting point. What matters is how the technology behaves on real phones, browsers and connections in the markets where your customers operate.
Fourth, someone needs to own the complexity when the standard changes. With Media over QUIC, we built the chain end to end, from contribution through distribution to playback, while the specification was still evolving. That meant changes in the standard became our engineering problem rather than the customer's.
A useful proof point came during Milano Cortina 2026, when Swedish Television used Vindral Live with MoQ transport across remote production sites.
For operators, I would use the same checklist when a supplier brings you something new. Ask what problem it solves, what the fallback is, what device data exists from your markets, and who carries the engineering burden when the standard moves. "New" is not a reason to deploy. Resilience is."
Gaming Eminence: Which parts of the live casino stack will studios still build themselves in three years' time, and which will they buy in?
Per Mafrost: "Studios will keep building the parts players can tell apart, and increasingly buy the parts players only notice when they fail.
The game itself will remain a studio competency: format, maths, presenters, set design, brand, game logic and result handling. Those are the things that make one live casino proposition meaningfully different from another, and in many cases they are also the elements the studio certifies and is accountable for.
Delivery is different. Transport, encoding, playback and protection are essential, but they sit on standards and device ecosystems that keep moving. In a relatively short period, the industry has had to absorb AV1 and is now working through Media over QUIC. Keeping pace with that internally can consume a full engineering team, yet the player does not experience it as a feature. They only notice when the stream fails.
Production and graphics sit somewhere in the middle. I expect studios increasingly to buy the underlying engine but own the creative layer. Computer vision illustrates the split well. Reliably tracking a roulette or money wheel from a studio camera takes years of specialist work. Deciding what the multipliers look like, how the round feels and how the experience is branded should remain with the studio. With a green-screen money wheel, for example, one physical asset can support different branded presentations while the studio retains control of the show.
AI tools will follow the same split. Noise cancellation for presenters, for example, is something studios will buy, while the decision about how a host sounds stays with them.
My test is simple: if a player could name the difference, consider building it. If they would only notice it breaking, buy it from someone whose core business is making sure it never does."
Per Mafrost is CTO of Vindral, the Swedish live video company behind Vindral Live and Vindral Composer. He has led product development since 2015, following previous roles as lead architect for several CDNs. Under Per's technical leadership, Vindral adopted AV1 for ultra-low-latency streaming in 2022 and built Media over QUIC end to end while the specification was still evolving. Vindral received a 2026 Technology & Engineering Emmy® Award. Per holds a BSc in Computer Science from Umeå University.
