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:
v4l2h264encare negotiated normally. The V4L2 pool is used between these two elements and gets activated.
decodebinis negotiated it links some new elements together causing a pipeline reconfigure.
videotestsrcgets to the point where it performs the allocation query with the old V4L2 pool still activated. The
v4l2h264encelement replies with no pools due to the above commit.
videotestsrcdeactivates the V4L2 pool and creates its own pool.
v4l2h264encgets 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).