Multiple activve jobs with the V4L2 request i/f?

Multiple activve jobs with the V4L2 request i/f?

[John Cox]

Hi

I have built a H265 V4L2 request decoder and I based it on the staged
sunxi cedrus decoder.  As it stands it appears to me that in the request
environment one request comes in which is processed and then is acked
with v4l2_m2m_buf_done_and_job_finish which returns the output & capture
(if not held) buffers and then the next request can start.  Our decode
process has two passes and so is most efficient if two frames are being
processed at the same time.  Is it possible in the stateless request
world to separate the return of the output & capture buffers and/or to
allow multiple requests to be active at the same time?  If so is there
any example code I can look at?

Many thanks

John Cox

Re: Multiple activve jobs with the V4L2 request i/f?

[Hans Verkuil]

Hi John,

On 2/17/20 1:16 PM, John Cox wrote:
> Hi
> 
> I have built a H265 V4L2 request decoder and I based it on the staged
> sunxi cedrus decoder.  As it stands it appears to me that in the request
> environment one request comes in which is processed and then is acked
> with v4l2_m2m_buf_done_and_job_finish which returns the output & capture
> (if not held) buffers and then the next request can start.  Our decode
> process has two passes and so is most efficient if two frames are being
> processed at the same time.  Is it possible in the stateless request
> world to separate the return of the output & capture buffers and/or to
> allow multiple requests to be active at the same time?  If so is there
> any example code I can look at?

If I understand it correctly, you want to start two buffers in
flight at the same time: one doing phase 1, and the other in phase 2.
And when both phases finish processing you return the buffer in phase 2,
move the buffer in phase 1 to phase 2, and dequeue a new buffer to start
processing in phase 1.

Right?

This means that there are two jobs running, and I don't think the
framework likes that.

On the other hand, I think it should be possible to add support for this
in v4l2-mem2mem.c, although I am not entirely sure what the right approach
would be.

One idea would be to model a pipeline as part of a job: so you can have
multiple jobs running, but each would run at a different phase of the
pipeline.

Erm, for the record, I have no plans to implement this, but patches are
welcome! :-)

Regards,

	Hans

Re: Multiple activve jobs with the V4L2 request i/f?

[John Cox]

Hi

>Hi John,
>
>On 2/17/20 1:16 PM, John Cox wrote:
>> Hi
>> 
>> I have built a H265 V4L2 request decoder and I based it on the staged
>> sunxi cedrus decoder.  As it stands it appears to me that in the request
>> environment one request comes in which is processed and then is acked
>> with v4l2_m2m_buf_done_and_job_finish which returns the output & capture
>> (if not held) buffers and then the next request can start.  Our decode
>> process has two passes and so is most efficient if two frames are being
>> processed at the same time.  Is it possible in the stateless request
>> world to separate the return of the output & capture buffers and/or to
>> allow multiple requests to be active at the same time?  If so is there
>> any example code I can look at?
>
>If I understand it correctly, you want to start two buffers in
>flight at the same time: one doing phase 1, and the other in phase 2.
>And when both phases finish processing you return the buffer in phase 2,
>move the buffer in phase 1 to phase 2, and dequeue a new buffer to start
>processing in phase 1.
>
>Right?
Yes - that is exactly correct.

>This means that there are two jobs running, and I don't think the
>framework likes that.
Looking at the code I got that impression quite strongly.

>On the other hand, I think it should be possible to add support for this
>in v4l2-mem2mem.c, although I am not entirely sure what the right approach
>would be.
As I'm new to this area I have even less idea :-)

>One idea would be to model a pipeline as part of a job: so you can have
>multiple jobs running, but each would run at a different phase of the
>pipeline.
Comments?  Does this seem like the way to go?  If so I could have a
first hack at it (though beware my unfamiliarity with this code - I'm
still getting used to the usage of "output" & "capture").

>Erm, for the record, I have no plans to implement this, but patches are
>welcome! :-)
Bother :-)

>Regards,
>
>	Hans

Regards

John Cox