As I bisect, this issue starts from the following commit.
"media/gpu/v4l2: lazy-assign EGLImages to image processor buffers"
https://chromium-review.googlesource.com/c/chromium/src/+/1288498

I verified reverting this CL on Chrome ToT resolves this issue.
Alex, could you take a look?

By the way, the CL makes the problem serious and always happen. However, even before the CL, sometimes a part of thumbnail is invalid on nyan_big (See attached image). There must be some other issue.

Deleted: thumbnail_corruption2.png 584 KB

	thumbnail_corruption2.png 584 KB View Download

I'm a bit flooded, but will try to take a look later today.

I think the observation of #2 might be fixed by crrev.com/c/1424629. This does not fix the initial problem though, it seems like we have a race condition between EGLImage creation and the buffer being passed to the client.

Also FWIW the issue is still visible on R73 ToT.

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

commit a2062b754caeca0f1ce708b686ee91a0fff2bad4
Author: Alexandre Courbot <acourbot@chromium.org>
Date: Mon Jan 21 07:35:09 2019

media/gpu/v4l2: move picture clearing back to the correct thread

CL crrev.com/c/1391649 changed the thread on which picture clearing
takes place from the child thread to the decode thread. This can result
in a picture being sent before an EGLImage is created for it, since the
later event happens on the child thread and is scheduled before the
picture clearing. Moving picture clearing to the decoder thread removes
any order guarantee that we had before.

Revert this part to what it was before crrev.com/c/1391649 since it
seems to be a typo.

Bug:  917310 
Bug: 920908
Test: VDA passing in debug mode on nyan_big
Change-Id: Ic44c37f6aaa6a966c2f11a5e7363975229ec04a8
Reviewed-on: https://chromium-review.googlesource.com/c/1424629
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#624526}
[modify] https://crrev.com/a2062b754caeca0f1ce708b686ee91a0fff2bad4/media/gpu/v4l2/v4l2_video_decode_accelerator.cc

https://chromium-review.googlesource.com/c/chromium/src/+/1424683 should be the fix for this, PTAL!

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

commit c5ccd039a73e8f7226ae0d5d3848600c99899354
Author: Alexandre Courbot <acourbot@chromium.org>
Date: Mon Jan 21 09:16:56 2019

media/gpu/v4l2: do not start decoding before EGL image is assigned.

CL crrev.com/c/1288498 tried to optimize things a bit by assigning the
EGL image for a new buffer while the decoder started using said buffer.
This works on all platforms but Tegra: when doing so the first frame of
each buffer is a partially-cleared image without any trace of decoding.

What may be happening is that the Tegra EGL or V4L2 library clears the
buffers that are assigned to EGL images. This would explain the observed
behavior since the first frame is likely to get decoded into the buffer
before its EGL image is assigned. This would also explain why subsequent
frames are not affected.

Work this around by making sure that the buffer is not made available
for decoding before it is assigned an EGL image. This was the behavior
before crrev.com/c/1288498, so no performance penalty is introduced.

correct on nyan_big.

Bug: 920908
Test: Checked that H.264 playback on crosvideo.appspot.com was
Change-Id: I3bd79a02c82676b743305d23ac0691be7d67f8a7
Reviewed-on: https://chromium-review.googlesource.com/c/1424683
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Cr-Commit-Position: refs/heads/master@{#624537}
[modify] https://crrev.com/c5ccd039a73e8f7226ae0d5d3848600c99899354/media/gpu/v4l2/v4l2_video_decode_accelerator.cc

Thanks Alex for fixing this so quickly!
Could you verify this on M72 and merge-request to M72?

Thanks!

That wasn't exactly quick. :)

Requesting merge for M72 since the issue was initially reported there.

This bug requires manual review: We are only 7 days from stable.
Please contact the milestone owner if you have questions.
Owners: govind@(Android), kariahda@(iOS), djmm@(ChromeOS), abdulsyed@(Desktop)

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

It turns out the CL#9 breaks playback starts on hana.
Remove Merge-Request labels.

Reproduce step:
1.) Play any video on crosvideo.appspot.com or youtube.com
2.) Push play button on HTML5 Player.
3.) Video player shows loading icon and video playback doesn't start forever.

Could confirm that VDA unittest remains stuck on trying to playback the video on Hana. This is likely due to me overlooking the code path when an image processor is present.

Found the issue, trying the fix on both Hana and Nyan, with import mode enabled/disabled and with rendering on/off to make sure I haven't missed anything. Will take some time to complete the tests.

Fix for Hana has been merged.

djmm, can we have permission to merge these three small CLs into M72? 

https://chromium-review.googlesource.com/c/1424629
https://chromium-review.googlesource.com/c/1424683
https://chromium-review.googlesource.com/c/1428623

Without them Nyan will glitch during video playback as shown in the first post.

This bug requires manual review: We are only 5 days from stable.
Please contact the milestone owner if you have questions.
Owners: govind@(Android), kariahda@(iOS), djmm@(ChromeOS), abdulsyed@(Desktop)

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

Correction: we only need to merge these two:

https://chromium-review.googlesource.com/c/1424683
https://chromium-review.googlesource.com/c/1428623