Understanding about the 'tee' element

[Nicolas Dufresne]

Le sam. 7 mai 2022, 05 h 45, neoragex2002 via gstreamer-devel <
gstreamer-devel at lists.freedesktop.org> a écrit :

> Hey all,
>
> Recently I'm learning about how to use 'tee' and found things really weird.
>
> What I'm doing is below:
>
> ```bash
> $ gst-launch-1.0 videotestsrc pattern=18 ! 'video/x-raw, width=1920,
> height=1080' ! \
>     tee name=t \
>     t. ! queue ! videoconvert ! fpsdisplaysink sync=false \
>     t. ! queue ! videoconvert ! fpsdisplaysink name=sink0 sync=false
> ````
>
> A probe function of gst-python was also been written to to hook the 'sink'
> pad of sink0 in the 2nd tee-branch.
> As you can see the probe function was very simple. It just slept for
> random msec.
>
> ```python
> import random
>
> def probe_func(pad, info):
>     delay = random.randint(0,2)
>     GLib.usleep(delay*200000) # 200ms x delay
>     return Gst.PadProbeReturn.OK
> ````
>
> But I found things are going weird: the display of the 1st tee-branch was
> frequently choked because of the random sleeps in the 2nd tee-branch.
> It seems that the queue in 2nd tee-branch was totally USELESS to decouple
> the running of the two branches.
>

The Python interpreter is single threaded, as a side effect the probes are
being serialized. Don't use python if you need to interact with multiple
streaming threads.


> All I want is an 'independent enough' behavior of the 2nd tee-branch that
> does not block the 1st branch. and I also want my probe func could
> read EVERY frame AT ITS OWN PACE, instead of DISCARDING some frames to
> catch up the pace of 1st branch by using `queue leaky=2 max-size-buffers=1'
> in the 2nd tee-branch.
>
> Can anyone kindly enough to explain this for me?
>
> Thanks in advance,
>
> Rio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20220507/4de76ae9/attachment.htm>