Allow WebView to force MediaPlayer for unsupported containers.

content/renderer/render_frame_impl.cc

Index: content/renderer/render_frame_impl.cc
diff --git a/content/renderer/render_frame_impl.cc b/content/renderer/render_frame_impl.cc
index 1218cb618dfc6964dd450fd4c2f544e594c7c667..0d976608a6e68c0e6c543cc91ff1555f4d01ccd6 100644
--- a/content/renderer/render_frame_impl.cc
+++ b/content/renderer/render_frame_impl.cc
@@ -26,6 +26,7 @@
 #include "base/process/process.h"
 #include "base/stl_util.h"
 #include "base/strings/string16.h"
+#include "base/strings/string_split.h"
 #include "base/strings/utf_string_conversions.h"
 #include "base/thread_task_runner_handle.h"
 #include "base/time/time.h"
@@ -768,6 +769,22 @@ bool UseWebMediaPlayerImpl(const GURL& url) {
     return false;
   }
 
+  // Android WebView may allow codecs and containers that Chrome does not.

[ncarter (slow), 2016/03/28 22:30:03]

A command line switch seems like an awkward way to implement AW-specific
treatment of a few extensions. My instinct is that the renderer process ought to
know that it's an AW renderer, so there ought to be a more direct way to query
the AW platform, than to plumb state in via a command line.

Could we add a bool-returning ContentRendererClient method for this instead,
with a default implementation that either just 'return true' or 'return false'?
With a name like ShouldForcePlatformDecoderForPath() or
ShouldDisableUnifiedMediaPipelineForPath()?

(If this command line flag has utility otherwise, feel free to push back on this
suggestion)

[ncarter (slow), 2016/03/28 22:50:07]

Also, I checked with Charlie, who thinks it's a good idea to make this
ContentRendererCient method be #ifdef OS_ANDROID, which gives you more
flexibility in the naming.

[ddorwin, 2016/03/28 22:50:51]

See, for example ShouldUseVideoOverlayForEmbeddedEncryptedVideo(). This ends up
using prefs, which can only be modified by WebView. (I don't think we want that
because all existing users of WebView would be broken, but you could certainly
hook up the WebView logic within RendererMediaPlayerManager or similar.

Long-term, it would be nice for WebView applications, especially browsers, to
not use MP or WMPA just like Chrome. We may want to talk to the WebView team
about exposing this capability to WebView applications (or making it the default
when building against newer versions of the WebView API).

[DaleCurtis, 2016/03/29 00:28:19]

Done. Thanks for the suggestion, it's much cleaner. David: I started that long
term discussion on clank-webview@ and clank-security@ prior to publishing this.
I can't link to it from here though since they are private groups.

The short of it is: WebView doesn't have UMA yet, so we have no idea what the
compatibility risk looks like. It is coming though, so for now we'll forward
everything and then add some UMA to figure out how often these containers are
actually used.

+  const std::string media_player_extension_csv =
+      base::CommandLine::ForCurrentProcess()->GetSwitchValueASCII(
+          switches::kUseMediaPlayerForExtensions);
+  if (!media_player_extension_csv.empty()) {
+    std::vector<std::string> media_player_extensions =
+        base::SplitString(media_player_extension_csv, ",",
+                          base::TRIM_WHITESPACE, base::SPLIT_WANT_NONEMPTY);
+    for (const auto& extension : media_player_extensions) {
+      if (base::EndsWith(url.path(), extension,
+                         base::CompareCase::INSENSITIVE_ASCII)) {
+        return false;
+      }
+    }
+  }
+
   // Otherwise enable WMPI if indicated via experiment or command line.
   return media::IsUnifiedMediaPipelineEnabled();
 }