Zuma 8K won't be shipped on P23 devices, so "8K" should be removed
from media_profiles as it's visible to the public.
This CL removes 8K support on udc-d1-dev, which is the branch for
launching P23.
To continue developing 8K using P23 devices, we'll re-enable 8K support
on udc-qpr-dev with a follow-up CL.
Bug: 288304801
Test: python gca_smoke.py
Test: CTS & PTS
Change-Id: Ie0c35ea2c2bb1ab49912b69079b2038b42f632f1
The 2nd attempt (ag/20294157) was reverted due to b/259732944. To avoid
the bug, we explicitly define the "high" quality encoder as a 4k
encoder. Note (1) below explains the reasons.
8k encoder specs:
Codec: h264
bitRate: 80000000 (80M); source: b/241178681#comment3
Size: 7680x4320 (8K UHD)
Frame rate: 30fps
Notes:
(1) Regarding b/259732944 (the bug caused by the 2nd attempt):
If CamcorderProfile.QUALITY_HIGH isn't explicitly specified, the highest
resolution available will be used.
Therefore, when the 8k profile was added, apps requesting QUALITY_HIGH
would ask HAL to perform 8k recording.
This created the following issues:
(a) As 8k support in HAL isn't ready, existing tests using QUALITY_HIGH
will fail (such as CTS, PTS, FATP, etc.).
(b) 3rd-party apps currently using QUALITY_HIGH will get 8k, which might
not be their intention.
So we chose to keep QUALITY_HIGH at 4k, which was the highest resolution
on P22 devices.
Detailed discussions are in b/259599407.
----------------
(2) Regarding the "quality" attribute in EncoderProfile:
It must match what's defined in MediaProfiles::sCamcorderQualityNameMap
(see frameworks/av/media/libmedia/MediaProfiles.cpp).
----------------
(3) Regarding the camera IDs:
The camera IDs in media_profiles_{device_name}.xml correspond to the
IDs inside vector ModelSpecificDataControllerBase::visible_camera_ids_.
The vector is populated in
lyric/silo/hardware/devices/{device_name}/data/model_specific_data_controller.cc
According to the documentation of "visible_camera_ids_", "the first ID
for each facing will be used as the default camera ID". As
visible_camera_ids_[0] is always the first (default) ID for the rear
camera, and only the rear camera supports 8k, we add 8k encoder
profiles for camera 0 in media_profiles.
The explanation above isn't obvious. You'll need to read
model_specific_data_controller.cc to understand it.
----------------
(4) Regarding tests:
We can't test the 8k encoder since we haven't brought up the 8k support
in ISP.
We can use CTS, PTS, and EECoexer to test this CL for existing use cases.
Note that RecordingTest#testBasicRecording currently fails at TOT due to
a different reason. For this CL, we only need to make sure no 8k stream
is requested by observing logs with the "GCH_HalUtils" tag.
Bug: 232811715
Bug: 262423942
Test: build & boot Android
Test: atest RecordingTest#testBasicRecording
Test: adb shell /data/sysval/scripts/eecoexer/eecoex.sh -s CAM,22,0,5,true,HIGH
Test: manually testing GCA video recording
Change-Id: Ie6c054e641810da9c231f3839961cbe8fcc16fdc
Per b/259732944#comment2, using CamcorderProfile.QUALITY_HIGH will
request an 8k stream if 8k is present in media_profiles. This is because
QUALITY_HIGH is the "quality level corresponding to the highest
available resolution".
(https://developer.android.com/reference/android/media/CamcorderProfile#QUALITY_HIGH)
However, the 8k support in camera HAL isn't ready, so we have to remove
8k from media_profiles to avoid breaking apps using QUALITY_HIGH.
Bug: 232811715
Bug: 259732944
Test: build
Test: boot & check GCA video recording
Change-Id: I52a2b6c577acfff1d871cc038916d1490abd0fd6
