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

07-03-03 Базовый RTSP-клиент: минимальная цепочка

Теперь, когда мы познакомились с архитектурой GStreamer и научились читать простые команды gst-launch-1.0, пришло время перейти к главной практической теме курса — работе с RTSP-потоками. В этом разделе мы разберём минимальный, но рабочий пайплайн для приёма видео с IP-камеры по протоколу RTSP. Это будет первое реальное доказательство того, что RTSP-поток может передаваться с очень низкой задержкой, особенно при правильной настройке.

Пример минимального пайплайна для RTSP-камеры​

Рассмотрим следующую команду:

gst-launch-1.0 rtspsrc location=rtsp://user:pass@ip/stream latency=0 ! decodebin ! videoconvert ! autovideosink

Эта строка — полный, самодостаточный пайплайн, способный подключиться к реальной IP-камере, принять поток, расшифровать его и вывести на экран. Давайте разберём её по частям, чтобы понять, как работает каждый элемент и зачем он нужен.

Элемент rtspsrc: вход в мир RTSP​

rtspsrc — это источник, отвечающий за приём RTSP-потока. Он не просто «скачивает видео», а выполняет несколько сложных задач:

  1. RTSP-сигналинг — устанавливает соединение с камерой по протоколу RTSP (как HTTP-запрос «включи поток»).
  2. Приём RTP-пакетов — после установки сессии начинает получать видеоданные, упакованные в RTP (Real-time Transport Protocol).
  3. Управление джиттер-буфером — сглаживает неравномерность прихода пакетов из-за сетевых задержек.

Параметр location​

Указывает адрес RTSP-потока:

rtsp://user:pass@ip/stream
  • user:pass — логин и пароль (если камера требует аутентификацию).
  • ip — IP-адрес камеры.
  • /stream — путь к потоку (может быть /live, /h264, /unicast и т.п. — зависит от модели камеры).

⚠️ Если вы не знаете точный путь, попробуйте посмотреть документацию камеры или использовать утилиты вроде ffprobe rtsp://... для анализа.

Параметр latency: ключ к низкой задержке​

latency=0

Этот параметр задаёт время в миллисекундах, которое rtspsrc будет ждать пропущенные или задержанные RTP-пакеты, прежде чем продолжить декодирование.

  • latency=0 — минимальная задержка: пакеты обрабатываются почти сразу, без буферизации.
    ✅ Подходит для локальной сети (LAN), где пакеты редко теряются.
    ⚠️ При нестабильной сети может привести к артефактам или обрывам.

  • latency=50, latency=100 — более устойчивый режим: буфер компенсирует сетевой джиттер.
    ✅ Подходит для Wi-Fi или WAN.
    ❌ Увеличивает общую задержку.

💡 Это один из ключевых параметров для баланса между «живостью» изображения и стабильностью. В локальной сети всегда начинайте с latency=0.

decodebin: «умный» декодер​

После rtspsrc идёт decodebin:

! decodebin !

decodebin — это специальный элемент-автомат, который:

  • Анализирует входящие данные (например, H.264, H.265, MJPEG).
  • Сам выбирает подходящий декодер (avdec_h264, vtdec_h265, omxh264dec и т.п.).
  • Подключает его в пайплайн автоматически.

Почему это удобно?​

Вы не обязаны знать, какой кодек использует камера. decodebin сам «подберёт» нужный декодер, как универсальный ключ.

🔄 Это аналог uridecodebin, но decodebin работает только с уже распакованными данными (например, после rtspsrc), тогда как uridecodebin может сам подключиться к потоку.

videoconvert: согласование форматов​

Следующий элемент:

! videoconvert !

Он преобразует видеоформат (цветовое пространство, глубину цвета и т.п.) в тот, который понимает следующий элемент — в данном случае autovideosink.

Пример проблемы без videoconvert​

Допустим:

  • Камера отправляет видео в формате NV12.
  • Видеовыход (autovideosink) ожидает I420.

Без videoconvert пайплайн не соберётся, потому что элементы не договорятся о формате.

videoconvert решает эту проблему: он умеет перекодировать между большинством стандартных форматов в реальном времени.

autovideosink: вывод на экран​

Последний элемент:

! autovideosink

autovideosink — это универсальный приёмник, который:

  • Автоматически выбирает подходящий способ вывода видео (X11, Wayland, DRM и т.п.).
  • Создаёт окно и отображает в нём кадры.

🖥️ Это как «видеовыход» на задней панели видеокарты: вы подключаете кабель — и изображение появляется.

Альтернативы:

  • ximagesink — для X11 (устаревший, но надёжный).
  • waylandsink — для Wayland.
  • fpsdisplaysink — как autovideosink, но с отображением FPS.

Как работает весь пайплайн: пошагово​

Давайте проследим путь данных:

  1. rtspsrc:

    • Подключается к rtsp://user:pass@ip/stream.
    • Выполняет RTSP-запрос DESCRIBE и PLAY.
    • Начинает получать RTP-пакеты с видео.
    • Собирает их в джиттер-буфере (размер — latency=0 мс).
    • Передаёт RTP-поток дальше.

  2. decodebin:

    • Получает RTP-данные, распаковывает их (если нужно).
    • Определяет кодек (например, H.264).
    • Автоматически подключает avdec_h264 (или другой декодер).
    • Декодирует поток в несжатое видео (например, NV12).

  3. videoconvert:

    • Преобразует NV12 → I420 (или другой формат, нужный для вывода).

  4. autovideosink:

    • Получает несжатые кадры.
    • Отображает их в окне.

Почему это доказательство «почти без задержки»?​

Комбинация:

  • latency=0 — убирает буфер задержки в rtspsrc;
  • decodebin — работает без лишней буферизации;
  • autovideosink — выводит кадры сразу по готовности;

— позволяет достичь общей задержки 50–150 мс в локальной сети. Это визуально незаметно для мониторинга, видеоконференций или интеграции в OBS.

🔍 Для сравнения: типичный FFMPEG-вывод через ffplay может иметь задержку 300–1000 мс из-за больших буферов по умолчанию.

Таблица: элементы пайплайна и их роль​

ЭлементТипНазначение
rtspsrcsourceПодключение к RTSP-камере, приём RTP-потока, управление задержкой
decodebinfilterАвтоматический выбор и подключение декодера под кодек камеры
videoconvertfilterПреобразование формата видео для совместимости с выводом
autovideosinksinkАвтоматический вывод видео на экран

Практические советы​

  1. Начинайте с latency=0 в локальной сети. Если появляются артефакты — увеличьте до 50.
  2. Если пайплайн не запускается — проверьте:
    • Правильность URL (rtsp://...).
    • Доступность камеры по сети (ping, telnet ip 554).
    • Нужен ли пароль (иногда камера требует ?tcp или &tcp в конце URL).
  3. Для отладки добавьте verbose: 
    GST_DEBUG=2 gst-launch-1.0 ...
    Это покажет, какие элементы создаются и где может быть ошибка.

Заключение​

Мы рассмотрели минимальный, но рабочий RTSP-клиент на GStreamer. Этот пайплайн — основа для всех последующих улучшений: добавления низкой задержки, оверлеев, мультивью, интеграции в Python и OBS.

Теперь вы можете:

  • Подключиться к любой RTSP-камере.
  • Управлять задержкой через latency.
  • Понимать, зачем нужны decodebin, videoconvert и autovideosink.

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