RTMP, SRT чи WHIP: як обрати протокол приймання потоку

Перш ніж порівнювати: помилка, на яку багато хто витрачає свою першу годину, ховається в SRT-адресі, і жодного повідомлення про помилку вона не дає. Прочитайте наступний розділ, навіть якщо пропустите все інше.

Збій, який виглядає так, ніби нічого не відбувається

В SRT-адресі для приймання потоку є streamid такого вигляду: #!::r=live/sk_srt_…,m=publish. Ці символи — #, !, :, , — уважна людина за звичкою кодує відсотками. Не треба. Бібліотека SRT не розкодовує streamid, а передає серверу байти як є. Тому закодований streamid приходить як назва потоку, що починається з %23, сервер сприймає підключення як запит на перегляд, а не на публікацію, і вам про це нічого не повідомляють. Енкодер показує нормальне підключення. Картка трансляції показує, що сигналу немає. Помилки немає ніде.

Вставляйте SRT-адресу саме в тому вигляді, у якому її повертає API. dcast віддає її в буквальній, готовій до публікації формі в полі data.ingest.srt відповіді GET /api/v1/streams/:id, а те саме значення — у data.ingest.srtDisplay, яке існує лише як псевдонім для старих інтеграцій. Будь-яке з них вставляється в енкодер напряму, без переробок.

Що приймає dcast

Картку трансляції можна живити будь-яким із цих способів. Вибір робиться для кожної картки окремо й не змінює картинку, яку отримують ваші глядачі.

Ім'я хоста — завжди a.dcast.pro: точка входу в пул маршрутизації, а не назва конкретного сервера. Так зроблено навмисно: адреса, яку ви один раз налаштували, і далі працюватиме, коли потік потрапить на іншу машину.

RTMP: той, що працює завжди

RTMP старий, і в цьому вся його перевага. Будь-який енкодер, будь-яка камера з режимом стримінгу, будь-який застосунок на телефоні й будь-який апарат, який вам дадуть на майданчику, вміє надсилати RTMP без жодних налаштувань, крім сервера й ключа. Якщо ви стримите зі стабільної мережі й не розв'язуєте конкретну проблему, RTMP — правильний вибір, і далі можна не читати.

Його слабке місце — те, що відбувається, коли мережа нестабільна. RTMP працює поверх TCP, а TCP дає раду втратам, надсилаючи пакети повторно й чекаючи на них. На доброму каналі цього не видно. На каналі зі справжніми втратами пакетів — видно: потік набирає затримку, яку вже ніколи не віддає, або завмирає, а відновлення, залежно від енкодера, буває від акуратного до обриву з'єднання.

Якщо енкодер просить сервер і ключ окремо, розділіть адресу за останньою скісною рискою: сервер rtmp://a.dcast.pro/live, ключ sk_rtmp_…. (Ключі потоку починаються з префікса протоколу, під який створювали картку, — sk_rtmp_, sk_srt_, sk_webrtc_, — тож ключ, який ви вставляєте, має пасувати до тих дверей, у які ви стукаєте.)

SRT: той, що для поганих мереж

SRT створено для того випадку, з яким RTMP дає раду погано: канал із втратами пакетів, який ви не можете виправити. На практиці це мобільні мережі, публічний Wi-Fi на майданчиках і все, що йде на велику відстань.

Ідея — у фіксованому бюджеті затримки. Замість того щоб повторювати надсилання, доки пакет не дійде, скільки б це не забрало, SRT тримає буфер заданого розміру й перезапитує втрачені пакети лише доти, доки ще є час поставити їх на місце. Пакети, які не встигають, відкидаються, а не затримують усе, що йде слідом. У результаті потік має передбачувану затримку й м'яко деградує під час втрат — замість непередбачуваної затримки й зависань.

Цей буфер — параметр latency у мілісекундах. В адресах, які видає dcast, стоїть 500 мс, і ви можете підняти його до 7000. Обмін прямий, хитрого налаштування не існує: більше значення витримує сильніші втрати й додає рівно стільки ж затримки. Якщо потік втрачає пакети — піднімайте.

Опустити його нижче 500 — єдине, що не спрацює, і краще знати чому, ніж з'ясовувати на практиці. Наш прийом сам оголошує 500 мс, а SRT-з'єднання домовляється на більше зі значень двох сторін, — тож енкодер, який запросив 80 мс, однаково отримає 500. Це число — нижня межа, а не просто значення за замовчуванням.

Варто знати ще два налаштування SRT. Режим: dcast видає адреси в режимі caller, тобто енкодер сам встановлює з'єднання назовні, — саме це працює з-за роутера без прокидання портів. Режими listener і rendezvous існують для схем, де вони потрібні. І passphrase: SRT уміє шифрувати канал; якщо ви її задаєте, у ній має бути щонайменше десять символів.

WHIP: той, що з браузера

WHIP — це спосіб публікації для джерела WebRTC. Замість адреси потоку ви надсилаєте SDP-пропозицію на HTTPS-адресу, і встановлюється peer-з'єднання. dcast повертає цю адресу разом з іншими в картці трансляції.

Використовуйте його, коли джерело — браузер (гість, у якого нічого не встановлено, веб-пульт керування, демонстрація екрана) або коли потрібна затримка подачі сигналу, менша за ту, яку може дати сегментний шлях. Енкодери з підтримкою WHIP показують його як сервіс стримінгу, куди ви вставляєте повернуту адресу як є; окремого поля для ключа потоку немає, бо ключ уже входить в адресу.

Його обмеження в тому, що WebRTC вимогливіший у роботі, ніж надсилання через TCP. Він чутливіший до мереж з обмеженнями й гірше підтримується апаратними енкодерами, ніж RTMP.

Вибір протоколу не змінює вашу картинку

Ця частина позбавляє від купи тестів. Яким би протоколом не прийшов ваш потік, передусім він зводиться до єдиної внутрішньої форми, і драбина кодування, яка працює далі, однакова. Ті самі щаблі, ті самі стелі бітрейту, той самий інтервал ключових кадрів у 2 секунди, ті самі 4-секундні сегменти по два ключові кадри в кожному.

Це означає: SRT-потік і RTMP-потік з тим самим джерелом на тому самому бітрейті дають однаковий результат. SRT не дасть вам кращої картинки, а RTMP не зробить її гіршою. Обирайте за тим, як поводиться ваша мережа, — це єдине, на що вибір справді впливає.

Частоту кадрів теж визначаємо ми, а не протокол, і однаково для всіх трьох: на момент написання статті драбина прямого ефіру кодується в 30 fps, хоч би що ви надсилали.

Не збирайте адресу приймання вручну

Кожну адресу приймання, яку дає dcast, випускає API для конкретної картки трансляції, і кожна її частина виконує своє завдання. GET /api/v1/streams/:id повертає їх усі разом у data.ingest, і правильний порядок роботи — щоразу копіювати звідти, а не зберігати адресу в документі й міняти в ній ключ.

Ім'я хоста — це точка входу в пул, а не назва машини, тому воно лишається чинним, навіть якщо наступного тижня ваш потік роздаватимуть звідкись іще. Ключ визначає вашу картку. У SRT streamid додатково несе режим — саме m=publish робить з'єднання публікацією, а не переглядом, — і якраз тому збій із кодуванням із початку статті такий тихий: зіпсувавши streamid, ви надіслали не кривий запит, а цілком коректний запит на перегляд потоку, якого не існує.

Майже від усього цього рятують дві звички. Копіюйте адресу повністю, разом з усім після ?, однією дією. А якщо енкодер наполягає на окремих полях для сервера й ключа, розділіть за останньою скісною рискою й вставте обидві половини, нічого не передруковуючи.

Якщо ви робите інтеграцію, а не налаштовуєте вручну, запитуйте адреси приймання в момент використання, а не кешуйте їх, — з тієї самої причини: видане значення правильне зараз, а запитати знову майже нічого не коштує.

Шифрування каналу

SRT уміє шифрувати потік між вашим енкодером і нами за допомогою passphrase. Її варто вмикати щоразу, коли канал проходить через мережу, яку ви не контролюєте, — гостьовий Wi-Fi майданчика, готель, спільний канал на конференції, — бо в таких мережах сигнал, який ви подаєте, — це єдине, що ви справді не зможете переробити, якщо хтось у нього втрутиться.

Passphrase має містити щонайменше десять символів. Задайте однакове значення на обох сторонах; у разі розбіжності рукостискання не проходить, а не деградує, і це саме та поведінка, яка вам потрібна: тихий відкат до нешифрованого з'єднання був би гіршим за відмову.

Шифрування коштує трохи обчислювальних ресурсів на кожній стороні й нічого — у якості картинки. Якщо ви вже використовуєте SRT, бо мережі не можна довіряти, те саме міркування зазвичай стосується й питання, чи повинен хтось сторонній мати змогу прочитати потік.

Як обрати — в одному абзаці

Якщо у вас дротове підключення в будівлі, яку ви контролюєте, беріть RTMP. Якщо ви на мобільному зв'язку, на Wi-Fi майданчика або надсилаєте потік через континент, беріть SRT і піднімайте затримку, доки потік не стане чистим. Якщо джерело — веб-браузер, беріть WHIP. Якщо контент уже існує у вигляді потоку деінде, беріть HTTP pull і дайте нам забрати його, а не ретранслюйте вручну. Ці чотири речення охоплюють майже всі реальні випадки.

Перевірка приймання до події

Перевіряйте зі справжньою адресою зі справжньої картки трансляції, а не з адресою, яку зібрали самі. Більшість збоїв першого разу — це адреса, зібрана вручну.

Перевіряйте зі справжнього майданчика, на справжньому підключенні й, якщо майданчик буває переповнений, у справжній час доби. Мережа, яка чиста о дев'ятій ранку й забита о сьомій вечора, — це звичайний випадок, а не виняток.

У випадку SRT під час перевірки стежте за лічильниками втрат і повторних передач в енкодері, а не за картинкою. Картинка виглядає нормально аж до моменту, коли бюджет затримки вичерпано, тож попереджають лічильники, а не картинка.

І переконайтеся, що картка трансляції показує сигнал, а не лише те, що енкодер показує підключення. Це два різні твердження, і збій зі streamid в SRT із початку статті — саме той випадок, коли перше правдиве, а друге ні.