GStreamer hangs with v4l2src, compositor, tee and fakesync

[Terry Barnaby]

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.

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
>