| Message ID | 20211202132110.1067409-1-umang.jain@ideasonboard.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series |
|
| Related | show |
On 12/2/21 6:51 PM, 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. > > Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> > --- > On LIMITED level - no regressions were found : 230/231 pass rate > > 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 3e566755..6421456a 100644 > --- a/src/android/camera_capabilities.cpp > +++ b/src/android/camera_capabilities.cpp > @@ -810,8 +810,17 @@ int CameraCapabilities::initializeStreamConfigurations() > * 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; > + 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 > 0.01) oops. this should be delta > 1 > + minFrameDuration = capMinFrameDuration; > + } > > streamConfigurations_.push_back({ > res, androidFormat, minFrameDuration, maxFrameDuration,
diff --git a/src/android/camera_capabilities.cpp b/src/android/camera_capabilities.cpp index 3e566755..6421456a 100644 --- a/src/android/camera_capabilities.cpp +++ b/src/android/camera_capabilities.cpp @@ -810,8 +810,17 @@ int CameraCapabilities::initializeStreamConfigurations() * 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; + 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 > 0.01) + minFrameDuration = capMinFrameDuration; + } streamConfigurations_.push_back({ res, androidFormat, minFrameDuration, maxFrameDuration,
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 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(-)