06-02-01 RTSP/RTP: работа с IP-камерами и ONVIF-устройствами

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

---

Основная команда: подключение к IP-камере

Типичная команда FFMPEG для приёма видеопотока с IP-камеры выглядит так:

ffmpeg -rtsp_transport tcp -i rtsp://user:pass@ip/stream1 -c copy out.mkv

Разберём её по частям:

• -rtsp_transport tcp — указывает, что для передачи данных между клиентом и камерой должен использоваться TCP в качестве транспортного протокола поверх RTSP.
• -i rtsp://user:pass@ip/stream1 — адрес источника. Здесь:
  • user:pass — учётные данные для аутентификации,
  • ip — IP-адрес камеры,
  • /stream1 — путь к конкретному видеопотоку (часто соответствует профилю в настройках камеры).
• -c copy — указывает FFMPEG не перекодировать видео и аудио, а просто скопировать потоки (так называемая ремультиплекация).
• out.mkv — выходной файл в контейнере Matroska (MKV), в который будет записан поток.

Эта команда — базовый шаблон для записи потока с IP-камеры без перекодирования, что минимизирует нагрузку на процессор и сохраняет исходное качество.

---

Выбор транспорта: TCP, UDP или UDP Multicast

Протокол RTSP управляет сессией, но сам по себе не передаёт видео. Видеоданные передаются через RTP, который может работать поверх TCP или UDP. Выбор транспорта влияет на стабильность, задержку и пропускную способность.

Варианты транспорта в FFMPEG

Опция	Транспорт	Плюсы	Минусы	Когда использовать
-rtsp_transport tcp	TCP	Надёжная доставка, проходит через NAT и фаерволы	Более высокая задержка, риск буферизации	Стабильная сеть с потерями, сложные сетевые условия
-rtsp_transport udp	UDP	Низкая задержка, минимальные накладные расходы	Потеря пакетов при перегрузке сети	Локальная сеть с высокой пропускной способностью
-rtsp_transport udp_multicast	UDP Multicast	Эффективно для рассылки одного потока множеству получателей	Требует поддержки multicast в сети, сложнее настроить	Распределённые системы видеонаблюдения, видеостены

Практическое различие

• UDP — пакеты RTP отправляются «в слепую». Если сеть перегружена, часть кадров может потеряться, но задержка будет минимальной.
• TCP — данные передаются надёжно, с подтверждением получения. При потерях пакетов они перезапрашиваются, что может вызвать буферизацию и увеличение задержки, но изображение будет цельным.

💡 Рекомендация: в локальной сети (LAN) с хорошей пропускной способностью и низким уровнем потерь — используйте udp. В сложных сетях (WAN, Wi-Fi, через NAT) — предпочтительнее tcp.

---

Что делает -c copy и зачем он нужен

Опция -c copy означает копирование потоков без перекодирования. FFMPEG не декодирует и не кодирует видео и аудио, а просто перемещает пакеты из входного контейнера (RTSP/RTP) в выходной (например, MKV или FLV).

Почему это важно?

1. Минимальная нагрузка на CPU — не задействуется видеокодировщик (например, libx264), что позволяет запускать десятки таких процессов на одном сервере.
2. Сохранение качества — не происходит пережатия или потерь из-за повторного кодирования.
3. Минимальная задержка — отсутствие этапа кодирования ускоряет обработку.

⚠️ Важно: -c copy работает только если кодеки входного и выходного форматов совместимы. Например, если камера передаёт H.264, а выходной контейнер (MKV) его поддерживает — всё в порядке. Если нужно изменить кодек, разрешение или битрейт — -c copy использовать нельзя.

---

Задержка при приёме RTSP: откуда она берётся

Даже при использовании TCP или UDP, приём RTSP-потока в FFMPEG может вносить задержку в несколько секунд. Это происходит из-за нескольких встроенных буферов:

Основные источники задержки

1. Буферы сокетов — операционная система накапливает пакеты, прежде чем передать их FFMPEG.
2. Reordering RTP — пакеты RTP могут приходить не по порядку, FFMPEG должен их переупорядочить.
3. De-jitter буфер — компенсирует неравномерную задержку прихода пакетов (джиттер), чтобы видео воспроизводилось плавно.

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

FFMPEG предоставляет опции для управления буферизацией:

Опция	Назначение
-fflags nobuffer	Отключает внутренний буфер демультиплексора — данные передаются «как можно быстрее»
-flags low_delay	Уменьшает задержку в декодере (если используется)
-rtbufsize size	Устанавливает размер буфера для RTSP-потока (по умолчанию ~8 МБ). Уменьшение снижает задержку, но может вызвать обрывы при потерях. Пример: -rtbufsize 1M

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

ffmpeg -rtsp_transport tcp -fflags nobuffer -flags low_delay -rtbufsize 1M -i rtsp://user:pass@ip/stream1 -c copy out.mkv

---

ONVIF и получение RTSP-URL

ONVIF (Open Network Video Interface Forum) — стандарт, позволяющий управлять IP-камерами от разных производителей через единый интерфейс.

Как это работает?

1. Клиент (например, VMS — Video Management System) подключается к камере по ONVIF (через SOAP-запросы).

2. Запрашивает список профилей потоков (Profiles).

3. Получает RTSP-URL для каждого профиля, например:

   rtsp://192.168.1.100:554/onvif-media/media.amp?profile=Profile_1

4. Этот URL можно напрямую использовать в FFMPEG как источник.

Пример интеграции

ffmpeg -i "rtsp://192.168.1.100:554/onvif-media/media.amp?profile=Profile_1" -c copy record.mkv

💡 FFMPEG не работает с ONVIF напрямую, но использует RTSP-адреса, полученные через ONVIF. Это делает его идеальным инструментом для автоматизированного приёма потоков из ONVIF-совместимых камер.

---

Наглядный пример: сравнение транспортов через ffplay

Чтобы увидеть разницу между транспортами, можно использовать ffplay — встроенный проигрыватель FFMPEG.

Запуск с разными транспортами

# TCP — стабильно, но с задержкой
ffplay -rtsp_transport tcp rtsp://user:pass@ip/stream1

# UDP — быстрее, но возможны артефакты
ffplay -rtsp_transport udp rtsp://user:pass@ip/stream1

# Multicast — если камера поддерживает
ffplay -rtsp_transport udp_multicast rtsp://user:pass@ip/stream1

Что наблюдать?

• TCP: изображение появляется через 1–2 секунды, стабильное, без рывков.
• UDP: изображение появляется почти мгновенно, но при перегрузке сети могут быть артефакты, «зависания» или потеря кадров.
• Multicast: если сеть настроена правильно — низкая задержка и нагрузка на сеть, но требует настройки маршрутизаторов.

🔍 Совет: используйте ffplay для тестирования камер перед запуском записи или трансляции.

---

Итоги

• RTSP/RTP — стандартный способ приёма видеопотока с IP-камер.
• Выбор транспорта (tcp, udp, udp_multicast) влияет на задержку и стабильность.
• -c copy — ключ к эффективной записи без нагрузки на CPU.
• Задержка возникает из-за буферов; её можно уменьшить с помощью -fflags nobuffer, -flags low_delay, -rtbufsize.
• ONVIF предоставляет RTSP-URL, которые FFMPEG может использовать напрямую.

Эти принципы лежат в основе большинства систем видеонаблюдения, рестриминга и автоматизированного приёма видео — и FFMPEG является незаменимым инструментом для их реализации.