I don't see obvious culprit from the CLs.

Looks like we are failing to load the test streams.

Sheng-hao. Please take a look. This is high priority.

05/24 10:12:13.569 DEBUG|        base_utils:0269| [stdout] [ RUN      ] VideoDecodeAcceleratorTest.TestDecodeTimeMedian
05/24 10:12:13.569 ERROR|        base_utils:0269| [stderr] [0524/101213:FATAL:video_decode_accelerator_unittest.cc(1158)] Assert failed: base::ReadFileToString(filepath, &video_file->data_str). test_video_file: /usr/local/autotest/deps/chrome_test/test_src/media/test/data/test-25fps.vp9

The path in the source tree is still correct:
https://code.google.com/p/chromium/codesearch#chromium/src/media/test/data/test-25fps.vp9&q=test-25fps.vp9&sq=package:chromium&type=cs

If the files are really missing there is a good chance this could be caused by
https://chromium-review.googlesource.com/#/c/344931/

(Ebuild changes take into effect during upreving chrome, but they could even be delayed one extra cycle.)

fyi

Sheng-hao. Try building chrome with and without 344931. 

- emerge-oak chromeos-base/chromeos-chrome
- In chroot, check if the file exists.
/build/oak/usr/local/build/autotest/client/deps/chrome_test/test_src/media/test/data/test-25fps.vp9

I am a bit too tired right now. Kicked off a build overnight. But what you want is to capture the output from emerge-oak in both cases. Also it creates a tarball with all the test resources. It is good to have both tarballs and diff them.

I verified that before cl/344931, the test-25fps.vp9 would be generated in /build/veyron_minnie-cheets/usr/local/build/autotest/client/deps/chrome_test/test_src/media/test/data/ after running emerge. But after cl/344931 is included, the data/ directory is empty.
Lloyd, may you take a look?

Sorry, yes it is my change, and I thought I had tested to make sure it works for directory inputs before sending it out for review. But I verified it doesn't work for media/test/data at least.

Its a quirk of rsync that it wants a trailing '/' for directories. If I take the call to install_test_resources, and add a '/' to the end, it does copy files as intended:

    install_test_resources "${test_dir}" \
        base/base_paths_posix.cc \
        chrome/test/data/chromeos \
        chrome/test/functional \
        chrome/third_party/mock4js/mock4js.js  \
        content/common/gpu/testdata \
-       media/test/data  \
+       media/test/data/ \
        content/test/data \
        net/data/ssl/certificates \

While I could do add them throughout the file as one fix, that doesn't seem very robust. I'll add a few lines to install_test_resources to add a trailing slash if the input path refers to a directory and does not have one already.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/318ed0eb1dca1ba29bba9790b8fff93b89cc12f5

commit 318ed0eb1dca1ba29bba9790b8fff93b89cc12f5
Author: Lloyd Pique <lpique@google.com>
Date: Thu May 26 20:35:18 2016

Fix install_test_resources for directories

The switch to using rsync with a list of paths rather than having a loop
that copied each one individually with rsync introduced an unfortunate
regression. The previous code copied the contents of a directory, the
replacement did not. I thought I had tested that possibility, but a bug
was reported because it was not.

This patch fixes it -- when using --files-from with -a, you also need to
explicitly include -r to get recursive behavior.  This behavior is
documented in the man page.

BUG= chromium:614925 
TEST=Verified contents of media/test/data are copied
TEST=Verified also that individual files are copied
TEST=install_telemetry_dep_resources was not significantly slower

Change-Id: Icc2e49cc994719a463b46768ddeef41a1f6222bf
Reviewed-on: https://chromium-review.googlesource.com/347474
Tested-by: Lloyd Pique <lpique@google.com>
Reviewed-by: Ilja Friedel <ihf@chromium.org>
Commit-Queue: Ilja Friedel <ihf@chromium.org>
Tested-by: Ilja Friedel <ihf@chromium.org>
Commit-Queue: Lloyd Pique <lpique@google.com>

[modify] https://crrev.com/318ed0eb1dca1ba29bba9790b8fff93b89cc12f5/chromeos-base/chromeos-chrome/chromeos-chrome-9999.ebuild

This may need to be integrated, but lets wait for verification.

8376.0.0 picked up the fix in #11. But all VDA and VEA tests are still failing.

You have to wait for Chrome to rev higher than 53.0.2749.3.

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

It looks like the video_VideoDecodeAccelerator tests are once again green, but the video_VideoEncodeAccelerator tests are failing.

    https://wmatrix.googleplex.com/unfiltered?hide_missing=True&releases=tot&tests=video_VideoEncodeAccelerator

Looking at one of the test output logs for one of the runs (https://wmatrix.googleplex.com/testrun/unfiltered?test_ids=307239032), I see:

    [ RUN      ] MidStreamParamSwitchFPS/VideoEncodeAcceleratorTest.TestSimpleEncode/0
    ../../../../../../../home/chrome-bot/chrome_root/src/media/gpu/video_encode_accelerator_unittest.cc:1516: Failure
    The difference between bitrate and current_requested_bitrate_ is 171971, which exceeds kBitrateTolerance * current_requested_bitrate_, where
    bitrate evaluates to 28029,
    current_requested_bitrate_ evaluates to 200000, and
    kBitrateTolerance * current_requested_bitrate_ evaluates to 20000.
    [  FAILED  ] MidStreamParamSwitchFPS/VideoEncodeAcceleratorTest.TestSimpleEncode/0, where GetParam() = 20-byte object <00-01 00-00 01-7F 00-00 00-00 00-00 00-7F 00-00 01-00 00-00> (197 ms)
    [----------] 1 test from MidStreamParamSwitchFPS/VideoEncodeAcceleratorTest (197 ms total)

    [----------] 3 tests from MultipleEncoders/VideoEncodeAcceleratorTest
    [ RUN      ] MultipleEncoders/VideoEncodeAcceleratorTest.TestSimpleEncode/0
    [       OK ] MultipleEncoders/VideoEncodeAcceleratorTest.TestSimpleEncode/0 (103 ms)
    [ RUN      ] MultipleEncoders/VideoEncodeAcceleratorTest.TestSimpleEncode/1
    ../../../../../../../home/chrome-bot/chrome_root/src/media/gpu/video_encode_accelerator_unittest.cc:1516: Failure
    The difference between bitrate and current_requested_bitrate_ is 171949, which exceeds kBitrateTolerance * current_requested_bitrate_, where
    bitrate evaluates to 28051,
    current_requested_bitrate_ evaluates to 200000, and
    kBitrateTolerance * current_requested_bitrate_ evaluates to 20000.
    ../../../../../../../home/chrome-bot/chrome_root/src/media/gpu/video_encode_accelerator_unittest.cc:1516: Failure
    The difference between bitrate and current_requested_bitrate_ is 171971, which exceeds kBitrateTolerance * current_requested_bitrate_, where
    bitrate evaluates to 28029,
    current_requested_bitrate_ evaluates to 200000, and
    kBitrateTolerance * current_requested_bitrate_ evaluates to 20000.
    ../../../../../../../home/chrome-bot/chrome_root/src/media/gpu/video_encode_accelerator_unittest.cc:1516: Failure
    The difference between bitrate and current_requested_bitrate_ is 171971, which exceeds kBitrateTolerance * current_requested_bitrate_, where
    bitrate evaluates to 28029,
    current_requested_bitrate_ evaluates to 200000, and
    kBitrateTolerance * current_requested_bitrate_ evaluates to 20000.
    [  FAILED  ] MultipleEncoders/VideoEncodeAcceleratorTest.TestSimpleEncode/1, where GetParam() = 20-byte object <00-01 00-00 01-FF 52-35 00-00 00-00 00-F1 1C-3D 03-00 00-00> (591 ms)
    [ RUN      ] MultipleEncoders/VideoEncodeAcceleratorTest.TestSimpleEncode/2
    [       OK ] MultipleEncoders/VideoEncodeAcceleratorTest.TestSimpleEncode/2 (598 ms)
    [----------] 3 tests from MultipleEncoders/VideoEncodeAcceleratorTest (1292 ms total)
    [----------] Global test environment tear-down
    [==========] 10 tests from 7 test cases ran. (2032 ms total)
    [  PASSED  ] 8 tests.
    [  FAILED  ] 2 tests, listed below:
    [  FAILED  ] MidStreamParamSwitchFPS/VideoEncodeAcceleratorTest.TestSimpleEncode/0, where GetParam() = 20-byte object <00-01 00-00 01-7F 00-00 00-00 00-00 00-7F 00-00 01-00 00-00>
    [  FAILED  ] MultipleEncoders/VideoEncodeAcceleratorTest.TestSimpleEncode/1, where GetParam() = 20-byte object <00-01 00-00 01-FF 52-35 00-00 00-00 00-F1 1C-3D 03-00 00-00>

     2 FAILED TESTS

This seems to match the failure in a second DUT (https://wmatrix.googleplex.com/testrun/unfiltered?test_ids=307236994), but I didn't confirm more than those two had the same issue.

Sending to posciak@ as he would probably know more than I about these tests and what might be needed to fix them.

Thanks!

Tests on Exynos-based platforms are failing keyframe tests (e.g. https://wmatrix.googleplex.com/testrun/unfiltered?test_ids=308297167). It's likely to be related to our recent changes to remove deprecated keyframe API ( issue 572825 ). Could be as simple as desynced Chrome and CrOS versions.

We should address this asap. Sheng-hao, would you have some cycles to please take a look?

Tried to revert https://chromium-review.googlesource.com/#/c/321573/7 but still got the same failure. Assign it back to Pawel because there will be a vacation in TW starting tomorrow.

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

commit 02baad155bcc05e6bac4034aa7897408dbee5260
Author: shenghao <shenghao@chromium.org>
Date: Wed Jun 08 11:53:06 2016

VEA Test: revert timestamp test

Reverting timestamp unit test in VEA would make the broken VEA tests
pass. I will fix the test in another CL.

BUG= 614925 
TEST=VEA tests pass

Review-Url: https://codereview.chromium.org/2044203003
Cr-Commit-Position: refs/heads/master@{#398521}

[modify] https://crrev.com/02baad155bcc05e6bac4034aa7897408dbee5260/media/gpu/video_encode_accelerator_unittest.cc

M53 is better, but M52 seems to still be failing, lpique@: does your change need to be merged back to 52? Thanks.

lpique@ Can you merge your fix to M52? Thanks.

Sorry, pushed just right now here
https://chromium-review.googlesource.com/#/c/352786/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/d37f8a5033796a5b428741d32f47201b86b0c146

commit d37f8a5033796a5b428741d32f47201b86b0c146
Author: Lloyd Pique <lpique@google.com>
Date: Thu May 26 20:35:18 2016

Fix install_test_resources for directories

The switch to using rsync with a list of paths rather than having a loop
that copied each one individually with rsync introduced an unfortunate
regression. The previous code copied the contents of a directory, the
replacement did not. I thought I had tested that possibility, but a bug
was reported because it was not.

This patch fixes it -- when using --files-from with -a, you also need to
explicitly include -r to get recursive behavior.  This behavior is
documented in the man page.

BUG= chromium:614925 
TEST=Verified contents of media/test/data are copied
TEST=Verified also that individual files are copied
TEST=install_telemetry_dep_resources was not significantly slower

Change-Id: Icc2e49cc994719a463b46768ddeef41a1f6222bf
Reviewed-on: https://chromium-review.googlesource.com/347474
Tested-by: Lloyd Pique <lpique@google.com>
Reviewed-by: Ilja Friedel <ihf@chromium.org>
Commit-Queue: Ilja Friedel <ihf@chromium.org>
Tested-by: Ilja Friedel <ihf@chromium.org>
Commit-Queue: Lloyd Pique <lpique@google.com>
(cherry picked from commit 318ed0eb1dca1ba29bba9790b8fff93b89cc12f5)
Reviewed-on: https://chromium-review.googlesource.com/352786
Reviewed-by: Ilja H. Friedel <ihf@chromium.org>
Tested-by: Ilja H. Friedel <ihf@chromium.org>

[modify] https://crrev.com/d37f8a5033796a5b428741d32f47201b86b0c146/chromeos-base/chromeos-chrome/chromeos-chrome-9999.ebuild

ihf@ -- Thanks!

I just looked, and the test dashboard shows mostly green for 52 and 53

https://wmatrix.googleplex.com/unfiltered?hide_missing=True&tests=video_VideoEncodeAccelerator&releases=52
https://wmatrix.googleplex.com/unfiltered?hide_missing=True&tests=video_VideoDecodeAccelerator&releases=52
https://wmatrix.googleplex.com/unfiltered?hide_missing=True&tests=video_VideoEncodeAccelerator&releases=53
https://wmatrix.googleplex.com/unfiltered?hide_missing=True&tests=video_VideoDecodeAccelerator&releases=53

Closing.

bulk verified