Планирование и протоколы передачи данных¶

Ядро Perfect Streamer — надёжная доставка потоков MPEG-TS между узлами через публичную сеть с потерями пакетов и задержками. В этом разделе описана модель передачи, транспортные протоколы и то, как спланировать канал: выбрать протокол, рассчитать полосу, задержку и порты. Детальные настройки отдельных полей вынесены в контекстное описание веб-интерфейса (Веб-интерфейс), а обработка потока на узле — в раздел Streamer: особенности реализации.

Модель передачи: Stream, Sender, Receiver, Peer¶

Единица работы — поток (Stream), один канал MPEG-TS. Для каждого потока настраивается сервер-передатчик (Sender) и один или несколько приёмников (Receiver); связка «передатчик — приёмник» обозначается Peer.

Настройка сводится к спискам входов (input) и выходов (output) для каждого потока:

на передатчике input — источники MPEG-TS, output — передача на приёмники;
на приёмнике input — приём потока от передатчика.

Несколько входов в списке дают резервирование источников, несколько выходов — одновременную раздачу одного канала многим получателям и по разным протоколам.

Для протоколов, где соединение инициирует приёмник, приёмник за NAT подключается к передатчику сам — проброс входящих портов на его стороне не требуется.

Peer-протоколы надёжной передачи¶

Для передачи между передатчиком и приёмником доступны четыре Peer-протокола. Они делятся на два класса по принципу компенсации потерь:

ARQ (Automatic Repeat reQuest) — потерянные пакеты передаются повторно по запросу приёмника. Требует обратного канала и буфера на приёмнике; глубина восстановления настраивается. К этому классу относятся PS1, SRT и RIST.
FEC (Forward Error Correction) — к потоку постоянно добавляются избыточные данные, позволяющие восстановить потери без обратного канала. К этому классу относится Pro-MPEG / RTP+FEC.

PS1 (Perfect Stream)¶

Протокол собственной разработки на базе UDP. Работает по принципу ARQ с выборочной ретрансмиссией. Отличается низкой ресурсоёмкостью и переносит потоки высокого битрейта, включая полноразмерный MPTS.

Соединение инициирует приёмник, поэтому передатчик требует аутентификации: приёмники прописываются как Peer с логином и паролем либо авторизуются по IP. Задержка определяется буфером приёмника (окно устранения джиттера и ретрансмиссии); буфер передатчика должен быть больше буфера приёмников. При смене активного источника на передатчике приёмники не переподключаются — разрыв восстанавливается штатной ретрансмиссией без видимого переподключения.

PS1 — проприетарный протокол и работает только между узлами Perfect Streamer. Особенно эффективен в конфигурации точка-многоточка: один передатчик и много приёмников.

SRT¶

Открытый протокол на базе UDP (UDT). Широко распространён и хорошо компенсирует потери пакетов. Поддерживает режимы listener и caller, что даёт совместимость со сторонним SRT-оборудованием и облачными сервисами.

В режиме listener на передатчике к одному потоку подключается несколько приёмников; для авторизации приёмники прописываются как Peer, доступна авторизация по IP. Инициирующая сторона (caller) может находиться как на приёмнике, так и на передатчике. Запас полосы на ретрансмиссию задаётся в процентах сверх битрейта потока.

На плотных приёмных узлах с большим числом SRT-входов в режиме caller можно отключить встроенную буферизацию приёмника SRT (TSBPD): синхронизацию берёт на себя джиттер-буфер узла (Синхронизация), что заметно снижает нагрузку на CPU.

RIST¶

Открытый протокол на базе RTP/RTCP. Работает по принципу ARQ без ACK, только по NACK, что обеспечивает высокую эффективность. Использует unicast и multicast.

Реализованы профили Simple и Main: Simple занимает два UDP-порта подряд (базовый порт должен быть чётным), Main мультиплексирует данные в один порт. Поддерживается несколько путей (пиров) с взвешенной балансировкой — для резервирования и агрегации. При multicast приёмников может быть много, с авторизацией по IP.

Pro-MPEG / RTP+FEC (SMPTE 2022-1/2)¶

Доставка MPEG-TS поверх RTP с упреждающей коррекцией ошибок (FEC), без обратного канала. Протокол известен также как Pro-MPEG COP3. В PSS реализована двумерная матрица FEC (строки и колонки, SMPTE 2022-2).

Поток RTP-пакетов группируется в матрицу заданного размера, по строкам и колонкам которой формируются FEC-пакеты. Чем меньше матрица, тем лучше восстановление, но выше постоянные накладные расходы. FEC-каналы занимают два дополнительных порта (port+2 и port+4), что нужно учитывать при размещении нескольких потоков на одном хосте или в одной multicast-группе.

Достоинства — низкая фиксированная задержка и совместимость с профессиональным вещательным оборудованием. Недостатки — постоянный дополнительный трафик и слабое восстановление при больших потерях (свыше ~0,2 %), поэтому протокол рассчитан на управляемые каналы с низкими потерями, а не на «тяжёлый» публичный интернет.

Выбор протокола передачи¶

Протокол	Принцип	Обратный канал	Задержка	Совместимость
PS1	ARQ поверх UDP	требуется	настраиваемая	только между узлами Perfect Streamer
SRT	ARQ поверх UDP (UDT)	требуется	настраиваемая	открытый; стороннее SRT-оборудование и облако
RIST	ARQ (NACK) поверх RTP/RTCP	требуется	настраиваемая	открытый; стороннее RIST-оборудование; unicast и multicast
Pro-MPEG / RTP+FEC	FEC поверх RTP	не требуется	низкая, фиксированная	открытый (SMPTE 2022-1/2); профессиональное вещательное оборудование

Ориентиры выбора:

канал между узлами Perfect Streamer, высокий битрейт или полноразмерный MPTS, раздача точка-многоточка — PS1;
совместимость со сторонним оборудованием или облаком, гибкая настройка запаса на ретрансмиссию — SRT;
открытый транспорт на базе RTP, multicast, балансировка по нескольким путям — RIST;
управляемый канал с низкими потерями, минимальная задержка без обратного канала, профессиональное вещательное оборудование — Pro-MPEG / RTP+FEC.

Планирование полосы, задержки и портов¶

ARQ-протоколы (PS1, SRT, RIST). Потери компенсируются повторной передачей, поэтому нужно предусмотреть:

обратный канал от приёмника к передатчику;
запас полосы сверх номинального битрейта — всплески потерь вызывают всплески ретрансмиссионного трафика;
буфер на приёмнике под задержку канала. Чем больше буфер, тем глубже восстановление потерь, но выше сквозная задержка; ориентир — несколько значений RTT. Потоки низкого битрейта требуют большего по времени буфера, чтобы в окне восстановления помещалось достаточно пакетов.

FEC-протокол (Pro-MPEG / RTP+FEC). Избыточные пакеты передаются постоянно, независимо от фактических потерь, поэтому накладные расходы фиксированы и зависят от размера матрицы FEC. Обратный канал не нужен, задержка низкая и фиксированная, но восстановление ограничено — этот транспорт для каналов с низкими потерями.

Порты. Каждой слушающей точке нужен уникальный UDP-порт в пределах хоста или группы. Дополнительно учитывайте, что профиль RIST Simple занимает два порта подряд (чётный базовый и следующий), а Pro-MPEG — базовый порт плюс два FEC-порта (port+2 и port+4). В сети Meshwork общий каталог занятых адресов и портов помогает избегать коллизий (см. Meshwork).

Шифрование потоков¶

Все Peer-протоколы поддерживают шифрование AES по общей парольной фразе, которая вводится на обеих сторонах. Для SRT дополнительно выбирается длина ключа (128, 192 или 256 бит). Шифрование не изменяет битрейт потока.

Для Pro-MPEG шифрование является нестандартным расширением, поэтому при его включении совместимость со сторонним ПО и оборудованием не гарантируется.

Другие входы и выходы¶

Помимо Peer-протоколов доступны стандартные транспорты для приёма и передачи:

Протокол	Вход	Выход	Примечание
UDP	да	да	unicast/multicast, SSM, выбор интерфейса; до 7 TS-пакетов на датаграмму
RTP	да	да	восстановление порядка переставленных пакетов
TCP	да	—	режим клиента; приём там, где UDP заблокирован
HLS / HTTP	да	да	на приёме выбирается вариант адаптивного плейлиста по настраиваемому номеру (по умолчанию первый); вход — только для SPTS
RTSP	да	—	IP-камеры и RTSP-серверы; авто-ремукс в MPEG-TS; только для SPTS
RTMP / RTMPS	да	да	публикация на сторонние RTMP-приёмники; H.264 и HEVC; только для SPTS
file / device	да	да	запись в TS-файл и вывод на устройство (в т.ч. SDI); цикличное воспроизведение из файла
pipe (FIFO)	да	да	мост к внешнему процессу через именованный канал
std (внешнее приложение)	да	да	мост к нештатным протоколам через консольное приложение

Публикация и приём RTMP описаны в Публикация и приём RTMP; RTSP, HLS/HTTP-вход, файлы и устройства, именованные каналы и внешние приложения — в Прочие входы и выходы. Детальные настройки каждого транспорта — в разделе Веб-интерфейс. OTT-раздача (HLS, LL-HLS, DASH) описана отдельно в OTT и DVR.

Резервирование источников и раздача¶

Резервирование. Для потока можно задать несколько входов; активен всегда только один. При аварии активного входа поток автоматически переключается на следующий по списку, а при восстановлении может возвращаться к приоритетному источнику. Это позволяет заранее спланировать основной и резервные источники канала; детальные настройки переключения входов описаны в SPTS-потоки.

Раздача. Несколько выходов на один поток позволяют раздавать один канал сразу многим получателям и по разным протоколам одновременно.

Требования к входному потоку¶

Соответствие ISO/IEC 13818-1, Single Program (SPTS) или Multi Program Transport Stream (MPTS).
Состав дорожек — по выбранному типу контента SPTS-потока, см. SPTS-потоки.
Скремблированные (закодированные) потоки поддерживаются, см. SPTS-потоки.
Для синхронизации в потоке должны быть валидные метки PCR.

Фильтрация, модификация и режимы битрейта входного потока описаны в SPTS-потоки, особенности мультиплекса — в MPTS-потоки.