Implemented HEVC video demuxing and parsing

build/common.gypi

 # Copyright (c) 2012 The Chromium Authors. All rights reserved.
 # Use of this source code is governed by a BSD-style license that can be
 # found in the LICENSE file.
 
 # IMPORTANT:
 # Please don't directly include this file if you are building via gyp_chromium,
 # since gyp_chromium is automatically forcing its inclusion.
 {
   # Variables expected to be overriden on the GYP command line (-D) or by
   # ~/.gyp/include.gypi.
@@ skipping 1825 matching lines @@
         'ozone_platform_ozonex%': 1,
         'use_playready%': 0,
         'conditions': [
           ['target_arch=="arm"', {
             'arm_arch%': '',
             'arm_tune%': 'cortex-a9',
             'arm_thumb%': 1,
             'video_hole%': 1,
           }],
         ],
+        # HEVC/H265 demuxing support. Note that toggling this flag will enable

[ddorwin, 2015/03/25 01:21:59]

Where is the equivalent GN change?

[servolk, 2015/03/25 02:20:20]

This chunk is inside a conditions section guarded by chromecast==1. Chromecast
doesn't use GN builds and no chromecast specific sections in .gn/.gni files, so
there's no corresponding GN change. I assume if/when chromecast migrates to use
GN builds, we'll copy all the variable definitions from here into some .gn file.

+        # only HEVC demuxing support, it does not imply decoding support (since
+        # HEVC is proprietary and HEVC decoders typically require additional
+        # licensing). Chromecast has hardware HEVC decoder on some platforms.

[ddorwin, 2015/03/25 01:21:59]

Do you have codec detection yet? If not, you cannot enable this by default
because it will cause all platforms to advertise support.

[servolk, 2015/03/25 02:20:20]

No codec detection yet, but again, this is inside chromecast==1 section, so I
believe it should be fine, we are not enabling hevc by default.

[ddorwin, 2015/03/25 18:02:57]

But you ARE enabling it by default for all Chromecast devices. I think that is
wrong. You should remove this line until you have a way to support existing
devices. Also, it probably shouldn't be enabled by default until the profile
strings are worked out.

[servolk, 2015/04/29 23:50:32]

Yes, but that was because the current mechanism of checking which codec is
supported on each platform isn't extensible. Codec choices are essentially
hard-coded in net/base/mime_util.cc and media/filters/stream_parser_factory.cc.
I've created a separate CL to make the mechanism for codec checks extensible by
various embedders, including Clank and Chromecast, see
https://codereview.chromium.org/1054943004/.
We have already merged that CL in Chromecast source tree and I've made sure HEVC
is only enabled only on platforms that actually support it (I can send you links
to internal CLs if you are interested to see how it's going to be used).

+        'defines': ['ENABLE_HEVC_DEMUXING'],
       }],
       ['android_webview_build==1', {
         # When building the WebView in the Android tree, jarjar will remap all
         # the class names, so the JNI generator needs to know this.
         'jni_generator_jarjar_file': '../android_webview/build/jarjar-rules.txt',
       }],
       ['OS=="linux" and target_arch!="mipsel"', {
         'clang%': 1,
       }],  # OS=="mac"
       ['OS=="mac"', {
@@ skipping 4237 matching lines @@
     # settings in target dicts.  SYMROOT is a special case, because many other
     # Xcode variables depend on it, including variables such as
     # PROJECT_DERIVED_FILE_DIR.  When a source group corresponding to something
     # like PROJECT_DERIVED_FILE_DIR is added to a project, in order for the
     # files to appear (when present) in the UI as actual files and not red
     # red "missing file" proxies, the correct path to PROJECT_DERIVED_FILE_DIR,
     # and therefore SYMROOT, needs to be set at the project level.
     'SYMROOT': '<(DEPTH)/xcodebuild',
   },
 }