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

07-07-02 RTSP → UDP, RTMP, SRT: GStreamer как шлюз между протоколами

В этой части мы рассмотрим один из ключевых сценариев использования GStreamer — трансляция (рестриминг) RTSP-потока в другие транспортные протоколы. Это особенно полезно, когда необходимо адаптировать поток с IP-камеры под требования внешних сервисов: например, отправить видео в облачный стриминг через RTMP, передать в локальную сеть по UDP или организовать защищённую доставку по SRT.

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

Типовые сценарии рестриминга​

Ниже приведены три распространённых паттерна преобразования RTSP-потока в другие форматы. Все они строятся по одному принципу:
приём → демультиплексирование/декодирование → упаковка → отправка.

Мы не декодируем и не перекодируем видео, если это не требуется — работа ведётся с сырыми H.264-пакетами, что снижает нагрузку на CPU и задержку.

RTSP → UDP/TS: передача в локальную сеть по multicast или unicast​

Этот сценарий часто используется для интеграции с медиа-серверами, IPTV-системами или приёмниками, ожидающими MPEG-TS-поток по UDP.

Пайплайн:

rtspsrc location=rtsp://user:pass@ip:554/stream latency=0 protocols=tcp !
rtph264depay !
h264parse config-interval=1 !
mpegtsmux !
udpsink host=239.255.1.1 port=1234

Пояснение этапов:​

  1. rtspsrc — подключается к RTSP-камере по указанному URI.

    • latency=0 — минимальная задержка в буфере джиттера.
    • protocols=tcp — используем TCP как более стабильный транспорт (UDP может терять пакеты, что критично для H.264).

  2. rtph264depay — снимает RTP-обёртку с H.264-потока.
    Каждый RTP-пакет содержит фрагмент NAL-юнита; этот элемент собирает их обратно в полные NAL-юниты.

  3. h264parse — анализирует H.264-поток, выделяет ключевые кадры (IDR), и, что важно, вставляет параметрические наборы (SPS/PPS) перед каждым ключевым кадром, если задан config-interval=1.
    Это необходимо, так как MPEG-TS-демультиплексеры (например, VLC, FFmpeg) ожидают SPS/PPS в потоке для корректного декодирования.

  4. mpegtsmux — упаковывает H.264-поток в MPEG-TS-контейнер.
    Это стандартный формат для транспорта по UDP, особенно в телевизионных и вещательных системах.

  5. udpsink — отправляет поток по UDP.

    • host=239.255.1.1 — multicast-адрес (можно заменить на 127.0.0.1 или IP конкретного получателя).
    • port=1234 — порт назначения.

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

Такой пайплайн может использоваться для трансляции с камеры в локальной сети на медиа-сервер, который принимает MPEG-TS через UDP. Например, в системах видеонаблюдения с централизованным приёмом или при интеграции с программами вроде VLC или OBS (через плагин UDP-источника).

RTSP → RTMP: стриминг в YouTube, Twitch, Wowza и др.​

RTMP — стандартный протокол для стриминга в облачные платформы. GStreamer позволяет напрямую пересылать поток с камеры в RTMP-сервер без перекодирования.

Пайплайн:

rtspsrc location=rtsp://user:pass@ip:554/stream latency=0 !
rtph264depay !
h264parse config-interval=1 !
flvmux streamable=true !
rtmpsink location=rtmp://live.twitch.tv/app/STREAM_KEY

Пояснение этапов:​

  1. rtspsrc, rtph264depay, h264parse — те же, что и в предыдущем примере.
    Обратите внимание: config-interval=1 гарантирует, что SPS/PPS будут в потоке — это обязательно для RTMP, иначе плеер не сможет начать воспроизведение.

  2. flvmux — упаковывает видео в FLV-контейнер (формат, используемый RTMP).

    • streamable=true — отключает запись размеров тегов в конец файла (что невозможно при стриминге), делает поток пригодным для потоковой передачи.

  3. rtmpsink — отправляет поток на RTMP-сервер.

    • location — полный путь к RTMP-приёмнику, включая ключ стрима.
    • Альтернатива: rtmp2sink — более современный элемент (если доступен), с улучшенной поддержкой ошибок и переподключений.

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

Вы подключаете IP-камеру к GStreamer на мини-ПК (например, Raspberry Pi) и транслируете напрямую в Twitch. Это позволяет организовать низколатентный стрим без использования компьютера и OBS.

⚠️ Важно: RTMP требует стабильного соединения. При нестабильном интернете лучше использовать srt или webrtc (см. ниже), но RTMP остаётся самым поддерживаемым протоколом.

RTSP → SRT: защищённая доставка через ненадёжные сети​

SRT (Secure Reliable Transport) — современный протокол, разработанный для передачи видео через публичные сети с автоматической компенсацией потерь и шифрованием.

Пайплайн:

rtspsrc location=rtsp://user:pass@ip:554/stream latency=0 !
rtph264depay !
h264parse config-interval=1 !
srtsink uri=srt://192.168.1.100:8888?mode=caller&passphrase=secret123&pbkeylen=16

Пояснение этапов:​

  1. rtspsrc, rtph264depay, h264parse — стандартная цепочка приёма и подготовки H.264-потока.

  2. srtsink — отправляет поток по SRT.

    • uri — адрес получателя.
    • mode=caller — режим инициатора (отправитель сам устанавливает соединение).
    • passphrase и pbkeylen — параметры шифрования (AES). Без них SRT не будет безопасным.

🔎 Если srtsink недоступен, убедитесь, что установлен плагин gst-plugins-bad и поддержка SRT включена при сборке GStreamer.

Альтернатива: srtclientsink​

Некоторые версии GStreamer используют srtclientsink — функционально аналогичный элемент, но с другим API.

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

Камера на удалённом объекте (например, стройплощадка) передаёт поток через 4G-модем в центральный сервер. SRT обеспечивает устойчивость к потере пакетов, низкую задержку и шифрование, что делает его идеальным для таких сценариев.

Почему GStreamer лучше FFMPEG для таких задач?​

На первый взгляд, те же операции можно выполнить через FFMPEG:

ffmpeg -i rtsp://... -c copy -f flv rtmp://...

Но у GStreamer есть ключевые преимущества:

КритерийFFMPEGGStreamer
Контроль над буферамиОграниченный (через -rtsp_transport, -buffer_size)Полный: можно настроить latency, queue, jitter-buffer
Чтение формата (caps)НеявноЯвно: можно вставить capsfilter, контролировать разрешение, FPS
ГибкостьЛинейная цепочкаГраф: можно ветвить, комбинировать, вставлять обработку
Интеграция с кодомЧерез вызов процессаЧерез API (Python, C), можно управлять в реальном времени
ОтладкаЛогиGST_DEBUG, gst-inspect, графы DOT

Например, в GStreamer вы можете:

  • Вставить queue leaky=downstream перед flvmux, чтобы при перегрузке сбрасывать старые кадры, а не накапливать задержку.
  • Добавить capsfilter с video/x-h264,profile=constrained-baseline, чтобы гарантировать совместимость с мобильными плеерами.
  • Динамически менять location у rtspsrc при переключении между камерами.

Рекомендации по настройке​

  1. Используйте h264parse config-interval=1 всегда, если выходной формат требует SPS/PPS (RTMP, MPEG-TS, SRT). Без этого поток может не воспроизводиться.

  2. Выбирайте транспорт RTSP (TCP/UDP):

    • protocols=tcp — стабильнее, но может быть чуть медленнее.
    • protocols=udp — ниже задержка, но теряется при перегрузке сети.

  3. Контролируйте задержку:

    • latency=0 — минимум задержки.
    • Добавьте sync=false в appsink или autovideosink, если выводите для мониторинга.

  4. Проверяйте поддержку плагинов:

    • gst-inspect-1.0 rtmpsink — проверить наличие RTMP.
    • gst-inspect-1.0 srtsink — проверить SRT.

Заключение​

GStreamer — это не просто инструмент для просмотра RTSP, а мощный шлюз для преобразования и маршрутизации медиапотоков. Благодаря модульной архитектуре, он позволяет:

  • Точечно управлять форматами и буферами.
  • Организовывать низколатентную передачу в RTMP, UDP, SRT.
  • Интегрировать потоки в сложные системы без перекодирования.

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