We'll probably want to make this a WebView setting of some sort so that platform apps can play things like HEVC, AMR, 3gp, etc if they so desire.

we are planning to keep the current media decode path forever?

s/current/non-unified/

If you mean WebMediaPlayerAndroid and associated machinery -- no; not in it's current form. We are planning to expose a more limited MediaPlayer primitive through WMPI though.

This is necessary to support HLS, devices with blacklisted MediaCodec. We can also reuse it to support platform applications that want to play things Chrome does not normally play (HEVC, AMR, etc).

I see. Then what does this proposed new switch do exactly? Sounds to me, nothing you described needs a setting (except maybe for testing), so should not expose anything to apps that embed webview?

We will not automatically be able to detect HEVC/AMR/etc and would not want to in the general case (not web codecs, extra attack surface).

So if you have WebView apps that want non-web codec support, they will (likely) have to request we use MediaPlayer in some manner (or through some means I haven't thought of). 

This switch is just for testing, but I cc'd you as an FYI that we might want something similar for WebView if there are WebView apps out there using codecs Chrome doesn't support. Chrome usage of such codecs is effectively nil.

I have no idea how many apps depends on these codecs though..

If it's big enough to worth adding a setting, then webview probably can't ship unified media pipeline (with web codecs only? what's the word here?) as default for a long time.

* setting can only be added for the next android version, old android versions won't have the setting, so can't enable this ever
* Also we've probably missed the window for N already

I don't know if it's big enough to be worth adding; I don't think it's actually that common (since these pages wouldn't work on the web then), we just don't have numbers on it. Does WebView report UMA and respond to finch experiments? If so we'll get this info in the same way we are for Clank.

In the worst case, we could add automatic fallback for WebView only at the risk of increased attack surface.

> Does WebView report UMA and respond to finch experiments?

Right now, nope and nope :( UMA should be coming *soon* though.

> In the worst case, we could add automatic fallback for WebView only at the risk of increased attack surface.

Might want to keep that in the back pocket when shipping to stable. Webview's beta population is so tiny that it's effectly useless for catching this kind of thing..

M50 will be a soft launch w/ finch, so no problems for WebView M50. 

Hmm, no Finch makes it difficult to get this information ahead of time. How do you do WebView experiments then? We may want a manual x% experiment then after the clank launch.

Adding torne and webview label.

We don't have anything in general.

Webview ramps ups to stable slowly. For the features that I'm responsible for, I always make sure that if there are problems during ramp up, I can disable and go back to the old path easily. Not a great tradeoff.

Okay, we'll at least want to wait until UMA are available before turning this on for WebView. Do you know when that's coming? For whatever version supports UMA, we could add a UMA logging all supported-media extensions:
http://developer.android.com/guide/appendix/media-formats.html

Fallback for files which end with known extensions like .amr, .3ga, .3gp is easy; we just want to make sure we should do that and not secure WebView more strongly by default. I defer to the WebView team on that decision. I think we should if usage rates for non-Chrome codecs are < 1-2%.

We can also let H.263 and H.265 through the unified pipeline since it could be supported by our GpuVideoDecoder infrastructure.

+paulmiller,sgurun for UMA, although details about shipping should move to a private thread

Actually, I'll start a private thread

https://codereview.chromium.org/1824143004 is a CL we can land if we decide that WebView needs to support all system level codecs. Again I boliu@ I defer to your team to determine what you want to do from a security perspective. Is there a place we should start a thread on this?