[libcamera-devel,v3,16/16] android: capabilities: Cap frame rate to 30 FPS
diff mbox series

Message ID 20211011151154.72856-17-jacopo@jmondi.org
State Superseded
Headers show
Series
  • IPU3 control info update and HAL frame durations
Related show

Commit Message

Jacopo Mondi Oct. 11, 2021, 3:11 p.m. UTC
Limit the reported minumum frame duration to 30 FPS.

The reason to do is to bring the libcamra HAL in par with the Intel
HAL implementation on IPU3 platform, where 30FPS is the frame rate used
to perform quality tuning in the closed-source IPA module and has been
validated as the most efficient rate for the power/performace budget.

This change bring into the HAL a platform specific constraints, which
might be opportune for most platforms but should rather be configurable
by system integrators. Record that with a \todo entry.

Also record that, even if we report a lower frame rate, we currently
do not limit what the camera actually produce.

Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 src/android/camera_capabilities.cpp | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

Comments

Kieran Bingham Oct. 14, 2021, 9:09 a.m. UTC | #1
Quoting Jacopo Mondi (2021-10-11 16:11:54)
> Limit the reported minumum frame duration to 30 FPS.
> 
> The reason to do is to bring the libcamra HAL in par with the Intel
> HAL implementation on IPU3 platform, where 30FPS is the frame rate used
> to perform quality tuning in the closed-source IPA module and has been
> validated as the most efficient rate for the power/performace budget.
> 
> This change bring into the HAL a platform specific constraints, which
> might be opportune for most platforms but should rather be configurable
> by system integrators. Record that with a \todo entry.
> 
> Also record that, even if we report a lower frame rate, we currently
> do not limit what the camera actually produce.
> 
> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
>  src/android/camera_capabilities.cpp | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/src/android/camera_capabilities.cpp b/src/android/camera_capabilities.cpp
> index fbce816c5f61..0d72a1ff07fa 100644
> --- a/src/android/camera_capabilities.cpp
> +++ b/src/android/camera_capabilities.cpp
> @@ -635,6 +635,30 @@ int CameraCapabilities::initializeStreamConfigurations()
>  
>                         int64_t minFrameDuration = frameDurations->second.min().get<int64_t>() * 1000;
>                         int64_t maxFrameDuration = frameDurations->second.max().get<int64_t>() * 1000;
> +
> +                       /*
> +                        * Cap min frame duration to 30 FPS.
> +                        *
> +                        * 30 frames per second has been validated as the most
> +                        * opportune frame rate for quality tuning, and power
> +                        * vs performances budget on Intel IPU3-based
> +                        * Chromebooks.
> +                        *
> +                        * \todo This is a platform-specific decision that needs
> +                        * to be abstracted and delegated to the configuration
> +                        * file.
> +                        *
> +                        * \todo libcamera only allows to control frame duration
> +                        * through the per-request controls::FrameDuration
> +                        * control. If we cap the durations here, we should be
> +                        * capable of configuring the camera to operate at such
> +                        * duration without requiring to have the FrameDuration
> +                        * control to be specified for each Request. Defer this
> +                        * to the in-development configuration API rework.
> +                        */
> +                       if (minFrameDuration < 1e9 / 30.0)
> +                               minFrameDuration = 1e9 / 30.0;
> +

It would be nice to be using std::chrono::durations or something here to
be able to use 1s/30 or perhaps some other friendly way of describing
frame rates..

But I guess that needs considerably more changes so it doesn't need to
be part of this:


Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>


>                         streamConfigurations_.push_back({
>                                 res, androidFormat, minFrameDuration, maxFrameDuration,
>                         });
> -- 
> 2.33.0
>

Patch
diff mbox series

diff --git a/src/android/camera_capabilities.cpp b/src/android/camera_capabilities.cpp
index fbce816c5f61..0d72a1ff07fa 100644
--- a/src/android/camera_capabilities.cpp
+++ b/src/android/camera_capabilities.cpp
@@ -635,6 +635,30 @@  int CameraCapabilities::initializeStreamConfigurations()
 
 			int64_t minFrameDuration = frameDurations->second.min().get<int64_t>() * 1000;
 			int64_t maxFrameDuration = frameDurations->second.max().get<int64_t>() * 1000;
+
+			/*
+			 * Cap min frame duration to 30 FPS.
+			 *
+			 * 30 frames per second has been validated as the most
+			 * opportune frame rate for quality tuning, and power
+			 * vs performances budget on Intel IPU3-based
+			 * Chromebooks.
+			 *
+			 * \todo This is a platform-specific decision that needs
+			 * to be abstracted and delegated to the configuration
+			 * file.
+			 *
+			 * \todo libcamera only allows to control frame duration
+			 * through the per-request controls::FrameDuration
+			 * control. If we cap the durations here, we should be
+			 * capable of configuring the camera to operate at such
+			 * duration without requiring to have the FrameDuration
+			 * control to be specified for each Request. Defer this
+			 * to the in-development configuration API rework.
+			 */
+			if (minFrameDuration < 1e9 / 30.0)
+				minFrameDuration = 1e9 / 30.0;
+
 			streamConfigurations_.push_back({
 				res, androidFormat, minFrameDuration, maxFrameDuration,
 			});