GitLab

This CL modifies the V4L2JpegDecodeAccelerator::ConvertOutputImage
method to pass the coded size of the output VideoFrame to libyuv instead
of passing the size of the V4L2 output buffer.

The motivation is that the coded size of the V4L2 can be larger than the
coded size of the VideoFrame. For example, on an elm (CrOS 10802.0.0),
decoding a 41x22 image causes the V4L2 buffer to be 64x24 while the
coded size of the VideoFrame is 42x22. So, it doesn't seem safe to pass
64x24 to the libyuv conversion routines assuming that the VideoFrame is
backed by memory that's only enough for a 42x22 frame.

This doesn't fix the referenced bug, but it should make copies safer
even for even-sized images. I tested one of the modified paths on an elm
(when output_buffer_pixelformat_ == V4L2_PIX_FMT_YUV422M and the
output_buffer_num_planes_ != 1) to make sure the tests still pass. I
couldn't find a device to test the path when
output_buffer_pixelformat_ == V4L2_PIX_FMT_YUV420M and
output_buffer_num_planes_ != 1, so relying on automated testing.

Bug: 852236
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: Id0acef8f6f6c5e144ff4d6620dd3db3b53bff415
Reviewed-on: https://chromium-review.googlesource.com/1111247Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Commit-Queue: Andres Calderon Jaramillo <andrescj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#570090}