Re: [RFC] Request API and V4L2 capabilities

Paul Kocialkowski
2018-08-24T12:34:51Z

[-- Attachment #1: Type: text/plain, Size: 2421 bytes --]

Hi,

On Fri, 2018-08-24 at 09:29 +0200, Hans Verkuil 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.

I haven't tested decoding without requests, but I suppose it should work
when submitting only one source buffer at a time.

By the way, note that our VAAPI backend for the request API gets the
slice data and metadata for each frame sequentially and we are not yet
starting to fill the next request before the current one was completed
(fences would probably help implement that).

> 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.

Agreed.

Cheers,

Paul

--
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]