v4l2bufferpool: Only resurrect the right amount of buffers
authorNicolas Dufresne <nicolas.dufresne@collabora.com>
Fri, 26 Jun 2020 18:48:14 +0000 (14:48 -0400)
committerGStreamer Merge Bot <gitlab-merge-bot@gstreamer-foundation.org>
Sun, 28 Jun 2020 13:40:30 +0000 (13:40 +0000)
On streamon, we need to resurrect (queue back) some buffers, as during
flushign seek we'd endup with an empty queued. We initially started with
resurrecting as many as we could without blocking, but that miss-behaved with
dynamic CREATE_BUFS, causing the pool to grow dramatically. This was limited
by the number of allocated buffers, but this still tried to resurrect too many
buffers for the first run, as activating the pool will queued buffers.

In this patch, we calculte the missing detal in the queue and only try and
resurrect that amount of buffers.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/651>

sys/v4l2/gstv4l2bufferpool.c

index 5c42bb3..f9cf943 100644 (file)
@@ -650,13 +650,18 @@ gst_v4l2_buffer_pool_streamon (GstV4l2BufferPool * pool)
     case GST_V4L2_IO_DMABUF:
     case GST_V4L2_IO_DMABUF_IMPORT:
       if (!V4L2_TYPE_IS_OUTPUT (pool->obj->type)) {
-        guint i;
+        guint num_queued;
+        guint i, n = 0;
+
+        num_queued = g_atomic_int_get (&pool->num_queued);
+        if (num_queued < pool->num_allocated)
+          n = pool->num_allocated - num_queued;
 
         /* For captures, we need to enqueue buffers before we start streaming,
          * so the driver don't underflow immediately. As we have put then back
          * into the base class queue, resurrect them, then releasing will queue
          * them back. */
-        for (i = 0; i < pool->num_allocated; i++)
+        for (i = 0; i < n; i++)
           gst_v4l2_buffer_pool_resurrect_buffer (pool);
       }