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

RTMP — классический протокол для CDN и стриминговых платформ

06-02-02

RTMP (Real-Time Messaging Protocol) — один из старейших и наиболее устоявшихся протоколов для передачи потокового видео и аудио в режиме реального времени. Несмотря на свою возрастную архитектуру, RTMP продолжает широко использоваться в современных видеосистемах, особенно при публикации стримов на популярные платформы, такие как YouTube, Twitch, а также на локальные медиасерверы. В этом разделе мы рассмотрим, как FFMPEG работает с RTMP, какие команды используются, и на что влияют ключевые параметры при настройке трансляции.

Команда публикации на RTMP-сервер​

Рассмотрим типичную команду FFMPEG для отправки видеофайла в RTMP-сервер:

ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -c:a aac -f flv rtmp://server/app/stream

Эта команда означает следующее:

  • -re — читать входной файл в реальном времени (realtime).
  • -i input.mp4 — указывает на источник: видеофайл на диске.
  • -c:v libx264 — кодировать видео с помощью кодека H.264.
  • -preset veryfast — ускорить кодирование за счёт небольшого снижения эффективности сжатия.
  • -c:a aac — кодировать аудио в формате AAC.
  • -f flv — задать формат выходного контейнера как FLV.
  • rtmp://server/app/stream — адрес назначения, где:
    • server — IP или доменное имя сервера,
    • app — приложение (например, live),
    • stream — имя потока.

Такая команда часто используется для тестирования, демонстрации или подготовки трансляции из записанного файла.

Зачем нужен флаг -re?​

Когда FFMPEG читает видео из файла, по умолчанию он обрабатывает его максимально быстро — то есть декодирует и отправляет поток в выходной протокол без учёта временных меток. Это может привести к тому, что весь файл будет «залит» на сервер за несколько секунд, что:

  • перегружает RTMP-сервер,
  • вызывает ошибки буферизации у клиентов,
  • нарушает синхронизацию аудио и видео.

Флаг -re эмулирует реальное время воспроизведения. FFMPEG будет читать кадры с той же скоростью, с которой они были записаны — например, 25 или 30 кадров в секунду. Это критически важно при публикации файлов в потоковые платформы, чтобы избежать «засыпания» сервера и обеспечить плавный приём у зрителей.

Пример: если у вас 10-минутный файл, с -re он будет отправляться ровно 10 минут. Без -re — за 1–2 секунды.

Контейнер FLV как обёртка для RTMP​

RTMP изначально разрабатывался компанией Adobe для Flash-плееров, и его естественным контейнером является FLV (Flash Video). FFMPEG использует FLV как формат упаковки видео и аудио потоков при отправке по RTMP.

Ключевые особенности FLV:

  • Поддерживает H.264 и AAC — основные кодеки для стриминга.
  • Имеет минимальные накладные расходы.
  • Не поддерживает современные кодеки, такие как H.265 или AV1.
  • Структура позволяет передавать данные потоком, без предварительного чтения всего файла.

Поэтому, даже если исходный файл — MP4, FFMPEG перепаковывает его в FLV при отправке по RTMP. Это делается автоматически, если указан -f flv.

Важно: несмотря на устаревшее происхождение, FLV остаётся актуальным именно в контексте RTMP. Современные RTMP-серверы (например, nginx-rtmp, Wowza, OBS) корректно обрабатывают FLV-потоки.

Типичный пайплайн: от камеры до CDN​

На практике RTMP редко используется как конечная цель. Чаще он выступает транзитным протоколом в цепочке доставки видео. Типичная схема выглядит так:

IP-камера → FFMPEG (транскодирование/ремультиплексирование) → RTMP → CDN (YouTube, Twitch, локальный сервер) → Зрители

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

  1. Онлайн-трансляция с камеры
    Камера выдаёт RTSP-поток. FFMPEG принимает его, перекодирует (если нужно) и отправляет в YouTube через RTMP:

    ffmpeg -i rtsp://camera_ip:554/stream -c:v libx264 -preset veryfast -c:a aac -f flv rtmp://a.rtmp.youtube.com/live2/your-key

  2. Студийная трансляция
    FFMPEG комбинирует несколько источников (камеры, экран, аудио) и отправляет итоговый поток в Twitch.

  3. Локальный медиасервер
    RTMP-потоки собираются на внутренний сервер (например, с помощью nginx-rtmp), а затем перераздаются в HLS или SRT.

RTMP здесь играет роль унифицированного входного интерфейса, который понимают почти все стриминговые платформы.

Задержка при использовании RTMP​

Одно из главных ограничений RTMP — недостаточная оптимизация по задержке, особенно при использовании через публичные CDN.

Где возникает задержка?​

ЭтапИсточник задержки
FFMPEGБуферы ввода, кодирования, мультиплексации
RTMP-серверВнутренние буферы, балансировка, ретрансляция
CDNКэширование, сегментация, географическое распределение
КлиентБуферизация плеера для стабильности воспроизведения

Общая задержка может составлять от 5 до 30 секунд, особенно при использовании YouTube или Twitch.

Как уменьшить задержку?​

FFMPEG предоставляет ряд параметров для минимизации латентности:

  • -tune zerolatency — оптимизация кодера H.264 для минимальной задержки.
  • -g 30 — установка GOP (Group of Pictures) в 30 кадров (или меньше). Чем короче GOP, тем чаще ключевые кадры и тем быстрее можно начать воспроизведение.
  • -bf 0 — отключение B-кадров, которые требуют буферизации будущих кадров.
  • -maxrate 3000k -bufsize 6000k — ограничение битрейта и размера буфера VBV (Video Buffering Verifier), что помогает избежать «всплесков» и переполнения.

Пример команды с низкой задержкой:

ffmpeg -re -i input.mp4 \
  -c:v libx264 -preset veryfast -tune zerolatency \
  -g 30 -bf 0 -maxrate 3000k -bufsize 6000k \
  -c:a aac -b:a 128k \
  -f flv rtmp://server/app/stream

Примечание: слишком агрессивное снижение задержки может ухудшить качество видео и стабильность потока, особенно при нестабильном соединении.

Почему RTMP всё ещё используется?​

Несмотря на высокую задержку, RTMP остаётся популярным по нескольким причинам:

  • Универсальность: почти все платформы принимают RTMP-вход.
  • Простота настройки: легко интегрировать с FFMPEG, OBS, видеосерверами.
  • Стабильность: хорошо работает по TCP, обеспечивает надёжную доставку.
  • Поддержка транскодирования: сервер может перекодировать поток под разные параметры качества и форматы (HLS, DASH).

Однако для интерактивных сценариев (видеозвонки, вебинары с обратной связью, live-игры) RTMP не подходит из-за задержки. Здесь применяются более современные протоколы: SRT, WebRTC, CMAF.

Итоги​

  • RTMP — классический, но не оптимальный по задержке протокол для стриминга.
  • FFMPEG использует FLV как контейнер при отправке по RTMP.
  • Флаг -re критически важен при работе с файлами, чтобы избежать «заливки» сервера.
  • RTMP часто используется как входной протокол для CDN (YouTube, VK), но не как конечный формат доставки.
  • Задержка зависит от множества факторов: буферов FFMPEG, настроек кодирования, политики сервера и CDN.
  • Для снижения латентности применяют: -tune zerolatency, короткий GOP, отключение B-кадров, управление буферами.

RTMP — это «рабочая лошадка» потокового видео, но не инструмент для ультранизкой задержки. В следующих разделах мы рассмотрим более современные альтернативы, такие как SRT и WebRTC, которые лучше подходят для интерактивных задач.