5c22c15ed8c593189ed9bb8fcbccace2ca63b82a |
|
01-Jan-2018 |
Shuzhen Wang <shuzhenwang@google.com> |
Camera: Support physical camera metadata in capture result - 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
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
c28189a64a6ef65aecccb6e3bb980f1afc189a1c |
|
28-Nov-2017 |
Shuzhen Wang <shuzhenwang@google.com> |
Camera: Add physicalCameraId to OutputConfiguration 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
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
a936ac26464263367b7342a3501f3b6db2736888 |
|
24-Oct-2017 |
Chien-Yu Chen <cychen@google.com> |
camera: Drop pending preview for enableZsl shots 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)
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
40ead60d7163c2d5577099d49f11da7afa6124d1 |
|
26-Sep-2017 |
Emilian Peev <epeev@google.com> |
Add support for dynamic shared output surfaces The Camera API needs to support the dynamic attach/detach of extra output surfaces to a given camera stream. Bug: 63912484 Change-Id: I18809aea31f78fb9e125bd18b58951ade4fad3c5
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
050f5dcf7d1903926b165ebdd2dd30f7a2e83c02 |
|
18-May-2017 |
Emilian Peev <epeev@google.com> |
Camera: Switch usage flags to 64-bit unsigned Usage flags should use 64-bit unsigned values. Bug: 35215313 Test: Camera CTS Change-Id: Ib8d8ec07e16698e34183c3e54498ad7491348087
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
686f644f981badd481d8781bf80b221544df7b1f |
|
21-Jun-2017 |
Shuzhen Wang <shuzhenwang@google.com> |
Camera: Add debug messages for camera latency Log latency histogram of: - processCaptureRequest call, - dequeueBuffer call, and - waiting time for handout count fall below max_buffers Test: Camera CTS Bug: 62651109 Change-Id: I5ee1cdb4139fa359f0887d6f6871884e28739340
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
89954d931d7b952597dc8e29e7a87da31a4ae0b1 |
|
22-May-2017 |
Yin-Chia Yeh <yinchiayeh@google.com> |
Camera: Free buffers more aggressively 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
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
017d49c409af17a2e0ef3ca48fadb1b5a5ec3fe4 |
|
01-Apr-2017 |
Yin-Chia Yeh <yinchiayeh@google.com> |
Camera: add buffer freed notification for output streams Test: ReprocessCaptureTest fixed Bug: 34461678 Change-Id: Icd5af79a8f7fc35b0a040c57a639ae6777e71024
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
bee0f0a5e7aa19aa7c59de03b508985b68bc6b5e |
|
24-Jan-2017 |
Shuzhen Wang <shuzhenwang@google.com> |
Camera: Rework StreamSplitter for camera use cases - 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
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
758c215374dba397dabe17b8e96dd38593c09dd7 |
|
11-Jan-2017 |
Shuzhen Wang <shuzhenwang@google.com> |
Camera: Combine handling of deferred surface and shared surface - 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
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
0129d52df9794d6fdf06be304722b5cb51a2eab5 |
|
31-Oct-2016 |
Shuzhen Wang <shuzhenwang@google.com> |
camera2: Add support for secondary surface for stream - 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
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
2f919a49511af0b8736f6edb43d7ce579470b259 |
|
12-Sep-2016 |
Chih-hung Hsieh <chh@google.com> |
Merge "Fix google-explicit-constructor warnings in camera." am: f9ee5183c8 am: beff1fb18b am: 019e54142c Change-Id: I1278af9e5244995c7fdbc4ee7a54314571b3df3f
|
d19d994770a04f02c204affd29985c5aeaa58baa |
|
29-Aug-2016 |
Chih-Hung Hsieh <chh@google.com> |
Fix google-explicit-constructor warnings in camera. * Add explicit keyword to conversion constructors. Bug: 28341362 Test: build with WITH_TIDY=1 Change-Id: I61f9b5b2b6e13e0c6561327bc8dfe69c9cfc5ba5
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
f81b009d77466c5b3901d2c49b0fcc618e3d1592 |
|
02-Aug-2016 |
Zhijun He <zhijunhe@google.com> |
Camera3: don't let dequeueBuffer block indefinitely 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
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
f0645c19a8c8433766f4cb6edff7fca5db8017bf |
|
02-Aug-2016 |
Zhijun He <zhijunhe@google.com> |
Camera3: don't let dequeueBuffer block indefinitely 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
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
e8a984e43504890e0f676256a0445b9917a2af91 |
|
18-Jun-2016 |
Eino-Ville Talvala <etalvala@google.com> |
resolve merge conflicts of 77c1a35 to nyc-mr1-dev Change-Id: I18c301c55904c06b3f6f5d8eaa2df47ff87ddb4f
|
77c1a3554275a51ac8eb9fbe86f476afc8983192 |
|
13-Jun-2016 |
Eino-Ville Talvala <etalvala@google.com> |
Camera: BufferManager: Don't attach/detach on every frame - 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
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
5d677d1f0879d5101e38df480a38228a64d63959 |
|
30-May-2016 |
Zhijun He <zhijunhe@google.com> |
Camera3: add deferred surface support Initial native implementation and aidl changes for surfaceless support. Bug: 28323863 Change-Id: Id6634c3ef2ecc84422a88f63de0a19a0cb496e96
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
c28dcccb9bc0a94950a7475f9bd8a6a38be34419 |
|
12-Feb-2016 |
Shuzhen Wang <shuzhenwang@google.com> |
Camera3: Use proper timestamp clock domain for different streams 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
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
13a69633108f40f56aa47f1bcbb406cd5173c245 |
|
26-Jan-2016 |
Shuzhen Wang <shuzhenwang@google.com> |
Camera3: Selectively set buffer timestamp depends on consumer 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
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
125684aba1a11b7adbf5f9d607ee2bcc9449081c |
|
27-Dec-2015 |
Zhijun He <zhijunhe@google.com> |
Camera3: add camera3 buffer manager support * 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
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
85a6455f269d79adf9bf48d757a4b1b3c81cf760 |
|
29-Aug-2015 |
Chien-Yu Chen <cychen@google.com> |
Camera3Device: Support batch requests 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
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
727d172137b4f32681c098de8e2623c0b65a6406 |
|
09-Jun-2015 |
Eino-Ville Talvala <etalvala@google.com> |
CameraService: Add consumer name to output stream dumpsys 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
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
4d44cad22ea925a651463f2d51d6586c14d4b787 |
|
11-Apr-2015 |
Eino-Ville Talvala <etalvala@google.com> |
Camera2: Add prepare for output streams 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
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
b97babb8c08969b55af3b6456d15f764c8873d3f |
|
12-Mar-2015 |
Yin-Chia Yeh <yinchiayeh@google.com> |
Camera: plumbing rotation field through Change-Id: I0f4343a0bfa7bf09ba887c78a1da1c08daa35333
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
3d82c0d9ed2b3e956ad699a9ca2c8a70c9d24678 |
|
24-Feb-2015 |
Eino-Ville Talvala <etalvala@google.com> |
Camera: Wire up dataSpace, clean up ICameraDeviceUser - Remove unused arguments from ICameraDeviceUser::createStream - Add dataSpace as a stream parameter, plumb it through everything Change-Id: I608cafe694785d1c512276e71b2016f8ac3b0ccb
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
e0711f2651121754a10c784e3b149024d17fa4d5 |
|
18-Aug-2014 |
Ruchit Sharma <ruchits@nvidia.com> |
camera: add traces for KPI measurement Bug: 17658101 Change-Id: I1d8035c4a8fba7b88a87f205ce57c13d812e9df5
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
0a21051b91c2e07e49eb6fa568c505aee967ab9d |
|
24-Jul-2014 |
Zhijun He <zhijunhe@google.com> |
Camera3: tear down Camera3 streams when they are deleted. Also override the disconnectLocked method in Camera3ZslStream to make sure the Camera3ZslStream specific buffer queue is cleaned up properly. Also revert 0be123df1897fd3fe1b7ba30f24d8ae4c91b4dc7, as it was not the right fix. Change-Id: I89bdcb2e206379ae1f2602421e7fdbcde9a31399
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
b2f5b19e5b6e1408a259add23dba91037756a943 |
|
30-Jul-2013 |
Eino-Ville Talvala <etalvala@google.com> |
Camera3: Provide consumer usage flags to HAL for each stream 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
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|
7b82efe7a376c882f8f938e1c41b8311a8cdda4a |
|
26-Jul-2013 |
Eino-Ville Talvala <etalvala@google.com> |
Camera: Rename new API to camera2, rearrange camera service - 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
/frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.h
|