06-04-04 Комбинирование сетевых и локальных источников

06-04-04

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

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

::: info Разумеется, для таких задач используются видеомикшеры: как программные (VMix, OBS, ...), так и аппаратные. Мы рассматриваем эти возможности не для того, чтобы вы завтра сделали телестудию на базе FFMPEG и предложили её Останкино. Эти знания понадобятся для более узких задач в конкретных технических проектах. Еще более вероятно понадобится понимание, что "и так можно было" во многих труднопредсказуемых рабочих ситуациях -- это часть кругозора инженера.

:::

Сценарии комбинирования: локальные + сетевые источники

FFMPEG позволяет объединять разнородные источники в один выходной поток. Ниже приведены типичные примеры, часто встречающиеся в профессиональной практике.

1. Фоновое видео или статичное изображение + живой поток с камеры

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

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

Видеотрансляция лекции: презентация (локальный файл) — фон, а в углу — видео докладчика с камеры (RTSP-поток).
Телевизионный выпуск: на фоне видеоролика — вставка с ведущим в реальном времени.
Видеонаблюдение: на фоне схемы здания — изображение с камеры при тревоге.

Техническая реализация:

ffmpeg -i background.mp4 -i rtsp://user:pass@192.168.1.100:554/stream \
       -filter_complex "[0:v][1:v]overlay=main_w-overlay_w-20:main_h-overlay_h-20" \
       -c:v libx264 -c:a copy -f flv rtmp://streaming-server/live/output

Здесь:

background.mp4 — локальный файл, выступающий в роли основного фона.
RTSP-поток — «живое» видео, накладываемое в правый нижний угол.
Фильтр overlay выполняет наложение одного видео на другое.

💡 Визуализация: Представьте, что вы смотрите на экран, где большая часть занята анимацией презентации, а в правом нижнем углу — маленькое окно с человеком, говорящим в реальном времени. Именно такую композицию и создаёт данная команда.

2. Захват экрана + RTSP-камера

Другой важный сценарий — использование захвата экрана (например, презентации, дашборда или приложения) в сочетании с видеопотоком с камеры.

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

Вебинары: демонстрация слайдов (через захват экрана) + видео спикера.
Учебные платформы: преподаватель объясняет материал, показывая код на экране, а камера фиксирует его реакции.
Оперативные пульты: на экране — карта или схема, поверх — видео с места происшествия.

Техническая реализация (Linux, X11):

ffmpeg -f x11grab -s 1920x1080 -i :0.0+0,0 \
       -i rtsp://cam-ip:554/stream \
       -filter_complex "[0:v][1:v]overlay=10:10" \
       -c:v libx264 -f flv rtmp://server/app/stream

Для Windows (через gdigrab):

ffmpeg -f gdigrab -i desktop \
       -i rtsp://cam-ip:554/stream \
       -filter_complex "[0:v][1:v]overlay=10:10" \
       -c:v libx264 -f flv rtmp://server/app/stream

💡 Примечание: -f x11grab и gdigrab — специальные входные форматы FFMPEG, позволяющие захватывать изображение с экрана. Они работают напрямую с графической подсистемой ОС.

Проблемы синхронизации: локальный файл vs сетевой поток

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

Характеристика	Локальный файл	Сетевой поток (RTSP, SRT, RTMP)
Воспроизведение	Детерминированное: кадры идут строго по расписанию	Недетерминированное: зависит от сети, буферов, задержек
Задержка	Нулевая или предсказуемая	Может варьироваться (джиттер, потери пакетов)
Синхронизация	Легко контролируется	Требует буферизации и выравнивания
Контроль скорости	Полный контроль (ускорение/замедление)	Зависит от источника и протокола

Проблема: локальный файл воспроизводится слишком быстро

Если вы используете локальный файл как фон (например, background.mp4) и не указываете специальных флагов, FFMPEG будет читать его как можно быстрее, а не в реальном времени. Это приводит к тому, что:

Фоновое видео «пролетает» за доли секунды.
Сетевой поток (например, с камеры) не успевает синхронизироваться.
Итоговый поток может начинаться с середины или вообще не стартовать корректно.

Решение: флаг `-re` для эмуляции реального времени

Чтобы заставить FFMPEG воспроизводить локальный файл в реальном времени, как если бы это был «живой» поток, используется флаг -re (от realtime).

Что делает `-re`?

Ограничивает скорость чтения входного файла до оригинальной частоты кадров.
Имитирует поведение потокового источника: кадры подаются с той же скоростью, с которой они были записаны.
Позволяет корректно синхронизировать локальный и сетевой источники.

Пример с `-re`:

ffmpeg -re -i background.mp4 -i rtsp://cam-ip:554/stream \
       -filter_complex "[0:v][1:v]overlay=main_w-overlay_w-20:main_h-overlay_h-20" \
       -c:v libx264 -c:a aac -f flv rtmp://server/app/stream

🔍 Обратите внимание: Без -re фоновое видео будет обработано мгновенно, и выходной поток либо прервётся, либо будет содержать только первый кадр. С -re FFMPEG будет «ждать» нужное время между кадрами, обеспечивая плавное и синхронное воспроизведение.

Дополнительные соображения при комбинировании источников

При построении таких композиций важно учитывать несколько технических аспектов:

1. Выравнивание временных меток (PTS)

Разные источники могут иметь разные временные шкалы. Чтобы избежать рассинхронизации, в сложных сценариях используют фильтры вроде setpts:

[0:v]setpts=PTS-STARTPTS[v0]; [1:v]setpts=PTS-STARTPTS[v1]; [v0][v1]overlay...

Это приводит временные метки обоих потоков к одной отсчётной точке.

2. Аудиосинхронизация

Если оба источника содержат аудио, важно:

Убедиться, что они синхронизированы по времени.
При необходимости использовать фильтр adelay для компенсации задержки одного из потоков.
Рассмотреть возможность отключения аудио с одного источника (-an), если оно не нужно.

3. Нагрузка на систему

Комбинирование нескольких источников — особенно при наличии декодирования, фильтрации и перекодирования — требует значительных ресурсов CPU. Особенно это критично при:

Использовании нескольких RTSP-камер.
Работе с высоким разрешением (1080p и выше).
Применении сложных фильтров (наложение, масштабирование, шумоподавление).

Итог: гибкость FFMPEG в студийных и оперативных сценариях

FFMPEG демонстрирует свою силу именно в таких гибридных сценариях, где требуется гибкое объединение разнородных источников — будь то файлы, экран, камеры или потоки. Умение сочетать локальные и сетевые данные позволяет:

Создавать профессиональные студийные композиции без дорогостоящего ПО.
Организовывать оперативные пульты с мультиисточниковой визуализацией.
Автоматизировать трансляции с динамическим контентом.

Сценарии комбинирования: локальные + сетевые источники​

1. Фоновое видео или статичное изображение + живой поток с камеры​

2. Захват экрана + RTSP-камера​

Проблемы синхронизации: локальный файл vs сетевой поток​

Проблема: локальный файл воспроизводится слишком быстро​

Решение: флаг -re для эмуляции реального времени​

Что делает -re?​

Пример с -re:​

Дополнительные соображения при комбинировании источников​

1. Выравнивание временных меток (PTS)​

2. Аудиосинхронизация​

3. Нагрузка на систему​

Итог: гибкость FFMPEG в студийных и оперативных сценариях​