Looks like this failure is flaky.

I reproduced this problem on a peach-pi with CrOS version 10780.0.0. I'm thinking that it might be a driver issue with odd dimensions. I printed the decoded data for the 40x23 test image, and it looks like all the planes are missing one row (see my debugging CL at https://chromium-review.googlesource.com/c/chromium/src/+/1106913). See the output below (note e.g. that the Y plane has all 0's for row 23).

jcliang@ Can you please help me confirm if it's a driver issue or tell me who I should talk to?

============================================================
  1: 3F3F4041424142434340483F444543444641454A49454048425849434E4746494A47464646494A480000000000000000
  2: 474441414242414141414947424B49484C5C504048555A585D68574B414C4B4C464C4D49484B4D4B0000000000000000
  3: 3F414343434345474F3F4543494346473F707974818789817C72504A4C4D49494746464B4F4B47490000000000000000
  4: 454748464546474944484B434B4A4A49607C8983857E828B818591664A4A464E4D4E4D4C4B474A550000000000000000
  5: 45444341434443404048434C4A4448678D80898082837E7E8B7F76806145504A484C4B4A4E514D470000000000000000
  6: 445362696B6C6F716F5E4E424A4269918288AA907975787F9DB0837E634C514D544F50514D494A4B0000000000000000
  7: 899EB3BBBCBEC4C9C2B79C64464C7A7F7770816F7071777B84817B5A607058594A3B3C4449545F5B0000000000000000
  8: B4B6B5B3B5B9BBB9BDC1B4AF57637E9288818D898C706B747370806B8CB5C45D39719E82483E52520000000000000000
  9: B4B4B8B8BABCBBBCB5C2B9B39C869E9F90969B9398737F8481877364A4ABC65F60C2CD96934A3D4D0000000000000000
 10: B2B8BABBBABABEBDBFAFB6B4A99B969286828A8173766D6B7B67543F5B92A068629CA2A2C2703A4C0000000000000000
 11: B5BAB6BABDBBBFBAB9BEB3ACA57D8BA6ADA4707579706C716F6038412A6F9088AE666A85794B3D510000000000000000
 12: B4B5B7B9B9B7B9BBB2B2ACAD9E87C0C3C0B78162787B646A5F645E40394CA2A7AC3F352E213A464C0000000000000000
 13: BAB1B3B5BBC0BABDBFACA6979686AEB7C2AB7D5F6662596153648F443627494C3E37423F483D508D0000000000000000
 14: AEADB1AEB1B8BABEBBC5AD7680779EB4B8C57C484D5A5C4E3F2F404C647449392D383E443E3F66640000000000000000
 15: A9B6ACA8ABB3C2B8AB8DA99D835F96B1B3B17E37484C435764453B738F8A847E704338474578A0810000000000000000
 16: A79965719EB6B0711122A6926A688792A19D75262E23576B6E5A3F82808188837F805D3966B393990000000000000000
 17: 989A7966A1ACA3701C74A37B6375A184737E7D5455555C6559335C897586827D7F7E8550428792940000000000000000
 18: 95929397A7939A949999855C51689A9D84847B7A979F8C6D6275978F657C8383747A895F416D829A0000000000000000
 19: 988B8F92938D928B87704D313B68929A9F96859193959EA29D9B907B5A595F757A75755B578494970000000000000000
 20: B493848385857463424F55505D84826E8D74638187969C9F9CA3A0A79D855E4A4F6478716B85999D0000000000000000
 21: A8A58E5F4A54483F6167707880978B8486736B767599A19FA0A8A4A6A4A9A89E9092999D999499980000000000000000
 22: 98826E69777A6F7B7B7E8B989AA0959B867A88928FA2A6A4A8A4A5ABA19EA5A6A9A6A6A2A09DA4A30000000000000000
 23: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
 24: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
 25: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
 26: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
 27: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
 28: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
 29: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
 30: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
 31: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
 32: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
============================================================
  1: 67686969696867666864696463665F626767666600000000
  2: 64646565666768686069686F6F66675E5D61656800000000
  3: 6061626363626160746F736C696A61646264666800000000
  4: 7A7D80817E776F6B67686067717C92989489796A00000000
  5: 7D8185828083714E5E6D686D738285949583958900000000
  6: 808082807E8174585F726F666890948082938D9600000000
  7: 837E80817D7D7664646B6B6D71989F8C98A4A88000000000
  8: 837D8185807B75685E6F6C6E748F94969FA0917900000000
  9: 82818285867F72675C6F787173838E8D95938A7B00000000
 10: 7F7D7B7B7B776F68505362747A757C8A8789847A00000000
 11: 7E7B7876757472715B616D787B78777A797D7D7700000000
 12: 000000000000000000000000000000000000000000000000
 13: 000000000000000000000000000000000000000000000000
 14: 000000000000000000000000000000000000000000000000
 15: 000000000000000000000000000000000000000000000000
 16: 000000000000000000000000000000000000000000000000
============================================================
  1: 696869686768665F61606063676866646768686800000000
  2: 68676564656362646C747D7D776E6B6A6768696900000000
  3: 6A6B66666A605D6C7C7C7D81827A6B5F6566676800000000
  4: 787D797C816D657B7F7C7A7C7F7C736B67696C6F00000000
  5: 818283817E7F8388827C7F7D73777E786F887B6C00000000
  6: 818283807E7F848986817D7F7E75747F8C81796800000000
  7: 808283817F80858A86817B7E80706B7D736C6B8000000000
  8: 808283817F81868B89848482797474746C6C798A00000000
  9: 83817E7D7F83888C8F8A858486837B747277808800000000
 10: 86868687898B8D8E98938D8A8B8A87838082868900000000
 11: 87898B8D8E8E8D8D97948F8B8B8B8C8D8D8D8C8C00000000
 12: 000000000000000000000000000000000000000000000000
 13: 000000000000000000000000000000000000000000000000
 14: 000000000000000000000000000000000000000000000000
 15: 000000000000000000000000000000000000000000000000
 16: 000000000000000000000000000000000000000000000000

This needs more investigation, but I'd first make sure that the hardware supports odd resolutions. YUV 420/422 formats are very often constrained to even width (420 and 422) and height (420), due to chroma subsampling and I wouldn't be surprised if odd case was simply unsupported. One might need to decode such format as even (rounded up to 2) and simply ignore last line.

One more thing to node here is that peach and beltion/slippy are two completely different hardware platform, using different JPEG decoder drivers. The former uses V4L2-based s5p-jpeg and the latter VAAPI.

Okay, I missed the point that it was visible size which was odd, not coded (or buffer) size. In that case, I think the driver should handle it. Maybe it does some wrong rounding when calculating buffer size.

I think we should split this into 2 separate bugs, one for Intel platforms (beltino, slippy) with VAAPI used for decoding and one for Exynos (peach-pi). The former does things in a userspace library, so someone familiar with it take a look. The latter has a V4L2 kernel driver, so someone from our team should be able to take a look.

Also worth noting is that on Mediatek platforms (hana, etc.), with another V4L2 driver, the test seems to be passing.

I agree. The test passed without problems on an elm, although it was following a different path than it would in a peach-pi.

For VAAPI, I tried it on one of the boards where it was failing (a falco if I remember correctly) and I was getting inconsistent results when running the OddDimensions test: most of the time it succeeded, but when it failed, it failed differently between failures. I don't have the results with me because I no longer have access to that Chromebook, but you could see a black rectangle of varying heights that showed up on the decoded result.

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

commit f650c5e9c112931de860e78ee326ee1b8bca1b59
Author: Andres Calderon Jaramillo <andrescj@chromium.org>
Date: Mon Jun 25 17:56:30 2018

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/1111247
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Commit-Queue: Andres Calderon Jaramillo <andrescj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#570090}
[modify] https://crrev.com/f650c5e9c112931de860e78ee326ee1b8bca1b59/media/gpu/v4l2/v4l2_jpeg_decode_accelerator.cc

GPU Triage: Is this something that needs addl fixes? And if so should this still be P1? Thanks!