v4l2 dec queues capture buffers before streamon, broke the dynamic resolution change
I know the current v4l2 m2m driver could work with this flow.
I am talking about the flow that the kernel document suggests and the case when userspace didn't know the resolution or field information of the stream(when it decodes a secure(DRM) stream).
static gboolean
gst_v4l2_buffer_pool_streamon (GstV4l2BufferPool * pool)
{
GstV4l2Object *obj = pool->obj;
if (pool->streaming)
return TRUE;
switch (obj->mode) {
case GST_V4L2_IO_MMAP:
case GST_V4L2_IO_USERPTR:
case GST_V4L2_IO_DMABUF:
case GST_V4L2_IO_DMABUF_IMPORT:
if (!V4L2_TYPE_IS_OUTPUT (pool->obj->type)) {
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 < n; i++)
gst_v4l2_buffer_pool_resurrect_buffer (pool);
}
if (obj->ioctl (pool->video_fd, VIDIOC_STREAMON, &obj->type) < 0)
goto streamon_failed;
If the CAPTURE queue is streaming, keep queuing and dequeuing buffers on the CAPTURE queue until a buffer marked with the V4L2_BUF_FLAG_LAST flag is dequeued.
So, I assume, the buffer queuing should happen after the CAPTURE queue is streaming. Well that is the major problem here, when we decode a secure(DRM) stream, https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-good/sys/v4l2/gstv4l2videodec.c#L847
if (!g_atomic_int_get (&self->capture_configuration_change)) {
ret = gst_v4l2_video_dec_setup_capture (decoder);
if (ret != GST_FLOW_OK) {
GST_ERROR_OBJECT (decoder, "setup capture fail\n");
goto not_negotiated;
}
}
the flow I wish here is that it would queue a buffer into the OUTPUT queue and then start the stream in the OUTPUT queue. The capture queue should not start first.
Could I submit a patch to support this feature? I think any driver supports V4L2_EVENT_SOURCE_CHANGE event could support this flow while the other would keep using the old flow.