GStreamer hangs with v4l2src, compositor, tee and fakesync
Terry Barnaby
terry1 at beam.ltd.uk
Tue Nov 9 14:11:06 UTC 2021
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
>
More information about the gstreamer-devel
mailing list