Как устроен стриминг live-дилеров в реальном времени

1) Зачем нужна «реальная» реальность

Live-казино — это соединение видеопроизводства и транзакционной логики. Вся ценность — в синхронности: игрок видит дилера, нажимает «Поставить», бэкенд фиксирует ставку до «No more bets», и исход рассчитывается прозрачно. Любая рассинхронизация (задержка видео, «поздняя» ставка) конвертируется в VOID, спор или потерю доверия.

2) Контур от студии до игрока

Студия → Ингест → Оркестратор → Доставки → Плеер

1. Студия: камеры 1080p/60 (или 4K/60), микрофоны, свет, микшер, keyer оверлеев (таймеры/подсказки).

2. Ингест: SDI/NDI → энкодер (h.264/h.265, Opus/AAC) → SRT/RTMP на приём.

3. Процессинг: композит оверлеев, запись архива, CV/RFID события, синхронизация по timecode.

4. Транскод: профили под сети/устройства (1080p/720p/480p), GOP 0.5–1 с.

5. Рассылка:

WebRTC — основной низколатентный тракт (p95 150–500 мс), LL-HLS/DASH — фолбэк (2–5 с), DataChannel/WebSocket — сигналы ставок/таймеров.
6. Плеер: синхронизирован с server time (UTC), отрисовывает таймеры и принимает решения.

3) Протоколы: где какой уместен

WebRTC: самый быстрый до браузера/мобилы, UDP, congestion control, двунаправленный DataChannel.

SRT: устойчивый ингест из студии (ARQ, шифрование), хорош против джиттера/потерь до head-end.

LL-HLS/DASH: массовый фолбэк/CTV, сегменты 1–2 с, частые partial-updates; задержка выше, но масштаб дешевле.

RTMP: только как «прошлый век» для совместимости (ингест), не как клиентская доставка.

4) Синхронизация раундов и ставок

Истина — серверное время. Клиент периодически синхронизируется (NTP-подобные пинги) и корректирует local-offset.

Жизненный цикл:

1. `round.open` — окно ставок активировано (напр. 15 с).

2. `round.close` — сервер перестаёт принимать ставки, UI блокируется.

3. `round.result` — результат от CV/RFID/оператора.

4. `round.settle` — выплаты/списания в кошельке.

Инварианты: серверный дедлайн «жёстче» клиентского. Если сеть лагает — лучше отклонить ставку, чем принять «после гонга».

5) Дата-каналы и API

Сигналы (реал-тайм): DataChannel/WebSocket — статусы столов, таймеры, подтверждения ставок.

Транзакции (денежные): REST/gRPC с идемпотентностью (`X-Idempotency-Key`) и HMAC-подписью.

Телеметрия QoS: RTT, packet loss, bitrate, dropped frames, latency `bet.accept`.

Пример `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"
}

Пример размещения ставки (идемпотентно):

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) Тайминги и бюджеты задержек (целевые)

Клик → `hold` в кошельке: p95 ≤ 150–250 мс.

`round.close` → стоп приёма: ≤ 50 мс на сервере + мгновенная блокировка UI.

`result` → `settle`: p95 ≤ 1–2 с (включая проверку CV/RFID).

Видео-задержка: WebRTC p95 ≤ 500 мс; LL-HLS ≤ 5 с.

Сигналы: дата-канал p95 ≤ 150 мс в регионе.

7) Масштабирование и edge-архитектура

Edge-SFU/WebRTC узлы по регионам (EU/UK/CA/LA/SEA) — ближе к игроку.

Geo-routing (Anycast/DNS) и health-пробы по QoS (RTT/PLR).

Autoscaling по количеству подписчиков, битрейту и сигналам деградации.

Origin-shield для LL-HLS (кэш плейлистов/сегментов на краю).

Пулы профилей: сетевые (UDP-оптимизированные), CPU-heavy (транскод), memory-heavy (буферизация).

8) Обработка видеосигнала и оверлеев

Оверлей на сервере (композит): всегда совпадёт с видео, но дороже по транскоду.

Оверлей на клиенте (HTML/CSS/Canvas): дешевле, гибко; критично иметь тот же server time и маркеры событий.

Рекомендация: таймеры/«No more bets» — как оверлей на клиенте, но с «жёстким» серверным дедлайном в бэкенде.

9) Качество (QoS) и наблюдаемость

Тех-SLO: WebRTC RTT, packet loss, bitrate, разница server-client time, rate `bet.reject`, `VOID/REFUND`.

Бизнес-SLO: удержание сессии, aborted rounds, жалобы, CR lobby→game.

Дашборды: end-to-end trace (`traceId`: плеер → API → кошелёк → провайдер → вебхук), карты QoS по гео/операторам связи.

Алерты: всплеск `VOID`, рост RTT > 300 мс, packet loss > 5%, рост `bet.reject` > 0.2%.

10) Безопасность и честность

mTLS между сервисами/провайдерами, HMAC на вебхуках.

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

Идемпотентность на `bet.place`, `payout.`, вебхуках PSP.

Честность раундов: запись студийного видео, меток CV/RFID и нажатий дилера в WORM-хранилище для аудита/споров.

CSP/Referrer-Policy на плеерных доменах; токены доступа с коротким TTL.

11) Работа CV/RFID и «источник истины»

RFID: фишки/ячейки рулетки/поля ставок.

CV: распознавание карт/шаров, трекинг руки дилера.

Elections: если датчик спорит с CV — приоритет по политике (обычно RFID→CV→ручной ввод), все решения — в журнал.

12) Фолбэки и деградации

WebRTC деградировал → плавный фолбэк на LL-HLS, UI заранее уменьшает окно ставок (напр., на 1–2 с).

CV/RFID недоступны → ручной ввод исхода с двойной проверкой; при сомнении — VOID.

Edge узел перегружен → мгновенный ребаланс по DNS/Anycast; приоритизация платных столов/регионов.

13) Комплаенс и RG

Geo-fencing: доступность столов/провайдеров по стране.

Юридические/возрастные оверлеи на языке локали.

RG-политики: мягкие подсказки/тайм-ауты при риск-паттернах; лимиты ставок/сессий.

PII-изоляция: плеер не передаёт PII, только псевдонимы `playerId`.

14) DR/HA: без права на «чёрный экран»

Multi-AZ студии или резервная площадка; дубли энкодеров/сетей.

Двойная запись сигналов раунда (оркестратор/CV) в независимые сторажи.

План VOID/REFUND с шаблонами коммуникаций и таймингами.

Регулярные учения: отключение AZ, деградация сети, потеря CV.

15) Анти-паттерны

Полагаться на client time как на истину.

Нет LL-HLS фолбэка → «чёрный экран» при проблемах WebRTC.

Класть потоковую аналитику в OLTP кошелька → всплески латентности и `reject_rate`.

Отсутствие идемпотентности и HMAC на деньгах/вебхуках.

«Тихая» подмена ассетов/оверлеев без версияции (битые клиенты).

Нулевые лимиты на DataChannel/WebSocket (флуд/DoS чатами).

Отсутствие WORM-архива: нечем доказывать честность.

16) Чек-лист запуска live-стрима

Студия/ингест

Дубли камер/энкодеров, UPS; SRT-ингест с шифрованием.
Калиброваны CV/RFID, педаль дилера синхронизирована.

Медиастек

WebRTC p95 ≤ 500 мс, LL-HLS настроен (сегмент ≤ 2 c, preload hints).
Профили 1080/720/480, GOP ≤ 1 c, аудио Opus/AAC.

Синхронизация/геймплей

Server time на клиенте, дедлайны `round.close` проверены.
Таймеры — как оверлей клиента + «жёсткий» серверный стоп.

Финансы/безопасность

Идемпотентность денег/вебхуков, HMAC+mTLS, anti-replay.
Журнал раундов и видео в WORM; PITR кошелька.

Наблюдаемость

QoS-дашборды (RTT/PLR/bitrate), `bet.reject`, `VOID`, `settle p95`.
Алерты на деградацию и дрифт таймингов.

DR/Операции

Резервная студия/канал, сценарии фолбэка и VOID/REFUND.
Runbooks, шаблоны коммуникаций, регулярные учения.

Реальный live-стрим дилеров — это точно синхронизированная медиапайплайн и денежный движок. WebRTC обеспечивает скорость, LL-HLS — устойчивый фолбэк, SRT — надёжный ингест; дата-каналы передают критичные сигналы, а серверное время цементирует честность раунда. Добавьте телеметрию QoS, идемпотентные деньги, безопасность и DR — и игрок увидит естественную, быструю и справедливую игру, а оператор получит предсказуемые SLO и маржу.