New issue
Advanced search Search tips

Issue 894381 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Nov 29
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

Enable VEAs to encode any yuv format input

Project Member Reported by hiroh@chromium.org, Oct 11

Issue description

Currently, we always input I420 pixel buffer to VEAs [1, 2].
We should eliminate the format restriction in it so that an unnecessary conversion is required.

The detailed motivation is written in go/cros-vide0Capture.

[1] https://cs.chromium.org/chromium/src/media/gpu/v4l2/v4l2_video_encode_accelerator.cc
[2] https://cs.chromium.org/chromium/src/media/gpu/vaapi/vaapi_video_encode_accelerator.cc


 
Where does the restriction come from? I don't see any hardcoded I420 or YUV420 inside the code.
Description: Show this description
Cc: mcasas@chromium.org
Summary: Enable VEAs to encode any yuv format input (was: Enable V4L2VEA to encode any yuv format input)
Yeah, I remembered it after I had created it.
I thought to start this in V4L2VEA first before VAAPIVEA.
V4L2VEA has no restriction for yuv format. I should only work for VAAPIVEA.

Since I need to change VEA unittest, let me generalize this issue as both VEAs.
Status: Available (was: Untriaged)
I confirmed V4L2VEA is able to encode NV12 format on kevin.

I am trying VAAPIVEA. This is an experiment CL. https://chromium-review.googlesource.com/c/chromium/src/+/1272240
Status: Assigned (was: Available)
Project Member

Comment 6 by bugdroid1@chromium.org, Oct 12

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dd7080ae434cf6f6b7a0e388b466ae7c7b6dbee1

commit dd7080ae434cf6f6b7a0e388b466ae7c7b6dbee1
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Fri Oct 12 10:04:23 2018

media/gpu/VEA unittest: Enable VEAs to test with any yuv format stream

VEA unittest is only able to test I420 format input file.
This enables it to test any yuv format stream.

NV12, NV12 and YV21 formated raw videos are created by following commands.
$ ffmpeg -s 320x192 -i bear_320x192_40frames.yuv -pix_fmt nv12 bear_320x192_40frames.nv12.yuv
$ ffmpeg -s 320x192 -i bear_320x192_40frames.yuv -pix_fmt nv21 bear_320x192_40frames.nv21.yuv
$ ffmpeg -s 320x192 -i bear_320x192_40frames.yuv -pix_fmt yuv420p -vf shuffleplanes=0:2:1 bear_320x192_40frames.yv12.yuv

BUG= chromium:894381 
TEST=[kevin] ./video_encode_accelerator_unittest --test_stream_data=bear_320x192_40frames.nv12.yuv:320:192:1:bear.out:200000:30:::6 --ozone-platform=gbm

Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: I8a6b142671fc0532ba872f7eff966d43a2848ad9
Reviewed-on: https://chromium-review.googlesource.com/c/1135106
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kuang-che Wu <kcwu@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Cr-Commit-Position: refs/heads/master@{#599158}
[modify] https://crrev.com/dd7080ae434cf6f6b7a0e388b466ae7c7b6dbee1/media/gpu/video_encode_accelerator_unittest.cc
[modify] https://crrev.com/dd7080ae434cf6f6b7a0e388b466ae7c7b6dbee1/media/test/data/README.md
[add] https://crrev.com/dd7080ae434cf6f6b7a0e388b466ae7c7b6dbee1/media/test/data/bear_320x192_40frames.nv12.yuv
[add] https://crrev.com/dd7080ae434cf6f6b7a0e388b466ae7c7b6dbee1/media/test/data/bear_320x192_40frames.nv21.yuv
[add] https://crrev.com/dd7080ae434cf6f6b7a0e388b466ae7c7b6dbee1/media/test/data/bear_320x192_40frames.yv12.yuv

Project Member

Comment 7 by bugdroid1@chromium.org, Oct 18

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/7c4066d4cbb52193971cb860a63482088135bea9

commit 7c4066d4cbb52193971cb860a63482088135bea9
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Thu Oct 18 05:43:16 2018

video_VideoEncodeAccelerator: Add NV12 input buffer test case.

This adds NV12 input buffer test case.
NV12 is widely supported on devices which have HW encoding capability.
V4L2VEA doesn't have yuv format restriction on input buffers.
On the other hand, VaapiVEA is currently able to encode only I420 input buffers.
Therefore, NV12 input buffer test case is skipped on intel devices.

BUG= chromium:894381 
TEST=video_VideoEncodeAccelerator.{h264,vp8}.bvt on kevin

Change-Id: I31ac3dd9fdafc8b891725f2fc14a2f25a6e06b31
Reviewed-on: https://chromium-review.googlesource.com/1276326
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>

[modify] https://crrev.com/7c4066d4cbb52193971cb860a63482088135bea9/client/site_tests/video_VideoEncodeAccelerator/control.h264
[modify] https://crrev.com/7c4066d4cbb52193971cb860a63482088135bea9/client/site_tests/video_VideoEncodeAccelerator/control.h264.bvt
[modify] https://crrev.com/7c4066d4cbb52193971cb860a63482088135bea9/client/site_tests/video_VideoEncodeAccelerator/control.vp8.bvt
[modify] https://crrev.com/7c4066d4cbb52193971cb860a63482088135bea9/client/site_tests/video_VideoEncodeAccelerator/video_VideoEncodeAccelerator.py
[modify] https://crrev.com/7c4066d4cbb52193971cb860a63482088135bea9/client/site_tests/video_VideoEncodeAccelerator/control.vp8

Project Member

Comment 8 by bugdroid1@chromium.org, Oct 22

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/04f8f2c062f67483fdc6b0986a31ecb8195e9c90

commit 04f8f2c062f67483fdc6b0986a31ecb8195e9c90
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Mon Oct 22 07:19:32 2018

media/gpu/VEA unittest: Fill plane pointer and stride with NULL and 0 for 1- or 2- planes VideoFrame

When I enable VEA unittest to run any yuv format in crrev.com/c/1135106, I didn't
realize the code assumed the I420 when creating frame. Therefore, it passes
invalid pointer and wrong stride when the number of planes are less than 3.
This change fixes it by creating video frame, taking into account the number of
planes of input buffer format.

BUG= chromium:894381 
TEST=VEA unittest for NV12 and I420 on kevin

Change-Id: I31e157ce9317139e7cc42a38ba77b34c13d70d70
Reviewed-on: https://chromium-review.googlesource.com/c/1293095
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Cr-Commit-Position: refs/heads/master@{#601489}
[modify] https://crrev.com/04f8f2c062f67483fdc6b0986a31ecb8195e9c90/media/gpu/video_encode_accelerator_unittest.cc

Project Member

Comment 9 by bugdroid1@chromium.org, Oct 22

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f199bfbe0ceb0b5ec7384248724f1cfdee7dbde2

commit f199bfbe0ceb0b5ec7384248724f1cfdee7dbde2
Author: Fergal Daly <fergal@chromium.org>
Date: Mon Oct 22 07:42:10 2018

Revert "media/gpu/VEA unittest: Fill plane pointer and stride with NULL and 0 for 1- or 2- planes VideoFrame"

This reverts commit 04f8f2c062f67483fdc6b0986a31ecb8195e9c90.

Reason for revert: breaks windowd compile

Original change's description:
> media/gpu/VEA unittest: Fill plane pointer and stride with NULL and 0 for 1- or 2- planes VideoFrame
> 
> When I enable VEA unittest to run any yuv format in crrev.com/c/1135106, I didn't
> realize the code assumed the I420 when creating frame. Therefore, it passes
> invalid pointer and wrong stride when the number of planes are less than 3.
> This change fixes it by creating video frame, taking into account the number of
> planes of input buffer format.
> 
> BUG= chromium:894381 
> TEST=VEA unittest for NV12 and I420 on kevin
> 
> Change-Id: I31e157ce9317139e7cc42a38ba77b34c13d70d70
> Reviewed-on: https://chromium-review.googlesource.com/c/1293095
> Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
> Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#601489}

TBR=hiroh@chromium.org,acourbot@chromium.org

Change-Id: I02e53782dd3240da1dfd4548daefe275854601b4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  chromium:894381 
Reviewed-on: https://chromium-review.googlesource.com/c/1293099
Reviewed-by: Fergal Daly <fergal@chromium.org>
Commit-Queue: Fergal Daly <fergal@chromium.org>
Cr-Commit-Position: refs/heads/master@{#601491}
[modify] https://crrev.com/f199bfbe0ceb0b5ec7384248724f1cfdee7dbde2/media/gpu/video_encode_accelerator_unittest.cc

Project Member

Comment 10 by bugdroid1@chromium.org, Oct 22

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/07959d963e08a1024f8cf7ed7efae92fac7ebac2

commit 07959d963e08a1024f8cf7ed7efae92fac7ebac2
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Mon Oct 22 08:43:37 2018

Reland "media/gpu/VEA unittest: Fill plane pointer and stride with NULL and 0 for 1- or 2- planes VideoFrame"

When I enable VEA unittest to run any yuv format in crrev.com/c/1135106, I didn't
realize the code assumed the I420 when creating frame. Therefore, it passes
invalid pointer and wrong stride when the number of planes are less than 3.
This change fixes it by creating video frame, taking into account the number of
planes of input buffer format.

BUG= chromium:894381 
TEST=VEA unittest for NV12 and I420 on kevin

Change-Id: Ie917d5240c05cb32c59f21367252682dc14b573e
Reviewed-on: https://chromium-review.googlesource.com/c/1293066
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#601501}
[modify] https://crrev.com/07959d963e08a1024f8cf7ed7efae92fac7ebac2/media/gpu/video_encode_accelerator_unittest.cc

Project Member

Comment 11 by bugdroid1@chromium.org, Oct 23

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/63a6ceff98c64288c550ac1d3188486a1500174a

commit 63a6ceff98c64288c550ac1d3188486a1500174a
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Tue Oct 23 20:01:48 2018

video_VideoEncodeAccelerator: Add some ARM devices in NV12 encoding black list

According to test results, exynos and nyan drivers seems to have a bug that they
cannot encode NV12 input buffers.
NV12 input buffer case is skipped on the devices.

BUG= chromium:894381 
TEST=video_VideoEncodeAccelerator

Change-Id: If30c36dfd25c168eefd380ae2b3eee2c603b1c40
Reviewed-on: https://chromium-review.googlesource.com/1292694
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>

[modify] https://crrev.com/63a6ceff98c64288c550ac1d3188486a1500174a/client/site_tests/video_VideoEncodeAccelerator/video_VideoEncodeAccelerator.py

Project Member

Comment 12 by bugdroid1@chromium.org, Oct 25

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/662ccec2fdeee88625ebff328f9ddbd3e74fa1ec

commit 662ccec2fdeee88625ebff328f9ddbd3e74fa1ec
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Thu Oct 25 04:14:39 2018

media/gpu/vaapi/vaapiVEA: Enable vaapiVEA to encode NV12 input buffers

In Chromium, intel devices allocates NV12 VASurface.
VaapiVEA only accepts I420 input buffers for video encoding. It converts the
buffers to NV12 and copies to VA Surfaces.
This enables vaapiVEA to accept NV12 input buffers. It just copies the input
buffers to VA Surfaces without any conversion since their formats are same.

BUG= 894381 
TEST=VEA unittest with NV12 input buffer on eve

Change-Id: I83a53603a15c0eaa787c1b66cccbd8a2fcc48c18
Reviewed-on: https://chromium-review.googlesource.com/c/1293254
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#602609}
[modify] https://crrev.com/662ccec2fdeee88625ebff328f9ddbd3e74fa1ec/media/gpu/vaapi/vaapi_video_encode_accelerator.cc
[modify] https://crrev.com/662ccec2fdeee88625ebff328f9ddbd3e74fa1ec/media/gpu/vaapi/vaapi_wrapper.cc

Project Member

Comment 13 by bugdroid1@chromium.org, Oct 26

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/a4fc1d2dc63be531e55f6f77ca9b8e5c27cbbfa0

commit a4fc1d2dc63be531e55f6f77ca9b8e5c27cbbfa0
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Fri Oct 26 19:14:57 2018

video_VideoEncodeAccelerator: Start NV12 test cases on intel devices

crrev.com/c/1293254 enables VaapiVEA to encode NV12 input buffers.
This starts to run NV12 test cases on intel devices.

BUG= chromium:894381 
TEST=video_VideoEncodeAccelerator.h264.bvt on eve

Change-Id: I99b1ba36b8d700475fdaffce6befb634bf9dbe43
Reviewed-on: https://chromium-review.googlesource.com/1297874
Commit-Ready: Hirokazu Honda <hiroh@chromium.org>
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>

[modify] https://crrev.com/a4fc1d2dc63be531e55f6f77ca9b8e5c27cbbfa0/client/site_tests/video_VideoEncodeAccelerator/video_VideoEncodeAccelerator.py

Project Member

Comment 14 by bugdroid1@chromium.org, Oct 29

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/abf4f9a571823595a29ab05a1cf6699a45a4bffe

commit abf4f9a571823595a29ab05a1cf6699a45a4bffe
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Mon Oct 29 04:52:10 2018

media/base/VideoPixelFormat: Add XBGR and ABGR

VideoPixelFormat doesn't have values for XBGR and ABGR, even though it has ones
for ARGB, XRGB, RGB and RGBA. This adds XBGR and ABGR so that all sorts of RGBA
formats are in VideoPixelFormat.
They are not used on Chrome stack. On the other hand, in ARC++, Android
container can pass XBGR and ABGR formatted buffer. Those values are thus needed.

BUG= 894381 
TEST=./media_unittests on Linux

Change-Id: I03fda9a9afa9ae1d5dfa7af873898665f9ac2d9d
Reviewed-on: https://chromium-review.googlesource.com/c/1302933
Reviewed-by: Fredrik Hubinette <hubbe@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#603414}
[modify] https://crrev.com/abf4f9a571823595a29ab05a1cf6699a45a4bffe/media/base/video_frame.cc
[modify] https://crrev.com/abf4f9a571823595a29ab05a1cf6699a45a4bffe/media/base/video_frame_layout.cc
[modify] https://crrev.com/abf4f9a571823595a29ab05a1cf6699a45a4bffe/media/base/video_frame_unittest.cc
[modify] https://crrev.com/abf4f9a571823595a29ab05a1cf6699a45a4bffe/media/base/video_types.cc
[modify] https://crrev.com/abf4f9a571823595a29ab05a1cf6699a45a4bffe/media/base/video_types.h
[modify] https://crrev.com/abf4f9a571823595a29ab05a1cf6699a45a4bffe/media/capture/mojom/video_capture_types.mojom
[modify] https://crrev.com/abf4f9a571823595a29ab05a1cf6699a45a4bffe/media/capture/mojom/video_capture_types_mojom_traits.cc
[modify] https://crrev.com/abf4f9a571823595a29ab05a1cf6699a45a4bffe/media/remoting/media_remoting_rpc.proto
[modify] https://crrev.com/abf4f9a571823595a29ab05a1cf6699a45a4bffe/media/remoting/proto_enum_utils.cc
[modify] https://crrev.com/abf4f9a571823595a29ab05a1cf6699a45a4bffe/media/renderers/paint_canvas_video_renderer.cc
[modify] https://crrev.com/abf4f9a571823595a29ab05a1cf6699a45a4bffe/media/renderers/video_resource_updater.cc
[modify] https://crrev.com/abf4f9a571823595a29ab05a1cf6699a45a4bffe/media/video/gpu_memory_buffer_video_frame_pool.cc

Project Member

Comment 15 by bugdroid1@chromium.org, Oct 29

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/da284a92ea6d12fa0414247e8c771c1d02e106e0

commit da284a92ea6d12fa0414247e8c771c1d02e106e0
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Mon Oct 29 05:36:27 2018

video_encode_accelerator.mojom: Add pixel formats that can be passed from Android container

Currently, the pixel format of video frame passed from Android container is
always I420. This is because color format conversion is done in ARC++ container.
For zero format conversion (go/arc-vide0Capture), we needs to be able to pass
all pixel formats supported by our ARC++ HW video encoder to Chrome. If the color
format conversion is needed, it is performed in Chrome side by HW/SW
ImageProcessor.
The below is the table of YUV pixel formats supported by HW video encoder and
media::PixelFormat in Chrome side.
media::VideoPixelFormat associated with HAL_PIXEL_FORMAT_YCBCR_420_888 is
dependent on platform, but one of three formats, which minigbm actually decides.

HAL Pixel Format (Android)        media::VideoPixelFormat (Chrome)
--------------------------------------------------------------------
HAL_PIXEL_FORMAT_YV12          -> PIXEL_FORMAT_YV12
HAL_PIXEL_FORMAT_YCRCB_420_SP  -> PIXEL_FORMAT_NV12
HAL_PIXEL_FORMAT_YCBCR_420_888 -> PIXEL_FORMAT_YV12, PIXEL_FORMAT_NV12, PIXEL_FORMAT_NV21
HAL_PIXEL_FORMAT_RGBX_8888     -> PIXEL_FORMAT_XBGR
HAL_PIXEL_FORMAT_RGBA_8888     -> PIXEL_FORMAT_ABGR
HAL_PIXEL_FORMAT_BGRA_8888     -> PIXEL_FORMAT_ARGB
[I420] (No enum for this)      -> PIXEL_FORMAT_I420

BUG= chromium:894381 
TEST=CtsMediaTestCases on eve

Change-Id: If95c40fd673603adaf4eb8e95afdf5142f59ad4c
Reviewed-on: https://chromium-review.googlesource.com/c/1301573
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#603418}
[modify] https://crrev.com/da284a92ea6d12fa0414247e8c771c1d02e106e0/components/arc/common/video_encode_accelerator.mojom
[modify] https://crrev.com/da284a92ea6d12fa0414247e8c771c1d02e106e0/components/arc/common/video_encode_accelerator_struct_traits.cc

Project Member

Comment 16 by bugdroid1@chromium.org, Nov 1

Labels: merge-merged-chromeos-3.14
The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/3bf9028648260f6d163a9a6180253505a3915ea1

commit 3bf9028648260f6d163a9a6180253505a3915ea1
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Thu Nov 01 20:14:03 2018

CHROMIUM: media: rk3288-vpu: Honor format number of planes in encoder

The encoder always assumes 3 planes, but we also advertise support for 1- and
2-plane formats, so honor them.

This fixes a null pointer dereference which happened when the driver
tries to get a DMA address of an out of bounds plane.

BUG=chromium:893530,  chromium:894381 
TEST=Run VEA unit test with NV12 input on veyron_minnie

Change-Id: I7141b4349c48df7dffd5f068e3c3c1a6daa9822c
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1293111
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>

[modify] https://crrev.com/3bf9028648260f6d163a9a6180253505a3915ea1/drivers/media/platform/rk3288-vpu/rk3288_vpu_hw_vp8e.c

Regarding YV12 on mtk, mtk enc driver supports YVU420M. V4L2VEA tries to S_FMT with YVU420M, because VideoPixelFormatToV4L2PixFmt returns YYU420 for YV12, not YVU420M.
I created the CL to change it returns YVU420M. I need to change V4L2VDA::FindImageProcessorOutputFormat as they use multi planar formats. This is because media::VideoPixelFormat is passed to V4L2IP and it extracts YVU420M from it by the change.
https://cs.chromium.org/chromium/src/media/gpu/v4l2/v4l2_image_processor.cc?l=138&rcl=38dabcbbf77558e103ee3941d829aa0906f02248
But another issues are caused. Current V4L2 IP code only supports semi planar v4l2 pix fmt! :(
https://cs.chromium.org/chromium/src/media/gpu/v4l2/v4l2_image_processor.cc?l=283&rcl=38dabcbbf77558e103ee3941d829aa0906f02248

I abandoned 
Add YVU420M to supported formats on MTK. https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1337187
Return Multi-planar YVU420 pix fmt in VideoPixelFormatToV4L2PixFmt: https://chromium-review.googlesource.com/c/chromium/src/+/1335048

But we should change V4L2IP to support multi planar pix fmt in the future.
Project Member

Comment 18 by bugdroid1@chromium.org, Nov 28

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/82a8b043efe8b6ff9ddcf46269bfe5ef64a16bc9

commit 82a8b043efe8b6ff9ddcf46269bfe5ef64a16bc9
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Wed Nov 28 02:53:43 2018

media/gpu/v4l2/V4L2Device: Add |single_planar| args in VideoPixelFormatToV4L2PixFmt()

V4L2Device::VideoPixelFormatToV4L2PixFmt returns either single and multi plane
v4l2 pix fmt, depending on VideoPixelFormat. This would rather return single or
multi plane v4l2 pix format with given VideoPixelFormat and |single_planar|.
V4L2VEA always uses multi plane formats. On the other hand, V4L2 IP depends on
its caller's decision. So V4L2IP's caller specifies single or multi planes by
the number of buffers on VideoFrameLayout. VideoFrameLayoutToV4L2PixFmt() is
also added in this CL, which returns v4l2 pixel format from given
VideoFrameLayout. This CL also adds IsMultiPlanarV4L2PixFmt(), which returns
whether v4l2 pix fmt is multi planar or not.

BUG= chromium:894381 
TEST=VDA unittest with/without --test_import on hana
TEST=VEA unittest with YV12 raw video data on hana

Change-Id: I8cce3229e81fe041eb0bf8ea60f2735ef610e1b0
Reviewed-on: https://chromium-review.googlesource.com/c/1341428
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Cr-Commit-Position: refs/heads/master@{#611537}
[modify] https://crrev.com/82a8b043efe8b6ff9ddcf46269bfe5ef64a16bc9/media/gpu/v4l2/v4l2_device.cc
[modify] https://crrev.com/82a8b043efe8b6ff9ddcf46269bfe5ef64a16bc9/media/gpu/v4l2/v4l2_device.h
[modify] https://crrev.com/82a8b043efe8b6ff9ddcf46269bfe5ef64a16bc9/media/gpu/v4l2/v4l2_image_processor.cc
[modify] https://crrev.com/82a8b043efe8b6ff9ddcf46269bfe5ef64a16bc9/media/gpu/v4l2/v4l2_video_decode_accelerator.cc
[modify] https://crrev.com/82a8b043efe8b6ff9ddcf46269bfe5ef64a16bc9/media/gpu/v4l2/v4l2_video_encode_accelerator.cc

Cc: -wuchengli@google.com
Status: Fixed (was: Assigned)
All work in VEAs are done. Closed.

Sign in to add a comment