Media: Do not support new codecs with legacy MIME type names.

media/base/mime_util_internal.cc

Index: media/base/mime_util_internal.cc
diff --git a/media/base/mime_util_internal.cc b/media/base/mime_util_internal.cc
index a0ce3c4951698d5f3f101f1d0cb4f866b4ca7ac3..37f6a121317773103cbde0fdaf633721d70e92d0 100644
--- a/media/base/mime_util_internal.cc
+++ b/media/base/mime_util_internal.cc
@@ -41,38 +41,52 @@ struct MediaFormat {
 //   mp4a.40.05  - MPEG-4 HE-AAC v1 (AAC LC + SBR) (leading 0 in aud-oti for
 //                 compatibility)
 //   mp4a.40.29  - MPEG-4 HE-AAC v2 (AAC LC + SBR + PS)
-//
-//   avc1.42E0xx - H.264 Baseline

[ddorwin, 2016/02/25 01:09:47]

These three lines were not necessary before either since the related code was
moved long ago.

-//   avc1.4D40xx - H.264 Main
-//   avc1.6400xx - H.264 High
-static const char kMP4AudioCodecsExpression[] =
-    "mp4a.66,mp4a.67,mp4a.68,mp4a.69,mp4a.6B,mp4a.40.2,mp4a.40.02,mp4a.40.5,"
+#define ORIGINAL_MP4_AUDIO_CODECS                                           \
+  "mp4a.66,mp4a.67,mp4a.68,mp4a.69,mp4a.6B,mp4a.40.2,mp4a.40.02,mp4a.40.5," \

[servolk, 2016/02/25 01:46:06]

Let's clean up those lists a little, while we are at it. Let's remove 
mp4a.40.02 and mp4a.40.05 since they represent the same codecs as the ids
without leading zero in the last element.

[ddorwin, 2016/03/04 01:26:29]

Let's handle that in
https://bugs.chromium.org/p/chromium/issues/detail?id=591869. Added TODO.

+  "mp4a.40.05,mp4a.40.29"
+
 #if BUILDFLAG(ENABLE_AC3_EAC3_AUDIO_DEMUXING)
-    // Only one variant each of ac3 and eac3 codec string is sufficient here,
-    // since these strings are parsed and mapped to MimeUtil::Codec enum values.
-    "ac-3,ec-3,"
+// Only one variant each of ac3 and eac3 codec string is sufficient here,
+// since these strings are parsed and mapped to MimeUtil::Codec enum values.
+#define NEWER_MP4_AUDIO_CODECS ",ac-3,ec-3"
+#else
+#define NEWER_MP4_AUDIO_CODECS
 #endif
-    "mp4a.40.05,mp4a.40.29";
-static const char kMP4VideoCodecsExpression[] =
-    // This is not a complete list of supported avc1 codecs. It is simply used
-    // to register support for the corresponding Codec enum. Instead of using
-    // strings in these three arrays, we should use the Codec enum values.
-    // This will avoid confusion and unnecessary parsing at runtime.
-    // kUnambiguousCodecStringMap/kAmbiguousCodecStringMap should be the only
-    // mapping from strings to codecs. See crbug.com/461009.
-    "avc1.42E00A,avc1.4D400A,avc1.64000A,"
+
+#define MP4_AUDIO_CODECS ORIGINAL_MP4_AUDIO_CODECS NEWER_MP4_AUDIO_CODECS
+
+// This is not a complete list of supported avc1 codecs. It is simply used
+// to register support for the corresponding Codec enum. Instead of using
+// strings in these three arrays, we should use the Codec enum values.
+// This will avoid confusion and unnecessary parsing at runtime.
+// kUnambiguousCodecStringMap/kAmbiguousCodecStringMap should be the only
+// mapping from strings to codecs. See crbug.com/461009.
+#define ORIGINAL_MP4_VIDEO_CODECS "avc1.42E00A,avc1.4D400A,avc1.64000A"

[servolk, 2016/02/25 01:46:06]

Now that all three of these codec ids map to the same value MimeUtil::H264 we
could keep just one of them.

[ddorwin, 2016/03/04 01:26:29]

Done.

+
 #if BUILDFLAG(ENABLE_HEVC_DEMUXING)
-    // Any valid unambiguous HEVC codec id will work here, since these strings
-    // are parsed and mapped to MimeUtil::Codec enum values.
-    "hev1.1.6.L93.B0,"
-#endif
-    "mp4a.66,mp4a.67,mp4a.68,mp4a.69,mp4a.6B,mp4a.40.2,mp4a.40.02,mp4a.40.5,"
-#if BUILDFLAG(ENABLE_AC3_EAC3_AUDIO_DEMUXING)
-    // Only one variant each of ac3 and eac3 codec string is sufficient here,
-    // since these strings are parsed and mapped to MimeUtil::Codec enum values.
-    "ac-3,ec-3,"
+// Any valid unambiguous HEVC codec id will work here, since these strings
+// are parsed and mapped to MimeUtil::Codec enum values.
+#define NEWER_MP4_VIDEO_CODECS ",hev1.1.6.L93.B0,"
+#else
+#define NEWER_MP4_VIDEO_CODECS
 #endif
-    "mp4a.40.05,mp4a.40.29";
+
+#define MP4_VIDEO_CODECS ORIGINAL_MP4_VIDEO_CODECS NEWER_MP4_VIDEO_CODECS
+
+static const char kMP4AudioCodecsExpression[] = MP4_AUDIO_CODECS;
+static const char kXM4AudioCodecsExpression[] = ORIGINAL_MP4_AUDIO_CODECS;
+
+static const char kMP4VideoCodecsExpression[] =
+    MP4_VIDEO_CODECS "," MP4_AUDIO_CODECS;
+static const char kOriginalMp4VideoCodecsExpression[] =

[servolk, 2016/02/25 01:46:06]

Each of k*Expression is only used once, so perhaps it would be easier to use
those expressions directly in the kFormatCodecMappings definition for saving one
level of indirection? Or is there some value in having those declared as
variables?

[ddorwin, 2016/03/04 01:26:29]

These are shorter. Also, this allows us to minimize the scope of the macros.
However, this may be moot if we change the approach.

+    ORIGINAL_MP4_VIDEO_CODECS "," ORIGINAL_MP4_AUDIO_CODECS;
+
+#undef ORIGINAL_MP4_AUDIO_CODECS
+#undef NEWER_MP4_AUDIO_CODECS
+#undef MP4_AUDIO_CODECS
+#undef ORIGINAL_MP4_VIDEO_CODECS
+#undef NEWER_MP4_VIDEO_CODECS
+#undef MP4_VIDEO_CODECS
 #endif  // USE_PROPRIETARY_CODECS
 
 // A list of media types (https://en.wikipedia.org/wiki/Media_type) and
@@ -100,16 +114,17 @@ static const MediaFormat kFormatCodecMappings[] = {
     {"audio/x-mp3", PROPRIETARY, ""},
     {"audio/aac", PROPRIETARY, ""},  // AAC / ADTS
     {"audio/mp4", PROPRIETARY, kMP4AudioCodecsExpression},
-    {"audio/x-m4a", PROPRIETARY, kMP4AudioCodecsExpression},
+    {"audio/x-m4a", PROPRIETARY, kXM4AudioCodecsExpression},
     {"video/mp4", PROPRIETARY, kMP4VideoCodecsExpression},
-    {"video/x-m4v", PROPRIETARY, kMP4VideoCodecsExpression},
+    {"video/x-m4v", PROPRIETARY, kOriginalMp4VideoCodecsExpression},
 #if BUILDFLAG(ENABLE_MSE_MPEG2TS_STREAM_PARSER)
     {"video/mp2t", PROPRIETARY, kMP4VideoCodecsExpression},
 #endif
 #if defined(OS_ANDROID)
     // HTTP Live Streaming (HLS)
-    {"application/x-mpegurl", PROPRIETARY, kMP4VideoCodecsExpression},
-    {"application/vnd.apple.mpegurl", PROPRIETARY, kMP4VideoCodecsExpression}
+    {"application/x-mpegurl", PROPRIETARY, kOriginalMp4VideoCodecsExpression},

[ddorwin, 2016/02/25 01:09:47]

servolk: We don't have tests for the newer codecs, but I don't believe we intend
to support them on the .src=HLS case.

[servolk, 2016/02/25 01:46:06]

Acknowledged. Yes, AFAIK neither HEVC nor AC3/EAC3 are support for Android HLS,
only for Chromecast's.

+    {"application/vnd.apple.mpegurl", PROPRIETARY,
+     kOriginalMp4VideoCodecsExpression}
 #endif
 #endif  // USE_PROPRIETARY_CODECS
 };