<div dir="ltr"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div style="font-size:12.8px"><div style="font-size:12.8px"><div style="font-size:small"><font color="#000000"><font face="arial, helvetica, sans-serif" style=""><a class="gmail_plusreply" id="plusReplyChip-1" href="mailto:kieran.bingham@ideasonboard.com" tabindex="-1">+Kieran Bingham</a> since Laurent is out.<br></font></font></div><div style="font-size:small"><font color="#000000"><font face="arial, helvetica, sans-serif" style=""><br></font></font></div><div style="font-size:small"><font color="#000000"><font face="arial, helvetica, sans-serif" style="">> </font><span style="font-size:12.8px">Could this be computed the same way we do it in the IPU3 IPA module ?</span></font></div></div></div></div></div></div></div><div><br></div><div>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.</div><div><br></div><div>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.</div><br>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:<br>      description: |<br>        The minimum and maximum (in that order) frame duration,<br>        expressed in microseconds.<br>...<br>      size: [2]<br><br><div>It looks like updateControls is only called once, during init(). We would need a hook that changes this static configuration for each video mode.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 25, 2022 at 10:16 AM Nicholas Roth <<a href="mailto:nicholas@rothemail.net">nicholas@rothemail.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Careful, we're claiming full per-frame control capabilities with this set to 0 :)<br>
<br>
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.<br>
<br>
> On Oct 25, 2022, at 8:20 AM, Jacopo Mondi <<a href="mailto:jacopo@jmondi.org" target="_blank">jacopo@jmondi.org</a>> wrote:<br>
> <br>
> Careful, we're claiming full per-frame control capabilities with this<br>
> set to 0 :)<br>
</blockquote></div>