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
1. Change Camera3Device logs to ALOGV
2. In Camera3OutputStream, only log before we mark stream state
to STATE_ABANDONED
3. Also changed BUFFER_ERROR log to ALOGV
Test: manually check log of GCA mode switch
Bug: 125415787
Change-Id: Ibd83b7010932a8be25d85573d9c9dce9c394f6bb
Fix the long (>1s) dequeueBuffer call when a stream is managed by
Camera3BufferManager and its consumer end discards free buffers.
Test: CTS, no more long dequeBuffer call in GCA mode switch
Bug: 126054873
Change-Id: I03d6526b076796bb44f15cc2c4a092ff3d04fc1d
Support runtime "SessionConfiguration" queries by camera
clients.
Bug: 111593096
Test: adb shell /data/nativetest64/camera_client_test/camera_client_test
--gtest_filter=CameraClientBinderTest.CheckBinderCameraDeviceUser,
Camera CTS
Change-Id: I1505e7bccdce468490b46ad4546e459354a4cda3
- 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
If the device support ZSL, drop pending preview buffers to reduce
the chance the rendering preview frames newer than the still frame
during takePicture().
Test: CTS
Bug: 67497723
Change-Id: I5f253a402a6302d31777ad4ca2878ef0d0d1ae44
(cherry picked from commit c75eb9b126b2c6b7fc8f47d8ae4e4ac15f6a176e)
The Camera API needs to support the dynamic attach/detach of extra
output surfaces to a given camera stream.
Bug: 63912484
Change-Id: I18809aea31f78fb9e125bd18b58951ade4fad3c5
This change attempts to free buffers managerd by
BufferManager more aggresively to reduce memory pressure.
Also fix a small buffer accounting issue: check detachBuffer
actually returns a non-null buffer.
Test: keep taking single shot in GCA, CTS
Bug: 38483630
Change-Id: I6c64d1dc2244cec4f1300bbf3992f66f2167eed2
- 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
- Refactor the OutputConfiguration to contain isDeferred and isShared
flag, and not contain NULL surface.
- Unify the handling of deferred surface and shared surface.
Test: Camera CTS, and manual testing of GoogleCamera use cases
Bug: 33777818
Change-Id: I5dd3472f0f2133699b0e9fbdd8ba456956222746
- Enhance OutputConfiguration to contain multiple surfaces for one
underlying stream.
- Create Camera3SharedOutputStream to handle streams with multiple
surfaces.
- Create Camera3StreamSplitter to handle buffer flows between camera and
multiple consumers.
Test: cts, and manually test camera preview/snapshot/recording
Bug: 33777818
Change-Id: Ia010c3cc9d9b4bd5b9ea03cc42fe4e0a0d8033f1
The synchronous consumers (e.g. ImageReader) may be very slow when the
clients have computational intensive image processings. When system
load is high, these processing will be even much slower. This could
starve the producer side and then cause dequeue/attach buffer block
indefinitely. If clients intends to close the capture session, right
after a capture request is submitted, the waitUntil drain could be
blocked indefinitely if the capture request dequeue buffer call is
blocked indefinitely, as the request thread will never become idle until
the last dequeue buffer is done and the request is sent.This indefinite
getBuffer() blocking could easily trigger the waitUntilDrained 5s timeout
thus put the camera device into error state although there is nothing
bad happening in the HAL.
Introducing the timeout will avoid such bad situation. When consumer is
slow, there will be no new request being sent to HAL, as there is really
no new buffer available.
Bug:30404840
Change-Id: Ibf08d2745911203bce6f31130800707f36d7f985
The synchronous consumers (e.g. ImageReader) may be very slow when the
clients have computational intensive image processings. When system
load is high, these processing will be even much slower. This could
starve the producer side and then cause dequeue/attach buffer block
indefinitely. If clients intends to close the capture session, right
after a capture request is submitted, the waitUntil drain could be
blocked indefinitely if the capture request dequeue buffer call is
blocked indefinitely, as the request thread will never become idle until
the last dequeue buffer is done and the request is sent.This indefinite
getBuffer() blocking could easily trigger the waitUntilDrained 5s timeout
thus put the camera device into error state although there is nothing
bad happening in the HAL.
Introducing the timeout will avoid such bad situation. When consumer is
slow, there will be no new request being sent to HAL, as there is really
no new buffer available.
Bug:30404840
Change-Id: Ibf08d2745911203bce6f31130800707f36d7f985
- Maintain separate count of attached buffers
- Only attach when new buffers need to be allocated
- Only detach when a buffer needs to be freed
- Fix missing notification initializations
- Remove warning that's always logged
Bug: 28695173
Change-Id: I38e997fa1e69c2b8743e43eed31a6a08a6f9cd7a
If buffer consumers assume different clock domain compared to the camera
output, camera3 device uses the offset between the clock domains to convert
the timestamp.
Bug: 27153476
Change-Id: Iaae33281411cb27b639e87b0dad957d640182898
Certain consumers such as Hardware Composer and AudioSource
use MONOTONIC timestamp, which causes time misalignment if
camera timestamp is in BOOTTIME.
Do not set buffer time stamp for such streams and let
BufferQueue handle it.
Bug: 22214409
Bug: 26762232
Change-Id: Id1c4b85a181e39827e8f27949a199165bbd445f9
* 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
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
Also switch use of ANativeWindow to Surface, to get to the
getConsumerName() method where necessary.
Surface can always be cast to ANativeWindow, but not the other way
around, so it's a better option anyway.
Change-Id: Ie5c2d30821c1a754f9e382699ff50b4b328288b3
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
- Remove unused arguments from ICameraDeviceUser::createStream
- Add dataSpace as a stream parameter, plumb it through everything
Change-Id: I608cafe694785d1c512276e71b2016f8ac3b0ccb
Also override the disconnectLocked method in Camera3ZslStream to make sure the
Camera3ZslStream specific buffer queue is cleaned up properly.
Also revert 0be123df18, as it was not the right
fix.
Change-Id: I89bdcb2e206379ae1f2602421e7fdbcde9a31399
At stream configure time, pass on the stream's consumer usage flags
to the HAL, to speed up final hardware configuration.
Bug: 9592202
Change-Id: Ie467be053be36a09e482f5f05cad65df42d66476
- 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
Shuzhen Wang
Yin-Chia Yeh
Emilian Peev
Chien-Yu Chen
Chih-hung Hsieh
Zhijun He
Eino-Ville Talvala
Ruchit Sharma