Updated link for repro step 2 [**] in OP:

https://rawgit.com/wolenetz/shaka-player/mse-codec-switching-demo-for-repro-of-crbug-873871/demo/#asset=https://storage.googleapis.com/shaka-demo-assets/angel-one/dash.mpd;lang=en-US;logtoscreen;debug;build=uncompiled

I was able to repro the video decode error. Due to the pattern of repro, it might be associated with chrome/shaka doing initial data fetches of the demo/assets. Or just coincidence.

Regardless, repro adblog for decode error on Google Pixel 2 XL is attached.

Deleted: crbug_873871_google_pixel_2_xl_DECODE_ERROR_adblog 19.1 KB

crbug_873871_google_pixel_2_xl_DECODE_ERROR_adblog 19.1 KB View Download

@#3 I might also be incorrectly assuming it's *video* decode err.

Flickering through white also occurs on Chromebook (v1 Pixel). Same repro steps.

Thanks the Android one might be us not tearing down the codec before the switch. Can you confirm if you saw the flashes on Windows and Mac? I'll try on my windows machine which has h264+vp9 hardware decode too. I suspect sw <=> hw is okay, since that's a similar path to suspend, but when it's hw <==> hw we might be encountering some surprises.

Dan points out that it's currently impossible to do a hw ==> hw transition. Both GVD and MCVD prevent codec switches, so we run through decoder selection again with the hardware decoder blacklisted. So this flickering must be coming from a hw ==> sw transition.

No flashes on windows or mac - I tried again this morning.

Also, with chrome://flags#enable-surfaces-for-videos *DISABLED*, there is no repro of flashing on either my google pixel 2 xl or on my pixel v1 chromebook.

I've updated the demo to include the mime type in the buffering log entries. It'll at least help understand what mime-types are being buffered (though media-internals is necessary to see what's decoded).

cc:mlamouri for white flashes relative to c#8.

The decode error is definitely due to no support for fall-forward. We end up on the vp9 hardware decoder and the reinitialize (with hardware decoder blacklisted) for h264 fails. sandersd@ do you already have a bug filed for adding that support for resolution changes? If not we can file one and leave this for the white frame flash with surface layer.

As discussed it seems fairly simple to add an exception to the blacklist when codec changes occur. Probably the simplest way to do this is to modify the DecoderStreamTraits to save the decoder config (audio already does this). Then during receipt of kConfigChanged save a flag indicator this is a codec change.

=>mlamouri@ for tracking since this one is now just for the white flash on Android/CrOS, but probably happens on any platform with surfaces enabled.

I cannot reproduce this on Linux with the right flags enabled on m71. Can you still repro this issue?

I never saw this on Linux.

It only occurred on android pixel 2 and chromebook pixel (v1) for me previously. With m71 on same android device, no repro. With old m69 (and default enable-surface-layers setting plus (to get changeType API) enable-experimental-web-platform-features enabled), no repro on that chromebook pixel. It may still be lurking, though, since I recall it was hard to get a repro. I tried to repro several times today on each of those two devices (including with m71 enable-surface-layers enabled on my android attempts) with no repro.

So, suspecting that this flashing might have instead been due to a bug in the demo that was fixed after this crbug was filed (https://github.com/wolenetz/shaka-player/commit/41d7ba121cce9f5a90d26c973746c4a7b20d5053), I retried android pixel 2 m71 repro attempts (with enable-surfaces-for-video enabled) against the unfixed demo (https://rawgit.com/wolenetz/shaka-player/f01389b6329a7889a999ad5d9bc6f5fba3fc6274/demo/#asset=https://storage.googleapis.com/shaka-demo-assets/angel-one/dash.mpd;lang=en-US;logtoscreen;debug;build=uncompiled) : no repro

Seems fixed somehow.