[Bug 736072] v4l2: set min_latency for output device according to required minimum number of buffers

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=736072
  GStreamer | gst-plugins-good | git

Nicolas Dufresne <nicolas.dufresne> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas.dufresne at collabora.
                   |                            |co.uk

--- Comment #4 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2014-09-04 19:21:04 UTC ---
(In reply to comment #3)
> Created an attachment (id=285405)
 View: https://bugzilla.gnome.org/attachment.cgi?id=285405
 Review: https://bugzilla.gnome.org/review?bug=736072&attachment=285405

> [PATCH] v4l2: Add support for MIN_BUFFERS_FOR_OUTPUT
> 
> 
> This was already there for capture device, now also implement it for
> output devices.
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=73607
> ---
>  sys/v4l2/gstv4l2bufferpool.c |  3 +--
>  sys/v4l2/gstv4l2object.c     | 16 ++++++++++------
>  sys/v4l2/gstv4l2object.h     |  4 ++--
>  sys/v4l2/gstv4l2videodec.c   |  3 +--
>  4 files changed, 14 insertions(+), 12 deletions(-)

Something approximately like this, not highly tested though.

(In reply to comment #0)
> Since we can get the minimum number of buffers needed by an output device to
> work, use it to set min_latency which will determine how many buffers are
> queued.
> 
> Device I use need at least 3 buffers to work correctly. Without this patch
> poo->min_latency is set to GST_V4L2_MIN_BUFFERS == 2.
> At allocation time, V4L2 device doesn't complain because we request more than 3
> buffers sinc v4l2 bufferpool min_buffers is set to 6.
> But when streaming only 2 buffers will be queued at a time since we will
> dequeue a buffer when pool->num_queued reachs pool->min_latency.

This underline some potential other issue, more complex to fix though. I think
adding MIN_BUFFER_FOR_OUTPUT support to drivers is the most standard and
straighforward approach. But in the long term, if we find too many driver
without this CID, we could consider some loop around REQBUFS. So, e.g. we
REQUEST N buffers, and the driver gives N+1, we know something wasn't quite
right. If min_latency is already set, there is a driver bug, can't really do
anything, but if min_latency is 2, We could update min_latency to be N+1, the
minimum the driver asked, and do REQBUFS again with the new min_latency + N -
2. As we know we request 2 buffers normally, while the remaining, N - 2 is what
downstream needs.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.