v4l2h264enc element stalls if pipeline is reconfigured
With GStreamer 1.18 this pipeline stalls after processing one frame:
gst-launch-1.0 -v videotestsrc ! v4l2h264enc ! decodebin ! fakesink
(I know the pipeline is a bit contrived. What matters is the decodebin
element causes a reconfigure after v4l2h264enc
has been setup).
The same pipeline works with GStreamer 1.16.
In both versions I tested this with the Hantro encoder, but I don't think the actual encoder implementation matters in this bug.
I think this is caused by 85b9893e and this is what is happening:
-
videotestsrc
andv4l2h264enc
are negotiated normally. The V4L2 pool is used between these two elements and gets activated. - When
decodebin
is negotiated it links some new elements together causing a pipeline reconfigure. -
videotestsrc
gets to the point where it performs the allocation query with the old V4L2 pool still activated. Thev4l2h264enc
element replies with no pools due to the above commit. -
videotestsrc
deactivates the V4L2 pool and creates its own pool. - When
v4l2h264enc
gets a new buffer it gets a bit confused and returns flushing because the V4L2 pool is not activated and the encoder task is already running (which would activate the pool if needed). The pipeline then stalls.
I'm not sure what the right fix for this would be (if the above commit is wrong, or maybe the V4L2 pool should get "reactivated" in this case).