Thanks for the report!

Able to repro on Nexus 5X with Android 7.0.

I was able to provoke the "Rats, WebGL hit a snag" with Chrome 53 on my Nexus 5X running Android 7.0, but not Chrome 55. Chrome 55 appears robust.

I'd really appreciate some help from people to get a symbolized stack trace from the GPU process when the crash happens. I don't know how to get this effectively on Android.

Chris, is there a possibility you could help with that?

+folk in the know on this stuff.

Hmm, video doesn't even play for me on N5X Dev. Not sure if I'm holding it wrong or what.

FWIW, you won't be able to use WebGL + fullscreen <video> on Android in the common case (h264, hardware decoded vp8, vp9). This is because we use a SurfaceView for fullscreen that doesn't allow readback for WebGL cases (for a 30% power savings). Fullscreening a <div> around the <video> should work though and put you on the SurfaceTexture path.

Looks like playback triggering broke on 55 Dev:

Failed to execute 'play' on 'HTMLMediaElement': API can only be initiated by a user gesture.

As a quick and dirty workaround I added a tiny "Play" button under the actual player that can be used to trigger playback. I noticed that the player does not go into actual fullscreen on Chrome 55. The action/status bar remains visible.

Furthermore, it does not crash immediately on Chrome 55, but it will crash if you enter/exit fullscreen a couple of times.

Concerning WebGL + fullscreen on <video>, that is good information to know. I want to clarify that we're not using fullscreen on the video tag directly, but on the div that wraps the entire player. In my demo it's the div with "container" as id. This div contains both the (hidden) video tag and the canvas.

i don't have any device capable of running N on my desk.

from the gpu log, the relevant line seems to be:

Offscreen context lost via ARB/EXT_robustness. Reset status = GL_GUILTY_CONTEXT_RESET_KHR

in other words, something that the offscreen context did caused a graphics driver reset => loss of context => EXT_robustness notification to chrome that it happened => chrome decides to exit the gpu process rather than recreate the context, figuring that GL is in an unrecoverable state.

unfortunately, there's nothing that says what caused the reset.  i'll need to pick up something running N to figure that out.

Ah, the reason the video was playing for me in Chrome Dev (55) was that I had already specified "disable gesture requirement for media playback" in about:flags. I thought that was going to be removed a while ago?

Rik, I think you could work around this by initially displaying the video element in the page, and then once the user initiates playback, removing it and swapping in the WebGL-rendered canvas to which the video is drawn. Have you tried that?

I find that the fullscreen button on the bottom right of the player is only a pseudo-fullscreen. The URL bar is still visible.

I was able to provoke a GPU process crash only once with Chrome 55.

I can try to gather a tombstone / logcat / etc. -- could someone point me to instructions to get useful data for this? Will it be symbolized reasonably well just coming off the device, or are more tools needed?

You only get autoplay on m53 (m54?)+ if there's no audio track.

This issue is about the WebGL ("Rats WebGL hit a snag") crash, can we focus on that please?

We're not using auto play to start the video and this issue is not about the fullscreen bar being visible. Furthermore the video tag is always hidden through a CSS rule when a 360 video is being played.

Rik, I'm trying to reproduce the crash on top-of-tree Chromium because it's difficult to debug against anything except tip of tree. Your player doesn't work there without additional command-line flags. I'm also having difficulty reproducing the GPU process crash there, I suspect because your page isn't going down the "true" full-screen path.

We're using the following code to enter fullscreen: https://github.com/jwplayer/jwplayer/blob/master/src/js/view/view.js#L102

It looks like the fullscreen button broke in 55. Our interaction handler receives a PointerEvent but it logs the following error to the console: Failed to execute 'requestFullscreen' on 'Element': API can only be initiated by a user gesture.

My guess is that this has to do with the upcoming autoplay changes, but I'm not sure.
In any case, it shouldn't be too relevant to this report.

watk can repro this on his 5X.  here's what we observed:

- it does seem to happen during full screen transitions most of the time, but not always.  this is interesting, since full screening the div doesn't really do much below the blink layer that we'd expect to matter.  timing changes during the transition, a lot, though.

- we're getting timeouts when waiting for decoded frames to arrive at the front buffer of the android SurfaceTexture (onFrameAvailable).  We're unclear if this is cause, effect, or what, but it tends to happen more around full screen transitions also.

we're going to try a few things:

- see if AndroidVideoDecodeAccelerator is somehow damaging the webgl context either during the texture copy or during an optimization that renders the frames early to texture.  we can turn off one or the other to see if that impacts the repro.

- see if turning off all AVDA updates to the texture (both cases above) causes the repro.  as in, render the first frame normally, but just skip updating the texture later.  We'll still return the VideoFrames to the renderer / WebGL as before, but we just won't try to put the most recently decoded frame into the texture that WebGL is sampling from.

- we can increase the frequency of checks for lost context via the robustness extension.  hopefully, this will narrow down what operation is triggering it.  we're hoping that the previous tests will help us narrow down where to look.

Thanks liberato@ and watk@ for picking this up.

Re: Comment #8

https://sites.google.com/a/google.com/clank/engineering/how-to-debug
ctrl+f "Symbolizing Crashes"

I haven't tried it, though.

on a Nexus 6, we get a GPU process crash, rather than graceful shutdown, in the adreno egl library, called from gpu::gles2::GLES2DecoderImpl::DoRenderbufferStorage .

coming up with a case where this doesn't crash is proving to be challenging.  i've shut off all decoding after ~200 frames, turned off AVDACodecImage::CopyTexImage entirely, and still it crashes.

it's basically an unchanging external texture at this point.  i'm going to turn off the unowned texture thing, to see if that helps, and then try 2D textures.

no effect -- AVDA now allocates 2D picture buffers, fills them with random colors, and stops decoding after 200 frames.  it still crashes.

so, i reverted all of that.  made WMPI::CopyVideoFrameTexture... just do a glTexImage2D(random solid color) to the texture on every call.  the colors show up, but no crash!

okay, so with a little more fiddling, i can make it crash if i remove all of the skia texture copier code except this glFlush: https://cs.chromium.org/chromium/src/media/renderers/skcanvas_video_renderer.cc?rcl=0&l=687

in other words, webgl doesn't touch the video frame at all anymore.

note that putting all of it back in except the glFlush doesn't make it stable; it still crashes.  the point is that it's not related to the decoded frame, or any weirdness happening due to AVDACodecImage during the copy with the webgl context.

So to summarize we're still not sure why it is crashing? Are there any possible workarounds?

i tried a few other things since c#19, but all of it points to a driver bug of some sort.  i haven't found any workaround -- things crash more or less often, but never stop crashing entirely.

We ended up "blocking" our renderer loop for about 500 ms upon entering/exiting fullscreen and on orientation changes. It appears to improve the situation slightly, but WebGL still crashes intermittently.

In the meantime, is there anything else we can do?
I'm not sure who is responsible for writing the GPU drivers on Android, but has this been reported to them? If that's not the case, do you have any pointers on where I should report this?

i'll track down how to file a bug against the gl drivers.

liberato: ping.  Were you able to file a bug? What's the next steps here?

2nd ping, a month later.. hello? This is P1 supposedly, is it wrong? I think this is crashing our users?

> i'll track down how to file a bug against the gl drivers.

Did this bug get filed? If so should we close this or what's the next step?

sorry for the delay.  these replies seem to be routed directly past my inbox to the trash for some reason.

no, i haven't filed the bug.  was spending a little more time on a self contained repro, but got side-tracked and didn't get back to it.

this no longer repros on my 6p, which used to crash intermittently.  it wasn't as bad as the 5x, but it was far from working.  since last time, it's got an android update + whatever's @ToT.

i don't have a 5x in the office.  i'd like to see if the behavior has changed there once it's fully updated.

on my nexus 5x, this also no longer repros @ 7.1.1 nmf26f (security patch on 12/5), chrome 53.0.2785.135.

marking as WAI.