[libcamera-devel] [PATCH v5 11/12] pipeline: raspberrypi: Allow pipeline handler to always use the newest frame

Laurent Pinchart laurent.pinchart at ideasonboard.com
Mon Jan 23 00:06:28 CET 2023


Hello,

On Fri, Jan 20, 2023 at 03:19:31PM +0000, Naushir Patuck via libcamera-devel wrote:
> On Fri, 20 Jan 2023 at 11:22, Kieran Bingham wrote:
> > Quoting Naushir Patuck via libcamera-devel (2023-01-18 08:59:52)
> > > Add a pipeline config parameter "return_newest_frames" to always use the
> > > most recently captured Unicam frame when processing a request. This effectively
> > > stops the pipeline handler from queuing Unicam buffers and processing requests
> > > using the buffer at the front of the queue.
> > >
> > > Note that setting this parameter might incur unnecessary frame drops during
> > > times of high transient CPU loads where the application might not be able to
> > > provide requests quick enough.
> >
> > I'd be tempted to add here, 'But it can lower perceived latency of the
> > output when recovering from a frame drop scenario' ? (if that's correct)
> 
> Yes, I think that's valid - I'll add it in.
> 
> > > Signed-off-by: Naushir Patuck <naush at raspberrypi.com>
> > > Reviewed-by: David Plowman <david.plowman at raspberrypi.com>
> > > ---
> > >  .../pipeline/raspberrypi/data/example.yaml    |  7 +++++-
> > >  .../pipeline/raspberrypi/raspberrypi.cpp      | 23 +++++++++++++++++++
> > >  2 files changed, 29 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/src/libcamera/pipeline/raspberrypi/data/example.yaml b/src/libcamera/pipeline/raspberrypi/data/example.yaml
> > > index 421f30e62aa3..04a117f38ada 100644
> > > --- a/src/libcamera/pipeline/raspberrypi/data/example.yaml
> > > +++ b/src/libcamera/pipeline/raspberrypi/data/example.yaml
> > > @@ -19,6 +19,11 @@
> > >
> > >                  # Override any request from the IPA to drop a number of startup
> > >                  # frames.
> > > -                "disable_startup_frame_drops": false
> > > +                "disable_startup_frame_drops": false,
> >
> > Can the options always have a comma so they don't require modifiying
> > the previous one to add a new one?
> >
> > Is that because you're treating this file as json instead of yaml ?
> 
> This was certainly needed when the files were named *.json in
> earlier revisions.
> Not sure now that they are *.yaml with json format...

Not that you have to do so, but there's also the option of formatting
the files with the "normal" YAML syntax.

> > > +
> > > +                # Always process a pending request with the last captured sensor
> > > +                # frame.  Note that this might lead to avoidable frame drops

s/  / /

> > > +                # during periods of transient heavy CPU loading.
> > > +                "return_newest_frames": false
> > >          }
> > >  }
> > > diff --git a/src/libcamera/pipeline/raspberrypi/raspberrypi.cpp b/src/libcamera/pipeline/raspberrypi/raspberrypi.cpp
> > > index 3529d331deb6..21edc8e05469 100644
> > > --- a/src/libcamera/pipeline/raspberrypi/raspberrypi.cpp
> > > +++ b/src/libcamera/pipeline/raspberrypi/raspberrypi.cpp
> > > @@ -314,6 +314,11 @@ public:
> > >                  * frames.
> > >                  */
> > >                 bool disableStartupFrameDrops;
> > > +               /*
> > > +                * Always process a pending request with the last captured sensor
> >
> > last / 'most recently' ?
> 
> Ack.
> 
> > > +                * frame.
> > > +                */
> > > +               bool returnNewestFrames;
> > >         };
> > >
> > >         Config config_;
> > > @@ -1712,6 +1717,7 @@ int RPiCameraData::configurePipeline()
> > >                 .minUnicamBuffers = 2,
> > >                 .minTotalUnicamBuffers = 4,
> > >                 .disableStartupFrameDrops = false,
> > > +               .returnNewestFrames = false,
> > >         };
> > >
> > >         char const *configFromEnv = utils::secure_getenv("LIBCAMERA_RPI_CONFIG_FILE");
> > > @@ -1747,6 +1753,8 @@ int RPiCameraData::configurePipeline()
> > >                 phConfig["min_total_unicam_buffers"].get<unsigned int>(config_.minTotalUnicamBuffers);
> > >         config_.disableStartupFrameDrops =
> > >                 phConfig["disable_startup_frame_drops"].get<bool>(config_.disableStartupFrameDrops);
> > > +       config_.returnNewestFrames =
> > > +               phConfig["return_newest_frames"].get<bool>(config_.returnNewestFrames);
> > >
> > >         if (config_.minTotalUnicamBuffers < config_.minUnicamBuffers) {
> > >                 LOG(RPI, Error) << "Invalid configuration: min_total_unicam_buffers must be >= min_unicam_buffers";
> > > @@ -2329,6 +2337,21 @@ bool RPiCameraData::findMatchingBuffers(BayerFrame &bayerFrame, FrameBuffer *&em
> > >         if (bayerQueue_.empty())
> > >                 return false;
> > >
> > > +       /*
> > > +        * If the pipeline is configured to only ever return the most recently
> > > +        * captured frame, empty the buffer queue until a single element is
> > > +        * left, corresponding to the most recent buffer. Note that this will
> > > +        * likely result in possibly avoidable dropped frames.
> > > +        */
> > > +       if (config_.returnNewestFrames && !unicam_[Unicam::Image].isExternal()) {
> > > +               while (bayerQueue_.size() > 1) {
> >
> > Is this required?
> >
> > I'm a bit puzzled at the need to drop all the other frames. Don't we
> > just need to choose the oldest buffer to drop so that we can capture a
> > new image?
> 
> I think it is needed.  We are flushing our internal Unicam buffer queue up-to
> the latest captured frame to process for the request.  Depending on the number
> of input buffers allocated, this may be > 1.
> 
> > There's still the potential for the pipeline to catch up
> > isn't there?
> 
> Yes it might be possible to catch up, but there is no way of knowing this
> deterministically.  Hence the comment in the config file saying that using this
> flag might lead to possibly avoidable frame drops.

Might may be a bit of an understatement :-) I wonder if it would be
possible to flush the queue only when we detect a frame drop.

What's the expected use case for this configuration parameter ?

> > > +                       FrameBuffer *bayer = bayerQueue_.front().buffer;
> > > +
> > > +                       unicam_[Unicam::Image].returnBuffer(bayer);
> > > +                       bayerQueue_.pop();
> > > +               }
> > > +       }
> > > +
> > >         /*
> > >          * Find the embedded data buffer with a matching timestamp to pass to
> > >          * the IPA. Any embedded buffers with a timestamp lower than the

-- 
Regards,

Laurent Pinchart


More information about the libcamera-devel mailing list