On Fri, Aug 24, 2018 at 4:30 PM Hans Verkuil <hverkuil@xxxxxxxxx> 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
