Gstreamer: мультиплексировать видеопоток + оверлей в один сетевой поток?
Я использую GStreamer в сценарии, где я хочу передавать видеопоток по сети, при этом части видео динамически помечаются как прозрачные для дальнейшей обработки / наложения на стороне приемника.
Изначально я пытался использовать данные RGBA (потому что это то, для чего они нужны), но, похоже, нет распространенных форматов сжатия видео или даже изображений, которые допускают альфа-канал. Самым близким, что я нашел, является JPEG2000, но, о боже, транскодеры работают медленно.
Мое текущее хакерско-работающее решение - просто закрасить предположительно прозрачные части видео ярко-зеленым цветом (0x00FF00) и использовать альфа-элемент на стороне приемника для слияния с наложением. Задача решена.
Однако другой новый вариант использования будет включать в себя наличие как полного исходного видео, так и маски прозрачности на стороне приемника. Конечно, подход "зеленого экрана" здесь не работает, потому что оригинальное видео было закрашено маской.
Я кратко экспериментировал с использованием мультиплексированного транспортного потока MPEG, но результаты не были ошеломляющими (массивные потери кадров и артефакты сжатия, даже на локальном хосте).
Для справки вот исходный конвейер, который я тестировал:
gst-launch-1.0 -e mpegtsmux alignment=7 name="muxer" ! rtpgstpay config-interval=1 ! udpsink host=127.0.0.1 port=5000 \
v4l2src ! video/x-raw,format=YUY2,framerate=15/1,width=640,height=480 ! videoconvert ! x264enc ! muxer. \
videotestsrc ! video/x-raw,framerate=15/1,width=640,height=480 ! x264enc ! muxer.
А вот и мойка трубопровода:
gst-launch-1.0 -m -e udpsrc port=5000 ! application/x-rtp ! rtpgstdepay ! \
tsparse ! tsdemux name=demux demux.video_0_0041 ! h264parse ! avdec_h264 ! \
videoconvert ! fpsdisplaysink
Я могу выбрать второй поток, используя demux.video_0_0042, но я получаю что-то вроде 2-3 FPS (у источников 15), и качество ужасающее (почти не распознается видео).
Конечно, я мог бы просто настроить второй, независимый сетевой поток, но это привело бы к большим накладным расходам (второй сетевой приемник и источник, второй кодер / декодер, плюс проблемы синхронизации и т. Д. И т. Д.). Любые предложения для альтернативных подходов будут очень приветствоваться!