picamera2 app_full.py wrong frameduratoin

[pbaetens]

In app_full.py ,there is some metadata in the infopanel and video panel showing the actual framerate.

Background:
I wrote a driver and cam helper.cpp for an ams-osram mira image sensor.
Everything is working, I can configure exposure, gain, framerate.
Using an oscilloscope, I can verify that the configured exposusure and framerate is correct.

However, in the video tab, the 'Actual framerate' is incorrect. Where is this metadata coming from?

[pbaetens]

@davidplowman @6by9 do you have any suggestions what the issue could be?

[pbaetens]

additional info: our sensor does not calculate time with line times, instead all parameters are directly configured in microseconds, such as the frame time and exposure registers.
modifying the pixel clock in the v4l driver such that (width+HBlank) / pixel clock = 1us seems to fix the issue.

[6by9]

https://www.kernel.org/doc/html/latest/userspace-api/media/drivers/camera-sensor.html#raw-camera-sensors defines the expected behaviour for setting frame rate, and from there exposure time (although cam_helpers can alter that association).

If your sensor doesn't use pixel clock to configure the line time, then you will have to amend pixel rate to make the calculations match.

[pbaetens]

AT ALL times i made sure this formula was true.
Still, different combinations of VBLANK and pixel rate yield different results in the [Actual Framerate]

frame interval = (analogue crop width + horizontal blanking) *
                 (analogue crop height + vertical blanking) / pixel rate

The terminology of VBLANK / HBLANK dates back from DVP image sensors, modern MIPI sensors are 'packet' based and don't have physical sync signals.

I suspect the culprit is inside the cam_helper class, and not in the v4l driver.

[6by9]

The terminology of VBLANK / HBLANK dates back from DVP image sensors, modern MIPI sensors are 'packet' based and don't have physical sync signals.

No, but there is almost always an active period and a blanking period per line.

Also note that this is the timing on the pixel array, not on the MIPI link. Frequently there is a FIFO between array and MIPI serialiser, and as long as there is sufficient time per line to be able to send all the data, then they can be running at very different rates.
This is true of imx477 for example - pixel rate is 840MPix/s, but MIPI is running at 450MHz and only 2 lanes, so with 12bit data is only carrying 150MPix/s. The minimum line length (width+hblank) is up at 24000 pixels for the full res mode so that the line period is sufficient to transfer the data.
imx290 is similar that the pixel rate is fixed as it is defined for the full array, but the MIPI link frequency is dropped in the cropped modes as there is less data to send.

I suspect the culprit is inside the cam_helper class, and not in the v4l driver.

You have the full source code to both.

Looking at the app_full.py source, frametime appears to be set from the "FrameDuration" metadata.
That is being set by the IPA at https://github.com/raspberrypi/libcamera/blob/main/src/ipa/rpi/common/ipa_base.cpp#L1263-L1264 based on computing the exposure time equivalent to frameLength and lineLength.

[pbaetens]

ok, that explains it.

I had overridden the exposure() function in my cam_helper with a different calculation.

thank you!