- 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
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
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
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
Also fix a issue for finishConfiguration is unintentionally
delayed till first capture request.
Test: Camera CTS + partner device testing
Bug: 126390310
Change-Id: Ibca740a7160cbf41e01884dbcef8ba51eb4c75f7
Bug: 120407707
Test: CTS
Test: Use camera to take pictures / record videos (sanity)
Change-Id: I7b29c337d0e217d2eb6a62e2c75ccc550d795e61
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
- Derive HEIC capabilities from camera HAL and media framework.
- Add HeicCompositeStream to encode camera buffers to HEIC buffers.
- Add ExifUtils to overwrite JPEG APP segments and send to media codec.
- Add NDK enums and corresponding format support.
Test: Camera CTS
Bug: 79465976
Change-Id: I0a885e76335f3eba4be0fd42241edb0b7349f284
Add the necessary logic to support dynamic depth metadata.
Bug: 109735087
Test: Manual using application,
Camera CTS
Change-Id: Ic4710872dc596bc718270e1c79d4da53fb850875
In case application sends 2 consecutive setRepeatingBurst, the first
request may be preparing the video stream, whiel the second request
fails the isPreparing check.
Fix this by distinguishing between internal and external prepare. For
internal prepare, allow new requests to come through to the request
thread.
Bug: 114422231
Bug: 109830370
Test: Camera CTS
Change-Id: I55a7271e3924f2cb8cf9c452e934b070a82bc4ca
In extreme cases, HAL needs to wait until all inflight requests
are fulfilled before it can return a buffer, so extend the
getBuffer wait accordingly.
Test: partner testing, smoke test Pixel
Bug: 113660745
Change-Id: I363098004e70b75e11651fe0f1c75efcfda970f4
Decreasing timestamp shouldn't happen in non ZSL or reprocessing case.
When that happens, treat the buffer as error and return to buffer queue
directly.
Test: Camera CTS
Bug: 113670946
Change-Id: I39d3417dd9307d6cc7c90ff357a82604566a9081
Certain devices generate duplicate timestamps for cases like video
recording. So do not treat non-increasing timestamps as fatal for now.
Test: Failed camera CTS on Pixel device
Bug: 113670946
Change-Id: I3708f46111edf031f48f460e4efce9f9c46f174e
Guard against case where timestamp of stream buffers doesn't increase.
Timestamp source is either monotonic or boottime, both of which are
guaranteed to increase.
There are 2 exceptions where timestamp may go back in time:
- For requests where HAL ZSL is enabled, and
- For reprocessing requests
Test: Camera CTS
Bug: 113340974
Change-Id: I0ae9290696d651168150fa5ed7aa13c140a0294f
It's possible that surface for a stream goes away after
cameraservice configures HAL stream, either during configure_streams
or when session parameters are updated.
In this case, do not put camera device in an error state.
Test: Camera CTS, GCA
Bug: 111581884
Change-Id: I7efc5aa22bc9b60ffaea23d8dae275f9a2bd026d
- Add physical camera metadata in capture result.
- Adjust capture_result book-keeping for physical capture result.
- Adapt to new version of ICameraDeviceCallback.
- Batch physical metadata with logical metadata within one
process_capture_result call.
Test: testLogicalCameraTest CTS test
Bug: 64691172
Change-Id: I63fd343770cbb6183b7c6e4566c698f69801a8e8
Add physical camera ID in OutputConfiguration so that the application
can optionally set physical camera id for an output stream.
Test: Camera CTS
Bug: 64691172
Change-Id: I5909cd71618cc07ef403c420913eb1c02f1e10f0
Camera clients are allowed to change session parameters during
active session, however some camera devices might not be able
to apply them without additional stream configuration. To resolve
this, detect whether any of the available session parameter changes
in the queued requests and re-configure the camera before trying
to apply it.
Bug: 64450664
Test: Manual, Camera CTS
Change-Id: I005d6b7d6c6b27d4b5bac4b0d0809c7c019af9a4
It is allowed and expected some stream formats to get overriden
by the Hal implementation. In such cases the original format should
be stored and made available to device clients.
Bug: 64571102
Test: Camera CTS
Change-Id: Ic1153390e0c4d194475fbda8c8a13323bd7e73c0
The producer end can disconnect at any time which
will trigger the freeing of the input buffer. If
any input buffers are outstanding and being processed
by the camera device freeing them can cause stability
issues.
Bug: 63682712
Test: Manual using application.
Change-Id: I25da97786d75e82b1b13dce34953de597bea9b2e
Fix below use after free issues:
==4947==ERROR: AddressSanitizer: heap-use-after-free on address
0xec61f434 at pc 0xf1954c18 bp 0xed3ff6f0 sp 0xed3ff6e8
READ of size 4 at 0xec61f434 thread T12 (C3Dev-1-ReqQueu)
#0 0xf1954c17 in _ZN7android7camera313Camera3Stream23removeOutstandingBufferERK21camera3_stream_buffer
frameworks/av/services/camera/libcameraservice/device3/Camera3Stream.cpp:508
#1 0xf1954c17 in _ZN7android7camera313Camera3Stream12returnBufferERK21camera3_stream_bufferx
frameworks/av/services/camera/libcameraservice/device3/Camera3Stream.cpp:543
#2 0xf193c663 in _ZN7android13Camera3Device13RequestThread21cleanUpFailedRequestsEb
frameworks/av/services/camera/libcameraservice/device3/Camera3Device.cpp:4131
#3 0xf193db5b in _ZN7android13Camera3Device13RequestThread10threadLoopEv
frameworks/av/services/camera/libcameraservice/device3/Camera3Device.cpp:3854
#4 0xf1562f35 in _ZN7android6Thread11_threadLoopEPv system/core/libutils/Threads.cpp:747
#5 0xf0ee6947 in _ZL15__pthread_startPv bionic/libc/bionic/pthread_create.cpp:214
#6 0xf0eba381 in __start_thread bionic/libc/bionic/clone.cpp:47
0xec61f434 is located 68 bytes inside of 136-byte region [0xec61f3f0,0xec61f478)
freed by thread T0 here:
#7 0xf1a64963 in _ZdlPvSt11align_val_tRKSt9nothrow_t [asan_rtl]
#8 0xf155df09 in _ZNK7android7RefBase9decStrongEPKv system/core/libutils/RefBase.cpp:435
#9 0xf19693ab in _ZN7android7camera319Camera3OutputStream22BufferReleasedListener16onBufferReleasedEv
frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.cpp:720
#3 0x1ff56dfb (<unknown module>)
Bug: 62218367
Change-Id: Ib03415f73a1e3c283520af752904b1bcc40bff28
Make sure the callback object won't be freed in the middle
of callback execution.
Test: CTS + stress test
Bug: 63683767
Change-Id: I6fb1b754cadb3d499c1c246687d2f60d444d00bb
When abortCaptures is called, the request queue is cleared; as part of that,
any requests with input buffers trigger the removal and return of one input
buffer from the input stream.
However, if the HAL currently is processing some number of reprocess
requests, the stream's max buffer limit may have been reached, in
which case getInputBuffer will block until the HAL returns an input
buffer. This stalls flushing (and calling of capture_request) for
some time, and seems to cause problems for the HAL during the flush.
So instead, don't respect the HAL's max buffer limit when all we're
doing is throwing work away.
Test: CTS, manual testing
Bug: 62420820
Change-Id: I72d8cdaf67fb3cc6876a03cee9e0021d95cecdfe
Camera device related code should be agnostic w.r.t.
device version as much as possible. Specifically the
following requirements must hold true:
- Since support for devices 3.0&3.1 is deprecated
"ANDROID_QUIRKS_USE_PARTIAL_RESULT" is no longer considered.
- "ANDROID_SCALER_AVAILABLE_STREAM_CONFIGURATIONS" is always
used instead of the deprecated "ANDROID_SCALER_AVAILABLE_JPEG_SIZES".
- Buffer manager for camera streams is used for dynamic buffer
allocation.
- "flush" is always used instead of waiting for buffers to drain.
- Similar to "flush" stream "tearDown" is always available.
- Dead code handling buffer registration is removed.
Bug: 34392075
Test: Manual using camera application
Change-Id: If1b215f785ba61c6991fdf163d4eb18733690471
To cleanup caches of obsolete buffers.
This CL addressed the input stream bit, the output
stream hook will be a followup CL.
Also cleanup some dead API in CameraDeviceBase.h
Test: fix CTS ReprocessCaptureTest
Bug: 34461678
Change-Id: I801cd81c29becaa45630ed0a5c2dab8df1278a6a
- Merge notifyRequestedSurfaces into getBufferLocked, so that during
getBufferLocked, the stream splitter gets to know which outputs the
current request is on.
- Reserve buffer slot in the output queue during getBufferLocked instead
of during onFrameAvailable. So if there is no slot/buffer available, no
new request is sent to HAL. This aligns with current cameraservice logic.
Do not hold the lock while calling attachBuffer to output queue because
it could block for a slow consumer.
- Instead of setting the consumer buffer count of input buffer queue to
maximum of all shared outputs, set it to sum of them. By doing this,
In the case of a slow consumer, other consumers sharing the same stream
won't be impacted.
- Handle the case where onBufferReleased not being fired for buffer
replaced by attachBuffer/queueBuffer.
- Add function to check the return value of onFrameAvailable so that
when output is abandoned, the error code is propagated back to
queueBuffer.
Test: Camera CTS, and CTS with StreamSplitter enabled for all
implementation defined use cases.
Bug: 33777818
Change-Id: I863f501d5283bbe70c71e66b4d37d690484b90fa
- Use string for device ID in Camera3Device
- Remove camera3_device_t parameter from Camera3Stream::finishConfiguration
- Disables ability for the stream to register buffers
- This means device HALv3.0 and v3.1 are no longer supported
- Add HIDL support to Camera3Device:
- Add HalInterface class to abstract whether legacy or HIDL HAL is in use
- TODO
- CameraHardwareInterface
- Switch to using HIDL definitions instead of camera3.h definitions in
main body of code
Test: Compiles
Bug: 30985004
Bug: 32991422
Change-Id: I9c3c0f7b7ea5d1d74e14b1d882779e3b9445da69
Stop repeating request if any of its output stream is abandoned.
Add a callback to notify the repeating request has been stopped
with frame number of the last frame.
Update NDK with the new callback and behavior.
Bug: 21270879
Change-Id: I3553775c7807a77104aa1650609480ca3321310c
Keep a list of outstanding buffers in Camera3Stream so that
it won't return invalid buffers or the same buffers twice back
to the buffer queue.
Bug: 27894484
Change-Id: I9f96629b4f531778433c2e1ec32a142f2040832b
Camera api1 doesn't have error notification if JPEG buffer is dropped.
Add retry logic to try again if such error happens.
Bug: 27074407
Change-Id: I646566c6ee5a064896b5a433d8e1797140f0d257
- Also fix error logging template inconsistency
- Also add a few error handling cases into camera2 NDK
to deal with previously-ignored error codes
Bug: 27149500
Change-Id: I8f1f4c72252dd48d652f24b595b642199f20c327
* Add camera buffer manager for buffer allocation and sharing management across
multiple streams. Only gralloc v0 implementation is done, v1 implementation is
pending. With this, the max mem footprint for multiple streams in the same
stream set will be the max buffer count x max buffer size.
* API1 client will still use the old bufferQueue code path, buffer manager
is only targeting at API2 clients.
* Prepare and teardown should work with buffer manager.
* Some existing code typo fix and cleanup (to fix the compiling warnings).
Bug: 25088440
Change-Id: I68b246faa43080302acd02a8e976384bd3e26a23
Signal buffer returned even after it failed so the thread waiting
for it can wake up sooner.
Bug: 23981045
Change-Id: Iccbcc7ece2e0f6204da9c54f2bdd96ff6843a8f5
Refactor request threadLoop to three parts: waiting for next
batch of requests, preparing HAL requests and output buffers for
next batch of requests, and submitting the batch of requests to
HAL.
Set the batch size to the size of the request list if it's a video
recording request in a high speed video configuration.
Add a flush lock so that HAL's flush() won't be called while
submitting a batch of requests.
Bug: 23360060
Change-Id: Icd395b1f955a9b336eec6fa5aff6b17741ce08c7
Shuzhen Wang
Yin-Chia Yeh
Jayant Chowdhary
Emilian Peev
Eino-Ville Talvala
TreeHugger Robot
Zhijun He
Chien-Yu Chen
Ruben Brunk