Протоколы раздачи

Полная карта адресов раздачи — HLS, LL-HLS, DASH, MSE-WS, HTTP-TS, RTSP, RTMP, WHEP и превью: задержка, применение и ограничения браузеров.

Принятый поток разбирается один раз и складывается в общий кольцевой буфер фрагментов. Все протоколы раздачи читают этот же буфер: HLS отдаёт фрагменты как сегменты плейлиста, MSE-WS шлёт их в браузер по вебсокету, RTSP распаковывает их обратно в пакеты. Переупаковка не повторяется.

Отсюда главный практический вывод: включать «лишние» протоколы раздачи не вредно. Стоимость несёт поток и число отправленных байт, а не количество включённых протоколов.

Полная карта раздачи#

Все HTTP-адреса обслуживаются слушателем http (и https) — отдельного медиа-порта нет.

Имя потока может содержать /: cam, live/cam1, cam/<UUID>/main. Все адреса привязаны к концу пути, поэтому внутренние слеши сохраняются.

Дополнительные адреса HLS#

curl -sS -I "https://media.example.com/demo/mse.ws"

HTTP/1.1 204 No Content
Cache-Control: no-store

Что включается директивой#

Директивы внутри блока stream применяются без перезапуска службы — перезапускается только сам поток; глобальные директивы отмечены отдельно.

stream cam1 {
  input rtsp://admin:пароль@10.0.0.10:554/Streaming/Channels/101;
  http_ts;                 # добавить /cam1/stream.ts
  hls_ts;                  # добавить /cam1/mpegts.m3u8
  segment_seconds 2;
  segments_count 5;
}

http_ts и hls_ts используют один и тот же кольцевой буфер MPEG-TS — любой из двух флагов включает мультиплексор.

Задержка#

Задержка у зрителя складывается из двух слоёв. Первый — доставка: путь кадра от источника через сервер до плеера. Второй — буфер плеера: запас между живым краем и точкой воспроизведения, который плеер держит, чтобы неровность сети не превращалась в подвисания картинки. Буфер обычно больше доставки, поэтому именно он определяет итог.

Доставка измерена на стенде разработки с синтетическим источником и настройками по умолчанию; измерялись четыре протокола, остальные в таблицу не попали. Итог у зрителя — целевая задержка встроенного веб-плеера, заложенная в его коде. Это позиция относительно живого края: она уже включает доставку, складывать колонки не нужно. Для RTSP плеер не участвует — буфер задаёт клиент, обычно минимальный.

Цели сдвинуты в сторону плавности сознательно: подвисания недопустимы, поэтому плеер держит запас, гасящий неровность сети, и мягко подтягивается к цели вместо рывков. У обычного HLS и DASH запас — несколько сегментов (цель у них общая, ≈8 с), у MSE-WS — доли секунды. Если задача требует меньшей задержки, целевое значение снижается настройкой плеера.

Реальные значения зависят от источника, сети и плеера. Порядок величин при этом устойчив: обычный HLS отстаёт от эфира на несколько сегментов, LL-HLS — на несколько секунд, MSE-WS — примерно на секунду, RTSP — на доли секунды.

Настройка задержки:

• segment_seconds — целевая длительность сегмента. Реальная длина попадает в диапазон от целевой до целевой плюс интервал между опорными кадрами: сегмент всегда закрывается по опорному кадру. Интервал опорных кадров на камере влияет на задержку сильнее любой серверной настройки.
• segments_count — сколько сегментов держится в живом окне. Меньше — меньше задержка, но у зрителя с плохой связью меньше запаса.
• prepush — насколько позади живого края начинает новый зритель. Больше — устойчивее к плохой связи, меньше — ниже задержка.
• Размер части LL-HLS сервер выбирает сам и объявляет в плейлисте атрибутом PART-TARGET; настройки у него нет.

Какие кодеки доходят до какого зрителя#

Перекодирования нет, поэтому кодек источника определяет всё дальнейшее. Каждый протокол несёт только то, что способен нести:

Несовместимая дорожка не вызывает ошибку — она просто не создаётся. Зритель получает исправное видео без звука, а не сломанный поток.

Звук G.711 и браузеры#

Большинство IP-камер выдают звук G.711, и ни один браузер не умеет декодировать G.711 через Media Source Extensions. Это ограничение браузеров, а не сервера, и исправить его на стороне плеера нельзя.

Сервер обрабатывает это честно: звуковая дорожка G.711 просто не создаётся в браузерных раздачах. Мастер-плейлист HLS не объявляет несуществующую дорожку и не упоминает её в списке кодеков — иначе плеер завис бы на всём варианте, хотя видео исправно.

Потребителей вне браузера это не касается: по RTSP звук G.711 передаётся как есть, и в архив на диске он пишется полностью.

RTSP: транспорт и ограничения#

rtsp://media.example.com:8554/<поток>

Управление дорожками: …/trackID=0 — видео, …/trackID=1 — звук.

Поддерживаемые методы:

OPTIONS, DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN, GET_PARAMETER

Ровно два транспорта: RTP/AVP/TCP;unicast;interleaved= и RTP/AVP;unicast;client_port=. Какой из них разрешён клиенту, задаётся в потоке:

stream cam1 {
  input rtsp://admin:пароль@10.0.0.10:554/Streaming/Channels/101;
  rtsp_transports tcp;      # both (по умолчанию) | tcp | udp
}

Отказы: 461 Unsupported Transport — запрошенный транспорт запрещён или не удалось занять пару UDP-портов; 453 Not Enough Bandwidth — исчерпан лимит max_sessions; 455 — метод не в свою очередь.

Смежные настройки:

Значение rtp_max_payload 1200 безопасно для туннелей и VPN. Внутри локальной сети с MTU 1500 его можно поднять примерно до 1460 и сэкономить на заголовках. rtsp_frame_source raw_au берёт кадры из буфера отдельных единиц доступа — задержка чуть ниже.

printf 'OPTIONS rtsp://media.example.com:8554/demo RTSP/1.0\r\nCSeq: 1\r\n\r\n' \
  | timeout 5 nc media.example.com 8554

RTSP/1.0 200 OK
CSeq: 1
Public: OPTIONS, DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN, GET_PARAMETER

Варианты мастер-плейлиста для приставок и телевизоров#

Некоторые устройства не справляются с отдельной звуковой дорожкой в мастер-плейлисте. Для них предусмотрен параметр ?variant=, действующий только на мастер-плейлист:

curl -sS "https://media.example.com/demo/master.m3u8?variant=video" | head -5

#EXTM3U
#EXT-X-VERSION:9
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-STREAM-INF:BANDWIDTH=10803752,AVERAGE-BANDWIDTH=9003127,CODECS="avc1.64001F",RESOLUTION=1280x720,FRAME-RATE=25.000,CLOSED-CAPTIONS=NONE
v0/playlist.fmp4.m3u8?sid=281474976710657

Директива audio_only_playlist; добавляет в мастер-плейлист вариант «только звук» — этого требуют правила публикации некоторых мобильных платформ.

Раздача MPEG-TS в группу#

stream cam1 {
  input rtsp://admin:пароль@10.0.0.10:554/Streaming/Channels/101;
  multicast_out 239.1.1.1:5000 ttl=4 iface=10.0.0.5 loopback=1 tos=184;
}

Равнозначная форма — со строкой запроса: multicast_out 239.1.1.1:5000?ttl=4&iface=10.0.0.5.

Группа обязана быть литеральным адресом IPv4. Значение проверяется при загрузке конфигурации:

stream "cam1": bad multicast_out "239.1.1.1" (expected <group:port>[?ttl=&iface=&loopback=&tos=])

Поток нарезается на датаграммы по 1316 байт; таблицы PAT и PMT периодически повторяются, чтобы поздно подключившийся приёмник смог их получить. Догон ограничен восьмикратной скоростью реального времени, чтобы не захлестнуть приёмники.

Кэширование и CDN#

Смена содержимого выражается именем, а не строкой запроса: init-<16 hex>.mp4, /player/embed.<хеш>.js. Устаревший init-<hex>.mp4 отвечает 410 init rotated — это сигнал плееру перечитать плейлист. Вытесненный сегмент отвечает 410, ещё не созданный — 404.

Тела медиа отдаются с Accept-Ranges: bytes и поддерживают 206 и 416.

Ограничение числа сессий#

Директива max_sessions действует глобально, на все протоколы сразу. Проверка выполняется после авторизации, а на HLS — только при первом обращении к мастер-плейлисту, поэтому уже смотрящий зритель никогда не отключается посреди просмотра из-за исчерпания лимита.

Медленный зритель не мешает остальным: индивидуальных очередей нет, каждый читает общий кольцевой буфер по своему курсору. Отставший «наматывает круг» только сам, а поставщик кадров не блокируется.

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

• Встраиваемый плеер — готовая страница просмотра и её параметры.
• Приём видео: обзор — с какой стороны поток приходит.
• Авторизация просмотра — как закрыть раздачу токенами.
• Порты и сеть — какие порты открывать наружу.