GNOME Bugzilla – Bug 745377
v4l2src: Camera restarts when used with decodebin
Last modified: 2015-03-14 13:08:33 UTC
When using decodebin, v4l2src receives a reconfigure-event. Even though it won't renegotiate, a new allocation query is run. In the decide allocation, v4l2 sets the negotiated configuration on the pool but the pool is active. This configuation is different because the pool do small adjustments. Currently the pool check for equality of the structure, and try to stop the pool in order to set the new configuration. I think the pool should not try to stop the configuration. Stopping the pool, cause the streaming to stop and start (which takes a bit of time with UVC cameras). In the end, the configuration didn't change, so there was no reason to stop the pool. I think start/stop the pool should be left to the user of the pool and not implicit. Instead, what the pool could do (and this is according to the doc) is simply return FALSE on the set_config. The caller will then read back the pool configuration (the active one) and check if it's usable. This way moves back the task of start/stop of the pool the controlling element instead of being implicit. Pipeline to reproduce: v4l2src ! image/jpeg ! decodebin ! autovideosink
Created attachment 298221 [details] [review] [PATCH] bufferpool: Don't stop the pool in set_config() Don't stop the pool in set_config(). Instead, let the controlling element manage it. Most of the time, when an active pool is being configured is because the caps didn't change. https://bugzilla.gnome.org/show_bug.cgi?id=745377 --- gst/gstbufferpool.c | 16 +++------------- 1 file changed, 3 insertions(+), 13 deletions(-)
Comment ?
Comment on attachment 298221 [details] [review] [PATCH] bufferpool: Don't stop the pool in set_config() This might break assumptions in existing code... but otherwise it makes sense
Fortunately, I might have been the only one aware of that new pool behaviour. I really think I over-engineered a way to try and accept a config. What I found later is that even the code I wrote for that may fail, as it didn't expect the pool to stop suddenly (v4l2videodec).
Ok, I also update the unit test. commit c740bad1a003e43c732183f18ed242b602e085a2 Author: Nicolas Dufresne <nicolas.dufresne@collabora.co.uk> Date: Sun Mar 1 13:15:40 2015 -0500 bufferpool: Don't stop the pool in set_config() Don't stop the pool in set_config(). Instead, let the controlling element manage it. Most of the time, when an active pool is being configured is because the caps didn't change. https://bugzilla.gnome.org/show_bug.cgi?id=745377