| 2d473c27a2a5fbda9bdc473d67f45023e9a2dfe8 |
|
06-Dec-2016 |
Bjoern Johansson <bjoernj@google.com> |
Strip alignment bytes for camera video frames
The encoder path in the emulator images do not expect any kind of
padding for YUV frames. After changing the emulator to correctly pass a
planar YUV format instead of a semiplanar format the encoding path
started breaking for resolutions with padding. This is because the
planar formats used by the camera had alignment padding. Since the video
encoding path is internal to the framework it's safe to use whatever
format works best. This change strips out any padding bytes used for
alignment for video frames, allowing the affected tests to pass.
BUG: 33382525
Test: ran camera CTS tests
Change-Id: I75cef46b03b90da13d91945cda8e2d2972df2f55
(cherry picked from commit 82a66bd172613835976e714d33fffa82412c88d6)
/device/generic/goldfish/camera/EmulatedCameraDevice.h
|
| 6ab39a68026a9a65dcdf190511bab50335a55d17 |
|
18-Nov-2016 |
Bjoern Johansson <bjoernj@google.com> |
Use YU12 instead of YV12 for camera video frames
The camera parameters API only supports formats where Y, U and V
components are in the YVU order, such as YV12 or NV21. Unfortunately the
software encoders that the emulator images use to encode video only
support YUV order. This presents a configuration problem as there is no
way to straight up match these. The CameraSource class in stagefright
that configures the encoder to match the camera settings actually
converts the YV12 setting to YU12 which leads to U and V components
being swapped. This caused problems as soon as we fixed the issue where
we were actually treating YV12 as YU12.
Fortunately it turns out that the data provided in the timestamped data
callback can be pretty much whatever format that the camera and the
encoder can agree upon. The settings and frames are only available
internally so it's mostly an implementation detail. This allows us to
generate YV12 frames and then convert them to YU12 before passing them
to the timestamped data callback. The regular data callback will still
receive YV12 frames, just like the caller asked for, but the encoder
will receive frames in a YU12 format that it will handle properly.
YU12 is the format of choice for video recording because the software
encoders do not seem to require extra conversion steps for this. As a
bonus the conversion from YV12 to YU12 is very cheap in this case. We
always had to copy memory, the only difference now is that we copy each
Y, U and V plane separately and just switch the order of the U and V
planes.
In more modern version of the camera HAL the camera does not provide raw
byte buffers like this but instead it feeds frames into a gralloc buffer
queue. This way the camera has a lot more flexibility in what formats it
can use and the encoders can also support YVU formats. So when we switch
to a new HAL version we shouldn't have to deal with this anymore.
BUG: 32771006
Test: ran camera CTS tests
Change-Id: Ic05c1f816dbb09d027f08dea59095a935716309c
(cherry picked from commit d7506ee34e9ccda8a8c7866706b8a2b897e842d7)
/device/generic/goldfish/camera/EmulatedCameraDevice.h
|
| d17319e5eb181b728484e4c95b3c53b8e38c601d |
|
27-Sep-2016 |
Bjoern Johansson <bjoernj@google.com> |
Prevent camera deadlocks when taking pictures
The camera in the emulator would sometimes end up in a deadlock when
taking pictuers. This happened because the request to take a picture
could be blocked on waiting for the frame delivery thread to end. But
the frame delivery thread was waiting to acquire a lock in the image
delivery callback, a lock that was held by the take picture call in the
camera client. This change changes the synchronous take picture call
into an asynchronous request. The take picture functionality is moved to
the same thread that delivers frames which ensures that all callbacks to
the camera client happen from the same thread.
BUG: 31599348
Test: ran camera CTS tests
Change-Id: Ib8d3a6c04e7e9bf7f297e1aafcd73d7f2e629132
(cherry picked from commit 31466a4d2304d5097e70d6437c7bd7c8b08d961b)
/device/generic/goldfish/camera/EmulatedCameraDevice.h
|
| d9753c9a91259d70aac0079aab9a47db91e19f05 |
|
20-Sep-2016 |
Bjoern Johansson <bjoernj@google.com> |
Separate camera frame production and delivery
Separate the production and delivery of camera frames into two separate
worker threads. The previous implementation did both at once and did not
take time taken for production and delivery into account when sleeping
between frames. Decoupling production and delivery allows the camera to
always deliver frames on time even if production can't keep up. The same
frame might be delivered more than once but performance testing
has not yet shown that this is happening. This also adjusts the sleeping
strategy in between frames to take the delivery or production time into
consideration. The goal is to deliver frames with very little deviation
from the configured frame rate.
BUG: 30034008
Test: ran camera CTS tests
Change-Id: I01d9c07795993e79c475249d87d9da32d7d14256
(cherry picked from commit c5f193548f3461a41b80b9720d66836e20b0999a)
/device/generic/goldfish/camera/EmulatedCameraDevice.h
|
| dac82a5541140e3de6a20223530a406be4828b87 |
|
01-Sep-2016 |
Bjoern Johansson <bjoernj@google.com> |
Respond to camera auto-focus requests
Even though the emulated cameras do not support auto-focus they are
required to respond to auto-focus commands. They should immediately
signal a successful auto-focus complete event to the client. This change
implements this behavior by setting a flag that is inspected as long as
the worker thread that generates preview frames is running. This is safe
since the documentation mentions that the camera must be in preview mode
for the auto-focus request to work.
BUG: 30700822
Test: ran camera CTS tests
Change-Id: I2be24c734255bba2dcb55a73b84b49f7ee3e2232
(cherry picked from commit 01089051c75ff1e00476191614911f6046862fb3)
/device/generic/goldfish/camera/EmulatedCameraDevice.h
|
| 23fc09071da1874cd14ae67fda8d546810220166 |
|
31-Aug-2016 |
Bjoern Johansson <bjoernj@google.com> |
Correct camera YV12 format usage
The camera code incorrectly generated and decoded YV12 encoded images.
The format requires that row strides are aligned to 16 bytes which
introduces padding at some of the resolution that the camera supports,
most notably 176x144 where half of 176 is not divisible by 16. The width
is halved because the U and V components each cover 2x2 pixel blocks so
the effective width of each row is 88 pixels, this has to be padded to 96
bytes. This change ensures that the images generated by the fake camera
have the required alignment and also that decoding the YV12 images to RGB
for the preview window correctly takes the alignment into consideration.
BUG: 30700822
Test: ran camera CTS tests
Change-Id: I16590551af59c730c0c8b024dbaee40f5c8e9ab2
(cherry picked from commit ddeced00136c1299dfca1ea5066f23b5ada2a142)
/device/generic/goldfish/camera/EmulatedCameraDevice.h
|
| d81ee62349fc40c82200803077b7a9550d44fe19 |
|
08-Apr-2016 |
bohu <bohu@google.com> |
Emulator: Fix camera crash
Because the camera runs a thread without giving it a name.
bug: 28074344
Change-Id: I85fd0d0786e82305d6615e7f50b7394785e96df7
/device/generic/goldfish/camera/EmulatedCameraDevice.h
|
| b3f642f2a22cd58e64e0dc6326e946ef7fd7589f |
|
15-Oct-2013 |
Douglas Leung <douglas@mips.com> |
Fix inconsistant results for some cts tests.
This patch fixes any cts test that uses the camera's startPreview function
without the proper timing delay before stopping the preview. When we do a
startPreview(), it will start a WorkerThread. If that thread don't get a
chance to run, then when we try to stop the thread, the stop can fail and
cause the current test to fail (thread not running) or subsequent tests
to fail (thread already started).
The following tests are known to fail randomly due to this timing problem:
android.hardware.cts.CameraTest#testDisplayOrientation
android.hardware.cts.CameraTest#testGetParameterDuringFocus
android.hardware.cts.CameraTest#testJpegCallbackStartPreview
android.hardware.cts.CameraTest#testRecordingHint
android.hardware.cts.CameraTest#testLockUnlock
android.hardware.cts.CameraTest#testPreviewCallback
android.hardware.cts.CameraTest#testSetOneShotPreviewCallback
android.media.cts.MediaRandomTest#testRecorderRandomAction
Change-Id: Ifc20d93bc02cdc49161f54c083a32138574a8d39
/device/generic/goldfish/camera/EmulatedCameraDevice.h
|
| 8a94683196406b83b14218d1beef66067f126a16 |
|
08-Mar-2013 |
keunyoung <keunyoung@google.com> |
migrate opengl and system from development/tools
- components under system are moved one directory up like all other HALs
Change-Id: I03b870b870d83b247ac398cadfb155f03c9adfa0
/device/generic/goldfish/camera/EmulatedCameraDevice.h
|