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 из начала статьи — ровно тот случай, когда первое верно, а второе нет.