[libcamera-devel] [PATCH 03/11] Adds rkisp1 metadata required for the Android HAL to use it.
Nicholas Roth
nicholas at rothemail.net
Wed Oct 26 06:40:11 CEST 2022
+Kieran Bingham <kieran.bingham at ideasonboard.com> since Laurent is out.
> Could this be computed the same way we do it in the IPU3 IPA module ?
It looks like each of the computed IPU3 FrameDurationLimit values
correspond to the minimum and maximum v4l2 blanking intervals. I suppose
that makes sense, though I suspect the minimum frame duration will be
constrained by i2c bandwidth and ISP limitations at the highest resolutions
rather than the sensor blanking intervals based on the datasheet.
I'm not really sure what the best thing to do here is. I'm concerned that
if we follow the IPU3 computation, we could easily end up asking for the
ISP to push more pixels than it has throughput for. A very conservative
approach might be to cap this at a few FPS, which is the advertised rate at
the highest resolution, but I would not enjoy using the camera that way.
Curious to read others' thoughts on this.
As a side-note, I'm really not sure why the IPU3 IPA treats
FrameDurationLimits as a 3-tuple, when control_ids.yaml explicitly states:
description: |
The minimum and maximum (in that order) frame duration,
expressed in microseconds.
...
size: [2]
It looks like updateControls is only called once, during init(). We would
need a hook that changes this static configuration for each video mode.
On Tue, Oct 25, 2022 at 10:16 AM Nicholas Roth <nicholas at rothemail.net>
wrote:
> > Careful, we're claiming full per-frame control capabilities with this
> set to 0 :)
>
> Good catch— I’ll revert this line. I couldn’t easily find this in the ISP
> manual and wanted to see what we’d need for FULL instead of LIMITED support
> while I was debugging a camera2 crash.
>
> > On Oct 25, 2022, at 8:20 AM, Jacopo Mondi <jacopo at jmondi.org> wrote:
> >
> > Careful, we're claiming full per-frame control capabilities with this
> > set to 0 :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libcamera.org/pipermail/libcamera-devel/attachments/20221025/ae9ace06/attachment.htm>
More information about the libcamera-devel
mailing list