---
title: Протоколы передачи
url: https://doc2.pstreamer.tv/ru/manual/planning/transport.html
lang: ru
product: Perfect Streamer
version: 2.0.2.423
---

# Протоколы передачи

Как доставить поток с одного узла на другой или к стороннему оборудованию. Здесь — какой протокол выбрать, сколько он стоит в полосе и задержке, какие порты занимает и как шифруется.

Если отказывает не канал, а источник, сеть или узел — [Резервирование: что от чего защищает](redundancy.md#planning-redundancy).

## 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.

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

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

### SRT

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

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

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

### RIST

Открытый протокол на базе RTP/RTCP. Работает по принципу ARQ по NACK: приёмник сообщает только о потерях. Использует unicast и multicast.

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

### Pro-MPEG FEC

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

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

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

> **Важно**
>
> **Бета-версия 2.1.** Описанное здесь есть только в бета-версии 2.1: она ставится из бета-репозитория и только с лицензией, в стабильной версии 2.0.2 и в демоверсии этого нет. Бета-версия поставляется без гарантий, поддержка — по возможности ([Программа бета-тестирования](../extras/beta.md#extras-beta)).

В версии 2.1 FEC входа и выхода соответствует SMPTE ST 2022-1:

- стандартные приёмники восстанавливают по нему потери;
- вход принимает FEC только по столбцам (1D) и по столбцам и строкам (2D), с матрицей любого размера;
- выход может отправлять только FEC по столбцам: при матрице 5 × 10 накладные расходы — 10 % вместо 30 %, но восстановление слабее;
- Pro-MPEG сочетается со вторым путём SMPTE ST 2022-7 и с горячим резервом выходов ([Резервирование: что от чего защищает](redundancy.md#planning-redundancy)).

Задержку на ожидание FEC — Планирование полосы, задержки и портов.

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

**Коротко.**

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

Подробнее:

| Протокол | Принцип | Обратный канал | Задержка | Совместимость |
| --- | --- | --- | --- | --- |
| 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); профессиональное вещательное оборудование |

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

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

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

**FEC-протокол (Pro-MPEG).** Избыточные пакеты передаются постоянно, независимо от фактических потерь, поэтому накладные расходы фиксированы и зависят от размера матрицы FEC. Обратный канал не нужен, задержка низкая и фиксированная, но восстановление ограничено, поэтому этот транспорт подходит для каналов с низкими потерями. Восстановление по FEC добавляет задержку на приёме: пока потерянный пакет ждёт FEC своей матрицы, вход задерживает выдачу. Чем больше матрица и ниже битрейт, тем дольше ожидание — при большой матрице и низком битрейте это секунды, и их должен покрывать буфер джиттера входа ([предел ожидания FEC](../webui/io/network.md#webui-io-prompeg-fec-wait)).

**Порты.** Каждой слушающей точке нужен уникальный UDP-порт в пределах хоста или группы. Дополнительно учитывайте, что профиль RIST Simple занимает два порта подряд (чётный базовый и следующий), а Pro-MPEG — базовый порт плюс два FEC-порта (`port+2` и `port+4`). В сети Meshwork общий каталог занятых адресов и портов помогает избегать коллизий (см. [Meshwork](../meshwork/index.md#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](../streamer/rtmp.md#streamer-rtmp); RTSP, HLS/HTTP-вход, файлы и устройства, именованные каналы и внешние приложения — в [Прочие входы и выходы](../streamer/other_io.md#streamer-other-io). Детальные настройки каждого транспорта — в разделе [Веб-интерфейс](../webui/index.md#webui). OTT-раздача (HLS, LL-HLS, DASH) описана отдельно в [OTT и DVR](../streamer/ott_dvr.md#streamer-ott-dvr).

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

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

Фильтрация, модификация и режимы битрейта входного потока описаны в [SPTS-потоки](../streamer/spts.md#streamer-spts), особенности мультиплекса — в [MPTS-потоки](../streamer/mpts.md#streamer-mpts).