Re: [RFC] Request API and V4L2 capabilities

Hans Verkuil
2018-08-24T11:03:20Z

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.

Regards,

Hans