GNOME Bugzilla – Bug 796681
v4l2videodec: do not call streamon while pool is flushing
Last modified: 2018-06-27 21:17:18 UTC
Created attachment 372831 [details] [review] 0001-v4l2videodec-do-not-call-streamon-while-pool-is-flus.patch gst_v4l2_buffer_pool_flush() executes streamoff for the output, but streamoff->streamon for the capture of the decoder. gst_v4l2_buffer_pool_streamon() on capture assumes that is able to resurrect the buffers from the pool, but acquiring buffers fails if the buffer pool is still flushing. The decoder needs to stop flushing the pools before calling gst_v4l2_buffer_pool_flush() to restart the v4l2 device. Otherwise starting the decoding thread might fail, because there are no buffers in the capture pool. This fixes a regression that was introduced in 97985a335c78 ("v4l2videodec: Add dynamic resolution change support").
Can you provide a way to produce the issue that this patch fixes please ?
Created attachment 372854 [details] trickmode-key-units.scenario Use the attached trickmode-key-units.scenario with the following pipeline. The used video does not matter. gst-validate-1.0 --set-scenario trickmode-key-units filesrc location=<some_h264_encoded_video> ! parsebin ! v4l2h264dec ! fakesink Decoding will sometimes, but not always, fail with the following error message. gstv4l2bufferpool.c:1032:gst_v4l2_buffer_pool_poll:<v4l2h264dec0> error: poll error 1: Broken pipe (32) The poll fails, because capture is streaming, but its buffer list is empty, because the v4l2videodec did not resurrect the buffers. The patch fixes the buffer resurrection in v4l2videodec.
Commited as 35ab185d752fb610aa26002c1aa03cf2fd954b7d