Как GStreamer управляет потоками при объединении нескольких веток (очередь) - PullRequest
Новая
       9

Как GStreamer управляет потоками при объединении нескольких веток (очередь)

0 голосов
/ 08 апреля 2019

У меня есть конвейер GStreamer, который записывает три камеры в реальном времени и в основном делает следующее: захват 3 камер в первом потоке;затем выполните некоторую обработку 3 потоков в 3 отдельных потоках;параллельно масштабировать кадры для композитора (видеомиксера, адаптированного для живых источников) в 3 других потоках;и, наконец, сделать композицию.План для каждой камеры следующий (поэтому x3): 

[capture] -> TEE |-> QUEUE -> [someProcessing] -> _
                 |-> QUEUE -> [rescale]        -> COMPOSITOR

gst-launch-1.0 \
${capture0} ! tee name='t0' ! queue ! ${someProcessing0} \
${capture1} ! tee name='t1' ! queue ! ${someProcessing1} \
${capture2} ! tee name='t2' ! queue ! ${someProcessing2} \
${someStuff} \
compositor name=compo ${compositorSinkProperties} \
t0. ! queue ! ${rescale0} ! compo.sink_0 \
t1. ! queue ! ${rescale1} ! compo.sink_1 \
t2. ! queue ! ${rescale2} ! compo.sink_2 \
-e

Мой конвейер работает хорошо, мне просто нужно уточнить его внутреннее поведение:

Я знаю, как форсировать использованиеотдельные темы с элементом queue .Однако я не знаю, что происходит, когда мои 3 ветви [rescale] объединяются в одном элементе, таком как compo в моем случае.

Создает ли GStreamer 3 потока в соответствии с запросом?
Если да, то в каких потоках работает compositor ?
Если нет, у меня есть только 1 поток для всего масштабирование + компоновка процесс?

Спасибо за любую информацию, которой вы можете поделиться!
С уважением

1 Ответ

0 голосов
/ 08 апреля 2019

Насколько мне известно, вы правы.У вас будут потоки для всех путей очередей вниз по течению.И я думаю агрегатор тоже имеет свой собственный поток.У меня нет доказательств этого - возможно, вы сможете обнаружить его в классе GstAggregator.

Но его функция aggregate срабатывает, как только все приемные площадки агрегатора имеют данные.

Взятые из базыдокументация по классам здесь : 

aggregate ()

Mandatory. Called when buffers are queued on all sinkpads. Classes should
iterate the GstElement->sinkpads and peek or steal buffers from the
GstAggregatorPads. If the subclass returns GST_FLOW_EOS, sending of the
eos event will be taken care of. Once / if a buffer has been constructed
from the aggregated buffers, the subclass should call _finish_buffer.
...