v4l2videoenc: element hangs on reconfigure event if caps are the same
Describe your issue
I have a pipeline that contains a v4l2videoenc
element. Another element on the pipeline sends a RECONFIGURE
event on the pipeline without actually changing its caps. If the caps differ, the new format is negotiated and the pipeline continues, but if the caps are the same, the pipeline hangs.
Expected Behavior
The pipeline continues running.
Observed Behavior
The pipeline hangs. No new buffers arrive at the sink pad of the v4l2videoenc.
I can see that after reconfigure has been triggered, the v4l2videoenc element receives a PROPOSE_ALLOCATION
query, which eventually calls to gst_v4l2_object_propose_allocation
. This function should return a buffer pool that can be used with the encoder. It doesn't return a buffer pool because the gst_v4l2_object_set_format
was skipped because the format didn't change. Therefore, the buffer pool of the v4l2object (OUTPUT) is still the same buffer pool, which is active and won't be used.
Steps to reproduce the bug
The following gst-validate scenario with the example pipeline triggers the bug. The caps on the pipeline and the scenario can be arbitrary, but have to be the same. If the caps differ from each other, the scenario works.
gst-validate-1.0 videotestsrc ! capsfilter caps="video/x-raw,width=1920,height=1080,framerate=30/1" ! v4l2jpegenc ! fakesink
set-property, playback-time=1.0, target-element-factory-name="capsfilter", property-name=caps, property-value=(string)"video/x-raw,width=1920,height=1080,framerate=30/1"
stop, playback-time=2.0
I am running the tests with a Hantro JPEG encoder and the CODA JPEG encoder. I am pretty sure that it doesn't depend on the platform.
How reproducible is the bug?
Always.
Solutions you have tried
I changed the gst_v4l2_object_propose_allocation
to return the pool even if it is active. With that hack, the pipeline continues. There is already a check in that function to only return the pool if its caps match the caps of the query, but I am not sure, if this is enough.
I also tried to change the upstream elements to send the CAPS
event even if the caps didn't change to trigger a re-allocation of the buffer pool. However, there are various locations that optimize the behavior on changed caps to avoid the reconfiguration. Thus, this didn't really work, and I guess that this is a bad solution anyway.