OS Version:Android 7.0.0;

the same issue to you

Thanks for reporting this. When I try on a Nexus 5x on M61.0.3163.98 there is a long delay (~10 seconds) before the video starts flowing, but then it works well. Is this what you experienced as well, or does the video simply never start?

brandtr@ this might be a duplicate:
https://bugs.chromium.org/p/chromium/issues/detail?id=769622

You are right,I test a few more times,eventually video start after a long delay,but no regular pattern (may be a few minutes or dozens of seconds).
I check log from logcat find the same error as https://bugs.chromium.org/p/chromium/issues/detail?id=769622.

09-29 10:11:58.459 18438 18459 E chromium: [ERROR:gles2_cmd_decoder.cc(15702)] Context lost because SwapBuffers failed.
09-29 10:11:58.459 18438 18459 E chromium: [ERROR:gles2_cmd_decoder.cc(5332)] Error: 5 for Command kSwapBuffers

So I think its the same issue.

My test device is Huawei Honor V8(KNT-AL20) android 7.0
Full log is here:

Deleted: android-chrome-log-20170929.txt 1.3 MB

android-chrome-log-20170929.txt 1.3 MB View Download

Hey spang@,

I found you in the blamelist for gles2_cmd_decoder.cc. Would you mind taking a look here, or assign to the right person? Thanks!

 Issue 769622  has been merged into this issue.

Found a workaround: set "border-radius: 0px" css property of the video tag. I think it changes something in the rendering process.

ps: only stops rendering if there is no debugger attached

workaround: border-radius should be more than 0px, so 1px is fine

 Issue 771819  has been merged into this issue.

Possible culprit CL found by braveyao@ in  crbug.com/771819 :

https://chromium-review.googlesource.com/c/chromium/src/+/545195

See  crbug.com/771819  for text log.

i'll try to repro locally.

i've been able to repro locally.  will see what's up.

seems like the texture for the RHS image is being promoted to overlay when it shouldn't be.  (GLES2DecoderImpl::HandleScheduleOverlayPlayeCHROMIUM => GLSurface::ScheduleOverlayPlane => GLSurfaceOverlay::ScheduleOverlayPlane => AVDACodecImage::ScheduleOverlayPlane).

the frame isn't overlayable, though, and things go wrong.

i'll find where this is happening.

rtc_video_decoder just needs to check a new flag in the Picture, and not set 'allow overlay' if the new flag is set.  that seems to get it working locally, and fits with how gpu_video_decoder does things since my earlier CL.

the underlying issue that the earlier CL should not have changed the interpretation of the existing flag.  this is a bigger change, though, which i'll take up separately.  crbug.com/772167 .

in the interim, i'l put together a CL with the one-line fix to rtc_video_decoder.

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

commit 2a390a83bd4adf0c719584a7a40fcfbf62a09824
Author: liberato@chromium.org <liberato@chromium.org>
Date: Fri Oct 06 14:39:02 2017

Fix WebRTC when using AVDA.

RTCVideoDecoder didn't get updated to support overlay promotion
hints and the "is surface texture" flags.  This causes it to
try to promote video frames from AVDA to overlays.  This doesn't
work at all.

This is a short-term fix to the larger problem of the flags
changing interpretation.  crbug.com/772167 tracks the work to put
the flags back the way they were.

Bug:  769148 
Change-Id: I1d324262ad04144d1d7fb617231c8bca7ce672d3
Reviewed-on: https://chromium-review.googlesource.com/703931
Reviewed-by: Chris Watkins <watk@chromium.org>
Commit-Queue: Frank Liberato <liberato@chromium.org>
Cr-Commit-Position: refs/heads/master@{#507062}
[modify] https://crrev.com/2a390a83bd4adf0c719584a7a40fcfbf62a09824/content/renderer/media/gpu/rtc_video_decoder.cc

requesting merge to M62.  small change, fixes broken stuff in webrtc on clank.  not sure if we're re-spinning a beta before stable, but just in case.

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

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

 Issue 770560  has been merged into this issue.

+RBS, +M52, from 770560 (dup).

Can we write a test to prevent this from happening or regressing?

via unit test, not really.  the problem was a lack of "adding new code", which is very hard to catch via unit test.  i'd rather spend the time removing the new code, and replacing it with something more robust.

now, if there were some end-to-end tests that ran on the bots, then yes, it seems trivial to catch.  i'm not sure what rtc tests run normally.

phoglund@ will know where webrtc bots run. It shows up pretty clearly in videoElement.webkitDecodedFrameCount when run in apprtc using VP8 (but not VP9)

nah... webkitDecodedFrameCount did not help, it still increases even when video is frozen :-/

If it's not crashing like the repro above, then it would have to be some sort of pixel test.

Im not a big fan of those for flakiness, but maybe we can figure out a way to check for sanity with screen shots inside a test that's not likely to fail intermittently. I did something similar to that for testing overlay positioning with DialogOverlayImplPixelTest. We wouldn't necessarily need that particular method of reading pixels (readback from the compositor would be good enough, I think).

Maybe we can "use rtc to display a blue frame" and verify that some vaguely blue thing is on the screen. That would at least catch something like this.

For now, I am approving the fix to be merged into 62 based on Comment 21. Please verify the fix on 3202 after merging it.

i've just done some local testing with the patch applied to 62.  turns out that  crbug.com/772899  starts to show up in the WebRTC case too, since this bug masked that one.

that one is also a simple fix, so i'll include it as well if there are no objections.

in fact, the fix for that one might be sufficient for both, at least in 62.  i'll sort it out and land something by EOD % any objections before then.

i'm going with the "one line fixes both cases" approach for 62.  manually tested out two previously broken webrtc cases, and some non-webrtc src= playback.  everything seems to work / use overlays / not use overlays as expected.

the M62 fix isn't clearly correct for ToT, since the ToT code is a bit more complicated than 62 is.  62's overlay handling is much simpler.  i'll revisit ToT separately, and maybe roll-back the individual ToT patches in favor of this simpler one, if it's still the correct fix there.

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

commit 23634a33affce3a80d53f8aa18f0b2408794389e
Author: liberato@chromium.org <liberato@chromium.org>
Date: Mon Oct 09 20:55:38 2017

[M-62] Fix WebRTC when using AVDA.

RTCVideoDecoder didn't get updated to support overlay promotion
hints and the "is surface texture" flags.  This causes it to
try to promote video frames from AVDA to overlays.  This doesn't
work at all.  This is  crbug.com/769148  .

This CL also fixes a bug caused by receiving promotion feedback
when AVDA is initialized in sync mode (WebRTC), that wasn't visible
due to 769148.  The callbacks for AndroidVideoSurfaceChooser aren't
initialized, but promotion feedback can cause us to call into the
chooser.  That can cause the chooser to try to use one of the
unitialized callbacks.

Since the sync init path doesn't support overlays anyway, we simply
don't request overlay feedback when we use sync init.  This stops
AVDA from setting the unsupported Picture flags (769148), and
prevents it from asking the surface chooser while the chooser
doesn't have any callbacks (772613, 772899).

This is somewhat smaller than the ToT fixes, since the ToT code
has been changed a bit since M62.  It's less clear at ToT that
this simple fix is sufficient.

The ToT changes are here:
https://chromium-review.googlesource.com/703931
https://chromium-review.googlesource.com/706250

Tests on M62 were manual:

 - Clusterfuzz test case from crbug.com/772613 .
 - Test WebRTC url from  crbug.com/669148 
 - Non-WebRTC src= videos, switching between fullscreen and inline
   playback.  Also checked devtools inspection while in fullscreen,
   to be sure that fallback worked.  'dumpsys SurfaceFlinger'
   confirmed that overlays were in use at the correct times.

TBR=watk@chromium.org
NOPRESUBMIT=true
NOTRY=true

Bug:  769148 , 772613,  772899 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I46c0c2c2c10f67a45cf7f72caf6fd59a949e4723
Reviewed-on: https://chromium-review.googlesource.com/707588
Reviewed-by: Frank Liberato <liberato@chromium.org>
Cr-Commit-Position: refs/branch-heads/3202@{#623}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/23634a33affce3a80d53f8aa18f0b2408794389e/media/gpu/android_video_decode_accelerator.cc

Camera screen is getting shown on both video windows, verified in latest M62-62.0.3202.52 on Moto G4 Plus(athene_f)/7.0.0

 Issue 769735  has been merged into this issue.