Перейти к основному содержимому

SRT и UDP TS: надёжность vs задержка

06-02-03

В этой части лекции мы рассматриваем два подхода к передаче видеопотока по сети — SRT (Secure Reliable Transport) и UDP с MPEG-TS (MPEG-2 Transport Stream). Оба используются для передачи видео в реальном времени, но решают разные задачи: один делает упор на надёжность, другой — на минимальную задержку и простоту. FFMPEG позволяет легко работать с обоими, но выбор между ними зависит от требований к качеству, стабильности и латентности.

SRT: надёжная доставка с контролируемой задержкой​

SRT — это современный протокол, разработанный для передачи потокового видео по ненадёжным сетям (включая интернет) с минимальными потерями и предсказуемой задержкой. Он сочетает в себе механизмы обратной связи, подтверждения доставки, восстановления потерянных пакетов и динамического управления буферами, что делает его идеальным для профессиональных видеопередач.

Примеры использования SRT в FFMPEG​

Приём потока (режим listener):​

ffmpeg -i "srt://192.168.1.100:1234?mode=listener" -c copy out.ts

Эта команда запускает FFMPEG в режиме слушателя (listener): он ожидает входящее SRT-соединение на указанном IP и порту. Как только отправитель подключится, FFMPEG начнёт принимать поток и записывать его в файл out.ts, не перекодируя (-c copy).

Отправка потока (режим caller):​

ffmpeg -i input.ts -f mpegts "srt://192.168.1.100:1234?mode=caller&latency=120"

Здесь FFMPEG выступает в роли инициатора (caller). Он читает файл input.ts, упаковывает его в контейнер MPEG-TS (-f mpegts) и отправляет по SRT на указанный адрес. Параметр latency=120 задаёт целевую задержку в миллисекундах.

⚠️ Важно: latency в SRT — это не минимальная задержка, а максимальный буфер, который протокол может использовать для компенсации потерь и джиттера. Чем больше значение — тем устойчивее передача, но тем выше задержка.

Параметр latency: как он влияет на работу FFMPEG​

Параметр latency в SRT — один из ключевых при настройке баланса между надёжностью и латентностью. Он определяет, сколько времени (в миллисекундах) SRT может «задерживать» поток, чтобы:

  • обнаружить потерянные пакеты;
  • запросить их повторную отправку (ARQ — Automatic Repeat reQuest);
  • восстановить правильный порядок пакетов (reordering);
  • сгладить сетевой джиттер.

Как это работает на практике:​

  • При latency=120 SRT резервирует буфер на ~120 мс.
    → Если пакет пришёл с опозданием, но в пределах этого окна — он будет восстановлен.
    → Если опоздал больше чем на 120 мс — считается потерянным.
  • При latency=50 задержка меньше, но и шанс восстановить пакет — ниже.
    → Подходит для стабильных сетей (LAN, выделенные каналы).
    → Не подходит для интернета с высоким джиттером.
  • FFMPEG автоматически интегрируется с этим буфером:
    → Входной буфер SRT становится частью общего буферного цикла FFMPEG.
    → Уменьшать latency — значит уменьшать запас на восстановление, но снижать общую задержку.

🔍 Совет: в реальных системах latency часто устанавливают в диапазоне 120–500 мс в зависимости от качества канала. Для интернет-трансляций — 300–500 мс, для локальных сетей — 100–200 мс.

UDP с MPEG-TS: минимальные накладные расходы, но без гарантий​

Альтернативой SRT является прямая передача потока через UDP в формате MPEG-TS:

ffmpeg -i input.ts -f mpegts udp://192.168.1.100:1234

Этот способ — один из самых лёгких и быстрых. UDP не требует установки соединения, не подтверждает доставку и не восстанавливает потерянные пакеты. MPEG-TS — стандартный контейнер, устойчивый к ошибкам: он позволяет декодеру продолжать работу даже при частичной потере данных.

Плюсы UDP + MPEG-TS:​

  • Минимальная задержка: нет буферов подтверждения, нет ARQ.
  • Низкая нагрузка на CPU и сеть: нет шифрования, нет служебного трафика.
  • Поддерживается большинством профессиональных устройств (видеомикшеры, рекордеры, мониторы).

Минусы:​

  • Нет гарантии доставки: потерянные пакеты — навсегда.
  • Нет защиты от джиттера: при переменной задержке в сети возможны сбои.
  • Требует стабильной сети и дополнительного запаса по джиттеру на стороне приёмника.

🎯 Пример: если в сети возможен джиттер до 50 мс, приёмник должен иметь буфер минимум на 50 мс, чтобы избежать сбоев. Это дополнительная задержка, которую инженер должен закладывать в систему.

Сравнение SRT и UDP TS: таблица различий​

ПараметрSRTUDP + MPEG-TS
Гарантия доставкиДа (ARQ, восстановление пакетов)Нет
ЗадержкаКонтролируемая (100–500 мс)Минимальная (1–10 мс + джиттер)
Нагрузка на сетьВыше (служебный трафик, ACK)Очень низкая
Устойчивость к потерямВысокаяНизкая
ШифрованиеПоддерживается (AES)Нет (только при внешнем туннеле)
Типичное применениеИнтернет, межстудийные линииЛокальные сети, SDI-over-IP

Где реально используются эти схемы?​

SRT — для «профессионального интернета»:​

  • Межстудийные передачи: трансляция с удалённой площадки в студию.
  • Новостные репортажи: камера в поле → SRT → центр обработки.
  • Рестриминг в CDN: FFMPEG принимает RTSP с камеры, перекодирует и отправляет через SRT на медиасервер.
  • Удалённая работа с видеоматериалами: передача потока в редакцию для монтажа.

💡 SRT особенно ценен, когда нет выделенного канала, но нужна стабильность — например, при использовании 4G/5G.

UDP TS — для «студийной внутренней сети»:​

  • SDI-over-IP: замена коаксиальных кабелей на IP-сеть в телецентре.
  • Межблочные соединения: передача сигнала между видеомикшером, рекордером, монитором.
  • Тестовые генераторы: отправка эталонного потока для проверки оборудования.
  • Синхронные многокамерные системы: когда все камеры и приёмники в одной локальной сети с гарантированной пропускной способностью.

📌 UDP TS — это «цифровой аналог SDI». Он работает быстро и предсказуемо, но только в контролируемой среде.

FFMPEG как переключатель между режимами​

Один из главных плюсов FFMPEG — его гибкость. Вы можете легко переключаться между SRT и UDP TS, просто изменив URL вывода:

# Передача через SRT (надёжно, с задержкой)
ffmpeg -i rtsp://cam -c copy -f mpegts "srt://server:1234?mode=caller&latency=300"

# Передача через UDP (быстро, но без гарантий)
ffmpeg -i rtsp://cam -c copy -f mpegts udp://server:1234

Это позволяет:

  • тестировать разные сценарии в одной инфраструктуре;
  • использовать SRT для внешних соединений и UDP для внутренних;
  • строить гибридные системы, где FFMPEG адаптирует поток под требования каждого участка сети.

Вывод: выбор зависит от контекста​

  • Нужна стабильность по интернету? → Используйте SRT с разумным latency.
  • Работаете в локальной сети с гарантированным каналом? → Выбирайте UDP TS для минимальной задержки.
  • Хотите баланс? → SRT в локальной сети тоже работает отлично, особенно если есть микросбои или джиттер.

FFMPEG не навязывает выбор — он предоставляет инструменты для реализации обоих подходов. Ваша задача как инженера — понимать, где уместна надёжность, а где важнее скорость, и грамотно настраивать параметры, особенно latency, чтобы не «перебуферизовать» систему.