V4L2 JDA: Use VideoFrame size for libyuv output.
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}
Showing
Please register or sign in to comment