06-06-02 Приёмы уменьшения задержки в FFMPEG

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

В этом разделе мы рассмотрим основные приёмы снижения задержки, разделив их по этапам обработки потока: от входа до вывода. Каждый из них сопровождается пояснением, примерами и рекомендациями по применению.

---

Входной этап: снижение буферизации на приёме

На входе в FFMPEG задержка может возникать из-за буферов операционной системы и самого FFMPEG, которые накапливают данные перед началом обработки. Это особенно заметно при работе с RTSP, RTMP и другими сетевыми протоколами, где пакеты могут приходить с переменной задержкой (джиттер).

Ключевые опции для снижения входной задержки

• -fflags nobuffer
  Эта опция отключает внутренний буфер демультиплексора FFMPEG. Обычно FFMPEG накапливает несколько пакетов, чтобы стабильно определить формат потока и синхронизировать аудио и видео. При включении nobuffer он начинает обработку сразу после получения первого пакета, что уменьшает начальную задержку.

  ⚠️ Важно: может привести к ошибкам, если поток нестабилен или не содержит достаточной информации в первых пакетах.

• -flags low_delay
  Применяется к декодеру и указывает ему использовать стратегию минимальной задержки. Особенно полезно при декодировании потоков с B-кадрами, где по умолчанию декодер может буферизовать кадры для правильного восстановления порядка.

• -rtbufsize — ограничение размера буфера RTSP
  Эта опция задаёт максимальный размер буфера, который FFMPEG выделяет для приёма RTSP-потока (в байтах). По умолчанию он может быть достаточно большим, что добавляет задержку.
  Пример:

  ffmpeg -rtbufsize 1M -i rtsp://camera/stream ...

  Здесь буфер ограничен 1 МБ. Уменьшение этого значения ускоряет реакцию на поступление данных, но повышает риск переполнения при сетевых всплесках.

• Настройка TCP receive buffer
  На системном уровне можно уменьшить размер буфера приёма TCP, чтобы ОС не накапливала пакеты. Это делается через параметры ядра (например, net.core.rmem_default) или через специфичные опции в FFMPEG (в некоторых версиях поддерживается tcp_nodelay=1 или tcp_mss).

---

Кодирование: оптимизация видеокодека H.264

Кодирование — один из самых «тяжёлых» и буфероёмких этапов. Видеокодек H.264 (libx264) по умолчанию оптимизирован для качества и эффективности сжатия, а не для минимальной задержки. Однако с помощью специальных параметров его можно адаптировать под задачи реального времени.

Основные настройки для low-latency кодирования

Параметр	Назначение	Рекомендуемое значение
-tune zerolatency	Оптимизация кодека под минимальную задержку	zerolatency
-g	Размер GOP (группы кадров)	25–30 (или меньше, например 15)
-bf 0	Отключение B-кадров	0
-bufsize	Размер буфера виртуального декодера (VBV)	500k–1M (меньше — быстрее отклик)
-preset ultrafast или veryfast	Скорость кодирования	ultrafast для мин. задержки

Пояснения:

• -tune zerolatency
  Эта опция автоматически настраивает кодек на работу без look-ahead, отключает B-кадры (если не заданы явно) и уменьшает буферизацию. Она является «ярлыком» для нескольких низкоуровневых оптимизаций.

• Маленький GOP (-g N)
  GOP — это расстояние между I-кадрами. Чем меньше GOP, тем чаще появляются ключевые кадры, и тем быстрее можно начать декодирование при подключении. Однако слишком частые I-кадры увеличивают битрейт.
  Пример: -g 30 при 30 кадрах в секунду означает I-кадр каждую секунду.

• Отключение B-кадров (-bf 0)
  B-кадры требуют, чтобы следующие по времени кадры уже были закодированы, поэтому они вносят задержку в кодировании и декодировании. Отключение B-кадров (-bf 0) устраняет эту задержку, но может немного снизить эффективность сжатия.

• Уменьшение -bufsize
  Параметр -bufsize задаёт размер буфера VBV (Video Buffering Verifier), который имитирует поведение приёмника. Большой буфер сглаживает битрейт, но добавляет задержку. Уменьшение его до разумного минимума (например, 500 Кбит) позволяет быстрее реагировать на изменения нагрузки.

---

Фильтрация: минимизация влияния фильтров

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

Рекомендации:

• Избегайте тяжёлых фильтров в real-time сценариях
  Фильтры вроде hqdn3d (шумоподавление) или yadif (деинтерлейсинг) могут буферизовать несколько кадров, чтобы выполнить обработку. В задачах с низкой задержкой их лучше отключить или заменить на более лёгкие аналоги.

• Упрощайте цепочки фильтров
  Каждый дополнительный этап в filter_complex увеличивает общую задержку. Например, вместо:

  [0:v]scale=...,hqdn3d,setpts=...,drawtext=...,overlay=...[out]

  рассмотрите возможность удаления hqdn3d или переноса drawtext на сторону камеры или плеера.

• Используйте аппаратное ускорение, если возможно
  Некоторые фильтры (например, scale_cuda) выполняются на GPU и могут быть быстрее, чем CPU-аналоги, особенно при масштабировании.

---

Сетевой вывод: выбор протокола и транспорта

Протокол вывода напрямую влияет на общую задержку. Некоторые протоколы по своей природе более «медленные», другие — более чувствительны к потерям, но быстрее.

Сравнение протоколов по задержке

Протокол	Типичная задержка	Особенности
UDP / RTP / MPEG-TS	50–200 мс	Минимальные накладные расходы, нет подтверждения доставки, подходит для LAN
SRT	100–300 мс	Надёжная доставка с восстановлением, параметр latency управляет буфером
RTMP	200–1000 мс	Широко используется, но имеет внутренние буферы на сервере и в FFMPEG
HLS	5–30 сек	Сегментированный стриминг, не подходит для real-time

Рекомендации:

• Используйте UDP вместо TCP, если сеть стабильна
  TCP обеспечивает надёжность, но при потерях пакетов вызывает задержки из-за повторной передачи. UDP передаёт пакеты «и всё» — быстрее, но с риском потерь. В локальной сети (LAN) или при использовании FEC (Forward Error Correction) это допустимо.

• Настройте параметр latency в SRT
  При использовании SRT можно явно задать задержку буферизации:

  ffmpeg -i input -f mpegts "srt://ip:port?mode=caller&latency=120"

  Здесь latency=120 означает буфер в 120 мс. Чем меньше — тем ниже задержка, но выше риск потерь при джиттере.

---

Наглядный эксперимент: сравнение задержки при разных настройках

Чтобы продемонстрировать эффект от оптимизаций, можно провести простой эксперимент:

Сценарий:

1. Подключение к RTSP-камере.
2. Транскодирование в H.264 и отправка в RTMP-сервер.
3. Измерение задержки между реальным временем и отображением в плеере.

Вариант 1: «Обычная» настройка

ffmpeg -i rtsp://camera/stream \
  -c:v libx264 -preset medium -g 50 -bf 2 \
  -f flv rtmp://server/app/stream

→ Задержка: ~800 мс

Вариант 2: Агрессивное снижение задержки

ffmpeg -fflags nobuffer -flags low_delay \
  -rtbufsize 1M \
  -i rtsp://camera/stream \
  -c:v libx264 -preset ultrafast -tune zerolatency -g 15 -bf 0 -bufsize 500k \
  -f flv rtmp://server/app/stream

→ Задержка: ~200–300 мс

🔍 Как измерить задержку?
Показать на экране рядом с камерой цифровые часы или таймер, зафиксировать их в кадре, и сравнить с временем в плеере. Разница — и есть общая задержка.

---

Выводы

Снижение задержки в FFMPEG — это комплексная задача, требующая настройки на всех этапах пайплайна:

• На входе — отключение буферов и ускорение приёма.
• В кодировании — отказ от B-кадров, уменьшение GOP и буферов.
• В фильтрации — упрощение или удаление тяжёлых операций.
• На выходе — выбор быстрого протокола и настройка его параметров.

Однако важно помнить: каждое снижение задержки может стоить в виде ухудшения качества, стабильности или увеличения нагрузки на CPU. Поэтому инженер должен выбирать баланс в зависимости от сценария — например, 300 мс задержки приемлемы для видеонаблюдения, но недопустимы для видеозвонка.

В следующем разделе мы обсудим, почему FFMPEG, несмотря на все возможности, не всегда подходит для задач с ультранизкой задержкой, и как альтернативные инструменты вроде GStreamer позволяют достичь ещё более высокой гибкости и контроля.