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
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
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
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
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
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
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
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/429559b971ffcd4830b48ad457c1cba5e99f6983 commit 429559b971ffcd4830b48ad457c1cba5e99f6983 Author: Hirokazu Honda <hiroh@chromium.org> Date: Sat Nov 10 09:16:03 2018 video_encode_accelerator.mojom: Remove deprecated functions and structures BUG= chromium:895230 TEST=CtsMediaTestCases Change-Id: If928fa30cf6800809242b467c472b4549926f3d0 Reviewed-on: https://chromium-review.googlesource.com/c/1325584 Reviewed-by: Pawel Osciak <posciak@chromium.org> Reviewed-by: Greg Kerr <kerrnel@chromium.org> Commit-Queue: Hirokazu Honda <hiroh@chromium.org> Cr-Commit-Position: refs/heads/master@{#607116} [modify] https://crrev.com/429559b971ffcd4830b48ad457c1cba5e99f6983/components/arc/common/video_encode_accelerator.mojom [modify] https://crrev.com/429559b971ffcd4830b48ad457c1cba5e99f6983/components/arc/common/video_encode_accelerator.typemap [modify] https://crrev.com/429559b971ffcd4830b48ad457c1cba5e99f6983/components/arc/common/video_encode_accelerator_struct_traits.cc [modify] https://crrev.com/429559b971ffcd4830b48ad457c1cba5e99f6983/components/arc/common/video_encode_accelerator_struct_traits.h [modify] https://crrev.com/429559b971ffcd4830b48ad457c1cba5e99f6983/components/arc/video_accelerator/gpu_arc_video_encode_accelerator.cc [modify] https://crrev.com/429559b971ffcd4830b48ad457c1cba5e99f6983/components/arc/video_accelerator/gpu_arc_video_encode_accelerator.h
I verified Dmabuf input mode on minnie and kevin. I observes crash on hana. I will take a look tomorrow. go/paste/4963847236485120
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
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
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 .
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
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
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
All work in VEAs are done. Closed.
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
Comment 1 by bugdroid1@chromium.org
, Oct 25