GStreamer hangs with v4l2src, compositor, tee and fakesync

[Terry Barnaby]

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