commit 2c2156f54a770eaaf3946d67cc3188df65c6c21c
author Hirokazu Honda <hiroh@chromium.org> Tue Nov 27 10:41:24 2018
committer Commit Bot <commit-bot@chromium.org> Tue Nov 27 10:41:24 2018
tree ce15daac712fccf57ed7cad1ebc4da299227e4d4
parent 6951236286086f751a3fd8cadee3c337f4fbe12d

video_encode_accelerator.mojom: Attach format information on Encode()

ArcVideoEncoder has two patterns to encode:
1.) I420 buffer (OMX_COLOR_FormatYUV420Planar)
2.) several formats, including YV12, NV12, ARGB (OMX_COLOR_FormatAndroidOpaque)
In the latter case, no detail about pixel format of video frame to be encoded is
provided in initialization. We always configure I420 in initializing and perform
pixel format conversion in ArcVideoEncoder using libyuv.

One of the most common encoder use case is video capture. It is the latter case.
The pixel format of video frame is dependent on platform, YV12 on mediatek
devices, and NV12 on others. Furtheremore, video frame is provided as DmaBuf. If
no pixel format conversion is done anywhere, we can pass video frame to VDA as
DmaBuf without any mapping.

Our design is we configure flexible format on Initialize() if
OMX_COLOR_FormatAndroidOpaque is configured in ArcVideoEncoder. Thereafter, if
the different pixel format is provided on Encode(), we convert pixel format on
GpuArcVEA. We can have a chance to use Image Processor with HW Acceleration like
V4L2 Image Processor.

This is the first step for this task, attach format information on Encode() and
split GpuArcVideoEncoder::Encode() to EncodeSharedMemory() (I420 case) and
EncodeDmabuf() (Flexible format case). EncodeDmaBuf() is not implemented yet.

BUG=chromium:895230, b:118544836
TEST=CtsMediaTestCases

Change-Id: Ia12447b93f71fb2af579a9e27a1055b43e81cc2a
Reviewed-on: https://chromium-review.googlesource.com/c/1343593
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#611064}