GStreamer hangs with v4l2src, compositor, tee and fakesync

[Nicolas Dufresne]

Le mardi 09 novembre 2021 à 14:11 +0000, Terry Barnaby a écrit :
> Hi,
> 
> I forgot to mention, I have recently found that adding "! identity 
> drop-allocation=true" before the tee appears to fix/"work around" the 
> issue but I have no idea why.

Strange, having fakesink in the set of pads inside the tee should have the same
effect, since fakesink does not reply to the allocation query. v4l2src will then
guess the number of required buffer and enable a copy threshold if it's running
our of buffer (v4l2 works best with fixed number of pre-allocated buffers).

Also strange that it works for me, though I probably have a different GL stack
(which act as dmabuf importer) and different set of cameras. Have you tested
with fakevideosink as a curiosity ? This one replies to the allocation query,
allowing tee to aggregate and reply to upstream.

> 
> Terry
> On 09/11/2021 14:05, Terry Barnaby wrote:
> > Hi Nicolas.
> > 
> > Thanks for the response.
> > I have just tried it under Fedora35 with the system standard gstreamer 
> > (gstreamer1-1.19.2-1.fc35.x86_64) package and it also fails.
> > I will try building release 1.19.3 to see if that works first. I am 
> > testing with Intel graphics and also in a libvirtd VM.
> > 
> > Terry
> > On 09/11/2021 13:49, Nicolas Dufresne wrote:
> > > Hi Terry,
> > > 
> > > Le mardi 09 novembre 2021 à 08:26 +0000, Terry Barnaby via 
> > > gstreamer-devel a
> > > écrit :
> > > > Hi, I wonder if anyone can point me to where I am going wrong ?
> > > > 
> > > > I am working on an embedded video system and have a solid video stream
> > > > lockup on the pipeline start. I have reduced the problem to a
> > > > gst-launch-1.0 command line that fails under Fedora33 (as well as
> > > > Fedora29 and Centos8-stream) with default gstreamer packages installed.
> > > > When I run the following I see a glimagesink window with the 
> > > > contents of
> > > > the test1.png file displayed but no video stream from the webcam
> > > > (Logitec C920 USB). I should see the test1.png overlaying the video 
> > > > stream.
> > > > 
> > > > If I remove the "t. ! fakesink sync=false" part it runs fine (this 
> > > > would
> > > > normally go to further processing). I have also seen lockups with a
> > > > similar setup using videotestsrc rather than v4l2src intermittently.
> > > [below quote has been edited, re-indented for myself]
> > > 
> > > > gst-launch-1.0 -v \
> > > >    compositor name=c sink_1::alpha=1.0 ! videoconvert ! glimagesink \
> > > >     v4l2src ! jpegdec ! queue ! tee name=t \
> > > >     t. ! queue ! c.sink_0  \
> > > >     t. ! queue ! fakesink sync=false \
> > > >     multifilesrc location=./test1.png caps=image/png,framerate=1/1 ! 
> > > > pngdec ! imagefreeze ! videoconvert ! c.sink_1 \
> > > There is nothing suspicious about this pipeline, you have all the 
> > > required queue
> > > after tee branch and don't seem to be in an impossible "preroll" 
> > > situation. I've
> > > also tested this against dev release 1.19.3 and Fedora 35 provided 
> > > build and it
> > > works there.
> > > 
> > > Bisecting can take time, best is if you can locate a bit the cause, 
> > > perhaps run
> > > this through gdb and share a complete backtrace (make sure to install 
> > > all the
> > > dbginfo for the symbols in your backtrace).
> > > 
> > >    gdb <path-to-executable> <pi of the hung process>
> > >    gdb> thread apply all bt
> > > 
> > > regards,
> > > Nicolas
> > 
>