--- title: FAQ url: https://doc2.pstreamer.tv/ru/manual/faq/index.html lang: ru product: Perfect Streamer version: 2.0.2.362 --- # FAQ Ответы на вопросы, которые чаще других возникают при эксплуатации: совместимость SRT со сторонним ПО и приём мультикаста на высоких битрейтах. ## SRT: авторизация по логину и паролю в стороннем ПО Между двумя узлами Perfect Streamer авторизация SRT настраивается штатно, полями входа и выхода ([SRT](../planning/index.md#planning-srt)). Работа с другим ПО не гарантируется: параметр stream ID не стандартизован и в разном ПО реализован по-разному. Механизм совместимости общий: принимающая сторона берёт stream ID подключающегося клиента и ищет по нему учётную запись в списке локальных логинов ([Пользователь: добавление и изменение](../webui/configure.md#webui-user-editor)). Совпасть должно поле «Логин» — целиком со значением 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`) и по ошибкам непрерывности в анализаторе потока ([Анализатор](../streamer/analyzer.md#streamer-analyzer)). ## Рекомендации по настройке сети для мультикаста Раздел относится к сетевым входам UDP / RTP и Pro-MPEG. На приём SRT эти параметры не влияют: библиотека SRT задаёт размер буфера сама, а задержка и запас на ретрансмиссию настраиваются на самом входе ([SRT](../planning/index.md#planning-srt)). Размер приёмного буфера сокета задаётся дополнительной настройкой входа «Socket buffer (bytes)». По умолчанию она равна нулю — узел ничего не запрашивает, и сокет получает размер буфера, заданный в системе параметром `net.core.rmem_default`. Заданное значение — запрос, а не итог: как только оно указано явно, начинает действовать потолок `net.core.rmem_max`, и ядро урезает запрос до этого предела, сообщая об успехе в любом случае. Поэтому потолок поднимают до того, как задавать размер буфера у входа. Сколько буфера выдано на самом деле, узел показывает у работающего входа в двух местах: в статистике потока, в блоке «Входное соединение», есть строка «Буфер сокета (выдано)» ([Статистика потока](../webui/streams.md#webui-stream-stats)), а в редакторе входа ([Редактор входа и выхода](../webui/streams.md#webui-stream-io)) выданный размер выводится под самим полем и рядом появляется предупреждение, если запрос не уместился в потолок. В обоих местах показан полезный объём, доставшийся сокету, а не то, что набрано в поле: под полем — в байтах, чтобы сравнивать с ним напрямую, в статистике — округлённо. Отсутствие строки означает, что сокета нет: вход остановлен. Нулевого буфера она не означает никогда. Значение в статистике обновляется вместе с остальными показателями, а под полем оно считывается один раз, при открытии окна потока. Поэтому после сохранения нового размера строка под полем исчезает: сохранение переоткрывает сокет, и прежнее число к нему уже не относится. Чтобы увидеть выданное новому сокету, окно потока закрывают и открывают заново — или смотрят статистику, где значение живое. Параметры задаются отдельным файлом в `/etc/sysctl.d/`: ```bash cat > /etc/sysctl.d/99-pss-net.conf <