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

Ядро 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 COP3/RTP+FEC (SMPTE 2022-1/2).

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 FEC¶

Доставка MPEG-TS поверх RTP с упреждающей коррекцией ошибок (FEC), без обратного канала. В 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 FEC	FEC поверх RTP	не требуется	низкая, фиксированная	открытый (SMPTE 2022-1/2); профессиональное вещательное оборудование

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

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

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

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

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

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

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

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

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

Поддержка и допустимая длина фразы различаются по протоколам:

Протокол	Длина парольной фразы	Особенности
PS1	10–64 байта	—
SRT	10–79 байт	Дополнительно выбирается длина ключа: 128, 192 или 256 бит. Фраза вне допустимой длины останавливает вход или выход с явным сообщением об ошибке.
RIST	не проверяется; используются первые 127 байт	Только в профиле Main. В профиле Simple парольная фраза не действует.
Pro-MPEG	10–64 байта	Нестандартное расширение: при его включении совместимость со сторонним ПО и оборудованием не гарантируется.

Длина фразы считается в байтах, а не в символах: кириллическая буква занимает два байта.

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

Помимо 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-файл и вывод MPEG-TS на устройство (например, ASI); цикличное воспроизведение из файла
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-потоки.