Comment fonctionne le streaming en temps réel des revendeurs en direct

1) Pourquoi la réalité « réelle » est-elle nécessaire ?

Un casino en direct est une connexion de production vidéo et de logique transactionnelle. Toute la valeur est en synchronisme : le joueur voit le revendeur, appuie sur « Parier », le backend fixe la mise jusqu'à « No more bets », et le résultat est calculé de manière transparente. Toute dissynchronisation (retard vidéo, mise « tardive ») est convertie en VOID, litige ou perte de confiance.

2) Circuit du studio au joueur

Studio → Ingest → Orchestra → Livrations → Player

1. Studio : caméras 1080p/60 (ou 4K/60), microphones, lumière, mixeur, keyer overleys (minuteries/indices).

2. Ingest : SDI/NDI → encodeur (h. 264/h. 265, Opus/AAC) → SRT/RTMP à la réception.

3. Processeur : composite overley, enregistrement d'archive, événements CV/RFID, synchronisation par timecode.

4. Transcode : profils sous réseaux/appareils (1080p/720p/480p), GOP 0. 5–1 s

5. Newsletter :

WebRTC est le principal chemin de bas niveau (p95 150-500 ms), LL-HLS/DASH - folback (2-5 s), DataChannel/WebSocket - signaux de paris/minuteries.
6. Lecteur : synchronisé avec le temps serveur (UTC), dessine les minuteries et prend des décisions.

3) Protocoles : Où approprié

WebRTC : le plus rapide pour le navigateur/mobile, UDP, contrôle de congestion, DataChannel bidirectionnel.

SRT : L'ingest résistant du studio (ARQ, cryptage), est bon contre le jitter/perte à la tête.

LL-HLS/DASH : folback de masse/CTV, segments 1-2 s, mises à jour partielles fréquentes ; le retard est plus élevé, mais l'échelle est moins chère.

RTMP : seulement comme « dernier siècle » pour l'interopérabilité (ingest), pas comme livraison client.

4) Synchronisation des tours et des paris

La vérité est l'heure du serveur. Le client est synchronisé périodiquement (pings NTP) et ajuste local-offset.

Cycle de vie :

1. `round. open '- la fenêtre de paris est activée (par exemple, 15 s).

2. `round. close '- le serveur cesse d'accepter les paris, l'IU est bloqué.

3. `round. result 'est le résultat de CV/RFID/opérateur.

4. `round. settle '- paiements/débits dans le portefeuille.

Invariants : serveur dedline « plus dur » client. Si le réseau se couche, il vaut mieux rejeter le pari que d'accepter « après le gong ».

5) Canaux de date et API

Signaux (temps réel) : DataChannel/WebSocket - statuts de bureau, minuteries, confirmations de paris.

Transactions (en espèces) : REST/gRPC avec idempotence (« X-Idempotency-Key ») et signature HMAC.

Télémétrie QoS : RTT, packet loss, bitrate, drapped frames, latency'bet. accept`.

Exemple '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"
}

Exemple de placement de taux (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) Délais et budgets de retard (ciblés)

Click → 'hold'dans le portefeuille : p95 ≤ 150-250 ms.

`round. close '→ stop réception : ≤ 50 ms sur le serveur + verrouillage instantané UI.

result → settle : p95 ≤ 1-2 s (y compris la vérification CV/RFID).

Délai vidéo : WebRTC p95 ≤ 500 ms ; LL-HLS ≤ 5 с.

Signaux : Canal de données p95 ≤ 150 ms dans la région.

7) Mise à l'échelle et architecture edge

Les nœuds Edge-SFU/WebRTC par région (EU/UK/CA/LA/SEA) sont plus proches du joueur.

Géo-routing (Anycast/DNS) et échantillons de santé par QoS (RTT/PLR).

Autoscaling en fonction du nombre d'abonnés, du débit et des signaux de dégradation.

Origin-shield pour LL-HLS (cache de playlists/segments sur le bord).

Pools de profils : réseau (optimisé par UDP), CPU-heavy (transcode), mémoire-heavy (tampon).

8) Traitement du signal vidéo et des overleys

Overley sur le serveur (composite) : correspond toujours à la vidéo, mais plus cher par transcode.

Overlay sur le client (HTML/CSS/Canvas) : moins cher, flexible ; il est critique d'avoir le même serveur time et les mêmes marqueurs d'événements.

Recommandation : les minuteries/ » No more bets » sont comme une overlay sur le client, mais avec une deadline de serveur« rigide »dans le backend.

9) Qualité (QoS) et observabilité

To-SLO : WebRTC RTT, packet loss, bitrate, différence server-client time, rate 'bet. reject`, `VOID/REFUND`.

SLO d'affaires : séance de maintien en poste, rounds abortés, plaintes, RC lobby→game.

Dashboards : trace de bout en bout ('traceId' : lecteur → API → portefeuille → fournisseur → webhook), cartes QoS par géo/opérateurs de télécommunications.

Alert : sursaut de 'VOID', croissance de RTT> 300 ms, loss de packet> 5 %, croissance de 'bet. reject` > 0. 2%.

10) Sécurité et honnêteté

mTLS entre les services/fournisseurs, HMAC sur le Web.

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

Idempotentialité sur 'bet. place ',' payout. ', PSP webhooks.

Honnêteté des rounds : enregistrement d'une vidéo de studio, des étiquettes CV/RFID et des clics de revendeur dans le magasin WORM pour l'audit/controverse.

CSP/Referrer-Policy sur les domaines des joueurs ; jetons d'accès avec TTL court.

11) Travail de CV/RFID et « source de vérité »

RFID : jetons/cellules de roulette/champs de paris.

CV : reconnaissance de cartes/boules, tracking de la main du revendeur.

Elections : si le capteur se dispute avec le CV - une priorité de politique (généralement RFID→CV→ruchnoy entrée), toutes les solutions sont dans le journal.

12) Folbacks et dégradations

WebRTC a dégradé le folback lisse → sur LL-HLS, UI réduit la fenêtre de paris à l'avance (par exemple, de 1-2 s).

CV/RFID ne sont pas disponibles → entrée manuelle du résultat avec double contrôle ; en cas de doute - VOID.

Le nœud Edge est surchargé → rebalance instantanée DNS/Anycast ; hiérarchisation des tables/régions payantes.

13) Conformité et RG

Geo-fencing : disponibilité des tables/fournisseurs par pays.

Les overleys légaux/d'âge en langue locale.

Politiques RG : Conseils doux/temporisation dans les schémas de risque ; limites de taux/sessions.

Isolation PII : le lecteur ne passe pas PII, seulement les alias 'playerId'.

14) DR/HA : sans droit à un « écran noir »

Studio multi-AZ ou site de secours ; doublons d'encodeurs/réseaux.

Double enregistrement des signaux de round (orchestrateur/CV) en stores indépendants.

Plan VOID/REFUND avec modèles de communication et temporisations.

Exercices réguliers : coupure AZ, dégradation du réseau, perte de CV.

15) Anti-modèles

Compter sur le temps client comme la vérité.

Il n'y a pas de folback LL-HLS → « écran noir » pour les problèmes WebRTC.

Mettre l'analyse en streaming dans le portefeuille OLTP → des surtensions de latence et « reject _ rate ».

Manque d'idempotence et HMAC sur l'argent/webhooks.

Échange « silencieux » d'assets/overleys sans version (clients battues).

Limites zéro sur DataChannel/WebSocket (flood/DoS chat).

L'absence d'archives WORM : rien pour prouver l'honnêteté.

16) Chèque de lancement en direct-strim

Studio/ingest

Prises de caméras/encodeurs, UPS ; SRT-ingest avec cryptage.
Calibré CV/RFID, pédale de dealer synchronisée.

Mediastec

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

Synchronisation/gameplay

Server time sur le client, dedline 'round. close 'vérifié.
Les minuteries sont comme une overlay client + stop serveur « dur ».

Finances/sécurité

Idempotence de l'argent/webhooks, HMAC + mTLS, anti-replay.
Journal des rounds et des vidéos dans WORM ; Portefeuille PITR.

Observabilité

QoS-dashboards (RTT/PLR/bitrate), 'bet. reject`, `VOID`, `settle p95`.
Alerte sur la dégradation et la dérive des timings.

DR/Opérations

Studio/canal de secours, scripts folback et VOID/REFUND.
Runbooks, modèles de communication, exercices réguliers.

Le vrai live-stream des dealers est un moteur multimédia et monétaire synchronisé avec précision. WebRTC assure la vitesse, LL-HLS est un folback stable, SRT est un ingest fiable ; Les canaux de données transmettent des signaux critiques et le temps serveur cimente l'honnêteté de la ronde. Ajoutez la télémétrie QoS, l'argent idempotent, la sécurité et le DR - et le joueur verra un jeu naturel, rapide et équitable, et l'opérateur recevra des SLO et des marges prévisibles.