[libcamera-devel] [PATCH v3 5/6] libcamera: pipeline: ipu3: Do not mark metadata complete early

Laurent Pinchart laurent.pinchart at ideasonboard.com
Wed Mar 24 17:30:34 CET 2021


Hi Kieran,

On Wed, Mar 24, 2021 at 04:09:35PM +0000, Kieran Bingham wrote:
> On 24/03/2021 15:42, Laurent Pinchart wrote:
> > On Wed, Mar 24, 2021 at 03:01:24PM +0000, Kieran Bingham wrote:
> >> When the imguOutputBufferReady() detects a cancelled frame, it is
> >> reporting that the metadata has been processed in order to be able to
> >> complete the cancelled request.
> >>
> >> This causes the FrameInfo to be completed and deleted early, but then an
> >> active buffer on the IMGU can complete and be unable to find the
> >> FrameInfo for it to complete correctly.
> > 
> > This is because IPU3Frames::tryComplete() will erroneously consider that
> > the frame is complete, right ? I'm a bit puzzled, that function checks
> > if there's any pending buffer, wouldn't that condition be true until all
> > the buffers are returned ? What am I missing ?
> 
> It waits until all application provided buffers are returned. It doesn't
> track internal buffers. (assuming you mean the
> request->hasPendingBuffers check)

Ah of course. That's what I was missing. Thanks.

> This is why I previously raised the idea that internal buffers should
> also be tracked against a request directly, but that should be handled
> through a private implementation, as we can't associate them with
> streams that the application may interrogate.
> 
> 
> tryComplete requires 3 things.
> 
>   1) !request->hasPendingBuffers()
>   2) info->metadataProcessed
>   3) info->paramDequeued
> 
> 
> info->metadataProcessed is set:
> 
>  A) IPU3CameraData::statBufferReady()
>     If the stat buffer is cancelled, and not sent to the IPA.
> 
>  B) when ActionMetadataReady is received from the IPA
>     I.e., after successfully parsing the stats in IPA.
> 
>  C) here in IPU3CameraData::imguOutputBufferReady()
>     This is incorrect, as it's essentially completing the internal stats
>     buffer while it can be potentially still on a V4L2 device, and just
>     about to complete all by itself.
>     imguOutputBufferReady completes the user facing buffer, and that's
>      all it should do.
> 
> A, and B are perfectly valid times to complete the stats buffer. C
> (fixed by this patch) is not.

Thanks for putting up with me :-)

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

> >> Do not mark metadataProcessed early on the event that a single buffer is
> >> detected as cancelled. The stopping of the V4L2 devices will ensure
> >> that all queued buffers are returned to us and we can follow the normal
> >> and expected shutdown sequence.
> >>
> >> Signed-off-by: Kieran Bingham <kieran.bingham at ideasonboard.com>
> >> ---
> >>  src/libcamera/pipeline/ipu3/ipu3.cpp | 3 ---
> >>  1 file changed, 3 deletions(-)
> >>
> >> diff --git a/src/libcamera/pipeline/ipu3/ipu3.cpp b/src/libcamera/pipeline/ipu3/ipu3.cpp
> >> index 34ee600340b1..a8edf906220b 100644
> >> --- a/src/libcamera/pipeline/ipu3/ipu3.cpp
> >> +++ b/src/libcamera/pipeline/ipu3/ipu3.cpp
> >> @@ -1232,9 +1232,6 @@ void IPU3CameraData::imguOutputBufferReady(FrameBuffer *buffer)
> >>  		cropRegion_ = request->controls().get(controls::ScalerCrop);
> >>  	request->metadata().set(controls::ScalerCrop, cropRegion_);
> >>  
> >> -	if (buffer->metadata().status == FrameMetadata::FrameCancelled)
> >> -		info->metadataProcessed = true;
> >> -
> >>  	if (frameInfos_.tryComplete(info))
> >>  		pipe_->completeRequest(request);
> >>  }

-- 
Regards,

Laurent Pinchart


More information about the libcamera-devel mailing list