See the two bugs blocked by this for more details on the symptom of this issue.

I was unable to reproduce this with --disable-gpu or --use-gl=swiftshader or --use-gl=swiftshader-webgl

As noted in the other issues it needs a video with the AVC codec, which may change based on many factors, and perhaps it also depends on having an AMD graphics card which reports having support for hardware decoding while when we fall back to SwiftShader this is no longer available?

Either way I am very skeptical that this is a SwiftShader issue. As an OpenGL implementation, it has no direct interaction with video decoding. I suspect  Issue 859946  is more closely related to the root cause. Assigning to sugoi@ for a second assessment.

Interesting. So there is the difference in various feature modes when we fallback to SwiftShader or fallback to no GL. If the bug is not in SwiftShader itself, then one of such mode difference might explain the root cause.

Alexis, I'm closing this assuming you had no other conclusion than #3 ?

Feel free to re-open if there's an good indication of this being a SwiftShader bug.

Hmm I think GMBs are disabled by default on Windows, were you testing with:

--use-gl=swiftshader or --use-gl=swiftshader-webgl _plus_ --enable-gpu-memory-buffer-video-frames and/or --enable-gpu-memory-buffer-compositor-resources

By the way, I checked our feature status for SwiftShader mode and no-GL mode. The only difference is WebGL / WebGL2 are enabled in software for SwiftShader mode, but disabled for no-GL mode. I don't think such difference contributes to the bug here.

@dalecurtis: No, I wasn't testing with GMBs, but if they're required to reproduce the issue then it's definitely not a SwiftShader issue.

I double checked the video GMB logic, and FWICT video GMBs are disabled if GpuInfo says overlays are not supported like in the attached chrome://gpu in the linked bugs.

https://cs.chromium.org/chromium/src/content/renderer/render_thread_impl.cc?rcl=8a26785b1f53840100e4a4005f7440dac4f201ca&l=1346

I also noticed that the reporter for  issue 820643  was using --ignore-gpu-blacklist flag.  The reporter hasn't confirmed that swiftshader is actually running when the video stops working.  But other users on the product forums have also reported the same issue on old ATI cards, and have successfully used the suggested workarounds (--disable-software-rasterizer or --disable-direct-composition).

Another way this bug could happen is if we somehow submit YUVVideoDrawQuads instead of TextureDrawQuads from VideoResourceUpdater to display compositor.  Swiftshader fallback also implies software compositing, and we do not support YUV quads in software compositing.

https://cs.chromium.org/chromium/src/components/viz/service/display/software_renderer.cc?rcl=8a26785b1f53840100e4a4005f7440dac4f201ca&l=293

As to how direct composition is related, it's possible we're crashing more with direct composition, and hitting software compositing fallback more often.  For example, we know that old ATI drivers had issues initializing ID3D11VideoDevice ( issue 800950 ).

I also noticed that GpuVideoDecodeAcceleratorFactory in GPU process uses gpu_preferences.disable_accelerated_video_decode to early out from creating a VDA, but that flag isn't modified when we use swiftshader.  On Windows, that means using DXVAVideoDecodeAccelerator which sets allow_overlay flag to true, and causes overlays to be used with DirectComposition.  I can't say for sure if this happens with swiftshader.