- Handle various corner cases with regard to REQUEST_ERROR, RESULT_ERROR, and BUFFER_ERROR.
- Drain the codec outputs in case the input buffer isn't dropped.
- Allow APP_SEGMENT to drop while still producing valid output image.
- Add a status tracker to manage active/idle state.
- Use frame number as key for pending input frames since with ZSL, 2
capture result could have the same timestamp.
- Also removed some deprecated variable/methods.
Test: CTS, vendor testing
Bug: 145579077
Change-Id: I9c3e929469b8fb75b32b016f9006036c954f663f
Session parameter application may require an internal stream
re-configuration. Sometimes clients can abandon one ore more
registered outputs before changing a session parameter value.
Even if the new capture request doesn't reference the
abandoned surfaces the session parameter cannot be properly
configured. Keep the camera service behavior consistent with
older versions by skipping the internal stream
re-configuration.
Bug: 113513019
Test: Camera CTS
Change-Id: I8fb49b59ae0aecf537484a7238fe7a8a5d3efe64
Make sure the scaling of coordinates based on zoomRatio is symmetric
relative to the center of the image. And use the center of the pixel
for calculation.
Test: testZoomRatio, testDigitalZoom, cameraservice_test
Test: vendor testing
Bug: 153959755
Change-Id: I966bd31bde5afd50462a018590c7a4fefc3eaac6
mDistortionMappers are used in callback thread and request thread.
However, callback thread does not query before calling mDistortionMappers[mId.c_str()],
this may cause insertion to the map and mDistortionMappers.find may run at the same time.
Bug: 153506800, 153457587
Test: Camera CTS
Change-Id: I899033bacd355113fbad3e8f7ec76482aa147158
The metadata object might be overriden later and has it memory
re-allocated; hence snaping the sensor timestamp value before
we call into any method that might change the metadata.
Test: build
Bug: 150944913
Merged-In: I0f944fc9133d3ab279859f20236d956d7ca338f8
Change-Id: I0f944fc9133d3ab279859f20236d956d7ca338f8
(cherry picked from commit 60afc2fd8dab203a5697adbdb8dd4718d00bd9f1)
Clear the cached previous request in case of
successful offline switch. The request can
potentially continue to have valid references
to offline streams.
Clear the online camera device reference after
composite streams switch to offline mode.
In this case, all internal offline streams must
be released by the offline session.
Bug: 149346795
Test: Camera CTS
Change-Id: If29308dd0f402ab492e304e0475005b2a9801e74
This avoids unnecessary copying of camera metadata which can get
expensive in cases of large camera metadata blobs.
Bug: 71727540
Test: GCA (sanity)
Test: Add CallStack::logStack() in CameraMetadata's move asignment
operator -> see that it gets called for every insertResultLocked.
Change-Id: I6c75c7ce5267126916c865b028e5f7c7f50b763b
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
Methods like reconfigureCamera called by the RequestThread internally
call methods which might expect to have mInterfaceLock locked
(eg: configureStreamsLocked).
Also, function calls which expect to be serialized w.r.t
reconfigureCamera can cause reported camera status to be inconsistent
w.r.t the expected status.
For example the following situation might occur
through CameraTest.java#testVideoSnapshot :
For certain video sizes that would fail to configure the camera
startRecordingL
camera reconfiguration is triggered -> reconfigureCamera() starts
waitUntilDrained -> gets interleaved with reconfigureCamera()
reconfigureCamera() completes
Here the status of the camera device is active instead of CONFIGURED.
updateRecording
createStream() called expects the camera to not be in an ACTIVE
state since updateProcessorStream cannot handle stream
configuration failure gracefully when the device is streaming.
However since waitUntilDrained did not complete after
reconfigureCamera the camera status is STATUS_ACTIVE.
As a result, we should hold mInterfaceMutex while
calling these methods. To avoid deadlocks (b/143513518), we can have the thread
calling disconnect, relinquish mInterfaceMutex right before it starts
waiting on RequestThread to exit. It can re-acquire it when
RequestThread finishes.
Bug: 147313521
Test: atest CameraTest.java#testVideoSnapshot on pixel2 passes
Test: camera CTS
Test: GCA (sanity)
Change-Id: I384f62bc9936d9691dfe9c13ff743e3d07f2ed55
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
Notable fixes:
- Rework FrameProcessorBase so it accept and work with
offline sessions.
- Erase internal composite streams from offline stream list.
Bug: 135142453
Test: Camera CTS
Change-Id: I9dbc01e62fa94c1e0bfb84a8ddaa9e39ab4a7e34
When an app sets SCALER_ROTATE_AND_CROP to AUTO, the camera service
needs to select the right ROTATE_AND_CROP mode given the application
UI state at the moment, received from the window manager.
In addition, some of the metadata in the active array coordinate
system needs to be converted to/from the cropped+rotated coordinate
system to ensure roundtripping UI information works as before.
Also ensure that the available rotate and crop metadata field is
always available, with a value of NONE if nothing else.
This commit adds support for doing the coordinate transforms and
overriding AUTO to a concrete value; it does not wire up a connection
to another system service to receive the correct override value, but
does add a command to set the override value for all current camera
clients.
Test: New CTS tests pass, unit tests for RotateAndCropMapper pass
Bug: 134631897
Change-Id: Icc45530e2cfbaf838a1e4d04e4fd2aef8122e8e1
Camera clients must be aware of any configured streams
that can support offline processing mode.
A few corner cases that need to be considered:
- Composite streams can support offline mode only
when all internal streams support it as well.
- Streams that use the internal camera buffer manager
will not have support for offline mode.
- Shared streams are also unsupported in offline mode.
Bug: 135142453
Test: Camera CTS
Change-Id: Idde826a6fb18a8907850e87cfe593de7cb1c5f4a
ZoomRatioMapper's member variables are const after construction. As a
result, we don't need mutex to protect updateCaptureRequest and
updateCaptureResult calls.
Also fixed missing zoom ratio mapping initialization for physical
sub-camera.
Test: testZoomRatio CTS
Bug: 130025314
Change-Id: Ibe2ff7cffb13178dcf70fc9e2eb044184e58bcf2
- Add NDK API spec for the new zoom API
The new zoom API combines optical and digital zoom, and supports both
zoom-out and zoom-in with more precision.
- Add new NDK API to specify separate zoom ratio ranges for different
bokeh modes.
- Add ZoomRatioMapper in camera service to convert between
control.zoomRation to and from scaler.cropRegion.
Test: Camera CTS/ITS/CtsVerifier/ZoomRatioTest
Bug: 130025314
Change-Id: I4c7d867f840b5720bc73bb0485e8a9a93d2276b5
Functions called by RequestThread::threadLoop must not hold
mInterfaceMutex since the following deadlock scenario may occur:
T1: disconnect() -> holds mInterfaceMutex and waits for RequestThread to
exit
T2: RequestThread::threadLoop()->reconfigureCamera (or any other function) that waits on
mInterfaceMutex
leading to a deadlock
Bug: 143513518
Test: GCA
Test: CTS
Change-Id: I4bd856e5263934a54cd7087a01d35cfe10936196
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
Use onBuffersDiscarded callback from buffer queue to invalidate the
buffer caches in cameraserver process.
Test: Run testDiscardFreeBuffers, and use trace to profile memory
Bug: 136677409
Bug: 145617243
Change-Id: Ifac5e852e2a1ac50f5c3f2e047966c59eeb5f1ba
Merged-In: Ifac5e852e2a1ac50f5c3f2e047966c59eeb5f1ba
(cherry picked from commit 0160ddd149)
Explicitly signal and unblock the request thread
during device flushes via "mRequestSignal". This can
potentially reduce the time needed to go in to IDLE state.
Bug: 144978201
Test: Camera CTS
Change-Id: Ib212ca481a961252cf744af4b96f3c45865d121e
The internal buffer queue and respective 'mConsumer' may
never get initialized in case the connection and/or
configuration of client shared output surfaces fails.
To avoid possible instabilities check whether the
consumer interface is valid before trying to disconnect.
Bug: 143506890
Test: atest
cts/tests/camera/src/android/hardware/camera2/cts/MultiViewTest.java
Change-Id: Ia533233444fd548ddb52f4fde06212a21bc843bc
Merged-In: Ia533233444fd548ddb52f4fde06212a21bc843bc
The internal buffer queue and respective 'mConsumer' may
never get initialized in case the connection and/or
configuration of client shared output surfaces fails.
To avoid possible instabilities check whether the
consumer interface is valid before trying to disconnect.
Bug: 143506890
Test: atest
cts/tests/camera/src/android/hardware/camera2/cts/MultiViewTest.java
Change-Id: Ia533233444fd548ddb52f4fde06212a21bc843bc
Application may first call ImageWriter.queueInputImage without sending any capture
request before reconfiguring capture session using the same ImageWriter.
In this case, the stale buffers still exist in the buffer qeueue, and
ImageWriter.queueInputImage may stuck at waiting for free slots in the
new capture session.
Clear up all such queued buffers in the input buffer queue during stream
reconfiguration.
Test: Run testMandatoryReprocessConfigurations 300 times
Test: testQueueImageWithoutRequest
Bug: 138729150
Change-Id: Ie102dd018983bbd972f7c647d8c86c976a44e754
Camera preview stop only waits until the
current capture request is sent to Hal and
then immediately flushes the device.
Depending on timing and the pending request
queue size within CameraHal the current camera
client parameters may get flushed before
they are able to reach the end of the
processing pipeline.
Avoid this by waiting for the current request
id to appear in the incoming results.
Bug: 139330668
Test: Camera CTS, manual using application
Change-Id: I18de85557e8e76bfbe6d69b1eb2a5c36ed64e803
Use onBuffersDiscarded callback from buffer queue to invalidate the
buffer caches in cameraserver process.
Test: Run testDiscardFreeBuffers, and use trace to profile memory
Bug: 136677409
Change-Id: Ifac5e852e2a1ac50f5c3f2e047966c59eeb5f1ba
The previous logic was wrong(!) where DATASPACE_UNKNOWN shouldn't be
used as an initializtion condition.
Test: CTS and vendor testing
Bug: 139820060
Change-Id: I6b59d40ff796d48fe1804b45c189004f1ecc8c18
The HAL is allowed to notify RESULT_ERROR for physical sub-cameras.
Fix the condition check to allow absent physical metadata in such case.
Test: Partner testing and camera CTS
Bug: 138727686
Change-Id: I411a64d6fec2e06bc60a82fade65a02caab0ceca
Original logic was comparing an overridden format int, switch
to use a const original format.
Test: partner device, Pixel 3 CTS
Bug: 136456900
Change-Id: I03d6e190770ee05e40446c417e323f546fdc2689
By checking the expected duration for all inflight requests to
finish and only log when it takes more than a threshold (5 secs)
to process all inflight requests and the list is long.
Test: manual testing
Bug: 135927862
Change-Id: Iaa2c593f1e69f63b1da7d35d73c696de3510cd2c
With the new dataSpace/format override logic, during
finishConfiguration, we shouldn't check mDataSpaceOverride flag anymore
because now mDataSpaceOverride will be true for reconfigure.
Instead, we should check if the new override is the same as old
override.
Test: testPrepare on HAL device with dataSpace override
Bug: 134800141
Change-Id: I1ddc258100dfd7e3c2cc86f9e476d8d52c710e3f
Starting from HAL device version 3.5, the format and dataSpace for
IMPLEMENTATION_DEFINED pixel format uses original instead of overridden
values.
This makes HAL interface behavior consistent in that HAL doesn't need to
distinguish between first-time configureStreams and subsequent
reconfigure.
Test: Camera CTS and partner testing
Bug: 131864007
Change-Id: Ie5fdc7e9b6c11c1c96a069262b9458455855bcef
This patch fixes several issues:
* Change the timing the acquire fence FD is closed: we used to
close the FD when the buffer is returned from HAL. This patch
changes that to after the request is sent to HAL (or failed
to send to HAL)
* Cleanup inflight buffer map if the request fails to be sent to
HAL
* With the CL, the acquire fence FDs are now closed by
- HalInterface::processBatchCaptureRequests if the HIDL
processCaptureRequests call succeeds and HAL is running
in binderized mode (for passthrough mode the FD is owned
by HAL if the HIDL call succeeds)
- Camera3Device::cleanupFailedRequests otherwise
Test: Camera CTS tests
Bug: 132594861
Change-Id: I5f67ae9e7b8008738bd9a24246d754a6a3669b0c
We no longer have code path running non-HIDL interface.
This cleanup also simplifies some logic needed for fixing
b/132594861
Bug: 132594861
Test: Camera CTS
Change-Id: If15ea359a1a59c5a8e7a59818ce4db8120000bc4
Add below logical camera support to dumpsys:
- Physical camera id to stream info.
- Physical camera request/result metadata.
- Physical camera metadata in tag monitor.
Also fixed an issue of missing vendor tags in physical metadata.
Test: Run physical streams and observe dumpsys
Bug: 111940580
Change-Id: I02889b213ff5e7ec29506c0483ef40de9d107ccb
Shuzhen Wang
TreeHugger Robot
Emilian Peev
Yin-Chia Yeh
Jayant Chowdhary
Eino-Ville Talvala
Automerger Merge Worker