After trying locally on Eve, I could confirm that video_ChromeVidResChangeHWDecode.h264 passes 100% on 11118.0.0 but starts failing from 11119.0.0. Chromium has been updated from 71.0.3565.0 to 71.0.3567.0 on this version, so the issue is likely to lie somewhere there.

At first I suspected my V4L2VDA refactoring may be the cause, but we can rule it out since (1) the crash also happens on VA-API platforms, and (2) the patch making use of the new V4L2Queue API had not landed in 71.0.3567.0.

Could this be crrev.com/8e249e73fc18350dea393cecc8d344a5a355c1d6?

Confirmed this CL was the cause of these failures. It has already been reverted, but keeping the bug open and transferring to Aka until he lands the follow-up version.

The latest results are happy on all devices. Closed.

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

commit cd5181ecb173efdef4163f066c27bd136fca01d5
Author: Chih-Yu Huang <akahuang@google.com>
Date: Tue Oct 23 06:33:06 2018

Reland "v4l2_SVDA, Vaapi_VDA: Support VP9 show_existing_frame feature.""

This reverts commit e90cd145dd6709ae07f8ac43b29072c01a49d435.

In gpu_video_decoder, |available_pictures_| tracks the number of
picture buffers which are not sent to display.
In DimissPictureBuffer(), we should not decrease the value if the
buffer also at display.

|available_pictures_| is only used at CanReadWithoutStalling() method,
and no one will call this method from GpuVideoDecoder, so we calculate
the value instead of tracking the value to reduce the code complexity.

BUG= 755887 
BUG=890629
BUG= 892514 
TEST=Play some videos at Youtube and check Chrome doesn't crash
TEST=pass video_YouTubeHTML5, video_ChromeVidResChangeHWDecode,
          video_VideoDecodeMemoryUsage, video_VideoSeek autotest

Original change's description:
> v4l2_SVDA, Vaapi_VDA: Support VP9 show_existing_frame feature.
>
> For VP9 video, when the flag "show_existing_frame" is set, the
decoder
> should output the specified reference picture which is decoded
> previously. Originally V4L2 slice VDA and Vaapi VDA didn't handle
this
> situation that the reference picture is sent to client but not
> returned back.
> This CL supports this feature at these two VDA. If the reference
picture
> is sent to client side, then VDA just sends it directly.
>
> BUG= 755887 
> TEST=./video_decode_accelerator_unittest --ozone-platform=gbm
>
--test_video_data=vp90_2_10_show_existing_frame2.vp9.ivf:352:288:16:16:35:150:12
>      on Kevin and Eve device.
> TEST=Run AppRTC on Scarlet successfully
> TEST=Pass media:media_unittests

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: I3db1f5b650a5dec67bf46d439a6eeb4a2f3d995a
Reviewed-on: https://chromium-review.googlesource.com/c/1258787
Commit-Queue: Chih-Yu Huang <akahuang@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#601861}
[modify] https://crrev.com/cd5181ecb173efdef4163f066c27bd136fca01d5/content/renderer/media/webrtc/rtc_video_decoder.cc
[modify] https://crrev.com/cd5181ecb173efdef4163f066c27bd136fca01d5/content/renderer/media/webrtc/rtc_video_decoder.h
[modify] https://crrev.com/cd5181ecb173efdef4163f066c27bd136fca01d5/content/renderer/pepper/pepper_video_decoder_host.cc
[modify] https://crrev.com/cd5181ecb173efdef4163f066c27bd136fca01d5/media/filters/gpu_video_decoder.cc
[modify] https://crrev.com/cd5181ecb173efdef4163f066c27bd136fca01d5/media/filters/gpu_video_decoder.h
[modify] https://crrev.com/cd5181ecb173efdef4163f066c27bd136fca01d5/media/gpu/ipc/service/picture_buffer_manager.cc
[modify] https://crrev.com/cd5181ecb173efdef4163f066c27bd136fca01d5/media/gpu/ipc/service/picture_buffer_manager_unittest.cc
[modify] https://crrev.com/cd5181ecb173efdef4163f066c27bd136fca01d5/media/gpu/v4l2/v4l2_slice_video_decode_accelerator.cc
[modify] https://crrev.com/cd5181ecb173efdef4163f066c27bd136fca01d5/media/gpu/v4l2/v4l2_slice_video_decode_accelerator.h
[modify] https://crrev.com/cd5181ecb173efdef4163f066c27bd136fca01d5/media/gpu/vaapi/vaapi_common.cc
[modify] https://crrev.com/cd5181ecb173efdef4163f066c27bd136fca01d5/media/gpu/vaapi/vaapi_common.h
[modify] https://crrev.com/cd5181ecb173efdef4163f066c27bd136fca01d5/media/gpu/video_decode_accelerator_unittest.cc
[modify] https://crrev.com/cd5181ecb173efdef4163f066c27bd136fca01d5/media/gpu/vp9_decoder.cc
[modify] https://crrev.com/cd5181ecb173efdef4163f066c27bd136fca01d5/media/gpu/vp9_picture.cc
[modify] https://crrev.com/cd5181ecb173efdef4163f066c27bd136fca01d5/media/gpu/vp9_picture.h
[modify] https://crrev.com/cd5181ecb173efdef4163f066c27bd136fca01d5/media/test/data/README.md
[add] https://crrev.com/cd5181ecb173efdef4163f066c27bd136fca01d5/media/test/data/vp90_2_10_show_existing_frame2.vp9.ivf
[add] https://crrev.com/cd5181ecb173efdef4163f066c27bd136fca01d5/media/test/data/vp90_2_10_show_existing_frame2.vp9.ivf.md5
[modify] https://crrev.com/cd5181ecb173efdef4163f066c27bd136fca01d5/media/video/video_decode_accelerator.h