Що таке SRT-стримінг? Порівняння SRT і RTMP
SRT — це протокол передавання відео, створений, щоб витримувати ненадійні мережі. Розповідаємо, як він відновлює втрачені пакети, що робить налаштування затримки, чим відрізняється від RTMP і чому більшість платформ досі просять RTMP.
На цій сторінці
SRT (Secure Reliable Transport) — це протокол із відкритим кодом для передавання живого відео через непередбачувані мережі, як-от загальнодоступний інтернет. Він працює поверх UDP, повторно запитує втрачені пакети, дає змогу вибрати, скільки затримки обміняти на надійність, і може шифрувати потік. Мовники використовують його, щоб передавати високоякісні потоки між локаціями.
Він не замінює RTMP усюди, але дуже добре розв’язує конкретні проблеми. Ось як він працює і коли його варто використовувати.
Головне
- SRT використовує UDP і відновлює втрачені пакети в межах заданого вами вікна затримки.
- Він підходить для далеких каналів або каналів із втратами, як-от віддалених локацій і вхідних потоків для продакшену.
- Більшість платформ для авторів досі документують прийом потоку через RTMP або RTMPS.
- Шифрування AES зі спільною парольною фразою захищає потоки SRT під час передавання.
Звідки взявся SRT і яку проблему він розв’язує
SRT розробила відеокомпанія Haivision, і у 2017 році його відкрили як проєкт з відкритим кодом. Сьогодні його підтримує широкий спектр енкодерів, декодерів, медіасерверів і програм, зокрема OBS і FFmpeg.
Проблему, на яку він спрямований, легко описати: загальнодоступний інтернет втрачає пакети й змінює їхній порядок, особливо на великих відстанях, у перевантаженому Wi-Fi чи мобільних з’єднаннях. Традиційні мовні лінії уникали цього завдяки виділеним каналам або супутниковій ємності. SRT натомість прагне забезпечити надійність мовного рівня через звичайні інтернет-з’єднання.
Робить він це, майже не зважаючи на те, що всередині потоку. SRT — це транспорт, а не відеоформат, і найчастіше він переносить транспортний потік MPEG із відео H.264 або HEVC та аудіо AAC. Ця гнучкість допомогла професійним робочим процесам швидко його прийняти.
Як працюють відновлення пакетів і буфер затримки
RTMP працює поверх TCP, який повторно надсилає втрачені дані, але сповільнює все з’єднання щоразу, коли виявляє втрати. На далеких каналах із втратами це проявляється як зависання й буферизація.
SRT використовує UDP і сам відповідає за відновлення. Приймач тримає пакети в короткому буфері. Помітивши пропуск у послідовності, він просить відправника повторно надіслати лише втрачений пакет. Якщо заміна надійде раніше, ніж цей момент відео залишить буфер, ніхто далі по ланцюжку нічого не помітить.
Розмір буфера — це налаштування затримки (latency). Більші значення витримують гірші мережі ціною затримки; менші тримають затримку низькою, але відкидають пакети, що надходять надто пізно. Поширена відправна точка — кілька значень часу обміну пакетами між відправником і приймачем, із більшим значенням для нестабільних каналів. Різні інструменти вказують затримку в різних одиницях, тож звіряйтеся з документацією.
Шифрування, ідентифікатори потоку та режими з’єднання
SRT має функції, яких RTMP сам по собі не пропонує:
- Шифрування. AES із парольною фразою, спільною для обох сторін, із ключами 128, 192 або 256 біт. Щоб RTMP був зашифрованим, потрібен окремий варіант RTMPS.
- Stream ID. Необов’язковий ідентифікатор, який дозволяє одному порту приймача приймати кілька потоків і правильно маршрутизувати кожен, дещо схоже на ключ трансляції.
- Режими з’єднання. Одна сторона слухає порт, а інша до неї звертається. Третій режим, rendezvous, передбачає одночасне підключення обох сторін, що може допомогти, коли обидві перебувають за брандмауерами.
Оскільки SRT використовує UDP, UDP-порт слухача має бути відкритий у кожному брандмауері на шляху, на відміну від вихідних TCP-з’єднань RTMP. Про RTMP читайте в статтях як працює RTMP і RTMP чи RTMPS.
SRT чи RTMP: де виграє кожен
Жоден протокол не є просто кращим; вони добрі для різних завдань.
- SRT виграє для вхідних потоків. Надсилання потоку з віддаленої локації, від виїзної знімальної групи чи через мобільний зв’язок до продакшн-центру — саме там відновлення пакетів себе окуповує, так само як і в мовних ланцюжках, що живлять системи виведення в ефір, декодери й медіасервери.
- SRT краще справляється з відстанню. На міжконтинентальних каналах із втратами й джитером налаштований буфер затримки зазвичай дає стабільніший результат, ніж RTMP на основі TCP.
- RTMP виграє за сумісністю. Його підтримують майже всі енкодери, сервіси й платформи, а налаштування — це лише URL-адреса плюс ключ.
- RTMP простіше розгорнути. Не треба узгоджувати UDP-порти, налаштування затримки чи парольні фрази.
Практичне правило: використовуйте SRT між системами, які контролюєте ви чи ваш партнер, а RTMP або RTMPS — для останнього кроку до публічних платформ.
Чому YouTube, Twitch і більшість платформ досі просять RTMP
Якщо SRT такий стійкий, чому великі платформи для авторів і далі документують прийом потоку через RTMP і RTMPS?
По-перше, сумісність: платформи хочуть, щоб підключитися міг кожен стример, від мобільних застосунків до старших апаратних енкодерів, а RTMP — протокол, яким володіють усі вони. По-друге, більшість авторів транслюють із дому на найближчий сервер прийому, де TCP працює достатньо добре. По-третє, платформи роками будували навколо RTMP автентифікацію, керування ключами й моніторинг.
Ця картина змінюється. Деякі платформи й багато професійних відеосервісів приймають SRT або інші новіші протоколи прийому потоку. Утім, на момент написання популярна соціальна чи ігрова платформа зазвичай видасть вам URL-адресу RTMP або RTMPS. Як працюють такі призначення, пояснює посібник з власного RTMP-стримінгу.
Надсилання RTMP і SRT з однієї хмарної трансляції
Багатьом налаштуванням потрібні обидва протоколи одночасно: RTMP для публічних платформ і SRT для студії, сервера виведення в ефір чи приймача партнера. З домашнього енкодера це означає два виходи й подвійний вихідний трафік.
StreamHouse робить це в хмарі. Додайте до однієї трансляції YouTube, Twitch чи Kick через RTMP або RTMPS, а також власний SRT-вихід, спрямований на ваш приймач. Одна трансляція доходить до всіх, і додаткові призначення не займають додаткових слотів трансляцій.
Для попередньо записаних програм завантажте відео, які заздалегідь готуються за одним узгодженим профілем кодування, потім зберіть плейлист і запустіть його або заплануйте старт. Трансляція йде в циклі 24/7, автоматично перепідключається після збоїв мережі й працює далі, навіть коли ваш комп’ютер вимкнено.
Поширені запитання
Чи SRT кращий за RTMP для стримінгу?
Для довгих або ненадійних мережевих маршрутів — зазвичай так, бо SRT відновлює втрачені пакети, не зупиняючи все з’єднання. Проте популярні платформи часто пропонують лише RTMP або RTMPS, тож правильний вибір залежить від того, куди йде ваш потік.
Чи має SRT нижчу затримку, ніж RTMP?
Може мати. Транспортна затримка SRT приблизно дорівнює заданому вами буферу затримки, який у добрих мережах може бути малим. Але загальна затримка для глядачів також залежить від обробки й відтворення на платформі, тож зміна протоколу не завжди відчуватиметься як пришвидшення.
Чи може OBS транслювати через SRT?
Так. Введіть адресу srt:// як власний сервер в OBS, додавши в URL-адресу параметри на кшталт mode, latency і passphrase. Сервер або сервіс-приймач має підтримувати SRT і бути налаштований на прийом з’єднання.
Чи шифрується SRT за замовчуванням?
Лише коли ви задаєте парольну фразу. З однаковою парольною фразою на обох сторонах SRT шифрує потік за допомогою AES із ключами 128, 192 або 256 біт. Без неї потік передається незашифрованим, тож задавайте її для потоків, що йдуть через загальнодоступний інтернет.


