Re: [RFC] Request API and V4L2 capabilities

[Tomasz Figa <tfiga@chromium.org>]

On Fri, Aug 24, 2018 at 4:30 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
> On 08/23/2018 07:37 PM, Nicolas Dufresne wrote:
> > Le jeudi 23 août 2018 à 16:31 +0200, Hans Verkuil a écrit :
> >>> I propose adding these capabilities:
> >>>
> >>> #define V4L2_BUF_CAP_HAS_REQUESTS     0x00000001
> >>> #define V4L2_BUF_CAP_REQUIRES_REQUESTS        0x00000002
> >>> #define V4L2_BUF_CAP_HAS_MMAP         0x00000100
> >>> #define V4L2_BUF_CAP_HAS_USERPTR      0x00000200
> >>> #define V4L2_BUF_CAP_HAS_DMABUF               0x00000400
> >>
> >> I substituted SUPPORTS for HAS and dropped the REQUIRES_REQUESTS capability.
> >> As Tomasz mentioned, technically (at least for stateless codecs) you could
> >> handle just one frame at a time without using requests. It's very inefficient,
> >> but it would work.
> >
> > I thought the request was providing a data structure to refer back to
> > the frames, so each codec don't have to implement one. Do you mean that
> > the framework will implicitly request requests in that mode ? or simply
> > that there is no such helper ?
>
> Yes, that's done through controls as well.
>
> The idea would be that you set the necessary controls, queue a buffer to
> the output queue, dequeue a buffer from the output queue, read back any
> new state information and repeat the process.
>
> That said, I'm not sure if the cedrus driver for example can handle this
> at the moment. It is also inefficient and it won't work if codecs require
> more than one buffer in the queue for whatever reason.
>
> Tomasz, Paul, please correct me if I am wrong.
>
> In any case, I think we can do without this proposed capability since it is
> simply a requirement when implementing the pixelformat for the stateless
> codec that the Request API will be available and it should be documented
> as such in the spec.

No correction needed. :)

Best regards,
Tomasz