Enable VEAs to encode any yuv format input |
||||||||
Issue descriptionCurrently, 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
,
Oct 11
,
Oct 11
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.
,
Oct 11
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
,
Oct 11
,
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
,
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
,
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
,
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
,
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
,
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
,
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
,
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
,
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
,
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
,
Nov 1
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
,
Nov 16
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.
,
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
,
Nov 28
,
Nov 29
All work in VEAs are done. Closed. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by tfiga@chromium.org
, Oct 11