New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 895230 link

Starred by 2 users

Issue metadata

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

Blocked on:
issue 901264



Sign in to add a comment

Enable VEAs to encode DMABuf-backed video frame

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

Issue description

Currently, VEAs on Chrome OS (i.e. V4L2VEA[1] and VaapiVEA[2]) are able to encode user-space mapped video frame.

They should encode DMABuf-backed video frame for performance improvement.
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
 
Project Member

Comment 1 by bugdroid1@chromium.org, Oct 25

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

commit 7076423c4bd67ffee0ba2fbcb871b744ca86bdbe
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Thu Oct 25 10:10:19 2018

media/video/VEA: Add storage type in VideoEncodeAccelerator Initialize Config

V4L2VEA negotiates and creates ImageProcessor in Initialize(). ImageProcessor
needs to know in what storage type of a video frame will be given in Encode().
Currently, video frame is always mapped in userspace and ImageProcessor is
created assuming it.
In the future, video frame will be given as DMA buf, in some cases, e.g., Chrome
video capture.
This adds storage type to VideoEncodeAccelerator Initialize Config, so that
ImageProcessor can know what storag type of a video frame is provided in Encode().

BUG= chromium:895230 
TEST=Build chrome without any errors

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: I172dede5e900856a2adcb9e6f91bcbd61cd5af44
Reviewed-on: https://chromium-review.googlesource.com/c/1280096
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Hidehiko Abe <hidehiko@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Reviewed-by: Emircan Uysaler <emircan@chromium.org>
Reviewed-by: Greg Kerr <kerrnel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#602661}
[modify] https://crrev.com/7076423c4bd67ffee0ba2fbcb871b744ca86bdbe/components/arc/common/video_encode_accelerator.mojom
[modify] https://crrev.com/7076423c4bd67ffee0ba2fbcb871b744ca86bdbe/components/arc/common/video_encode_accelerator.typemap
[modify] https://crrev.com/7076423c4bd67ffee0ba2fbcb871b744ca86bdbe/components/arc/common/video_encode_accelerator_struct_traits.cc
[modify] https://crrev.com/7076423c4bd67ffee0ba2fbcb871b744ca86bdbe/components/arc/common/video_encode_accelerator_struct_traits.h
[modify] https://crrev.com/7076423c4bd67ffee0ba2fbcb871b744ca86bdbe/components/arc/video_accelerator/gpu_arc_video_encode_accelerator.cc
[modify] https://crrev.com/7076423c4bd67ffee0ba2fbcb871b744ca86bdbe/components/arc/video_accelerator/gpu_arc_video_encode_accelerator.h
[modify] https://crrev.com/7076423c4bd67ffee0ba2fbcb871b744ca86bdbe/content/renderer/media/webrtc/rtc_video_encoder.cc
[modify] https://crrev.com/7076423c4bd67ffee0ba2fbcb871b744ca86bdbe/media/mojo/clients/mojo_video_encode_accelerator_unittest.cc
[modify] https://crrev.com/7076423c4bd67ffee0ba2fbcb871b744ca86bdbe/media/mojo/interfaces/video_encode_accelerator_mojom_traits.cc
[modify] https://crrev.com/7076423c4bd67ffee0ba2fbcb871b744ca86bdbe/media/video/video_encode_accelerator.cc
[modify] https://crrev.com/7076423c4bd67ffee0ba2fbcb871b744ca86bdbe/media/video/video_encode_accelerator.h

Cc: akahuang@chromium.org acourbot@chromium.org tfiga@chromium.org jcliang@chromium.org mcasas@chromium.org deanliao@google.com wuchengli@chromium.org posciak@chromium.org
Upload CLs for enabling V4L2 VEA to encode DMABuf-backed video frame and testing it.
They are not tested yet, since drivers ignore data offset in V4L2_MEMORY_DMABUF API. 
https://chromium-review.googlesource.com/c/chromium/src/+/1301579
https://chromium-review.googlesource.com/c/chromium/src/+/1295636
Blockedon: 901264
Project Member

Comment 4 by bugdroid1@chromium.org, Nov 8

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

commit 7935975eafaa43da7ad820ff7be7bfd700cb6f05
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Thu Nov 08 17:39:11 2018

media/gpu/vaapiVEA: Support DMABuf-backed video frame input on Encode()

This enables VaapiVEA to encode DMABuf-backed video frame. Because the
va surface format is NV12, NV12 format is only acceptable.
This change is tested by crrev.com/c/1295636

BUG= chromium:895230 
TEST=VEA unittest --native_input

Change-Id: Ib3c09363936cdf3099bb9ed9fc14eb24bd0e70fe
Reviewed-on: https://chromium-review.googlesource.com/c/1306944
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Cr-Commit-Position: refs/heads/master@{#606519}
[modify] https://crrev.com/7935975eafaa43da7ad820ff7be7bfd700cb6f05/media/gpu/test/vaapi_dmabuf_video_frame_mapper.cc
[modify] https://crrev.com/7935975eafaa43da7ad820ff7be7bfd700cb6f05/media/gpu/vaapi/vaapi_picture_native_pixmap.cc
[modify] https://crrev.com/7935975eafaa43da7ad820ff7be7bfd700cb6f05/media/gpu/vaapi/vaapi_picture_native_pixmap.h
[modify] https://crrev.com/7935975eafaa43da7ad820ff7be7bfd700cb6f05/media/gpu/vaapi/vaapi_video_encode_accelerator.cc
[modify] https://crrev.com/7935975eafaa43da7ad820ff7be7bfd700cb6f05/media/gpu/vaapi/vaapi_video_encode_accelerator.h

Project Member

Comment 5 by bugdroid1@chromium.org, Nov 9

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

commit c4e9ae1b9abc167c177d659dbcc3d1f794e93064
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Fri Nov 09 10:41:08 2018

media/gpu/VEA unittest: Test DMABuf-backed input buffers

This adds the command line option, --natvie_input, that VEA unittest passes
DMABuf-backed video frame to VEA.
DMABufs are obtained by gbm though NativePixmap. To create NativePixmap on
Chrome OS, it needs to set up Ozone environment properly. Therefore, this change
also makes VEA unittest dependent on Ozone.

BUG= chromium:895230 
TEST=VEA unittest on eve w/wo --native_input

Change-Id: I67526a1b6b6cf1ae74a96000ec2af14995dbd4fc
Reviewed-on: https://chromium-review.googlesource.com/c/1295636
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Cr-Commit-Position: refs/heads/master@{#606788}
[modify] https://crrev.com/c4e9ae1b9abc167c177d659dbcc3d1f794e93064/media/gpu/BUILD.gn
[modify] https://crrev.com/c4e9ae1b9abc167c177d659dbcc3d1f794e93064/media/gpu/test/generic_dmabuf_video_frame_mapper.cc
[modify] https://crrev.com/c4e9ae1b9abc167c177d659dbcc3d1f794e93064/media/gpu/test/rendering_helper.cc
[modify] https://crrev.com/c4e9ae1b9abc167c177d659dbcc3d1f794e93064/media/gpu/test/texture_ref.cc
[modify] https://crrev.com/c4e9ae1b9abc167c177d659dbcc3d1f794e93064/media/gpu/test/texture_ref.h
[add] https://crrev.com/c4e9ae1b9abc167c177d659dbcc3d1f794e93064/media/gpu/test/video_encode_accelerator_unittest_helpers.cc
[add] https://crrev.com/c4e9ae1b9abc167c177d659dbcc3d1f794e93064/media/gpu/test/video_encode_accelerator_unittest_helpers.h
[modify] https://crrev.com/c4e9ae1b9abc167c177d659dbcc3d1f794e93064/media/gpu/test/video_frame_mapper_factory.cc
[modify] https://crrev.com/c4e9ae1b9abc167c177d659dbcc3d1f794e93064/media/gpu/test/video_frame_mapper_factory.h
[modify] https://crrev.com/c4e9ae1b9abc167c177d659dbcc3d1f794e93064/media/gpu/test/video_frame_validator.cc
[modify] https://crrev.com/c4e9ae1b9abc167c177d659dbcc3d1f794e93064/media/gpu/test/video_frame_validator.h
[modify] https://crrev.com/c4e9ae1b9abc167c177d659dbcc3d1f794e93064/media/gpu/video_decode_accelerator_unittest.cc
[modify] https://crrev.com/c4e9ae1b9abc167c177d659dbcc3d1f794e93064/media/gpu/video_encode_accelerator_unittest.cc

Project Member

Comment 6 by bugdroid1@chromium.org, Nov 9

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

commit a2ebf50601155e617b5966d1e585734cb4ffaade
Author: Findit <findit-for-me@appspot.gserviceaccount.com>
Date: Fri Nov 09 11:31:57 2018

Revert "media/gpu/VEA unittest: Test DMABuf-backed input buffers"

This reverts commit c4e9ae1b9abc167c177d659dbcc3d1f794e93064.

Reason for revert:

Findit (https://goo.gl/kROfz5) identified CL at revision 606788 as the
culprit for failures in the build cycles as shown on:
https://findit-for-me.appspot.com/waterfall/culprit?key=ag9zfmZpbmRpdC1mb3ItbWVyRAsSDVdmU3VzcGVjdGVkQ0wiMWNocm9taXVtL2M0ZTlhZTFiOWFiYzE2N2MxNzdkNjU5ZGJjYzNkMWY3OTRlOTMwNjQM

Sample Failed Build: https://ci.chromium.org/buildbot/chromium/win32-rel/5951

Sample Failed Step: compile

Original change's description:
> media/gpu/VEA unittest: Test DMABuf-backed input buffers
> 
> This adds the command line option, --natvie_input, that VEA unittest passes
> DMABuf-backed video frame to VEA.
> DMABufs are obtained by gbm though NativePixmap. To create NativePixmap on
> Chrome OS, it needs to set up Ozone environment properly. Therefore, this change
> also makes VEA unittest dependent on Ozone.
> 
> BUG= chromium:895230 
> TEST=VEA unittest on eve w/wo --native_input
> 
> Change-Id: I67526a1b6b6cf1ae74a96000ec2af14995dbd4fc
> Reviewed-on: https://chromium-review.googlesource.com/c/1295636
> Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
> Reviewed-by: Pawel Osciak <posciak@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#606788}

No-Presubmit: true
No-Tree-Checks: true
No-Try: true
BUG= chromium:895230 

Change-Id: I75c80e914ec2493c26b34ddb4644e53099ba6bf5
Reviewed-on: https://chromium-review.googlesource.com/c/1328713
Cr-Commit-Position: refs/heads/master@{#606796}
[modify] https://crrev.com/a2ebf50601155e617b5966d1e585734cb4ffaade/media/gpu/BUILD.gn
[modify] https://crrev.com/a2ebf50601155e617b5966d1e585734cb4ffaade/media/gpu/test/generic_dmabuf_video_frame_mapper.cc
[modify] https://crrev.com/a2ebf50601155e617b5966d1e585734cb4ffaade/media/gpu/test/rendering_helper.cc
[modify] https://crrev.com/a2ebf50601155e617b5966d1e585734cb4ffaade/media/gpu/test/texture_ref.cc
[modify] https://crrev.com/a2ebf50601155e617b5966d1e585734cb4ffaade/media/gpu/test/texture_ref.h
[delete] https://crrev.com/c028d7085fdc469ffdf4efec3f9ae8d22d1e3640/media/gpu/test/video_encode_accelerator_unittest_helpers.cc
[delete] https://crrev.com/c028d7085fdc469ffdf4efec3f9ae8d22d1e3640/media/gpu/test/video_encode_accelerator_unittest_helpers.h
[modify] https://crrev.com/a2ebf50601155e617b5966d1e585734cb4ffaade/media/gpu/test/video_frame_mapper_factory.cc
[modify] https://crrev.com/a2ebf50601155e617b5966d1e585734cb4ffaade/media/gpu/test/video_frame_mapper_factory.h
[modify] https://crrev.com/a2ebf50601155e617b5966d1e585734cb4ffaade/media/gpu/test/video_frame_validator.cc
[modify] https://crrev.com/a2ebf50601155e617b5966d1e585734cb4ffaade/media/gpu/test/video_frame_validator.h
[modify] https://crrev.com/a2ebf50601155e617b5966d1e585734cb4ffaade/media/gpu/video_decode_accelerator_unittest.cc
[modify] https://crrev.com/a2ebf50601155e617b5966d1e585734cb4ffaade/media/gpu/video_encode_accelerator_unittest.cc

Project Member

Comment 7 by bugdroid1@chromium.org, Nov 9

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

commit 341861b66e4ad99689c9842cdb723cf7429d3157
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Fri Nov 09 17:21:55 2018

Reland "media/gpu/VEA unittest: Test DMABuf-backed input buffers"

This adds the command line option, --natvie_input, that VEA unittest passes
DMABuf-backed video frame to VEA.
DMABufs are obtained by gbm though NativePixmap. To create NativePixmap on
Chrome OS, it needs to set up Ozone environment properly. Therefore, this change
also makes VEA unittest dependent on Ozone.

BUG= chromium:895230 
TEST=VEA unittest on eve w/wo --native_input
TBR=posciak@chromium.org

Change-Id: I2998f0695813e5e1b77ae2136140eebc385636bf
Reviewed-on: https://chromium-review.googlesource.com/c/1329121
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#606880}
[modify] https://crrev.com/341861b66e4ad99689c9842cdb723cf7429d3157/media/gpu/BUILD.gn
[modify] https://crrev.com/341861b66e4ad99689c9842cdb723cf7429d3157/media/gpu/test/generic_dmabuf_video_frame_mapper.cc
[modify] https://crrev.com/341861b66e4ad99689c9842cdb723cf7429d3157/media/gpu/test/rendering_helper.cc
[modify] https://crrev.com/341861b66e4ad99689c9842cdb723cf7429d3157/media/gpu/test/texture_ref.cc
[modify] https://crrev.com/341861b66e4ad99689c9842cdb723cf7429d3157/media/gpu/test/texture_ref.h
[add] https://crrev.com/341861b66e4ad99689c9842cdb723cf7429d3157/media/gpu/test/video_encode_accelerator_unittest_helpers.cc
[add] https://crrev.com/341861b66e4ad99689c9842cdb723cf7429d3157/media/gpu/test/video_encode_accelerator_unittest_helpers.h
[modify] https://crrev.com/341861b66e4ad99689c9842cdb723cf7429d3157/media/gpu/test/video_frame_mapper_factory.cc
[modify] https://crrev.com/341861b66e4ad99689c9842cdb723cf7429d3157/media/gpu/test/video_frame_mapper_factory.h
[modify] https://crrev.com/341861b66e4ad99689c9842cdb723cf7429d3157/media/gpu/test/video_frame_validator.cc
[modify] https://crrev.com/341861b66e4ad99689c9842cdb723cf7429d3157/media/gpu/test/video_frame_validator.h
[modify] https://crrev.com/341861b66e4ad99689c9842cdb723cf7429d3157/media/gpu/video_decode_accelerator_unittest.cc
[modify] https://crrev.com/341861b66e4ad99689c9842cdb723cf7429d3157/media/gpu/video_encode_accelerator_unittest.cc

Project Member

Comment 8 by bugdroid1@chromium.org, Nov 10

Comment 9 Deleted

I verified Dmabuf input mode on minnie and kevin.
I observes crash on hana. I will take a look tomorrow. go/paste/4963847236485120
Project Member

Comment 11 by bugdroid1@chromium.org, Nov 13

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

commit c8dada6eb2d55994e79f65d4ef04bb37abd2fd8d
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Tue Nov 13 10:29:29 2018

media/gpu/v4l2/v4l2 VEA: Support DMABuf-backed video frame input on Encode()

V4L2VEA supports only SHMEM video frame for Encode().
V4L2_MEMORY_USERPTR API is used on VIDIOC_QBUF, which is less efficient than
V4L2_MEMORY_{MMAP, DMABUF} API.
This enables V4L2VEA to accept DMABuf-backed video frame on Encode(). The video
frame is queued with V4L2_MEMORY_DMABUF API unless ImageProcessor outputs SHMEM
video frame.

BUG= 895230 , 901264
TEST=VDA unittest --native_input on minnie, kevin

Change-Id: I545e26ffb619eb6c065183f794cef78e42cc2ea8
Reviewed-on: https://chromium-review.googlesource.com/c/1301579
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Cr-Commit-Position: refs/heads/master@{#607546}
[modify] https://crrev.com/c8dada6eb2d55994e79f65d4ef04bb37abd2fd8d/media/gpu/v4l2/v4l2_video_encode_accelerator.cc

YV12+DMABUF on hana fails.
Looking kernel log, there was "Bad mode in Synchronous Abort handler detected"
Kernel log: https://paste.googleplex.com/5100821888892928
Project Member

Comment 13 by bugdroid1@chromium.org, Nov 17

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

commit fd5ba607b11a618d116e6ca230f57fa471e0664f
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Sat Nov 17 16:54:11 2018

HACK: CHROMIUM: rk3399-vpu: Compute plane address with data_offset

With V4L2 MEMORY DMABUF API, it is necessary to set a file descriptor on
each plane. The way to pass an offset with a DmaBuf is not defined in V4L2
specification. This is the case as it is needed to specify offsets because
Chromium creates one DmaBuf for the planes.
This is HACK to abuse data_offset for the purpose.
This patch should be reverted after the appropriate way is defined.

BUG= chromium:895230 , chromium:901264
TEST=VEA unittest --native_input on kevin

Change-Id: I0508ac10f2c2be4a0332125f41d0dd4b13d0499c
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1312535
Reviewed-by: Tomasz Figa <tfiga@chromium.org>

[modify] https://crrev.com/fd5ba607b11a618d116e6ca230f57fa471e0664f/drivers/media/platform/rockchip-vpu/rk3399_vpu_hw_vp8e.c
[modify] https://crrev.com/fd5ba607b11a618d116e6ca230f57fa471e0664f/drivers/media/platform/rockchip-vpu/rk3399_vpu_hw_h264e.c

Project Member

Comment 14 by bugdroid1@chromium.org, Nov 18

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

commit 1da370daf99f2e71ef2e092385df3db60b6cba22
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Sun Nov 18 00:41:42 2018

HACK: CHROMIUM: rk3288-vpu: Compute plane address with data_offset

With V4L2 MEMORY DMABUF API, it is necessary to set a file descriptor on
each plane. The way to pass an offset with a DmaBuf is not defined in V4L2
specification. This is the case as it is needed to specify offsets because
Chromium creates one DmaBuf for the planes.
This is HACK to abuse data_offset for the purpose.
This patch should be reverted after the appropriate way is defined.

BUG= chromium:895230 , chromium:901264
TEST=VEA unittest --native_input on veyron_minnie

Change-Id: Id1471ef622aa3e616dcdb5559f4f948b2c1155ee
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1319830
Reviewed-by: Tomasz Figa <tfiga@chromium.org>

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

I created the issue for DMABUF+YV12 failure on MTK,  crbug.com/906473 .
Project Member

Comment 16 by bugdroid1@chromium.org, Nov 20

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

commit db2bf67573cc0ff295f995e5746eb7516df0d26e
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Tue Nov 20 00:13:16 2018

GenericDmaBufVideoFrameValidator: Map YV12 VideoFrame as-is

GenericDmaBufVideoFrameValidator swaps U plane and V plane addresses so that
VideoFrameValidator is able to libyuv::I420Copy in the order Y, U and V. This
is a wrong design, meaning VideoFrameMapper does not only map but also
does something. VideoFrameMapper caller should expect the address acquired by
VideoFrame::data(UPlane) is V plane's and one by VideoFrame::data(VPlane) is U
plane's in the case of YV12 VideoFrame.

BUG= chromium:895230 ,  chromium:856562 
TEST=VDA unittest on hana with --frame_validator=check
TEST=VEA unittest on hana with --native_input

Change-Id: Ibf5e5685d95634fe6720f07dc154fd01907516d8
Reviewed-on: https://chromium-review.googlesource.com/c/1341783
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#609518}
[modify] https://crrev.com/db2bf67573cc0ff295f995e5746eb7516df0d26e/media/gpu/test/generic_dmabuf_video_frame_mapper.cc
[modify] https://crrev.com/db2bf67573cc0ff295f995e5746eb7516df0d26e/media/gpu/test/video_frame_validator.cc

Project Member

Comment 17 by bugdroid1@chromium.org, Nov 20

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

commit df8697848d558161684e543d6abcf231649d4351
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Tue Nov 20 07:43:56 2018

HACK: CHROMIUM: mtk-vcodec: Compute plane address with data_offset

With V4L2 MEMORY DMABUF API, it is necessary to set a file descriptor on
each plane. The way to pass an offset with a DmaBuf is not defined in V4L2
specification. This is the case as it is needed to specify offsets because
Chromium creates one DmaBuf for the planes.
This is HACK to abuse data_offset for the purpose.
This patch should be reverted after the appropriate way is defined.

BUG= chromium:895230 , chromium:901264
TEST=VEA unittest --native_input on hana

Change-Id: I7ad238d9bdb0916d429720faef27783fffeb2069
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1319829

[modify] https://crrev.com/df8697848d558161684e543d6abcf231649d4351/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c

Project Member

Comment 18 by bugdroid1@chromium.org, Nov 27

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

commit 2c2156f54a770eaaf3946d67cc3188df65c6c21c
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Tue Nov 27 10:41:24 2018

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}
[modify] https://crrev.com/2c2156f54a770eaaf3946d67cc3188df65c6c21c/components/arc/common/video_encode_accelerator.mojom
[modify] https://crrev.com/2c2156f54a770eaaf3946d67cc3188df65c6c21c/components/arc/video_accelerator/gpu_arc_video_encode_accelerator.cc
[modify] https://crrev.com/2c2156f54a770eaaf3946d67cc3188df65c6c21c/components/arc/video_accelerator/gpu_arc_video_encode_accelerator.h

Status: Fixed (was: Assigned)
All work in VEAs are done. Closed.
Project Member

Comment 20 by bugdroid1@chromium.org, Dec 5 (4 days ago)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/tast-tests/+/5d309770349f7258e4d0fc5e9a97bcf1988a761c

commit 5d309770349f7258e4d0fc5e9a97bcf1988a761c
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Wed Dec 05 09:13:35 2018

video.EncodeAccel*Dmabuf: Add DMABUF-NV12 test case

In DMABUF-NV12 test cases, VEA unittest just runs with --native_input

BUG=chromium:889496,  chromium:895230 
TEST=video.EncodeAccel*Dmabuf on kevin

Change-Id: I6da192d3a1baccf82654b0bb8831b9a497333691
Reviewed-on: https://chromium-review.googlesource.com/1351969
Commit-Ready: Hirokazu Honda <hiroh@chromium.org>
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>

[modify] https://crrev.com/5d309770349f7258e4d0fc5e9a97bcf1988a761c/src/chromiumos/tast/local/bundles/cros/video/encode_accel_vp8_nv12.go
[modify] https://crrev.com/5d309770349f7258e4d0fc5e9a97bcf1988a761c/src/chromiumos/tast/local/bundles/cros/video/encode_accel_vp8_i420.go
[modify] https://crrev.com/5d309770349f7258e4d0fc5e9a97bcf1988a761c/src/chromiumos/tast/local/bundles/cros/video/encode_accel_vp8_180p_i420.go
[modify] https://crrev.com/5d309770349f7258e4d0fc5e9a97bcf1988a761c/src/chromiumos/tast/local/bundles/cros/video/encode_accel_h264_180p_i420.go
[modify] https://crrev.com/5d309770349f7258e4d0fc5e9a97bcf1988a761c/src/chromiumos/tast/local/bundles/cros/video/encode_accel_vp8_720p_i420.go
[modify] https://crrev.com/5d309770349f7258e4d0fc5e9a97bcf1988a761c/src/chromiumos/tast/local/bundles/cros/video/encode_accel_h264_720p_i420.go
[modify] https://crrev.com/5d309770349f7258e4d0fc5e9a97bcf1988a761c/src/chromiumos/tast/local/bundles/cros/video/encode_accel_h264_i420.go
[modify] https://crrev.com/5d309770349f7258e4d0fc5e9a97bcf1988a761c/src/chromiumos/tast/local/bundles/cros/video/encode_accel_h264_360p_i420.go
[add] https://crrev.com/5d309770349f7258e4d0fc5e9a97bcf1988a761c/src/chromiumos/tast/local/bundles/cros/video/encode_accel_vp8_nv12_dmabuf.go
[modify] https://crrev.com/5d309770349f7258e4d0fc5e9a97bcf1988a761c/src/chromiumos/tast/local/bundles/cros/video/encode_accel_vp8_1080p_i420.go
[modify] https://crrev.com/5d309770349f7258e4d0fc5e9a97bcf1988a761c/src/chromiumos/tast/local/bundles/cros/video/encode_accel_h264_1080p_i420.go
[modify] https://crrev.com/5d309770349f7258e4d0fc5e9a97bcf1988a761c/src/chromiumos/tast/local/bundles/cros/video/encode/accel_video.go
[modify] https://crrev.com/5d309770349f7258e4d0fc5e9a97bcf1988a761c/src/chromiumos/tast/local/bundles/cros/video/encode_accel_h264_nv12.go
[add] https://crrev.com/5d309770349f7258e4d0fc5e9a97bcf1988a761c/src/chromiumos/tast/local/bundles/cros/video/encode_accel_h264_nv12_dmabuf.go
[modify] https://crrev.com/5d309770349f7258e4d0fc5e9a97bcf1988a761c/src/chromiumos/tast/local/bundles/cros/video/encode_accel_vp8_360p_i420.go

Sign in to add a comment