I separately filed crbug.com/833223 for one of them; video hang up when it becomes background tab and thereafter becomes active tab.

I could reproduce the video hang on elm on 10323.69.0.

Steps:
1. Play a youtube video in chrome.
2. Open a new tab or minimize the chrome.
3. Wait for 13 seconds.

Observed:
Sometimes (>50%) the audio of the youtube video paused. Switch back to the youtube tab. The video hanged and video loading icon was in the center.

I disabled hardware decoder in chrome://flags (Hardware-accelerated video decode) and the issue was gone.

Next step is to check if this issue is related to vpu fw revert.  http://crbug.com/820562 

VPU fw 1.0.8 was reverted in m65 10323.63.0.
In m67, it was reverted in 10530.0.0.

I reproduced the issue on 10323.62.0. So this is not related to vpu fw.

This doesn't seem to happen on other platforms. I tried dru on 10561.0.0 and eve on 10323.67.0.

We need a bisect. I'll test latest M64 first.

I tried 68.10586.0.0 with reverting of revert vpu-fw changes.
The problem still happened.

There was a change related to resolution change that landed on m65 10279.0.0.
https://chromium-review.googlesource.com/c/chromium/src/+/588034

I couldn't reproduce the issue on M64 10176.76.0. M64 was good.

Hiro said 10278 seems good and 10279 is bad. Assigning to him.

I could reproduce the video hang using crosvideo.appspot.com on elm M65 10279.0.0.

Steps:
- Go to crosvideo.appspot.com.
- Choose VP9 DASH 30 FPS. The video will start playing.
- Choose 854x480, 583309 bits/s in Available video tracks.

Observed result:
The video hanged.

Expected:
The video should continue playing.

I could not reproduce the issue on peach pi M65 10323.62.0 using crosvideo.appspot.com or YouTube.

Client requests Flush() and waits for NotifyFlushDone().
This Flush() is coming after Reset(). Reset() will invoke StopInputStream() and StopOutputStream().
Then input stream is off, and the flush dummy buffer is queued but it doesn't return from driver.
I can fix this by executing NotifyFlushDone() in FlushTask() in the case that input_streamon_ is false.

Please add a new test case in VDA unittest for this after fixing the bug. Thanks.

I create the fix CL and hopefully will submit soon.
https://chromium-review.googlesource.com/c/chromium/src/+/1013787

I have to cherry-pick the CL to M65, 66 and 67.

Hi TPMs, may I ask to approve merging following CLs?
M65: https://chromium-review.googlesource.com/c/chromium/src/+/1013803
M66: https://chromium-review.googlesource.com/c/chromium/src/+/1014820
M67: https://chromium-review.googlesource.com/c/chromium/src/+/1013802

Thanks

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

commit f856991a34dcec929bd2a5f01f4f0ec82c3ba5b7
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Tue Apr 17 05:17:54 2018

media/gpu/v4l2vda: Execute NotifyFlushDone for Flush if input stream is off

VDA client can request Flush() after Reset() and waits for NotifyFlushDone().
After FinishReset() is done, input stream becomes off. Even doing V4L2_DEC_CMD_STOP
at this time, the buffer with V4L2_BUF_FLAG_LAST will never be returned from
driver. As a result, NotifyFlushDone() will not be invoked and client waits
permanently.
To avoid this, V4L2VDA is changed as it tries to call NotifyFlushDone if input
stream is off.

BUG=chromium:833223,  chromium:833221 
TEST=Change resolution manually on crosvideo.appspot.com
TEST=VDA unittest on hana
TEST=CtsMediaTestCases on hana

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: I4245bdcee1e537dc7061e7833530ae59fc4aecb7
Reviewed-on: https://chromium-review.googlesource.com/1013787
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Cr-Commit-Position: refs/heads/master@{#551252}
[modify] https://crrev.com/f856991a34dcec929bd2a5f01f4f0ec82c3ba5b7/media/gpu/v4l2/v4l2_video_decode_accelerator.cc

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

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

No more releases planned for M65
Approved for M66, M67 

I see. Then, I am going to merge to M66 and M67.

Thanks.

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

commit f3cfea876e19ed66fafd646785bed602b9077077
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Wed Apr 18 00:34:02 2018

media/gpu/v4l2vda: Execute NotifyFlushDone for Flush if input stream is off

VDA client can request Flush() after Reset() and waits for NotifyFlushDone().
After FinishReset() is done, input stream becomes off. Even doing V4L2_DEC_CMD_STOP
at this time, the buffer with V4L2_BUF_FLAG_LAST will never be returned from
driver. As a result, NotifyFlushDone() will not be invoked and client waits
permanently.
To avoid this, V4L2VDA is changed as it tries to call NotifyFlushDone if input
stream is off.

BUG=chromium:833223,  chromium:833221 
TEST=Change resolution manually on crosvideo.appspot.com
TEST=VDA unittest on hana
TEST=CtsMediaTestCases on hana

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: I4245bdcee1e537dc7061e7833530ae59fc4aecb7
Reviewed-on: https://chromium-review.googlesource.com/1014820
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#734}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/f3cfea876e19ed66fafd646785bed602b9077077/media/gpu/v4l2/v4l2_video_decode_accelerator.cc

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

commit 3527d485c8ddfef1f831907cafac31270251d7f4
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Wed Apr 18 00:33:34 2018

media/gpu/v4l2vda: Execute NotifyFlushDone for Flush if input stream is off

VDA client can request Flush() after Reset() and waits for NotifyFlushDone().
After FinishReset() is done, input stream becomes off. Even doing V4L2_DEC_CMD_STOP
at this time, the buffer with V4L2_BUF_FLAG_LAST will never be returned from
driver. As a result, NotifyFlushDone() will not be invoked and client waits
permanently.
To avoid this, V4L2VDA is changed as it tries to call NotifyFlushDone if input
stream is off.

BUG=chromium:833223,  chromium:833221 
TEST=Change resolution manually on crosvideo.appspot.com
TEST=VDA unittest on hana
TEST=CtsMediaTestCases on hana

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: I4245bdcee1e537dc7061e7833530ae59fc4aecb7
Reviewed-on: https://chromium-review.googlesource.com/1013802
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Cr-Commit-Position: refs/branch-heads/3396@{#67}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/3527d485c8ddfef1f831907cafac31270251d7f4/media/gpu/v4l2/v4l2_video_decode_accelerator.cc

Will verify on 66 and 67 later.

Hiro. Can you help upload a patch for the new test case? Thanks.

Re #26: Working in  crbug.com/833698 

Great. Thanks.

ok, marking this as fixed to get it verified with latest builds 

Let's make sure a test case is added (bvt) to catch this earlier 

hang issue is observed on 10452.69.0, 66.0.3359.117 as per #11 repo steps.

#comment 30, Seems like the cl (crrev.com/c/1014820) was not landed on 10452.69.0 yet. Wait for a few days.

Verified on both M66 and M67.