SRT і WebRTC на своєму сервері: стрімінг з низькою затримкою

Значення низької затримки: від RTMP до WebRTC на VPS

Щоб налаштувати стрімінг з низькою затримкою (сотні мілісекунд для SRT та частки секунди для WebRTC) на власному сервері, потрібен VPS з мінімум 2 vCPU, 4 GB RAM, встановленим програмним забезпеченням (наприклад, SRS або MediaMTX) та відкритими UDP-портами для стабільної роботи протоколів. У сучасному світі, де інтерактивність та миттєвий зворотний зв'язок стали нормою, традиційні протоколи доставки відео, такі як RTMP, часто не справляються зі зростаючими вимогами до мінімальної затримки. Розуміння відмінностей між RTMP, SRT та WebRTC, а також їх правильне налаштування на власному сервері, стає критично важливим для створення високоефективних стрімінгових рішень.

Еволюція протоколів: RTMP, SRT, WebRTC

Історія протоколів для стрімінгу відео — це шлях від максимальної сумісності до мінімальної затримки. * **RTMP (Real-Time Messaging Protocol):** Розроблений Adobe, RTMP довгий час був стандартом де-факто для доставки відеоконтенту. Він використовує TCP, що забезпечує надійну, але не завжди швидку доставку. Типова затримка для RTMP становить **2-10 секунд**, що прийнятна для традиційного мовлення, але абсолютно неприйнятна для інтерактивних сценаріїв, таких як онлайн-конференції або кіберспорт. Його простота та широка підтримка зробили його популярним для надсилання потоків на такі платформи, як YouTube або Twitch. Проте, через високу затримку та проблеми з продуктивністю через HTTP/HTTPS, багато браузерів припинили його підтримку, і він поступово поступається місцем більш сучасним рішенням. * **SRT (Secure Reliable Transport):** Цей протокол, розроблений Haivision, становить значний крок уперед у сфері стрімінгу з низькою затримкою. SRT побудований на базі UDP, але додає рівень надійності, схожий на TCP. Він включає механізми корекції помилок (ARQ - Automatic Repeat Request) та адаптивне регулювання бітрейту, що дозволяє йому ефективно працювати в нестабільних мережах, відновлюючи втрачені пакети та мінімізуючи затримку. SRT здатний забезпечити затримку в діапазоні **сотень мілісекунд (200-800 мс)**, роблячи його ідеальним для прямого ефіру, спортивних трансляцій та інших сценаріїв, де критична швидкість доставки, але потрібна висока надійність. SRT також підтримує шифрування, що додає безпеки. * **WebRTC (Web Real-Time Communication):** Це відкритий стандарт, розроблений Google, який дозволяє браузерам та мобільним застосункам здійснювати передачу аудіо, відео та даних у реальному часі без встановлення додаткових плагінів. WebRTC також використовує UDP для основної передачі даних, але орієнтований на максимально можливу низьку затримку — **частки секунди (50-300 мс)**. Його ключова особливість — це P2P (peer-to-peer) архітектура, коли це можливо, або використання SFU/MCU серверів для багатьох учасників. WebRTC ідеально підходить для відеоконференцій, онлайн-ігор, інтерактивних вебінарів та відеоспостереження, де кожна мілісекунда має значення.

Чим ми платимо за низьку затримку?

Перехід до протоколів з низькою затримкою не є безкоштовним і вимагає певних компромісів: * **Складність налаштування:** SRT та WebRTC вимагають складнішого налаштування сервера, роботи з UDP-портами, NAT та файрволами порівняно з RTMP. * **Вимоги до сервера:** Для WebRTC, особливо при великій кількості одночасних глядачів, потрібні значно потужніші процесори (CPU) для транскодування та керування з'єднаннями. SRT менш вимогливий до CPU, але більш чутливий до якості мережевого каналу. * **Сумісність:** RTMP все ще широко підтримується мовними платформами. SRT набирає популярності, але не такий універсальний, як RTMP. WebRTC нативно підтримується в більшості сучасних браузерів, але вимагає спеціалізованих серверів (SFU/MCU) для масштабування на велику кількість глядачів. * **Буферизація:** Низька затримка означає меншу буферизацію. У разі короткочасних проблем з мережею це може призвести до помітних артефактів або короткочасних переривань відео, тоді як RTMP з його великим буфером може згладити такі моменти.

Вибір протоколу для SRT та WebRTC стрімінгу: коли що використовувати?

Вибір протоколу для вашого VPS або виділеного сервера безпосередньо залежить від ваших завдань та пріоритетів. Кожен протокол має свої сильні сторони та сфери застосування.

SRT: надійність та якість в умовах нестабільного каналу

SRT — це ідеальний вибір для професійного мовлення, де потрібна передача високоякісного відео з мінімальною затримкою, але не завжди ідеальними каналами зв'язку. * **Застосування:** * **Спортивні трансляції:** Передача сигналу з місця подій до студії або безпосередньо глядачам із затримкою в сотні мілісекунд. * **Прямі ефіри новин:** Оперативна передача репортажів з будь-якої точки світу. * **Мовлення на платформи:** Якщо ваша платформа підтримує SRT, це чудовий спосіб надіслати їй високоякісний потік з низькою затримкою. * **Відеоспостереження високої роздільної здатності:** Де важлива мінімальна затримка для реакції на події. * **Переваги:** Надійна доставка по UDP, корекція помилок, адаптивний бітрейт, шифрування. * **Недоліки:** Вимагає підтримки на стороні джерела та приймача, не є нативним для браузерів.

WebRTC: інтерактивність у реальному часі

WebRTC створений для ситуацій, де важлива максимальна інтерактивність і затримка має бути практично непомітною для людського сприйняття. * **Застосування:** * **Відеоконференції та вебінари:** Дозволяє учасникам спілкуватися в режимі реального часу без помітної затримки. * **Онлайн-ігри та стрімінг ігор:** Передача ігрового процесу або екрана з мінімальною затримкою для інтерактивної взаємодії. * **Віддалене керування та телемедицина:** Затримка в частки секунди критична для точних дій. * **Інтерактивне відеоспостереження:** Де оператору потрібно миттєво реагувати на те, що відбувається. * **Переваги:** Наднизька затримка (частки секунди), нативна підтримка в браузерах, P2P можливості. * **Недоліки:** Високі вимоги до серверного CPU при великій кількості учасників (особливо для SFU/MCU), складність масштабування, чутливість до мережевих умов клієнтів.

RTMP: класика для мовлення на платформи

Незважаючи на свої недоліки в плані затримки, RTMP все ще залишається актуальним для певних завдань. * **Застосування:** * **Мовлення на популярні стрімінгові платформи (Twitch, YouTube, Facebook Live):** Багато з них досі приймають RTMP-потоки. * **Традиційне мовлення:** Де затримка в кілька секунд не є критичною, наприклад, для трансляції лекцій або заздалегідь записаного контенту. * **Передача потоку між серверами:** Внутрішні мережі, де стабільність важливіша за швидкість. * **Переваги:** Широка підтримка, простота налаштування (для базових завдань), висока стабільність за рахунок TCP. * **Недоліки:** Висока затримка (2-10 секунд), відсутність нативної підтримки в сучасних браузерах (вимагає конвертації в HLS/DASH для перегляду).

Програмне забезпечення для low latency стрімінгу: що встановити на VPS?

Для розгортання low latency streaming server на вашому VPS існує кілька потужних та гнучких рішень. Вибір залежить від протоколів, які ви плануєте використовувати, та необхідної функціональності.

SRS (Simple Realtime Server): універсальне рішення

SRS — це високопродуктивний, промисловий медіасервер з відкритим вихідним кодом, написаний на C++. Він підтримує RTMP, WebRTC, HLS, HTTP-FLV і, звичайно ж, SRT. SRS є чудовим вибором для створення універсального стрімінгового сервера. * **Можливості:** * Прийом RTMP/SRT потоків, публікація їх у WebRTC, HLS, DASH. * Підтримка SRT у режимах Listener, Caller, Rendezvous. * Транскодування (з ffmpeg). * Масштабованість та стабільність. * **Приклад встановлення (Ubuntu):**

sudo apt update && sudo apt upgrade -y
sudo apt install -y git build-essential cmake libssl-dev
git clone -b 5.0 https://github.com/ossrs/srs.git
cd srs/trunk
./configure --with-srt --with-ssl --with-hls --with-dvr --with-transcode --with-webrtc
make -j$(nproc)
sudo make install
./objs/srs -c conf/srs.conf

* **Конфігурація SRT у `conf/srs.conf` (або окремому файлі):**

listen              1935;
max_connections     1000;
daemon              off;
srs_log_tank        console;

vhost __default__ {
    srt {
        enabled     on;
        listen      10080; # Порт для SRT
        latency     200; # Затримка в мс
    }
    rtc_server {
        enabled     on;
        listen      8000; # Порт для WebRTC
        candidate   0.0.0.0;
    }
}

MediaMTX (раніше RTMP-to-WebRTC): легкість та швидкість

MediaMTX (раніше known as RTMP-to-WebRTC) — це сучасний, легковий медіасервер, написаний на Go. Він фокусується на конвертації потоків RTMP, RTSP, HLS у WebRTC, а також підтримує SRT. Він відрізняється низьким споживанням ресурсів та високою продуктивністю. * **Можливості:** * Прийом RTMP, RTSP, SRT. * Видача потоків через WebRTC, HLS, RTSP. * Простота налаштування. * **Приклад встановлення (Ubuntu):**

wget https://github.com/bluenviron/mediamtx/releases/latest/download/mediamtx_v1.7.0_linux_amd64.tar.gz
tar -xvzf mediamtx_v1.7.0_linux_amd64.tar.gz
cd mediamtx_v1.7.0_linux_amd64
./mediamtx

* **Конфігурація SRT у `mediamtx.yml`:**

paths:
  all:
    readUser: ""
    readPass: ""
    publishUser: ""
    publishPass: ""

rtmp:
  listen: ":1935"

srt:
  listen: ":8000" # Порт для SRT
  readUser: ""
  readPass: ""
  publishUser: ""
  publishPass: ""

webrtc:
  listen: ":8888" # Порт для WebRTC
  iceHost: "0.0.0.0"
  iceCandidate: "YOUR_PUBLIC_IP" # Замініть на публічний IP вашого VPS

OvenMediaEngine: потужний комбайн для WebRTC

OvenMediaEngine — це комплексне рішення для медіасервера з відкритим вихідним кодом, оптимізоване для WebRTC. Він підтримує практично всі вхідні та вихідні протоколи, включаючи RTMP, SRT, RTSP, WebRTC, HLS, DASH. * **Можливості:** * Масштабованість до тисяч одночасних глядачів WebRTC. * Автоматичне транскодування та адаптивний бітрейт. * Підтримка DRM, CDN. * Дуже багатий функціонал, але й складніше налаштування. * **Встановлення:** Рекомендується використовувати Docker або їхній скрипт встановлення через складність залежностей. * **Конфігурація:** Багаторівнева, через YAML-файли для різних компонентів.

Janus Gateway: фокус на WebRTC SFU/MCU

Janus Gateway — це універсальний WebRTC сервер з відкритим вихідним кодом, орієнтований на створення інтерактивних застосунків реального часу. Він виступає як SFU (Selective Forwarding Unit) або MCU (Multipoint Control Unit), що робить його ідеальним для відеоконференцій та інтерактивних трансляцій з великою кількістю учасників. * **Можливості:** * Підтримка різних плагінів для конкретних завдань (відеоконференції, стрімінг, відеодзвінки). * SFU/MCU функціональність. * Низька затримка. * **Встановлення:**

sudo apt update && sudo apt upgrade -y
sudo apt install -y libmicrohttpd-dev libjansson-dev libnice-dev libssl-dev libsrtp2-dev libsofia-sip-ua-dev libglib2.0-dev libopus-dev libogg-dev libcurl4-openssl-dev libusrsctp-dev libtool automake cmake meson ninja-build
git clone https://github.com/meetecho/janus-gateway.git
cd janus-gateway
sh autogen.sh
./configure --prefix=/opt/janus
make
sudo make install
sudo make configs

* **Конфігурація:** У файлах `janus.jcfg` та плагінів.

Налаштування SRT та WebRTC серверів: вимоги до VPS та розрахунок конфігурації

Налаштування SRT сервер або WebRTC сервер трансляції вимагає уважного підходу до вибору конфігурації VPS. Вимоги сильно залежать від протоколу, кількості одночасних глядачів та необхідності транскодування.

Залежність від протоколу: CPU, RAM, канал

* **SRT Streaming Server:** * **CPU:** Менш вимогливий, ніж WebRTC. Основне навантаження — на мережевий стек та обробку ARQ. Якщо немає транскодування, достатньо 2-4 vCPU для сотень одночасних потоків. Якщо потрібне транскодування (наприклад, з одного SRT-потоку в кілька з різним бітрейтом), вимоги до CPU значно зростають. * **RAM:** 4-8 GB зазвичай достатньо для більшості завдань SRT, якщо немає інтенсивного транскодування або великої кількості буферів. * **Мережевий канал:** Це найкритичніший ресурс для SRT. Потрібен стабільний канал з високою пропускною здатністю (мінімум 1 Gbps, а краще 10 Gbps для великих обсягів). Для одного HD-потоку 5-10 Mbps, для 4K — 25-50 Mbps. Множте на кількість вихідних потоків. * **WebRTC Streaming Server:** * **CPU:** Це головний обмежувальний фактор. Для кожного вихідного WebRTC-потоку серверу потрібно виконувати кодування/декодування, мікшування (для MCU) або пересилання (для SFU). Чим більше одночасних глядачів і чим вища якість відео, тим більше ядер CPU знадобиться. Для SFU (Selective Forwarding Unit), де сервер тільки пересилає потоки без їх перекодування, навантаження нижче, але все одно значне. Для MCU (Multipoint Control Unit), де сервер мікшує кілька потоків в один, вимоги до CPU екстремально високі. * **RAM:** 8-16 GB і вище. WebRTC-сервери можуть споживати значний обсяг пам'яті для буферизації, зберігання метаданих про з'єднання та, при транскодуванні, для роботи з відеокадрами. * **Мережевий канал:** Також важливий. Кожен глядач WebRTC отримує свій потік даних. Для 50-100 глядачів HD-контенту знадобиться канал 1 Gbps. Для тисяч глядачів — 10 Gbps або розподілена архітектура. * **Загальні рекомендації щодо диска:** NVMe SSD є обов'язковим для будь-якої стрімінгової платформи. Хоча відеопотоки часто обробляються в оперативній пам'яті, швидкий диск потрібен для операційної системи, логів, тимчасових файлів та, можливо, запису архівів. 40-80 GB NVMe буде достатньо для більшості серверів без архівації.

Таблиця: Оптимальна конфігурація VPS для стрімінгу з низькою затримкою

Для 50 одночасних глядачів достатньо 4 vCPU, 8 GB RAM та NVMe-диска на 80 GB.

Одночасних глядачів (1080p, 5 Mbps)	vCPU	RAM (GB)	Диск (GB, NVMe)	Мережевий порт	Орієнтовна ціна Valebyte ($/міс)
10-20 (SRT/WebRTC SFU)	2	4	40	1 Gbps	Від $10
30-50 (SRT/WebRTC SFU)	4	8	80	1 Gbps	Від $25
50-100 (SRT/WebRTC SFU)	6	16	160	1 Gbps	Від $50
100-200 (SRT/WebRTC SFU)	8	32	240	10 Gbps	Від $90
200-500+ (SRT/WebRTC SFU, розподілена)	12-16+	64+	500+	10 Gbps+	Від $150 (кілька VPS)
10-20 (WebRTC MCU)	8	16	80	1 Gbps	Від $50

*Ціни є орієнтовними для тарифів Valebyte станом на січень 2024 року та можуть змінюватися залежно від акцій та регіону.

Приклад налаштування SRS для SRT та WebRTC

Для демонстрації, як на VPS налаштувати SRT сервер та WebRTC сервер трансляції, візьмемо SRS. Припустимо, у вас є чистий Ubuntu 22.04 VPS. 1. **Встановлення SRS (як показано вище):**

sudo apt update && sudo apt upgrade -y
sudo apt install -y git build-essential cmake libssl-dev
git clone -b 5.0 https://github.com/ossrs/srs.git
cd srs/trunk
./configure --with-srt --with-ssl --with-hls --with-dvr --with-transcode --with-webrtc
make -j$(nproc)
sudo make install

2. **Конфігурація SRS для SRT та WebRTC:** Відредагуйте `conf/srs.conf`. Знайдіть секцію `vhost __default__` і переконайтеся, що вона виглядає приблизно так:

# Minimal SRT/WebRTC config for SRS
listen              1935; # RTMP
max_connections     1000;
daemon              off;
srs_log_tank        console;

vhost __default__ {
    srt {
        enabled     on;
        listen      10080; # Порт для прийому SRT-потоків
        latency     200; # Затримка в мс
        # max_bw_mbps 100; # Максимальна пропускна здатність для SRT
    }
    rtc_server {
        enabled     on;
        listen      8000; # Порт для WebRTC сигнального сервера
        candidate   0.0.0.0; # Або ваша публічна IP-адреса
    }
    # Дозволяємо публікацію RTMP (наприклад, з OBS)
    # І перегляд через WebRTC
    dvr {
        enabled on;
        dvr_path ./objs/dvr/[app]/[stream]/[date].flv;
    }
}

Замініть `0.0.0.0` на вашу публічну IP-адресу, якщо у вас є проблеми з NAT. 3. **Запуск SRS:**

./objs/srs -c conf/srs.conf

Для запуску у фоновому режимі використовуйте `nohup ./objs/srs -c conf/srs.conf &`. 4. **Публікація SRT-потоку:** Використовуйте OBS Studio або ffmpeg для надсилання SRT-потоку на ваш сервер. * **OBS Studio:** Налаштування -> Трансляція -> Тип: Користувацький потоковий сервер. Сервер: `srt://YOUR_PUBLIC_IP:10080/live/stream` (або `srt://YOUR_PUBLIC_IP:10080?mode=listener`). Ключ потоку: `stream`. * **ffmpeg:**

ffmpeg -i input.mp4 -c:v libx264 -preset veryfast -b:v 3000k -maxrate 3000k -bufsize 6000k -c:a aac -ar 44100 -b:a 128k -f srt "srt://YOUR_PUBLIC_IP:10080?streamid=live/stream"

5. **Перегляд WebRTC-потоку:** SRS надає вебінтерфейс для перегляду WebRTC. Відкрийте у браузері `http://YOUR_PUBLIC_IP:8080/players/rtc_player.html`. Введіть `webrtc://YOUR_PUBLIC_IP:8000/live/stream` у поле URL та натисніть Play.

Робота з мережею: порти, UDP, NAT та файрвол

Правильне налаштування мережі — ключовий аспект для стабільної роботи SRT streaming server та WebRTC streaming server. Обидва протоколи активно використовують UDP, що вимагає особливої уваги до файрволів та NAT.

Відкриття портів для SRT та WebRTC

Для SRT та WebRTC необхідно переконатися, що відповідні порти відкриті на вашому VPS. * **SRT:** Використовує один UDP-порт для передачі даних. Зазвичай це `10080` (як у прикладі SRS) або будь-який інший, який ви оберете. * **WebRTC:** Складніший. Він використовує кілька портів: * **Сигнальний сервер:** Зазвичай TCP-порт `8000` (для SRS) або `8888` (для MediaMTX) для обміну метаданими про з'єднання. * **RTP/RTCP (медіадані):** Широкий діапазон UDP-портів. WebRTC намагається встановити пряме P2P-з'єднання, але якщо це не вдається, медіадані проходять через SFU/MCU сервер. Зазвичай виділяється діапазон з 200-300 портів, наприклад, `10000-12000` UDP. **Приклад відкриття портів за допомогою UFW (Uncomplicated Firewall) на Ubuntu:**

sudo ufw allow 1935/tcp  # Для RTMP (якщо використовується)
sudo ufw allow 10080/udp # Для SRT
sudo ufw allow 8000/tcp  # Для WebRTC сигнального сервера (якщо SRS)
sudo ufw allow 8888/tcp  # Для WebRTC сигнального сервера (якщо MediaMTX)
sudo ufw allow 10000:12000/udp # Для WebRTC медіаданих (діапазон)
sudo ufw enable
sudo ufw status verbose

Якщо ви використовуєте `firewalld` (наприклад, на CentOS/RHEL):

sudo firewall-cmd --zone=public --add-port=1935/tcp --permanent
sudo firewall-cmd --zone=public --add-port=10080/udp --permanent
sudo firewall-cmd --zone=public --add-port=8000/tcp --permanent
sudo firewall-cmd --zone=public --add-port=10000-12000/udp --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Проблеми з NAT та їх вирішення

NAT (Network Address Translation) може викликати проблеми з UDP-протоколами, оскільки він змінює IP-адреси та порти, що ускладнює встановлення прямих з'єднань. * **STUN/TURN-сервери:** * **STUN (Session Traversal Utilities for NAT):** Допомагає клієнтам визначити свою публічну IP-адресу та порт, щоб вони могли повідомити його іншим учасникам. Більшість WebRTC-серверів мають вбудовану підтримку STUN або дозволяють вказати зовнішній STUN-сервер (наприклад, `stun.l.google.com:19302`). * **TURN (Traversal Using Relays around NAT):** Якщо пряме P2P-з'єднання неможливе через суворі NAT-обмеження (наприклад, симетричний NAT), TURN-сервер виступає як ретранслятор, через який проходять усі медіадані. Це збільшує затримку та навантаження на сервер, але забезпечує надійну доставку. Для WebRTC-серверів, таких як Janus або OvenMediaEngine, часто потрібне налаштування власного TURN-сервера, якщо ви очікуєте клієнтів за складними NAT. * **Публічна IP-адреса:** Завжди використовуйте публічну IP-адресу вашого VPS у конфігураціях сервера (наприклад, `candidate` у SRS або `iceCandidate` у MediaMTX), щоб сервер правильно анонсував свої мережеві дані.

Налаштування файрволу (UFW/firewalld)

Окрім відкриття портів, переконайтеся, що ваш файрвол не блокує вихідні UDP-з'єднання, які можуть знадобитися для STUN/TURN або для зворотного зв'язку по SRT (наприклад, ARQ-пакети). Регулярно перевіряйте логи файрволу, якщо виникають проблеми з підключенням, щоб переконатися, що трафік не блокується.

Типові проблеми та їх діагностика при стрімінгу з низькою затримкою

При роботі з low latency streaming server неминуче виникають проблеми. Важливо знати, як їх діагностувати та усувати, щоб забезпечити безперебійну роботу.

Як зменшити високу затримку стріму: чеклист

Якщо ви спостерігаєте, що затримка стріму вища за очікувану, пройдіть за наступним чеклистом: 1. **Протокол:** Переконайтеся, що ви дійсно використовуєте SRT або WebRTC, а не RTMP або HLS, які за своєю природою мають більшу затримку. 2. **Налаштування сервера:** * **SRT:** Перевірте параметр `latency` у конфігурації SRT на сервері (наприклад, у SRS). Він повинен бути встановлений на низьке значення (наприклад, 200-400 мс). Переконайтеся, що `mode` SRT (listener, caller, rendezvous) відповідає вашому сценарію. * **WebRTC:** Переконайтеся, що ваш WebRTC-сервер (SRS, MediaMTX, Janus) правильно сконфігурований і не використовує транскодування, якщо воно не потрібне. Транскодування завжди збільшує затримку. 3. **Налаштування джерела (OBS/ffmpeg):** * **Буфер:** Зменшіть буфери в OBS Studio або ffmpeg. Наприклад, для OBS: Налаштування -> Вивід -> Розширений -> Затримка потоку. Для ffmpeg: ` -bufsize` та ` -probesize` параметри. * **Інтервал ключових кадрів (GOP):** Встановіть низький інтервал ключових кадрів (наприклад, 1-2 секунди). `keyint=1s` або `g=30` (для 30 fps). * **Профіль/Передустановки кодувальника:** Використовуйте швидші передустановки (наприклад, `veryfast` або `ultrafast` для x264/x265), які знижують навантаження на CPU, але можуть трохи погіршити якість при тому ж бітрейті. 4. **Мережеві умови:** * **Пропускна здатність:** Переконайтеся, що у вас достатньо пропускної здатності як на стороні джерела, так і на VPS. Недостатня пропускна здатність призведе до втрати пакетів і повторним запитам, збільшуючи затримку. * **Пінг/Затримка мережі:** Виміряйте пінг між джерелом та VPS, а також між VPS та глядачем. Високий пінг безпосередньо впливає на мінімальну досяжну затримку. * **Втрата пакетів:** Навіть невеликий відсоток втрати пакетів (більше 0.5-1%) може значно збільшити затримку, особливо для SRT. Використовуйте інструменти на кшталт `iperf3` для діагностики. 5. **Навантаження на сервер:** * **CPU:** Перевірте завантаження CPU на VPS (`htop`, `top`). Якщо CPU постійно завантажений на 90-100%, це може бути причиною затримок, особливо для WebRTC. Масштабуйте VPS або оптимізуйте конфігурацію. * **RAM:** Нестача RAM може призвести до свопінгу, що уповільнює роботу сервера. 6. **Файрвол/NAT:** Переконайтеся, що всі необхідні порти відкриті і немає проблем з NAT, які можуть змушувати трафік йти довшим шляхом (через TURN-сервери).

Проблеми з підключенням та якістю відео

* **Не вдається підключитися до сервера:** * Перевірте, чи запущено медіасервер (SRS, MediaMTX тощо). * Перевірте логи сервера на наявність помилок. * Переконайтеся, що порти відкриті на файрволі VPS. * Перевірте IP-адресу та порт в URL підключення. * **Відео переривається, зависає або має артефакти:** * **Низький бітрейт/висока компресія:** Збільште бітрейт або зменшіть ступінь стиснення на джерелі. * **Втрата пакетів:** Перевірте стабільність мережі між джерелом та сервером, а також між сервером та глядачем. Використовуйте `ping`, `mtr` для діагностики. * **Перевантаження сервера:** Занадто багато одночасних потоків або інтенсивне транскодування можуть перевантажити CPU або мережевий канал сервера. * **Неправильні налаштування кодування:** Переконайтеся, що налаштування кодування (профіль, рівень, B-кадри) сумісні з вашими клієнтами. * **Аудіо/відео розсинхронізація:** * Часто це відбувається через проблеми з кодуванням на джерелі або нестабільну мережу. Перевірте налаштування аудіо та відео бітрейту, частоти дискретизації. * Іноді допомагає перезапуск джерела та сервера.

Часті питання

Скільки vCPU потрібно для WebRTC-стрімінгу з 50 одночасними глядачами?

Для WebRTC-стрімінгу на 50 одночасних глядачів у режимі SFU (Selective Forwarding Unit) знадобиться не менше 4-6 vCPU. Якщо ж ви використовуєте режим MCU (Multipoint Control Unit), який вимагає перекодування та мікшування багатьох потоків в один, то для 50 учасників може знадобитися 8 vCPU і більше, залежно від роздільної здатності та бітрейту потоків.

Чи можна використовувати RTMP для стрімінгу з низькою затримкою?

RTMP не призначений для стрімінгу з низькою затримкою. Його типова затримка становить 2-10 секунд через використання TCP та механізмів буферизації. Для досягнення затримки в сотні мілісекунд або частки секунди необхідно використовувати протоколи SRT або WebRTC, які оптимізовані для швидкості та працюють на базі UDP.

Які порти потрібно відкрити на файрволі для SRT та WebRTC?

Для SRT зазвичай потрібно відкрити один UDP-порт, наприклад, 10080. Для WebRTC необхідно відкрити TCP-порт для сигнального сервера (наприклад, 8000 або 8888) та широкий діапазон UDP-портів для медіаданих, зазвичай 200-300 портів у діапазоні 10000-12000. Це дозволяє встановлювати прямі з'єднання та обходити NAT.

Як зменшити затримку стріму, якщо я використовую SRT?

Для зменшення затримки стріму по SRT переконайтеся, що параметр `latency` у конфігурації вашого SRT-сервера встановлений на мінімальне прийнятне значення (наприклад, 200-400 мс). Також критично важливою є стабільність мережевого каналу: чим менша втрата пакетів та джиттер, тим нижчою може бути встановлена затримка без втрати якості. Перевірте налаштування буфера на стороні джерела.

Чому WebRTC вимагає більше CPU, ніж SRT?

WebRTC часто вимагає більше CPU, тому що він призначений для інтерактивного, двостороннього спілкування та може включати транскодування, мікшування потоків (у режимі MCU) або керування безліччю одночасних P2P-з'єднань. SRT ж в основному фокусується на надійній односпрямованій передачі високоякісного відео, і якщо не потрібне транскодування, його навантаження на CPU нижче.

Висновки

Вибір між SRT та WebRTC для стрімінгу з низькою затримкою на власному сервері залежить від конкретних вимог вашого проєкту: SRT ідеальний для надійної доставки високоякісного відео через нестабільні канали із затримкою в сотні мілісекунд, тоді як WebRTC незамінний для інтерактивних застосунків, де критична затримка в частки секунди. Для більшості завдань, що вимагають низької затримки, підійде VPS з 4-8 vCPU, 8-16 GB RAM та NVMe-диском, а для масштабування на сотні та тисячі глядачів знадобиться потужніший виділений сервер або кластер з кількох VPS з мережевим портом 10 Gbps.