How Live Dealers Live Streaming Works

1) Why "real" reality is needed

A live casino is a combination of video production and transactional logic. All value lies in synchronicity: the player sees the dealer, clicks "Put," the backend fixes the bet to "No more bets," and the outcome is calculated transparently. Any misalignment (video delay, "late" bet) is converted to VOID, dispute or loss of trust.

2) Contour from studio to player

Studio → Ingest → Orchestrator → Delivery → Player

1. Studio: 1080p/60 (or 4K/60) cameras, microphones, lights, mixer, overlay keyer (timers/prompts).

2. Ingest: SDI/NDI → encoder (h. 264/h. 265, Opus/AAC) → SRT/RTMP for reception.

3. Processing: overlay composite, archive recording, CV/RFID events, timecode synchronization.

4. Transcode: profiles for networks/devices (1080p/720p/480p), GOP 0. 5-1 s.

5. Distribution:

WebRTC - the main low-patent path (p95 150-500 ms), LL-HLS/DASH - folback (2-5 s), DataChannel/WebSocket - bet/timer signals.
6. Player: synchronized with server time (UTC), draws timers and makes decisions.

3) Protocols: where which is appropriate

WebRTC: fastest to browser/mobile, UDP, congestion control, bidirectional DataChannel.

SRT: stable ingest from the studio (ARQ, encryption), good against jitter/loss before head-end.

LL-HLS/DASH: mass folback/CTV, segments 1-2 s, frequent partial-updates; the delay is higher, but the scale is cheaper.

RTMP: only as "last century" for compatibility (ingest), not as client delivery.

4) Synchronizing rounds and bets

True is server time. The client periodically synchronizes (NTP-like pings) and adjusts local-offset.

Lifecycle:

1. `round. open '- the betting window is activated (e.g. 15 s).

2. `round. close '- the server stops accepting bets, the UI is blocked.

3. `round. result '- result from CV/RFID/operator.

4. `round. settle '- payments/write-offs in the wallet.

Invariants: the server deadline is "tougher" than the client one. If the network lags, it is better to reject the bet than to accept "after the gong."

5) Data channels and APIs

Signals (real-time): DataChannel/WebSocket - table statuses, timers, bet confirmations.

Transactions (monetary): REST/gRPC with idempotency ('X-Idempotency-Key') and HMAC signature.

QoS telemetry: RTT, packet loss, bitrate, dropped frames, latency'bet. accept`.

Example'round. close`:

json
{
"event": "round. close",  "tableId": "evo_blackjack_23",  "roundId": "R-2025-10-17T14:23:10Z-evo-23",  "ts": "2025-10-17T14:23:12. 000Z",  "serverTime": "2025-10-17T14:23:12. 000Z"
}

Example of placing a bet (idempotent):

http
POST /live/bet/place
X-Idempotency-Key: 9a7f-2b1c
Content-Type: application/json
{
"playerId":"p_123",  "tableId":"evo_blackjack_23",  "roundId":"R-2025-10-17T14:23:10Z-evo-23",  "selections":[{"market":"player","amount":"10. 00"}],  "currency":"EUR"
}

6) Timings and delay budgets (targeted)

Click → 'hold' in wallet: p95 ≤ 150-250 ms.

`round. close '→ stop receiving: ≤ 50 ms on the server + instant UI blocking.

'result '→ 'settle': p95 ≤ 1-2 seconds (including CV/RFID checking).

Video delay: WebRTC p95 ≤ 500 ms; LL-HLS ≤ 5 с.

Signals: data channel p95 ≤ 150 ms in the region.

7) Scaling and edge architecture

Edge-SFU/WebRTC nodes by region (EU/UK/CA/LA/SEA) - closer to the player.

Geo-routing (Anycast/DNS) and QoS health samples (RTT/PLR).

Autoscaling by number of subscribers, bitrate and degradation signals.

Origin-shield for LL-HLS (Edge Playlist/Segment Cache).

Profile pools: network (UDP-optimized), CPU-heavy (transcode), memory-heavy (buffering).

8) Video and overlay processing

Overlay on the server (composite): always matches the video, but more expensive in transcode.

Overlay on the client (HTML/CSS/Canvas): cheaper, flexible; it is critical to have the same server time and event markers.

Recommendation: timers/" No more bets" - as an overlay on the client, but with a" hard "server deadline in the backend.

9) Quality (QoS) and observability

Tech-SLO: WebRTC RTT, packet loss, bitrate, server-client time difference, rate'bet. reject`, `VOID/REFUND`.

Business SLO: session hold, aborted rounds, complaints, CR lobby→game.

Dashboards: end-to-end trace ('traceId': player → API → wallet → provider → webhook), QoS cards for geo/telecom operators.

Alerts: surge 'VOID', RTT growth> 300 ms, packet loss> 5%, growth 'bet. reject` > 0. 2%.

10) Safety and integrity

mTLS between services/providers, HMAC on webhooks.

Anti-replay: `X-Request-Timestamp/Nonce`, окно ±300 с.

Idempotence on 'bet. place ',' payout. ', webhooks PSP.

Round integrity: Recording studio video, CV/RFID tags and dealer clicks in WORM repository for audit/disputes.

CSP/Referrer-Policy on player domains; access tokens with short TTL.

11) The work of CV/RFID and the "source of truth"

RFID: chips/roulette cells/bet fields.

CV: card/ball recognition, dealer hand tracking.

Elections: if the sensor argues with CV - priority by policy (usually RFID→CV→ruchnoy input), all decisions - in the log.

12) Folbacks and degradation

WebRTC degraded → smooth folback on LL-HLS, UI reduces the betting window in advance (e.g. by 1-2 s).

CV/RFID not available → manual entry of double-checked outcome; in doubt - VOID.

Edge node overloaded → instant DNS/Anycast rebalance; prioritization of paid tables/regions.

13) Compliance and RG

Geo-fencing: Table/provider availability by country.

Legal/age overlays in the Locali language.

RG policies: soft prompts/timeouts on risk patterns; rate/session limits.

PII isolation: the player does not transmit PII, only the aliases' playerId '.

14) DR/HA: no right to "black screen"

Multi-AZ studios or backup site; encoder/network duplicates.

Double recording of round signals (orchestrator/CV) into independent storages.

VOID/REFUND plan with communication templates and timings.

Regular exercises: AZ shutdown, network degradation, CV loss.

15) Anti-patterns

Rely on client time as truth.

There is no LL-HLS folback → black screen for WebRTC problems.

Put stream analytics in the OLTP wallet → latency spikes and 'reject _ rate'.

Lack of idempotency and HMAC on money/webhooks.

"Quiet" substitution of assets/overlays without version (broken clients).

Zero limits on DataChannel/WebSocket (flood/DoS chats).

Lack of WORM archive: there is nothing to prove honesty.

16) Live Stream Launch Checklist

Studio/ingest

Camera/encoder duplicates, UPS; SRT-ingest with encryption.
CV/RFID calibrated, dealer pedal synchronized.

Media stack

WebRTC p95 ≤ 500ms, LL-HLS configured (segment ≤ 2s, preload hints).
1080/720/480 profiles, GOP ≤ 1c, Opus/AAC audio.

Sync/Gameplay

Server time on the client, deadlines'round. close 'checked.
Timers - like an overlay of a client + a "hard" server stop.

Finance/Security

Money/webhook idempotency, HMAC + mTLS, anti-replay.
Rounds and video log in WORM; Purse PITR.

Observability

QoS dashboards (RTT/PLR/bitrate), 'bet. reject`, `VOID`, `settle p95`.
Degradation alerts and timing drift.

DR/Operations

Backup Studio/Channel, Folback Scripts and VOID/REFUND.
Runbooks, communication templates, regular exercises.

The real live stream of dealers is an accurately synchronized media pipeline and money engine. WebRTC provides speed, LL-HLS - stable folback, SRT - reliable ingest; data channels transmit critical signals, and server time cements the honesty of the round. Add QoS telemetry, idempotent money, security and DR - and the player will see a natural, fast and fair game, and the operator will receive predictable SLOs and margins.