Skip to content

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 and v4l2h264enc 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. The v4l2h264enc 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).