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
For some resolutions input HeifWriter surfaces have much higher
acquired buffer count compared to the maximum Hal buffer for the
respective use case. From the tests so far shared streaming doesn't
seem to be affected by the imbalance and the splitter is able to
support this case.
Bug: 110161669
Test: Camera CTS
Change-Id: I129221b0f35e45c8b26f27f94910a6edda8d675b
The maximum acquired count of the input buffer queue during surface
sharing should be set considering the total maximum acquired count of
individual registered outputs and also the current acquired count
of the input buffer queue. The reason the two can be different is
due to the fact that individual outputs can acquire and also block
buffers from the input. The latter portion contains all buffers
which are still queued but not acquired. This can happen in case
some output acquires the maximum amount of buffers possible then
stops consuming entirely and the camera client continues to reference
it in subsequent capture requests.
To handle this, track the number of acquired buffers in the input
queue and expand (or contract) the maximum acquired count only if
possible. The maximum shouldn't change otherwise because the blocked
buffers could still be used by the unresponsive output at some
later point in time.
Bug: 117982710
Test: Camera CTS
Change-Id: Ia4e743efdf59cb0c9baaea492f78c37d0f2c95b3
If HAL overrides stream format, use the overridden format to configure
the buffer queues.
Bug: 113326269
Test: Camera CTS, partner testing
Merged-In: I6b198e8ebfeaeafbda530722d995a12f88f0b35a
Change-Id: I6b198e8ebfeaeafbda530722d995a12f88f0b35a
If HAL overrides stream format, use the overridden format to configure
the buffer queues.
Bug: 113326269
Test: Camera CTS
Change-Id: I6b198e8ebfeaeafbda530722d995a12f88f0b35a
Shared surface outputs currently re-use the transformation
from the input queue directly. However the inverse display
flag will get reset by the queue logic and needs to be set
again before the incoming buffers are sent to the registered
outputs.
Bug: 110641448
Test: Manual using application,
Camera CTS
Change-Id: I36859eb41ccab8459bbd97bad3ea0b6a8575489c
Currently we are configuring the number of output
slots in each new shared surface as the sum between the
maxiumum stream buffers and the minimum undequeued buffers
per surface. However the total number of buffers that
will get allocated in the input stream queue increases
with the latter undequeued ammount on each new output.
The delta between these values could result in
insufficient output slots for some outputs that consume
buffers with vastly different speeds combined with a
slow camera producer that exhausts all dequeued slots.
To avoid this set the output slot count the the maximum
supported number by the framework. Allocation is disabled
so this should not increase the number of allocated buffers.
Bug: 80079782
Test: Manual using application,
Camera CTS
Change-Id: I36eed94a169a802f33126b640dd1d95725aec8db
The output slot vector will be initialized with the total number of
buffers per output and any buffers that get attached are indexed via
the returned slot value. However there is no guarantee that the slot
will be within the [0, totalNumberOfBuffers) range. The bufffer queue
can return anything from [0, BufferQueue::NUM_BUFFER_SLOTS) and this
can result in invalid memory operations and potential instabilities.
The resolve this validate the slot value and resize the output slot
vector accordingly.
Bug: 74828453
Test: Camera CTS
Change-Id: I20502000a5c278eb9a81600282d1fad98455a2c4
Blocking dequeue calls for async output surfaces seem to be
possible. Refactor the code so that stream splitter doesn't
hold any locks during output surface dequeue calls triggered
by buffer released callbacks.
Bug: 73953239
Test: Camera CTS
Change-Id: Ia2166de73d2b8de7ef4157e81c87f53c8a264c0c
Dynamic consumers removed by client could still hold one or
several buffer references after streaming stops and the
producer interface gets disconnected. Returning those buffers
in the input queue is not recommended as they can continue to get
accessed at the same time as the camera modifies them. To avoid this
try to detach all previously registered buffers. If the call
fails for some specific buffer, then try to detach it from both the
input queue and the remaining outputs.
Bug: 70223208
Test: Camera CTS
Change-Id: Ie35c7a2360d970ab5c860be7b580140dfb768934
The Camera API needs to support the dynamic attach/detach of extra
output surfaces to a given camera stream.
Bug: 63912484
Change-Id: I18809aea31f78fb9e125bd18b58951ade4fad3c5
- 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
For Async buffer queue, if a pending buffer is overwritten by an
incoming buffer, onBufferReleased callback isn't called. But the stream
splitter depends on the onBufferReleased to return buffer to input.
Fix the problem by checking the bufferReplaced flag in
QueueBufferOutput.
Test: Camera CTS
Bug: 33777818
Change-Id: I270c7bae7873797ae9b050782828b5a124d3eff9
- 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
Emilian Peev
Yin-Chia Yeh
TreeHugger Robot
Shuzhen Wang
Mathias Agopian