GNOME Bugzilla – Bug 791338
v4l2videoenc: calling S_FMT after REQBUFS fails
Last modified: 2018-01-08 22:34:16 UTC
S_FMT may return -EBUSY if buffers are already allocated with REQBUFS. Some drivers return -EBUSY on S_FMT if buffers are allocated [1]. This can cause negotiation to fail when the capture pool is activated too early. The attached patch stops activating the pool during negotiation and instead defers the pool activation until the first frame arrives.
Did you push send too soon? What is the link for [1]. I think it makes sense to try and allocate the output buffers as late as possible, in order to get the size right. Specially that we don't yet implement any king of output buffers reallocation if the required size increases.
Copy & paste error. I wanted to link to the documentation, which describes the possible EBUSY return value: [1] https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/vidioc-g-fmt.html#return-value
Created attachment 365741 [details] [review] v4l2videoenc: do not activate capture pool during negotiation And here is the missing patch.
Review of attachment 365741 [details] [review]: So this happens if the is a renegotiation ? Why not fixing that case instead ? Check is something have actually changed, if not return TRUE, then run the allocation (to drain) stop the pools, and then set the new format. Just ignoring the caps seems rather bad.
Created attachment 365867 [details] [review] v4l2videoenc: Delay capture pool activation This is to support CODA driver which prevents setting the output format if the capture is streaming. I haven't tested this one, but I think it should do pretty much the same, without breaking renegotiation and without calling set_active() for every frames coming in. I'm obsoleting the previous one because it's a regression on Venus driver.
Created attachment 365869 [details] [review] v4l2videoenc: Remove dead code gst_v4l2_object_stop() will free and nullify the pool, so the following if will never be true.
Created attachment 365870 [details] [review] v4l2videoenc: Call stop on object before renegotiation Otherwise renegotiation fails as we are still streaming.
Review of attachment 365867 [details] [review]: Thank you, this does indeed have the same effect on CODA.
Attachment 365867 [details] pushed as 4aa5298 - v4l2videoenc: Delay capture pool activation Attachment 365869 [details] pushed as a46756b - v4l2videoenc: Remove dead code Attachment 365870 [details] pushed as d90b6ec - v4l2videoenc: Call stop on object before renegotiation