Як влаштований стрімінг 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→ruchnoy введення), всі рішення - в журнал.

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 і маржу.