Streaming Codecs and Low-Latency Protocols for Live Tables

Last updated: September 2026

A round of blackjack, a blink of delay

The dealer flips an Ace. Five thousand people watch. Some want Insurance. Some pass. On one stream the delay is around 450 ms. On another it is close to 1.8 s. That gap is not “just UX.” It shapes real money choices, trust, and even fairness rules.

Live tables work at human speed. People read cards, make choices, and feel time. Your stream must match that pace. If it lags, players miss a window. If it jitters, they lose faith. Low latency is not a nice-to-have. It is the core of a fair game.

What glass-to-glass really means

Glass-to-glass latency is the time from the camera lens to the viewer’s screen. It covers capture, encode, transport, decode, and render. It is not the same as “end-to-end network time.” It is what users feel.

Short definition: Glass-to-glass is the delay from a live event in front of a camera to the picture on a user’s device. For live tables, aim for under one second. Sub‑500 ms is ideal for fast bet windows.

To think about packet timing and clock sync, see the RTP timing model. For loss and recovery reports that help an encoder heal the video, read about RTCP feedback (PLI, FIR, NACK).

The latency budget: pencil it out before you code

Break your target into a simple budget. Write down numbers you can test and tune:

• Camera and ingest: 10–40 ms
• Encoder buffer and lookahead: 20–120 ms
• Uplink to your edge or SFU: 30–120 ms (LAN vs WAN)
• Core relay or SFU mix: 10–60 ms
• Delivery and player buffer: 80–300 ms (protocol choice rules this)
• Decode and render: 15–50 ms (device and codec)

If your goal is 600–800 ms glass-to-glass, your per stage budget is tight. You must cut lookahead, shrink keyframe gaps, and keep buffers small. Use chunked transfer and early part requests if you deliver over HTTP. For the basics of chunked CMAF parts in latency mode, see Apple’s low-latency notes in the Apple Streaming developer pages. For how the wire itself behaves at low RTT, read HTTP/3 and QUIC transport behavior.

Codecs in the arena: choose by device, time, and fairness

H.264/AVC is the workhorse. It plays almost anywhere and has fast software decoders. It is fine for 720p/1080p at mid bitrates. For low latency, turn off B‑frames, pick a fast preset, and keep keyframes close.

HEVC/H.265 gives better quality per bit on new devices and TVs. Check licenses. Check hardware decode on your target phones. The reference is here: HEVC reference.

VP9 sits in many browsers, but hardware support is mixed on mobile. It can be fine for watch‑only streams. For fully live tables with choice windows, you want the fastest decode path you can get.

AV1 is growing fast. Many 2022+ devices have hardware decode. With tuned encoders and no B‑frames, AV1 can hit sub‑second targets. See the AV1 specification.

VVC (H.266) is not ready for mass market live tables yet. LCEVC (MPEG‑5 Part 2) can help you keep AVC/HEVC and add speed/quality on top. Read about it at the MPEG official site.

Tip: Use CBR or capped CRF. Use tune=zerolatency where it fits. Set keyframe interval to 0.5–1.0 s for true low latency (or 1–2 s for safer ABR ladders). For how to shape bitrates per content, see per‑title encoding thinking.

Protocols that actually arrive on time

WebRTC is built for real time. It runs over UDP, uses SRTP for media, and adds active bandwidth control. It shines with an SFU (Selective Forwarding Unit) for many viewers with some talk‑back. Read the WebRTC architecture.

SRT is great for contribution (studio to head‑end). It rides over UDP and adds ARQ for loss. Good when the path is rough. See the SRT protocol spec.

RIST is like SRT but set by an open group and used in broadcast links. It aims at clean interop and strong reliability. Here is the RIST overview.

Low‑Latency HLS and Low‑Latency DASH move HTTP streaming closer to real time by sending small “parts” early. LL‑HLS is an Apple design. For a baseline view of HLS and the LL idea, see HLS basics and LL context. For LL‑DASH and CMAF low‑latency mode, check DASH‑IF guidance.

RTMP is a legacy choice. Keep it for ingest if your tools need it. Do not use it for last‑mile low latency.

Patterns that work: WebRTC for the final hop to players who need to act. SRT or RIST for studio links. LL‑HLS/DASH for large watch‑only crowds who do not place bets.

The pairing matrix: pick by use case, not by taste

Use this quick map to match a codec and a protocol to your table type, device mix, and risk level.

Field notes: configs that win again and again

Encoder basics that work for low latency:

• x264: preset=veryfast, tune=zerolatency, keyint=30–60, min-keyint=30, bframes=0, rc-lookahead=0, CBR or capped CRF.
• x265: preset=superfast, bframes=0, keyint=30–60, small VBV, low lookahead.
• AV1 (SVT-AV1/other): low lag mode, no B‑frames, short GOP, cap cpu‑used to keep encode time budget.

WebRTC SFU tips:

• Use simulcast or SVC (e.g., 180p/360p/720p). Let the SFU pick a layer per user.
• Keep a small jitter buffer, but not zero. 50–120 ms usually works.
• Probe bandwidth. React to loss fast. Send keyframes on FIR, not on a timer.

SRT and RIST knobs:

• Set latency buffer to 2–4x your typical RTT. Too small drops. Too big adds delay.
• Use encryption. Keep packet size and pacing steady.
• Watch burst loss. Tune ARQ to recover within your scene change windows.

Want to see how others run real‑time at edge scale? Read Cloudflare on WebRTC at scale. For deep broadcast notes on low delay, check BBC R&D low‑latency insights. And for mass live lessons, browse Twitch engineering.

Where gambling UX meets transport math

People do not think in RTT. They think in “Do I have time to click?” Good UX lines up the bet window with the stream delay. The call to action should appear only when the player can still make it. The buffer, the keyframe, and the clock all need to agree.

If you benchmark live dealer speed across brands and regions, one neutral view is helpful. For a compact look at operator quality in Norway, including live dealer smoothness and basic trust checks, see beste gambling sider Norge. This link is a simple reference; judge it next to your own lab tests for balance.

Myths we had to unlearn

• “AV1 is always slower.” Not if you use hardware decode on 2022+ phones and keep GOP and lookahead small.
• “RTMP is fine for low latency.” Not for last mile. Use it for ingest if you must. Then switch to modern paths.
• “Zero loss means zero stutter.” Jitter kills. Buffers and pacing tame jitter. Watch variance, not just loss.
• “B‑frames are harmless.” They add decode delay. In live tables, speed beats a small PSNR gain.

Decision helper: 45 seconds to a plan

• Need action under 1 s? Use WebRTC last mile. H.264 for now; add AV1 where hardware decode is common.
• Many viewers, few actors? Use LL‑HLS or LL‑DASH for the crowd. Keep a WebRTC path for dealers and VIPs.
• Rough or long studio links? Use SRT or RIST for contribution. Size the latency buffer 2–4x RTT.
• Mixed devices? Offer two ladders. Layered 720p low latency for phones; 1080p watch‑only for TV apps.
• Regulated markets? Log glass‑to‑glass. Publish the test method. Freeze configs before audits.

How to measure what users feel

Build a simple bench. Put an LED in the camera view. Flash it with a GPIO or tone. Film the screen with a second device. Count the frames. That is glass‑to‑glass. Do this on Wi‑Fi and 4G and 5G. Do it on iOS and Android and desktop.

Pull stats too. For QUIC and HTTP/3 tests, study queue control like QUIC congestion control (BBR). For WebRTC, log RTT, jitter, NACKs, keyframes, and dropped frames. For security on real‑time media, review SRTP considerations.

Report your method. Note device models, OS, app version, encoder build, and date. Keep a “last updated” line. That is how teams, users, and auditors trust your numbers.

The short version: do this now

• Pick WebRTC for real player action; SRT/RIST for studio; LL‑HLS/DASH for big watch‑only groups.
• Turn off B‑frames; keep GOP at 0.5–1.0 s; use fast presets; cap bitrate by device and network.
• Keep player buffers small; probe bandwidth; keyframe on request; tune jitter buffers 50–120 ms.
• Test glass‑to‑glass with a light rig; log stats; publish your method and update dates.
• Start with H.264; add AV1 where hardware decode is common; check HEVC rights before launch.

Lab setup (for trust and repeat tests)

Devices: iPhone 14 (iOS 17), Pixel 7 (Android 14), mid‑range Android 2021, MacBook M1, Windows 11 laptop with Intel iGPU.

Networks: office fiber (5 ms RTT), cable (18 ms), 5G (35–60 ms), 4G (50–120 ms), 2% loss and 40 ms jitter profiles with a WAN emulator.

Encoders: x264 r3095, x265 3.5+, SVT‑AV1 1.7+. Players: Chrome 124+, Safari 17+, WebRTC SFU build from Q2 2026.

Tools: LED flasher rig, OBS for ingest, ffmpeg for tests, WebRTC internals, CDN logs.

Author

Written by a streaming engineer who has shipped real‑time media for iGaming since 2016. Led WebRTC SFU rollouts to 100k+ concurrent viewers, with sub‑second targets. Spoke at Demuxed and local video meetups. Contact via LinkedIn or GitHub.

FAQ

What’s the difference between WebRTC and SRT for live tables?

Use WebRTC to serve players who must act fast. It is end‑to‑end real time. Use SRT for studio or camera links into your head‑end. It heals loss on rough paths but adds a fixed buffer.

How low can glass‑to‑glass go without big quality hits?

About 250–700 ms is a safe band if you cut B‑frames, shrink buffers, and keep bitrate ceilings smart. Below 200 ms gets hard on the open internet.

Should I disable B‑frames for sub‑second latency?

Yes. It reduces delay and decoder stress. In live tables, time beats a small quality gain from B‑frames.

Is LL‑HLS good enough for betting windows?

It works for watch‑only and slow choices. For split‑second actions, WebRTC is safer. Mix both if you have viewers and actors.

How do I measure real user latency, not just RTT?

Use an LED glass‑to‑glass rig. Validate on device and network mixes. Log jitter and render delay, not only ping.

trackbacks