The idea is that we want to eventually use the JpegDecodeAccelerator to do general JPEG decoding (as opposed to just camera capture decoding). I want to use media/gpu/jpeg_decode_accelerator_unittest.cc to run an Autotest experiment to see what kinds of JPEGs are supported on all our Intel Chrome OS platforms.

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

commit fc5da42bddc20e919d2e590a72e19046b275b994
Author: Andres Calderon Jaramillo <andrescj@chromium.org>
Date: Wed Jun 06 19:23:26 2018

Make the JDA unit tests save decoded output as .png instead of .yuv.

This CL changes the JpegClient::SaveToFile method in
jpeg_decode_accelerator_unittest.cc so that it saves the decode result
as a PNG file for easy visualization. Previously, the output was a .yuv
file which couldn't be readily visualized.

This makes the problem with odd-sized images more evident. Here are
examples of the PNG output for three images (compared to a reference
output which is the result of opening the original JPEG image in GIMP):

- 80x46 JPEG (even-sized):
  Reference:
  https://drive.google.com/open?id=15hv1c4d2Iy1SPXxTk6575JPGhkGMEYnr
  Unit test:
  https://drive.google.com/open?id=1ZQtNkZzwvfIwp9kBsbwf301aIjY7zSmY

- 81x46 JPEG (odd-sized):
  Reference:
  https://drive.google.com/open?id=1WB2gW0H4XB9T4-fkRIBygXvfpKkX1rxY
  Unit test:
  https://drive.google.com/open?id=1Zprc8UaPyVoYw7IWGngSmwXNEsyy__jQ

- 80x45 JPEG (odd-sized):
  Reference:
  https://drive.google.com/open?id=1tnOQU4cvbtgIH5036pbb2qmaOLPBLOmK
  Unit test:
  https://drive.google.com/open?id=1XWXYnStEqTtLQPqDxZidaPIH4ShzDSaq

The issue with odd-sized images will be corrected in follow-up CLs.

Bug: 849776
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: I50a8662544b014c6d26ed8017c1a20f2fdca329f
Reviewed-on: https://chromium-review.googlesource.com/1087727
Commit-Queue: Andres Calderon Jaramillo <andrescj@chromium.org>
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Cr-Commit-Position: refs/heads/master@{#565000}
[modify] https://crrev.com/fc5da42bddc20e919d2e590a72e19046b275b994/media/gpu/jpeg_decode_accelerator_unittest.cc

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

commit 4d88718eaf872788f779c27ad23072b6b03ab364
Author: Andres Calderon Jaramillo <andrescj@chromium.org>
Date: Thu Jun 07 02:51:13 2018

Use only visible data when computing mean differences in JDA unit tests.

This CL modifies the computation of the mean absolute difference between
the software and hardware decoding results in the JDA unit tests.
Previously, the shared memory segments containing the decoded data were
compared byte by byte. However, if the decoded data contains stride
padding, this would underestimate the mean absolute difference because
the padding would be counted as data points. Now, the computation only
considers the visible portion. Since this makes the computation not
trivial, a unit test is added for it.

Note that now, the software decode result is kept track of in a
VideoFrame. This is for convenience: we don't have to recalculate the
data pointers and the strides every time we need them.

Bug: 849776
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: Ifec58c872cd788a124265471444f0746ccb2db76
Reviewed-on: https://chromium-review.googlesource.com/1090153
Commit-Queue: Andres Calderon Jaramillo <andrescj@chromium.org>
Commit-Queue: Daniele Castagna <dcastagna@chromium.org>
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Cr-Commit-Position: refs/heads/master@{#565157}
[modify] https://crrev.com/4d88718eaf872788f779c27ad23072b6b03ab364/media/gpu/jpeg_decode_accelerator_unittest.cc

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

commit 65ce78ca60eb998704a07457a5552349000fb825
Author: Andres Calderon Jaramillo <andrescj@chromium.org>
Date: Sat Jun 09 23:00:43 2018

Make the JDA unit tests work with odd-sized images.

This CL fixes media/gpu/jpeg_decode_accelerator_unittest.cc so that the
strides and pointers for the VideoFrame that holds the decode result are
computed correctly when the JPEG image has at least one odd dimension.

The strategy is to keep track of a visible size and a coded size for
each image. For odd-sized images, the visible size corresponds to the
original dimensions whereas the coded size corresponds to the odd
dimensions rounded up to the next even number. Thus, the stride
computations will be correct when we call WrapExternalSharedMemory to
build the VideoFrame.

A test case is added for odd-sized images.

To visualize the results, both the software and hardware decode outputs
are saved as PNG when using the --save_to_file flag.

Bug: 849776
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: Ia80c038059949d873b59958afe1fad1533b32226
Reviewed-on: https://chromium-review.googlesource.com/1094037
Commit-Queue: Daniele Castagna <dcastagna@chromium.org>
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Cr-Commit-Position: refs/heads/master@{#565895}
[modify] https://crrev.com/65ce78ca60eb998704a07457a5552349000fb825/media/gpu/jpeg_decode_accelerator_unittest.cc
[add] https://crrev.com/65ce78ca60eb998704a07457a5552349000fb825/media/test/data/peach_pi-40x23.jpg
[add] https://crrev.com/65ce78ca60eb998704a07457a5552349000fb825/media/test/data/peach_pi-41x22.jpg
[add] https://crrev.com/65ce78ca60eb998704a07457a5552349000fb825/media/test/data/peach_pi-41x23.jpg

Could you take a look crbug.com/852236?
Odd image test case is flaky at some boards.

Thanks