v4l2h264enc: produces huge amount of "newly allocated buffer %u is not free" on Raspberry Pi

tested on 1.24 branch.

It happens in gst_v4l2_buffer_pool_alloc_buffer:

    if (g_atomic_int_get (&pool->buffer_state[group->buffer.index])) {
      GST_WARNING_OBJECT (pool, "newly allocated buffer %u is not free",
          group->buffer.index);
    }

After some debugging I found possible reason. Please look to following places in code:

gst_v4l2_allocator_release

  if (g_atomic_int_dec_and_test (&group->mems_allocated)) {
    GST_LOG_OBJECT (allocator, "buffer %u released", group->buffer.index);
    gst_atomic_queue_push (allocator->free_queue, group);
    g_signal_emit (allocator, gst_v4l2_allocator_signals[GROUP_RELEASED], 0);
  }

gst_v4l2_buffer_pool_start

    pool->group_released_handler =
        g_signal_connect_swapped (pool->vallocator, "group-released",
        G_CALLBACK (gst_v4l2_buffer_pool_resurrect_buffer), pool);

gst_v4l2_buffer_pool_resurrect_buffer

  params.flags =
      (GstBufferPoolAcquireFlags) GST_V4L2_BUFFER_POOL_ACQUIRE_FLAG_RESURRECT |
      GST_BUFFER_POOL_ACQUIRE_FLAG_DONTWAIT;
  ret =
      gst_buffer_pool_acquire_buffer (GST_BUFFER_POOL (pool), &buffer, &params);

gst_v4l2_allocator_alloc

  group = gst_atomic_queue_pop (allocator->free_queue);

And if imagine free_queue contains only single buffer, it's possible to pop in gst_v4l2_allocator_alloc the same buffer what was pushed in gst_v4l2_allocator_release right before. Alone it's not a problem, but problem is there is no code updating buffer_state to BUFFER_STATE_FREE in between.

P.S.: I didn't find any related changes in main...