Understanding about the 'tee' element
neoragex2002 at qq.com
Sat May 7 17:21:48 UTC 2022
------------------ Original ------------------
From: "Nicolas Dufresne";<nicolas at ndufresne.ca>;
Date: May 7, 2022
To: "Discussion of the development of and with GStreamer"<gstreamer-devel at lists.freedesktop.org>;
Cc: "neoragex2002"<neoragex2002 at qq.com>;
Subject: Re: Understanding about the 'tee' element
Le sam. 7 mai 2022, 05 h 45, neoragex2002 via gstreamer-devel <gstreamer-devel at lists.freedesktop.org> a écrit :
Recently I'm learning about how to use 'tee' and found things really weird.
What I'm doing is below:
$ 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.
def probe_func(pad, info):
delay = random.randint(0,2)
GLib.usleep(delay*200000) # 200ms x delay
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.
That is one of good points. Thanks for your mention! But what I concerned here is not the GIL of python, because there is no computing-bound python probe in the 1st tee-branch.
According to the docs of gstreamer, the queue-seperated 1st tee-branch and 2nd tee-branch are belong to different streaming threads. Their runnings should not be dependent with each other right?
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,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gstreamer-devel