Thanks for working on this. Before I review this properly, I want to offer some suggestions that will hopefully make it a bit easier to review (and easier to maintain too):

- Please try to keep patches to Chromium as small as possible. There's already a couple that are too big (although not quite as big as this). I rebase the canary branch of Oxide on Chromium daily which normally only takes half an hour or so, but it will almost be a full time job with this patch ;)

- If you need to compile new code in to an existing Chromium target rather than Oxide, please place the code in to an appropriately named directory shared/port (I use something that vaguely matches the Chromium target name) and then just use the patch to modify the gyp file to add the new source files.

- That said, you should only need to compile code in to an existing Chromium component if it requires access to API's that aren't exported (using API's that aren't exported from a component will cause link failures in component builds) or your patch makes other changes to existing code in Chromium that adds a dependency on the new code. There are examples of this in shared/port and qt/core/port.

- MediaWebContentsObserver is just a content::WebContentsObserver - there's no reason to compile this in to patch this in to Chromium at all - it can just be implemented in shared/browser and created by WebView (or maybe WebViewContentsHelper - I need to think about that). content::WebContentsObserver is there so we can get events from RenderViews and RenderFrames without having to modify Chromium. This would avoid making any changes to content::RenderViewHostImpl.

- It doesn't look like BrowserMediaPlayerManager needs to be patched in to Chromium either (nor could it be if MediaWebContentsObserver is implemented in Oxide).

- Does BrowserMediaPlayerManager need to use the media::MediaPlayerManager interface? It looks like that is there to allow media::MediaPlayerAndroid (and media::MediaPlayerBridge) in media/ to talk to the Android implementation of media::MediaPlayerManager in content/, but as we aren't using media::MediaPlayerAndroid it seems unnecessary to implement this interface.

- Similar comments with RendererMediaPlayerManager - it's just a content::RenderFrameObserver. This could be implemented in shared/renderer, and you can use ContentRendererClient::RenderFrameCreated() to create it. This would avoid making changes to content::RenderFrameImpl to add the media_player_manager_ member. You can implement a static method to map from content::RenderFrame to RendererMediaPlayerManager in Oxide that the WebMediaPlayer implementation would use.

- With RendererMediaPlayerManager implemented as a content::RenderFrameObserver in Oxide, WebMediaPlayerOxide would need to move there too. For this, you'd definitely need a small patch which would:
  - Add content::ContentRendererClient::OverrideWebMediaPlayer() that returns a blink::WebMediaPlayer.
  - Modify content::RenderFrameImpl::createMediaPlayer() to call content::ContentRendererClient::OverrideWebMediaPlayer(), falling back to the default if Oxide returns nothing.
We could then implement this in our ContentRendererClient impl in shared/renderer to create the Oxide WebMediaPlayer if support is enabled.

- The change to content::RenderProcessHostImpl::PropagateBrowserCommandLineToRenderer() should be done in our implementation of ContentBrowserClient::AppendExtraCommandLineSwitches() instead.

- New IPC messages can go in shared/common/oxide_messages.h.

I hope that all makes sense :)