By Staff, Onkaji Scout News Equipment Streaming

How does live casino streaming work? Latency by protocol

Live casino streaming from encoder to screen: ingest, delivery protocols and the latency figures streaming vendors publish for each, side by side.

How does live casino streaming work? Latency by protocol

Live casino streaming works as a relay. Cameras and a game control unit capture the table, an encoder compresses the video, an ingest protocol such as RTMP, SRT or WHIP carries it to a media server, and a delivery protocol (WebRTC, HLS, DASH or Media over QUIC) sends it to each player, with the game data aligned alongside.

This is an evergreen explainer of the delivery chain, from the encoder onward. The capture end, where the table result becomes data, is covered in what a game control unit is and how OCR works in live casino. On 18 October 2026 this desk read nanocosmos’s protocol comparison, the live casino pages of Red5 and Vindral, the Amazon IVS betting and gaming page, and the IETF’s record for the Media over QUIC transport draft. Every latency number below is the vendor’s own published statement, not a measurement by this desk.

How does live casino streaming work, step by step?

The chain has five links, and each one adds some delay.

Capture. Cameras film the dealer and the table, and a game control unit or recognition software turns the result into data. This is the part the sibling posts trace.

Encode. The camera feed is compressed into a codec. Red5’s live casino page lists H.264, H.265 (HEVC) and AV1 among the codecs it supports, and pitches H.265 as the way to keep quality up on poor networks.

Ingest. The encoded stream is pushed from the studio to a media server or cloud service. nanocosmos calls RTMP the industry-standard ingest protocol. It says browsers and players no longer accept RTMP for playback, but it remains valid for getting video into the system. Amazon IVS lists WebRTC, WHIP and RTMP as the ways into its Real-time tier, and RTMP and SRT for its Low-latency tier.

Deliver. The server sends the stream out to players. This is where the protocol choice happens, and where most of the latency difference lies. It is the subject of the table below.

Play. The player’s browser or app decodes the stream and shows it, with the betting interface drawn on top.

What protocols do live casinos use to stream?

No page this desk read names the delivery protocol any particular live casino supplier uses, so this section describes the options vendors sell to the sector rather than what any studio runs.

HLS and MPEG-DASH cut the stream into short files that are fetched over ordinary HTTP. nanocosmos describes them as cacheable segment-based protocols that scale across a content delivery network (CDN) to millions of viewers. The cost is delay: its table gives 6 to 60 seconds, and 6 seconds only when tuned for reduced latency.

WebRTC was built for video calls. nanocosmos says it typically delivers under 500 milliseconds, but only when WebRTC runs end to end. As a peer-to-peer technology, it says, WebRTC was not designed to scale beyond 50 concurrent connections. Broadcasting it to a large audience needs extra infrastructure, and then latency “can range anywhere from 0.5 to 60 seconds”, per the same page.

Media over QUIC (MoQ) is the newest route. It runs over QUIC and WebTransport. nanocosmos describes MoQ as matching WebRTC’s sub-second latency while scaling to hundreds of thousands of viewers. The IETF Datatracker lists the transport specification as draft-ietf-moq-transport-22, an Active Internet-Draft of the moq working group, last updated 1 October 2026. It is a draft and not a finished standard. nanocosmos also states that MoQ is supported across browsers except Safari on iOS, which it says “will be available later in 2026”. That is a forward statement, not a shipped feature.

Vendors’ own stacks wrap these protocols. nanocosmos sells H5Live, which it describes as a hybrid of WebSockets, low-latency HLS, WebRTC and WebTransport. Red5 says its live casino product uses WebRTC. Amazon IVS sells two tiers, described below.

Live casino streaming latency, by protocol and vendor

This is the comparison the player-facing explainers this desk read leave out. Each row is what the named vendor publishes, read on 18 October 2026.

Delivery routeStated latencyStated scaleSource
HLS / MPEG-DASH6-60 s; 6 s only when tunedUp to millions, via CDNnanocosmos
RTMP / RTSP5 s or lessNo longer accepted by browsers; used for ingestnanocosmos
WebRTC, end to endSub-500 msNot designed past 50 connectionsnanocosmos
WebRTC at broadcast scale0.5-60 sNeeds added infrastructurenanocosmos
H5Live / MOQSub-second end to endHundreds of thousands (100,000+)nanocosmos
Red5 WebRTC, live casino“Guaranteed” sub-250 ms“Thousands of concurrent tables”; no viewer figureRed5
Amazon IVS Real-timeLower than 300 msBeyond 25K viewers; up to 12 hosts; 720p inputAmazon IVS
Amazon IVS Low-latency2-5 s out of the boxBeyond 1M+ viewers; 1080p inputAmazon IVS
Vindral LiveNo figure in the text readOne table serving many operatorsVindral

Three cautions. First, the vendors disagree about the baseline. Red5 says “traditional streaming solutions” can introduce 2-3 seconds of delay, while nanocosmos puts HLS and DASH at 6-60 seconds. Those are different claims about different set-ups, and they should not be averaged. Second, Amazon IVS’s page describes its Low-latency tier both as “out-of-the-box 2-5s” and as latency that “can be under 3 seconds”, so the table gives the range. Third, every figure is a marketing statement about the vendor’s own product. Red5’s “guaranteed” is Red5’s word.

Why does live casino need sub-second latency?

The table shows a trade-off. The cheapest way to reach a very large audience is segment-based HTTP over a CDN, and it is also the slowest. The fastest route, WebRTC, was never designed for large audiences. Every vendor in the table is selling a way to get closer to both at once, and the figures they choose to publish show where each one has landed.

Live casino sits at the low-latency end for two reasons in the vendors’ own wording. Vindral’s live casino page says the vertical “places stricter demands on video and infrastructure than most other live use cases”. It lists short decision windows with minimal delay, and the requirement that “all players see the same thing at the same time”. The betting window is the first constraint. A player has to see the round in time to bet before the window closes, and a delay of several seconds eats into that window.

The second constraint is synchronisation. Vindral also lists multi-brand studios where one table serves many operators. A single dealer may be streamed to players on several operators’ sites. If those players received the picture at different delays, some would see the outcome before others. Red5 makes the same point in its own terms, describing sub-250ms latency as essential “for fair betting”.

Scale pulls the other way. Amazon IVS’s two tiers make the trade explicit. Its Real-time tier is pitched at “highly-engaging real-time iCasino experiences”, with latency under 300 ms but a stated scale of beyond 25,000 concurrent viewers. Its Low-latency tier scales beyond 1 million concurrent viewers at 2-5 seconds, and IVS pitches it at sports betting, where timed metadata keeps bets in step with the action. Amazon says IVS uses the same technology that powers Twitch.

Why do some streams lag more than others?

Latency is not the only property in play. nanocosmos makes a point about quality in one-to-many WebRTC: because the protocol adjusts the stream to the network conditions of sender and receiver, the viewer with the worst network condition determines the quality. That is one reason vendors put a CDN with adaptive bitrate (ABR) delivery behind their low-latency routes. nanocosmos says its own nanoStream CDN supports ABR, so each player can receive a version of the stream suited to their connection.

Device support matters as well. nanocosmos’s table says iOS and Apple TV support only HLS natively, not DASH, while Chrome, Firefox and Safari support WebRTC without plugins. A studio that wants to reach every phone has to account for what each browser will play, which helps explain why vendors sell hybrid players rather than a single protocol.

Cost is the third axis. Red5’s live casino page contrasts its deployment options with “per-user pricing models that become prohibitive at scale”, and says operators can run it on premises, in the cloud or in hybrid set-ups. Amazon IVS publishes a cost estimator alongside its tiers. Neither page read gives a price for streaming a live casino table, so the cost side of the trade cannot be put into numbers here.

Vindral adds the operating constraints: 24/7 production with “extremely limited tolerance for downtime”, and consistent quality in markets with weaker or unstable networks.

Is live casino streaming really live?

Live, yes; instant, no. Every link in the chain takes time, and the only question is how much. On the vendors’ own numbers, the gap between the dealer’s hand and the player’s screen can be under a quarter of a second or a minute, depending on the route. The nanocosmos comparison lists betting and gambling among the use cases where that gap matters. None of the five sources read says what latency any named live casino supplier achieves in production.

How does the game data reach the screen with the video?

The picture is only half the stream. The result data from the capture end has to arrive in step with the video, or the screen shows a card the game has not yet recorded. Amazon IVS’s featured demo is a live blackjack table on its Real-time tier, in which “card and player events are delivered as SEI data”. SEI is supplementary information carried inside the video stream itself, and the demo offers multiple camera angles. Vindral lists “tight alignment between video, data, overlays and game events” among live casino’s demands. Red5’s page names a multi-view feature for managing more than one camera feed.

Kit at the studio end is covered in what equipment a live casino studio needs.

FAQ

Are live casino streams really live or slightly delayed?

Every stream carries some delay; the question is how much. Vendors’ own figures run from under 250 milliseconds, Red5’s claim for its live casino product, to the 6-60 seconds nanocosmos gives for HLS and MPEG-DASH. Which a given studio runs is not stated on any page this desk read.

Why do live casino games sometimes lag or buffer?

The pages read point to the network. nanocosmos says that in one-to-many WebRTC the viewer with the worst connection sets the quality, and that its CDN uses adaptive bitrate delivery. Vindral lists consistent quality on weaker or unstable networks among live casino’s demands rather than as a given.

How do player bets connect to the dealer in real time?

The game data rides with the video and must stay aligned to it. Amazon IVS’s blackjack demo sends card and player events as SEI data with the video, and Vindral names tight alignment of video, data, overlays and game events as a requirement. None of the pages read describes the bet’s return path.

Industry coverage for an adult, 18+ readership: Onkaji Scout offers no gambling services and does not say where to play.