Implemented HEVC video demuxing and parsing

media/base/mime_util.cc

Index: media/base/mime_util.cc
diff --git a/media/base/mime_util.cc b/media/base/mime_util.cc
index bc12773ca7bd1b16d041ce0c29d67b5f0283cec0..1cc28abb8c9c14086e1f8fa285a4a09808d58930 100644
--- a/media/base/mime_util.cc
+++ b/media/base/mime_util.cc
@@ -36,6 +36,7 @@ class MimeUtil {
     H264_BASELINE,
     H264_MAIN,
     H264_HIGH,
+    HEVC_MAIN,

[ddorwin, 2015/06/12 00:52:26]

Is there a reason that "HEVC" is used instead of "H265", which would match
"H264"? It's certainly easier to distinguish, but that's not a good reason.
Should "H264" be "AVC"?

[ddorwin, 2015/06/12 00:52:26]

Are there HEVC profiles other than main? Is that the only flavor that Cast
supports?

[servolk, 2015/06/12 21:57:31]

There are 3 HEVC v1 profiles: main, main10 and main_still_picture, but at the
moment we'll support only the main profile, and other enum values will be added
as part of work on crbug.com/482761.

[servolk, 2015/06/12 21:57:31]

Re this and your other comments on HEVC/H265. As far as I understand HEVC and
H.265 are pretty much synonyms, H.265 may have been used earlier in the codec
development process, but now that it's finalized and standardized more people
are starting to refer to it as HEVC. But  I can see a lot of places and articles
on the internet that refer to it as "H.265/HEVC" (much like "H.264/AVC"). I have
mentioned both intentionally, to make it easier for people to find in source
code, e.g. somebody might be searching for "265", others for "hevc". But if you
insist, I can get rid of that and pick just one (which should probably be HEVC).
Btw, out of curiosity, I can see that there are also ~44 occurences of string
"264" under media/ and ~40 occurences of "avc1" - does that need to be fixed as
well?

     VP8,
     VP9,
     THEORA
@@ -199,6 +200,15 @@ static bool IsCodecSupportedOnAndroid(MimeUtil::Codec codec) {
     case MimeUtil::VORBIS:
       return true;
 
+    case MimeUtil::HEVC_MAIN:
+#if defined(ENABLE_HEVC_DEMUXING)
+      // HEVC/H.265 is supported only in Lollipop+ (API Level 21). According to

[ddorwin, 2015/06/12 00:52:26]

nit: remove "only"
s/. According/ according/

[servolk, 2015/06/12 21:57:31]

Done.

+      // http://developer.android.com/reference/android/media/MediaFormat.html
+      return base::android::BuildInfo::GetInstance()->sdk_int() >= 21;
+#else
+      return false;
+#endif
+
     case MimeUtil::MPEG2_AAC_LC:
     case MimeUtil::MPEG2_AAC_MAIN:
     case MimeUtil::MPEG2_AAC_SSR:
@@ -253,6 +263,11 @@ static const char kMP4VideoCodecsExpression[] =
     // kUnambiguousCodecStringMap/kAmbiguousCodecStringMap should be the only
     // mapping from strings to codecs. See crbug.com/461009.
     "avc1.42E00A,avc1.4D400A,avc1.64000A,"
+#if defined(ENABLE_HEVC_DEMUXING)
+    // Any valid-looking HEVC string will work here, since these strings are
+    // parsed and mapped to MimeUtil::Codec enum values.
+    "hvc1.1.L0.0,"
+#endif
     "mp4a.66,mp4a.67,mp4a.68,mp4a.69,mp4a.6B,mp4a.40.2,mp4a.40.02,mp4a.40.5,"
     "mp4a.40.05,mp4a.40.29";
 
@@ -561,6 +576,26 @@ static bool ParseH264CodecID(const std::string& codec_id,
   return true;
 }
 
+#if defined(ENABLE_HEVC_DEMUXING)
+static bool ParseHEVCCodecID(const std::string& codec_id,
+                             MimeUtil::Codec* codec,
+                             bool* is_ambiguous) {
+  if (StartsWithASCII(codec_id, "hev1.", true) ||
+      StartsWithASCII(codec_id, "hvc1.", true)) {
+    // TODO(servolk): Implement parsing of hevc codec ids as described in
+    // ETSI TS 126 244 standard section A.2.2, but for now allow any
+    // HEVC tiers/profiles and let decoder decide if it can handle that.
+    // crbug.com/482761
+    *codec = MimeUtil::HEVC_MAIN;
+    // Make this false for now to avoid dcheck at line 696
+    *is_ambiguous = false;

[ddorwin, 2015/06/12 00:52:26]

This isn't correct. I know it prevents the DCHECK, but this is not an acceptable
semi-permanent solution because it will result in "probably" when we don't
really know ("maybe") per the comment above. Is there a string we know is always
supported? Otherwise, see my comment above about modifying the DCHECK.

[servolk, 2015/06/12 21:57:31]

Ok, I've added a special case in this method, to ensure we have at least one
unambigous HEVC codec id: "hev1.1.6.L93.B0", which means HEVC main profile,
level 3.1. That is likely to be supported by any HEVC-capable decoder and this
exact string is given as an example in ISO/IEC standard and in DASH-IF docs,
e.g. http://dashif.org/w/2015/04/DASH-IF-IOP-v3.0.pdf. So now we'll use that
special case string in kMP4VideoCodecsExpression without hitting DCHECKs and any
other HEVC codec id is going to be considered ambiguous until complete HEVC
codec id parsing is implemented.

PS: Also added "hvc1.1.6.L93.B0", since that's what I'm using in unit tests.

+    return true;
+  }
+
+  return false;
+}
+#endif
+
 bool MimeUtil::StringToCodec(const std::string& codec_id,
                              Codec* codec,
                              bool* is_ambiguous) const {
@@ -573,8 +608,13 @@ bool MimeUtil::StringToCodec(const std::string& codec_id,
   }
 
   // If |codec_id| is not in |string_to_codec_map_|, then we assume that it is
-  // an H.264 codec ID because currently those are the only ones that can't be
-  // stored in the |string_to_codec_map_| and require parsing.
+  // either H.264 or HEVC/H.265 codec ID because currently those are the only

[ddorwin, 2015/06/12 00:52:26]

ditto on mixing synonyms for the codecs. Also, why does "HEVC/H.265" appear
throughout the CL? Can we pick one? It seems anyone looking at this code would
understand.

[servolk, 2015/06/12 21:57:31]

See above - yes, people would understand, but mentioning both is useful for
finding pieces of code that deal with H.265/HEVC. Plus we seem to be mixing
H.264 and avc1 also.

+  // ones that are not added to the |string_to_codec_map_| and require parsing.
+#if defined(ENABLE_HEVC_DEMUXING)
+  if (ParseHEVCCodecID(codec_id, codec, is_ambiguous)) {

[ddorwin, 2015/06/12 00:52:26]

Note: It seems wrong to check the less common codec first. The enum order is
also the inverse. However, this is simpler to read, especially since the
majority of platforms that do not enable this code.

[servolk, 2015/06/12 21:57:31]

Acknowledged.

+    return true;
+  }
+#endif
   return ParseH264CodecID(codec_id, codec, is_ambiguous);
 }
 
@@ -602,6 +642,7 @@ bool MimeUtil::IsCodecProprietary(Codec codec) const {
     case H264_BASELINE:
     case H264_MAIN:
     case H264_HIGH:
+    case HEVC_MAIN:
       return true;
 
     case PCM: