[libcamera-devel,RFC,v2] android: Do not cap those minFrameDuration nearabout 30fps

14987 diff mbox series

We have some stream resolution which can provide slightly better
frame duration than what we cap (i.e. 1/30 fps). The problem with
this is CTS complains if the camera goes faster during the test
than minFrameDuration reported for that stream. For instance,

1080p minFrameDuration:
	- Nautilus : 33282000
	- Soraka   : 33147000

Both are less than capped minFrameDuration (3333333).

This patch considers this situation and doesn't cap the
minFrameDuration if the hardware can provide frame durations slightly
better. The delta considered is 1% only from the cap.

Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
---

On LIMITED level - no regressions were found : 230/231 pass rate
(retested locally from RFC v1)

On FULL level - this fixes the test:
android.hardware.camera2.cts.SurfaceViewPreviewTest#testPreviewFpsRange
---
 src/android/camera_capabilities.cpp | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

Hi Umang

On Thu, Dec 02, 2021 at 07:16:44PM +0530, Umang Jain wrote:
> We have some stream resolution which can provide slightly better
> frame duration than what we cap (i.e. 1/30 fps). The problem with
> this is CTS complains if the camera goes faster during the test
> than minFrameDuration reported for that stream. For instance,
>
> 1080p minFrameDuration:
> 	- Nautilus : 33282000
> 	- Soraka   : 33147000
>
> Both are less than capped minFrameDuration (3333333).
>
> This patch considers this situation and doesn't cap the
> minFrameDuration if the hardware can provide frame durations slightly
> better. The delta considered is 1% only from the cap.

We're piling hack over hack, but all of this will go away with a
proper configuration API that allows to set a frame duration per
configuration session, so this is good if it fixes tests..

>
> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
> ---
>
> On LIMITED level - no regressions were found : 230/231 pass rate
> (retested locally from RFC v1)
>
> On FULL level - this fixes the test:
> android.hardware.camera2.cts.SurfaceViewPreviewTest#testPreviewFpsRange
> ---
>  src/android/camera_capabilities.cpp | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/src/android/camera_capabilities.cpp b/src/android/camera_capabilities.cpp
> index f357902e..66ff1274 100644
> --- a/src/android/camera_capabilities.cpp
> +++ b/src/android/camera_capabilities.cpp
> @@ -667,8 +667,17 @@ int CameraCapabilities::initializeStreamConfigurations()
>  			 * control to be specified for each Request. Defer this
>  			 * to the in-development configuration API rework.
>  			 */

Do you think the comment should report we have a 1% tollerance ?

> -			if (minFrameDuration < 1e9 / 30.0)
> -				minFrameDuration = 1e9 / 30.0;
> +			int64_t capMinFrameDuration = 1e9 / 30.0;
> +			if (minFrameDuration < capMinFrameDuration) {
> +				float delta = (capMinFrameDuration - minFrameDuration) * 100 / capMinFrameDuration;
> +
> +				/*
> +				 * If the delta is less than 1%, do not cap the
> +				 * frame duration.
> +				 */
> +				if (delta > 1)
> +					minFrameDuration = capMinFrameDuration;
> +			}
>
>  			streamConfigurations_.push_back({
>  				res, androidFormat, minFrameDuration, maxFrameDuration,
> --
> 2.31.0
>