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
Also fix a issue for finishConfiguration is unintentionally
delayed till first capture request.
Test: Camera CTS + partner device testing
Bug: 126390310
Change-Id: Ibca740a7160cbf41e01884dbcef8ba51eb4c75f7
- 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
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
The Camera API needs to support the dynamic attach/detach of extra
output surfaces to a given camera stream.
Bug: 63912484
Change-Id: I18809aea31f78fb9e125bd18b58951ade4fad3c5
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
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
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
* 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
- Support new set video format/dataspace command in camera service
- HALv3: Select gralloc usage flags based on format
- HALv1: Pass format command directly to HAL layer
- Use format/dataspace command in CameraSource
- Switch all API1 recording to use metadata mode
- Switch all >= HALv2 API1 recording to use kMetadataBufferTypeANWBuffer
Bug: 13222807
Change-Id: I2e609b92c65792611bb1dab09e0c41c363ebbc42
The prepare call asynchronously pre-allocates buffers for a given
output stream, and then fires the onPrepared callback.
Not implemented for Camera2Device or used in Camera2Client.
Change-Id: I1cccdfff846dd6985133c591dbdceed823929ade
- Add more error codes to the binder camera2 callbacks
- Translate HAL errors to callback errors
- When flushing, report failures for queued requests
- Treat stream config failure as nonfatal
- Send request errors when buffers aren't available for captures
Bug: 15524101
Bug: 14448494
Bug: 11272459
Bug: 17160301
Change-Id: I81aa54e805a9cce1cb8a6a9374549daa7666deb2
- Update callback Binder interface
- Rename frameId to be requestId to be consistent and disambiguate
from frameNumber.
- Implement shutter callback from HAL2/3 notify()
- Add in-flight tracking to HAL2
- Add requestId to in-flight tracking
- Report requestId from shutter callback
- Implement idle callback from HAL3 process_capture_result
- Add new idle tracker thread
- Update all idle waiting to use the tracker
- Add reporting from request thread, all streams to tracker
- Remove existing idle waiting infrastructure
Bug: 10549462
Change-Id: I867bfc248e3848c50e71527e3561fe92dc037958
- Support API rename from photography to camera2
- Reorganize camera service files
- API support files to api1/, api2/, api_pro/
- HAL device support files into device{1,2,3}/
- Common files into common/
- Camera service remains at top-level
Change-Id: Ie474c12536f543832fba0a2dc936ac4fd39fe6a9