Status Update
Comments
da...@gmail.com <da...@gmail.com> #2
The same issue happens when passing an ordered list of qualities starting with UHD. It consistently skips UHD unless you use QualitySelector.from(Quality.UHD).
da...@gmail.com <da...@gmail.com> #3
It doesn't appear to ever use the first value you pass. I'm experimenting with trying to find a workaround. Maybe we can pass the value twice.
da...@gmail.com <da...@gmail.com> #4
getSupportedQualities and isSupportedQuality work fine but require that the camera was already started. It doesn't appear that the from/fromOrderedList methods work in any case other than passing a single specific quality. They always skip the initial quality. Perhaps this is a race condition in CameraX or something similar. I'm not sure. It's a frustrating API because you can't figure out the supported qualities until you've started the camera and you can't be sure about what quality it ended up using if you didn't pass a specific one other than passing a list yourself and then assuming it used the first one that was supported.
Maybe there's a way to do it via Camera2 directly via the interop APIs but that's not well documented and probably doesn't work for this kind of thing.
wu...@google.com <wu...@google.com> #5
Thank you for reporting. Which version and devices are you using?
da...@gmail.com <da...@gmail.com> #6
CameraX 1.1.0-beta03 and we're primarily testing on 3rd/4th/5th/6th generation Pixels (every model) but we expect this occurs elsewhere. The issue seems reproducible on each Pixel phone at least.
wu...@google.com <wu...@google.com> #7
Thanks for the update. We will take a look and update the status here!
le...@google.com <le...@google.com> #8
Hi,
Thanks for the feedback. QualitySelector.isQualitySupported() can only know whether the device support this quality, but the final selected quality is still constrained by UseCase combinations when
For example, assume isQualitySupported(UHD) returns true on a device. When trying to bind use cases with QualitySelector only contains UHD, you may get below results for different combinations
- Preview + VideoCapture(UHD) => success
- Preview + ImageCapture + VideoCapture(UHD) => fail
- Preview + ImageCapture + VideoCapture(FHD) => success
In your case, I think you want to know in advance what qualities are supported under a certain use cases combination (ex: Preview + VideoCapture). However, there is not yet a convenient API to query about this. Currently you can create a VideoCapture with a single quality (QualitySelector.from(quality)) and then bind the use cases you want, use try-catch on ProcessCameraProvider.bindToLifecycle() to know if the combination is supported (ProcessCameraProvider.bindToLifecycle() will throw an exception if the combination is not supported).
However, this method will open camera when the combination is supported. It would be better to have an API that only checks for support without opening camera. There is a bug related to such API requirement. See
Let us know if you have any questions.
Leo
da...@gmail.com <da...@gmail.com> #9
Pixels appear to be capable of taking photos while recording 4k video and we're still seeing 4k resolution not being used on them when we try to use QualitySelector with UHD as the main choice and FHD as a fallback. It's likely that what you're describing does occur on some devices but I don't think it explains the QualitySelector issue we're seeing on Pixels.
da...@gmail.com <da...@gmail.com> #10
If you try our app from
le...@google.com <le...@google.com> #11
This sounds like a bug. I will investigate it and get back to you.
Thanks
le...@google.com <le...@google.com>
le...@google.com <le...@google.com> #12
The issue happens when combining ImageCapture + VideoCapture.
In a FULL level camera device, there are two possible combinations for Preview + VideoCapture + ImageCapture. (refer to
- (PRIV, PREVIEW) + (PRIV, RECORD) + (JPEG, RECORD)
- (PRIV, PREVIEW) + (PRIV, PREVIEW) + (JPEG, MAXIMUM)
MAXIMUM > RECORD > PREVIEW
In the current CameraX settings, ImageCapture has higher surface occupancy priority than VideoCapture by default. That means ImageCapture has higher priority to choose resolution than VideoCapture. When QualitySelector contains multiple qualities as candidates, such as
QualitySelector.from(Quality.UHD, FallbackStrategy.lowerQualityOrHigherThan(Quality.UHD)))
It means VideoCapture can accept UHD, FHD, HD, SD. CameraX auto-resolution mechanism will then adopt combination (2) because ImageCapture has higher priority. i.e. ImageCapture gets MAXIMUM size and VideoCapture gets Preview size (FHD).
For
QualitySelector.from(Quality.UHD)
Since there is only one option UHD (RECORD size) for VideoCapture, combination (2) can't be met and combination (1) is adopted. i.e. both ImageCapture and VideoCapture gets RECORD size.
will have a solution to fix this.
ap...@google.com <ap...@google.com> #13
Branch: androidx-main
commit 76d3d536e73a8c119534d7fbb2110e29bacc3706
Author: leo huang <leohuang@google.com>
Date: Tue May 03 00:54:01 2022
Increase VideoCapture surface occupancy priority over ImageCapture
Root Cause:
In a FULL (or higher) hardware level camera device, there are two possible combinations for Preview + VideoCapture + ImageCapture
(1) (PRIV, PREVIEW) + (PRIV, RECORD) + (JPEG, RECORD)
(2) (PRIV, PREVIEW) + (PRIV, PREVIEW) + (JPEG, MAXIMUM)
In the current code, ImageCapture has higher surface occupancy priority than VideoCapture by default. When QualitySelector contains multiple qualities as candidates, such as using QualitySelector.from(Quality.UHD, FallbackStrategy.lowerQualityOrHigherThan(Quality.UHD))) as the bug mentioned. The CameraX auto-resolution mechanism will give ImageCapture higher priority than VideoCapture to select the largest resolution it can use. So combination (2) is adopted and VideoCapture obtains PREVIEW size, i.e VideoCapture gets FHD but not UHD.
Solution:
For scenario using VideoCapture + ImageCapture, it makes sense to give VideoCapture higher surface occupancy priority than ImageCapture. Then combination (1) can be adopted for the issue case.
The CL also removes impossible resolutions from prioritized resolution list to prevent auto-resolution mechanism from incorrectly assuming that VideoCapture might use them. This ensure ImageCapture can still get the MAXIMUM size when VideoCapture only requests a surface resolution under PREVIEW size for combination (2).
Relnote: "Fixed QualitySelector fails to record a UHD video when a fallback strategy is enabled. The issue happens when VideoCapture is bound with ImageCapture and Preview on a FULL or higher hardware level camera device. A fallback strategy of QualitySelector causes VideoCapture incorrectly to get a FHD resolution. UHD resolution is actually supported for this use case combination and should be adopted."
Bug:
Test: ./gradlew camera:camera-video:testDebug
Change-Id: I0e788060512feef5fa934d7f35374da218ffe8e8
M camera/camera-camera2/build.gradle
M camera/camera-video/src/main/java/androidx/camera/video/VideoCapabilities.java
M camera/camera-camera2/src/test/java/androidx/camera/camera2/internal/SupportedSurfaceCombinationTest.java
M camera/camera-video/src/main/java/androidx/camera/video/VideoCapture.java
M camera/camera-video/src/test/java/androidx/camera/video/VideoCaptureTest.kt
Description
When we create a QualitySelector with the following code, it doesn't use UHD even when UHD is supported:
We had to implement a workaround for this in our app:
This works but led to a regression (a crash) because
camera
isnull
when the app is being opened immediately to video mode via the standard Android video capture intent. We'll try some other approaches to using QualitySector but it doesn't seem thatFallbackStrategy
works correctly at the moment.Our app is open source if for some reason you can't reproduce this yourselves.