diff options
author | Paul Elder <paul.elder@ideasonboard.com> | 2021-03-30 18:43:38 +0900 |
---|---|---|
committer | Paul Elder <paul.elder@ideasonboard.com> | 2021-05-25 18:20:55 +0900 |
commit | 77c6ac0ae70e962a3776a06fa844653f181183cc (patch) | |
tree | b20c7ee04c90ea4ca076a5b4b647daac6c878059 /src/qcam/assets/feathericons/trash-2.svg | |
parent | 63c3c545926d7eb9af8c03930e79df8c2b46a8e9 (diff) |
android: CameraDevice: Report proper min and max frame durations
The HAL layer was getting the min and max frame durations from the
camera, then rounding it to fps to report as available fps ranges. The
same min and max frame durations were then being reported as min and max
frame durations. Since the fps are integer values while the frame
durations are in ns, this caused a rounding error making it seem like we
were reporting an available max fps that was higher than what was
allowed by the minimum frame duration.
An example is if the minimum frame duration is reported as 33366700ns.
The HAL layer would then convert it to fps, which is 29.97, but it would
be rounded and reported as 30 fps. When 30 fps is converted to a frame
duration it is 33333333ns, which is less than the minimum frame duration
that we report. Thus the minimum frame duration that we report
contradicts the fps range that we report.
Fix this by recalculating the frame durations based on the rounded fps
values.
This allows the following CTS test to pass:
- android.hardware.camera2.cts.SurfaceViewPreviewTest#testPreviewFpsRange
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Diffstat (limited to 'src/qcam/assets/feathericons/trash-2.svg')
0 files changed, 0 insertions, 0 deletions