FAQ

Ответы на вопросы, которые чаще других возникают при эксплуатации: совместимость SRT со сторонним ПО и приём мультикаста на высоких битрейтах.

SRT: авторизация по логину и паролю в стороннем ПО

Между двумя узлами Perfect Streamer авторизация SRT настраивается штатно, полями входа и выхода (SRT). Работа с другим ПО не гарантируется: параметр stream ID не стандартизован и в разном ПО реализован по-разному.

Механизм совместимости общий: принимающая сторона берёт stream ID подключающегося клиента и ищет по нему учётную запись в списке локальных логинов (Пользователь: добавление и изменение). Совпасть должно поле «Логин» — целиком со значением stream ID. Например, при ссылке

srt://Stream_IP:port?streamid=!#::u=1234567890,password=1234567890

в поле «Логин» вводится

!#::u=1234567890,password=1234567890

Синтаксис stream ID для Perfect Streamer значения не имеет: строка не разбирается по частям, а сравнивается целиком. Исключение составляют три символа, которые узел трактует сам:

  • | — разделитель: часть строки до первого такого символа считается логином, остальное паролем учётной записи;

  • * — stream ID не задан; клиент авторизуется по адресу, то есть учётной записью с признаком «Учётная запись по IP-адресу»;

  • @ в начале строки зарезервирован за служебной авторизацией между узлами домена Meshwork.

Длину stream ID Perfect Streamer не ограничивает — ограничение приходит от библиотеки SRT и составляет 512 байт вместе с завершающим нулём. Значения длиннее примерно 500 символов передавать не следует: слишком длинная строка либо обрывает соединение, либо уходит пустой без сообщения об ошибке.

Разное ПО формирует stream ID по-своему, поэтому, если приём по ссылке не работает, включите на выходе SRT дополнительную настройку Trace. В журнале потока, который принимает подключение, появятся адрес клиента, полученный stream ID и причина отказа — по этой строке видно, что сторона прислала на самом деле. Дальше stream ID можно скорректировать: например, убрать лишние символы в начале строки, мешающие передаче значения.

Рекомендации по работе с UDP-мультикастом

Задача. Стабильно принять UDP-мультикаст с суммарным битрейтом в несколько сотен Мбит/с (1 Гбит/с и более) на одном сервере.

Проблема. При приёме на сетевые карты с интерфейсом RJ-45 с ростом трафика выше нескольких сотен мегабит начинаются нарастающие потери пакетов мультикаста. Тонкая настройка карты не помогает — в современных версиях операционных систем уже используются оптимальные значения. Карты на лучших чипах проблему не снимают, особенно после 500 Мбит/с. Не помогает и бондинг двух карт: одна мультикаст-группа всегда приходит на один физический канал и на одну очередь приёма, поэтому агрегируется суммарная полоса, а не запас по отдельному потоку.

Решение. По опыту эксплуатации для приёма и передачи UDP-мультикаста следует использовать 10-гигабитные сетевые карты с интерфейсом SFP+. Достаточно бюджетной карты уровня Intel X520-DA1/2 (Intel 82599ES) — в наших тестах она устраняет потери пакетов при трафике мультикаста свыше 1 Гбит/с. Дополнительно заметно снижается нагрузка на CPU: обработка прерываний и очередей приёма на таких картах обходится дешевле.

Учтите при диагностике: счётчик ошибок приёма recv-err в статистике входа считает только ошибки чтения сокета и рассинхронизацию по границе TS-пакета. Потери, вызванные переполнением приёмного буфера ядра, до приложения не доходят и в этот счётчик не попадают — их видно командой netstat -su (строка RcvbufErrors) и по ошибкам непрерывности в анализаторе потока (Анализатор).

Рекомендации по настройке сети для мультикаста

Раздел относится к сетевым входам UDP / RTP и Pro-MPEG COP3/RTP+FEC (SMPTE 2022-1/2). На приём SRT эти параметры не влияют: библиотека SRT задаёт размер буфера сама, а задержка и запас на ретрансмиссию настраиваются на самом входе (SRT).

Размер приёмного буфера сокета задаётся дополнительной настройкой входа Socket buffer (bytes). По умолчанию она равна нулю — узел ничего не запрашивает, и сокет получает размер буфера, заданный в системе параметром net.core.rmem_default. Заданное значение — запрос, а не итог. Как только оно указано явно, начинает действовать потолок net.core.rmem_max, и ядро урезает запрос до этого предела, сообщая об успехе в любом случае. Поэтому потолок поднимают до того, как задавать размер буфера у входа.

Сколько буфера выдано на самом деле, узел показывает у работающего входа в двух местах: в статистике потока, в блоке «Входное соединение», есть строка «Буфер сокета (выдано)» (Статистика потока), а в редакторе входа (Редактор входа и выхода) выданный размер выводится под самим полем и рядом появляется предупреждение, если запрос не уместился в потолок. В обоих местах показан полезный объём, доставшийся сокету, а не то, что набрано в поле: под полем — в байтах, чтобы сравнивать с ним напрямую, в статистике — округлённо. Отсутствие строки означает, что сокета нет: вход остановлен. Нулевого буфера она не означает никогда.

Значение в статистике обновляется вместе с остальными показателями, а под полем оно считывается один раз, при открытии окна потока. Поэтому после сохранения нового размера строка под полем исчезает: сохранение переоткрывает сокет, и прежнее число к нему уже не относится. Чтобы увидеть выданное новому сокету, окно потока закрывают и открывают заново — или смотрят статистику, где значение живое.

Параметры задаются отдельным файлом в /etc/sysctl.d/:

cat > /etc/sysctl.d/99-pss-net.conf <<EOF
net.core.rmem_default=8388608
net.core.rmem_max=16777216
EOF

Применить:

sudo sysctl --system

Значение rmem_max — только потолок, память по нему не резервируется. Значение rmem_default применяется ко всем UDP-сокетам системы; если такой глобальный размер нежелателен, оставьте его без изменений и задайте Socket buffer (bytes) только тем входам, которым он действительно нужен. Ноль и явно заданное число неравноценны даже при одинаковой величине: запрошенный размер ядро удваивает, а размер по умолчанию берёт как есть, тогда как половина выданного в обоих случаях уходит на служебный учёт пакетов. Поэтому на системе с тем же rmem_default вход с явно указанным числом получает вдвое больше полезного места, чем вход с нулём.

Ориентир для расчёта — битрейт потока, умноженный на допустимую паузу в обслуживании сокета. Так, 8 МБ покрывают около 64 мс при 1 Гбит/с. Ориентир задаёт полезный объём, то есть число в поле входа; потолок net.core.rmem_max при этом должен быть вдвое больше самого крупного такого числа. Рекомендованная пара значений выше это условие выполняет.

SRT: приём на стороннем ПО со своим stream ID

Пример ссылки SRT для приёма на стороннем ПО, которое при работе с SRT само передаёт stream ID:

srt://Stream_IP:port?streamid=client1

Здесь client1 — логин учётной записи на вкладке «Локальные логины» (Пользователь: добавление и изменение). При добавлении учётной записи достаточно указать только логин. Если такое ПО передаёт собственный stream ID, а логин в ссылке не указан, поток не принимается: Perfect Streamer не находит учётную запись и не отдаёт поток.

Так же stream ID задаётся в формате логина и пароля: у учётной записи поле «Логин» равно !#::u=1234567890,password=1234567890, а в стороннем ПО прописывается ссылка:

srt://Stream_IP:port?streamid=!#::u=1234567890,password=1234567890

Можно задать stream ID и в формате IP-адреса — для этого у учётной записи включается признак «Учётная запись по IP-адресу», а в поле адреса вводится:

  • 192.168.1.1 — единичный IP;

  • 192.168.1.1-192.168.1.254 — диапазон IP.

В обоих случаях ссылка для приёма по IP в стороннем ПО выглядит так: srt://Stream_IP:port?streamid=*

Поток привязывается к IP-адресу клиента: приём по этой ссылке возможен только с указанного IP-адреса (или из указанного диапазона).