Приём видео: обзор

Какие источники понимает сервер, как выбрать подходящий, как включить приём по требованию и что происходит при обрыве.

Источник задаётся директивой input внутри блока stream. Больше ничего не требуется: имя потока становится путём в URL, а раздача по HLS, DASH, MSE-WS, RTSP и WebRTC поднимается автоматически.

stream cam1 {
  input rtsp://admin:пароль@10.0.0.10:554/Streaming/Channels/101;
}

Схема в начале URL полностью определяет способ приёма — отдельной директивы «тип источника» нет.

Два способа получить видео#

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

Подробности: RTSP, HLS, DASH, MPEG-TS и Приём публикации: RTMP и WHIP.

Источник → когда применять#

Режим по требованию#

По умолчанию сервер подключается к источнику при старте и держит соединение постоянно. Флаг on_demand меняет это: поток не подключается, пока его никто не смотрит, и отключается снова, когда зрителей нет дольше отведённой грации.

on_demand_grace 30;          # глобально, секунды

stream cam1 {
  input rtsp://admin:пароль@10.0.0.10:554/Streaming/Channels/101;
  on_demand;                 # голый флаг = включено
}

Одно и то же значение служит и окном ожидания, и грацией простоя — это сделано намеренно, чтобы поток не «дребезжал» между подключением и отключением.

Что считается спросом: любой запрос HLS (мастер-плейлист, плейлист дорожки, init, сегмент, часть LL-HLS), запрос DASH, апгрейд MSE-WS, подключение HTTP-TS, запрос превью-кадра, запрос WHEP, DESCRIBE или SETUP по RTSP. Спрос засчитывается после проверки прав доступа, поэтому неавторизованный запрос никогда не разбудит закрытую камеру.

Что спросом не считается: публикация по WHIP — это приём, а не просмотр.

Режим экономит трафик до камеры и ресурсы сервера, но добавляет задержку первому зрителю: он ждёт подключения к источнику и первого опорного кадра.

Переподключение и сторожевой таймер#

Обрыв источника не разрушает поток. Кольцевой буфер, зрительские сессии и запись в каталоге переживают переподключение: ни один зритель не отключается и ни один запрос HLS не отвечает 404 во время повторного соединения. В момент возобновления в плейлист вставляется EXT-X-DISCONTINUITY, а звуковая ось пересогласуется заново.

Тайм-ауты приёма зафиксированы в сборке и не настраиваются:

Настраивается другое — сторож «замершего медиа»:

Он ловит самую неприятную неисправность камеры: сокет открыт и здоров, ответы на служебные запросы приходят, а кадры не идут. Каждая дорожка считается отдельно, и дорожка, которая никогда не отдавала данных, ложную тревогу не вызывает — источник без звука не будет переподключаться из-за отсутствующей звуковой дорожки. Отсчёт ведётся по монотонным часам, поэтому перевод системного времени не вызывает срабатывания. Сторож не взводится, если в цепочке источников есть publish://: живой, но молчащий публикатор не должен отключаться.

Что считается ошибкой источника#

Состояние потока видно в панели управления и в API (GET /api/v1/streams). Ключевые поля:

Вердикт рассчитывается так:

• есть текст source_error → failing, причина source_error;
• припаркованный поток on_demand без ошибки → ok (это не сбой, а штатный простой);
• кадров не было ни разу → absent, причина no_source;
• кадров нет 30 секунд и дольше → failing, причина ts_stuck;
• кадров нет 8 секунд и дольше → degraded, причина ts_delay_high;
• иначе → ok.

Срабатывание сторожа замершего медиа показывается как media stall — source frozen (socket alive, no fragments).

curl -sS "https://media.example.com/api/v1/streams" \
  -H "Authorization: Bearer $TOKEN" \
  | python3 -c 'import sys, json
for s in json.load(sys.stdin)["items"]:
    print(s["id"], "alive=" + str(s["alive"]), "health=" + s["health"], s["health_reasons"])'

cam1 alive=True health=ok []
cam2 alive=True health=ok []

Общие директивы источника#

tls_verify управляет доверием к сертификату источника при схемах rtsps://, https:// и rtmps://. Значение проверяется при загрузке конфигурации, поэтому опечатка — это явная ошибка, а не молчаливый откат к системным корневым сертификатам:

stream "cam1": bad tls_verify "pin:zz": invalid verify spec "pin:zz": pin must be 64 hex chars (leaf DER SHA-256)

Наследование через template работает на один уровень: шаблон не может ссылаться на шаблон. Собственные директивы потока всегда важнее унаследованных.

Куда двигаться дальше#

• RTSP, HLS, DASH, MPEG-TS — формы адресов и параметры для каждого забираемого источника.
• Приём публикации: RTMP и WHIP — как настроить приём от кодировщика.
• Резервирование источников — запасной источник и правила переключения.
• Протоколы раздачи — что получат зрители.