OSDN Git Service

Use YU12 instead of YV12 for camera video frames
authorBjoern Johansson <bjoernj@google.com>
Fri, 18 Nov 2016 20:28:12 +0000 (12:28 -0800)
committerBjoern Johansson <bjoernj@google.com>
Wed, 11 Jan 2017 21:03:23 +0000 (13:03 -0800)
commit6ab39a68026a9a65dcdf190511bab50335a55d17
treee7fb6dca0b5acdda6ac51c682b58ca12ef13ed77
parent018c17305d8a7dce11a28327ebbc5f430ac113b9
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)
camera/CallbackNotifier.cpp
camera/EmulatedCameraDevice.cpp
camera/EmulatedCameraDevice.h
camera/EmulatedQemuCameraDevice.cpp
camera/EmulatedQemuCameraDevice.h