Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 122 users

Comments by non-members will not trigger notification emails to users who starred this issue.
H.264 WebRTC in Chrome support
Project Member Reported by mflodman@chromium.org, Jun 15 2015 Back to list
Add H.264 support to WebRTC in Chrome, including call setup and RTP payload profile.
 
Cc: juberti@chromium.org
Comment 2 by Deleted ...@, Jun 24 2015
H.264 support for Chrome Canary ? Chromium ? I made some tests with a home-made webrtc app and I didn't see H.264 on SDP packets.
That's why this bug is still open.
Comment 4 by dsun...@gmail.com, Jun 26 2015
When can we expect H.264 to be supported in Chrome WebRTC?
What profiles and resolutions are planned?
Can 1:1 aspect ratio like 1440x1440 be supported?

Comment 5 by lrp...@gmail.com, Jul 1 2015
what's the plan for this issue ? Very interested to see H.264 support in chromium.
Comment 6 by laforge@google.com, Jul 1 2015
Labels: hotlist-trend-0701
Initially we will be supporting OpenH264, which is constrained-baseline only. However, you should be able to use any resolution.

We are aiming to release a version of Chrome with this functionality this year.


Comment 8 by roysj...@gmail.com, Sep 4 2015
What are the plans for Chrome on Android?  Will hardware acceleration be used in place of OpenH264?
Comment 9 by juberti@webrtc.org, Sep 5 2015
Not initially. Most 264 encoders on Android don't work all that well.

Eventually we will support this via a whitelist.
Comment 10 Deleted
Will it be possible to get the H264 encoded stream from USB webcams supporting it directly (I am NOT talking about using a separate encoder)?
Comment 12 by juberti@webrtc.org, Sep 13 2015
Not initially. We will first focus on software encoder, then built-in HW encoders. 
Comment 13 by open...@yeah.net, Sep 16 2015
hi ,will this be in webrtc android demo app ?
This issue is regarding H.264 support in Chrome. H.264 already works in the webrtc libs for Android and iOS (when the phone has a HW encoder).
Comment 15 by open...@yeah.net, Sep 17 2015
thanks sir,i mean openh264 support in android webrtc, will this available ? as most android phone has poor support for h264 HW encoder, software solution maybe a good choice. 
Good question, but out of scope for this bug. Please file a new bug in the webrtc tracker for this.
Comment 17 by Deleted ...@, Sep 21 2015
While videoconf is certainly the dominating use case for webrtc, it's also very valuable in other domains. e.g. streaming low latency video from ip cameras. those are mostly h264 producers. for these cases just having hw decode alone would be great..encode could still be software if hw encoder are buggy. additionally openh264 is currently only constrained baseline while most real-time h264 content is main/high profile. 
Is this likely to get into 48 under a command line switch. Motivation for early access for testing is to be able to work on compatibility testing with Edge as they release their H.264 compatible (non H.264-UC) codec, which is purportedly pre- Christmas.     
yes, hopefully this will show up in canary in the next few weeks
Project Member Comment 20 by bugdroid1@chromium.org, Oct 13 2015
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e409ed4bb768e07371b5e4ebcf107c023796ac57

commit e409ed4bb768e07371b5e4ebcf107c023796ac57
Author: hbos <hbos@chromium.org>
Date: Tue Oct 13 16:27:40 2015

openh264_unittests empty dummy test added.

This will enable trybots to run this new test binary (openh264_unittests) for a future CL that adds actual test code and more to it.
In the follow-up CL OpenH264 will be pulled in (adding third_party/openh264/src) and build files and test code will be added. That CL needs the trybots to run its test code.

BUG=500605

Review URL: https://codereview.chromium.org/1394983003

Cr-Commit-Position: refs/heads/master@{#353769}

[modify] http://crrev.com/e409ed4bb768e07371b5e4ebcf107c023796ac57/BUILD.gn
[modify] http://crrev.com/e409ed4bb768e07371b5e4ebcf107c023796ac57/build/all.gyp
[modify] http://crrev.com/e409ed4bb768e07371b5e4ebcf107c023796ac57/build/gn_migration.gypi
[add] http://crrev.com/e409ed4bb768e07371b5e4ebcf107c023796ac57/third_party/openh264/DEPS
[add] http://crrev.com/e409ed4bb768e07371b5e4ebcf107c023796ac57/third_party/openh264/LICENSE
[add] http://crrev.com/e409ed4bb768e07371b5e4ebcf107c023796ac57/third_party/openh264/OWNERS
[add] http://crrev.com/e409ed4bb768e07371b5e4ebcf107c023796ac57/third_party/openh264/README.chromium
[add] http://crrev.com/e409ed4bb768e07371b5e4ebcf107c023796ac57/third_party/openh264/tests/BUILD.gn
[add] http://crrev.com/e409ed4bb768e07371b5e4ebcf107c023796ac57/third_party/openh264/tests/openh264_unittests.cc
[add] http://crrev.com/e409ed4bb768e07371b5e4ebcf107c023796ac57/third_party/openh264/tests/openh264_unittests.gyp

Comment 21 by hbos@chromium.org, Oct 15 2015
Blocking: chromium:543540
Comment 22 by hta@google.com, Oct 15 2015
Blockedon: chromium:543540
Could you please clarify what are the patent/license issues associated with the use of H264? Are you going to include the source code from the openh264 Cisco repository directly or will you make use of the h264 binary-only module at run time? If the former case is true, will Cisco cover license fees if one builds the native webrtc library with h264 (enabled by default?) and distributes it in his/her product? I am basing my question on what is written at http://www.openh264.org/faq.html:

"Q: If I use the source code in my product, and then distribute that product on my own, will Cisco cover the MPEG LA licensing fees which I'd otherwise have to pay?
A: No. Cisco is only covering the licensing fees for its own binary module, and products or projects that utilize it must download it at the time the product or project is installed on the user's computer or device. Cisco will not be liable for any licensing fees incurred by other parties. "
Comment 24 by juberti@webrtc.org, Oct 19 2015
We are going to reference the source code from the OpenH264 repo; we will not be using the binary-only module. This will be off by default and will require explicit build-time configuration to enable.

Licensing fees will be the responsibility of the application if they choose to use the OpenH264 code.
Project Member Comment 25 by bugdroid1@chromium.org, Nov 13 2015
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dc28e3ffd89faa7cf1a38ca63084685186534108

commit dc28e3ffd89faa7cf1a38ca63084685186534108
Author: hbos <hbos@chromium.org>
Date: Fri Nov 13 14:43:51 2015

Preparation work for third_party/openh264 build-from-src CL

This CL reverts the parts of https://codereview.chromium.org/1394983003/ that added dummy unittest binaries for openh264.
This was decided to be a bad move (overhead of binaries, only wanting the tests if flag is set). The unittests will be placed and implemented in content_unittests instead in a follow-up CL.

This CL also pulls in openh264/src source code. The building of this and test code will be added in a follow-up CL.

BUG=500605, 468365

Review URL: https://codereview.chromium.org/1438553002

Cr-Commit-Position: refs/heads/master@{#359548}

[modify] http://crrev.com/dc28e3ffd89faa7cf1a38ca63084685186534108/.gitignore
[modify] http://crrev.com/dc28e3ffd89faa7cf1a38ca63084685186534108/BUILD.gn
[modify] http://crrev.com/dc28e3ffd89faa7cf1a38ca63084685186534108/DEPS
[modify] http://crrev.com/dc28e3ffd89faa7cf1a38ca63084685186534108/build/all.gyp
[modify] http://crrev.com/dc28e3ffd89faa7cf1a38ca63084685186534108/build/gn_migration.gypi
[delete] http://crrev.com/c1f1f87d6a7b38b02ea9ef755561651c52c01990/third_party/openh264/LICENSE
[modify] http://crrev.com/dc28e3ffd89faa7cf1a38ca63084685186534108/third_party/openh264/OWNERS
[modify] http://crrev.com/dc28e3ffd89faa7cf1a38ca63084685186534108/third_party/openh264/README.chromium
[delete] http://crrev.com/c1f1f87d6a7b38b02ea9ef755561651c52c01990/third_party/openh264/tests/BUILD.gn
[delete] http://crrev.com/c1f1f87d6a7b38b02ea9ef755561651c52c01990/third_party/openh264/tests/openh264_unittests.cc
[delete] http://crrev.com/c1f1f87d6a7b38b02ea9ef755561651c52c01990/third_party/openh264/tests/openh264_unittests.gyp
[modify] http://crrev.com/dc28e3ffd89faa7cf1a38ca63084685186534108/tools/checklicenses/checklicenses.py

Comment 26 by brian@highfive.com, Nov 17 2015
@juberti can you elaborate on what you mean in #24?  Will chrome not be leveraging the openh264 binary from cisco in a similar way to firefox?

What do you mean by "Licensing fees will be the responsibility of the application if they choose to use the OpenH264 code."?  Does a 'webpage' count as an application there?  Basically...what does chrome's method of leveraging openh264 mean for people who want to write a webapp that uses it? (with regards to licensing)
Comment 27 by juberti@google.com, Nov 18 2015
Chrome will not leverage the h.264 binary from Cisco; this represents a complexity that we would rather avoid.

Web pages and anything else running inside Chrome do not need to worry about licensing on the client, it will be handled by Chrome. However, anything compiling openh264 sources directly will need to deal with the licensing implications.
Comment 28 by e...@younow.com, Dec 4 2015
@juberti, first of all congrats for VP9 getting into the beta channel. Exciting stuff. Any prediction on when you think H.264 is going to become available in the beta channel? Chrome 49 perhaps?
yes, M49 is the target
Project Member Comment 30 by bugdroid1@chromium.org, Dec 7 2015
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/17a7b4a2959f7b65f764fffcdb7b39e276f040b7

commit 17a7b4a2959f7b65f764fffcdb7b39e276f040b7
Author: hbos <hbos@chromium.org>
Date: Mon Dec 07 10:49:45 2015

Adding third_party/openh264 build files for encoding (but not decoding).

Adds GYP and GN build files. Only building C++ code. Architecture-specific assembly code will be added in follow-up CL(s).

(This is a reupload of https://codereview.chromium.org/1403893007/ after having split it up into pieces and removed decoding and tests).

BUG=500605, 468365

Review URL: https://codereview.chromium.org/1446453004

Cr-Commit-Position: refs/heads/master@{#363443}

[modify] http://crrev.com/17a7b4a2959f7b65f764fffcdb7b39e276f040b7/.gn
[modify] http://crrev.com/17a7b4a2959f7b65f764fffcdb7b39e276f040b7/BUILD.gn
[modify] http://crrev.com/17a7b4a2959f7b65f764fffcdb7b39e276f040b7/build/all.gyp
[modify] http://crrev.com/17a7b4a2959f7b65f764fffcdb7b39e276f040b7/build/gn_migration.gypi
[add] http://crrev.com/17a7b4a2959f7b65f764fffcdb7b39e276f040b7/third_party/openh264/BUILD.gn
[delete] http://crrev.com/511c5db753ff5f6e099b182fb7bfc713f4ffabce/third_party/openh264/DEPS
[add] http://crrev.com/17a7b4a2959f7b65f764fffcdb7b39e276f040b7/third_party/openh264/openh264.gyp
[add] http://crrev.com/17a7b4a2959f7b65f764fffcdb7b39e276f040b7/third_party/openh264/openh264.gypi
[add] http://crrev.com/17a7b4a2959f7b65f764fffcdb7b39e276f040b7/third_party/openh264/openh264_args.gni
[add] http://crrev.com/17a7b4a2959f7b65f764fffcdb7b39e276f040b7/third_party/openh264/openh264_args.gypi

@juberti: Will the release targeting M49 support both encoding and decoding
of h.264 streams over webrtc?
Comment 32 by hbos@chromium.org, Dec 7 2015
When you get encoding you'll also get decoding (hard to test one without the other). Behind a flag in M49 if all goes as planned.
Comment 33 by Deleted ...@, Dec 22 2015
@hbos Which flag is this in current canary? Did this get merged in M49?
Comment 34 by hbos@chromium.org, Jan 4 2016
@steinbrecker.johann: Sorry for the late response, I've been on vacation. It will likely be delayed to M50 behind a flag though, I'll write an update at the M49 branch cut next week, but the feature freeze has already passed and decoder/sdp parts are still being worked on.
Comment 35 Deleted
Will FEC be supported with H.264 in chrome (assume chrome peers on both ends)?
Comment 37 by hbos@chromium.org, Jan 7 2016
@andj2223: I believe our FEC is not dependent on which codec is used. I could be wrong though.
Project Member Comment 38 by bugdroid1@chromium.org, Jan 8 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2df474a40afd6976066d61f84040b3ada302949a

commit 2df474a40afd6976066d61f84040b3ada302949a
Author: hbos <hbos@chromium.org>
Date: Fri Jan 08 09:23:35 2016

Updating third_party/openh264 build files.

Changes necessary for it to compile (ignoring appropriate warnings) after I'm guessing somebody changed the default build flags (added -Wall etc).

BUG=500605, 468365

Review URL: https://codereview.chromium.org/1567903003

Cr-Commit-Position: refs/heads/master@{#368302}

[modify] http://crrev.com/2df474a40afd6976066d61f84040b3ada302949a/third_party/openh264/BUILD.gn
[modify] http://crrev.com/2df474a40afd6976066d61f84040b3ada302949a/third_party/openh264/openh264.gyp

@hbos will this be behind a flag even when it hits stable, or just while it's in the canary phase? do you know what the criteria will be for removing the flag and having this be on by default?
Comment 40 by hbos@chromium.org, Jan 11 2016
@brian: The feature will go through all phases like normal, meaning the flag will be there in stable as well. It will be removed once we are confident it is working correctly and compatibly.
Can someone confirm whether the Chrome binary will be built with H.264 enabled?  Is the flag mentioned a build or runtime flag?

Justin mentioned in October "This will be off by default and will require explicit build-time configuration to enable", but the latest comments sound like this may have changed and Chrome will be built with this enabled now.    

Any clarification much appreciated.  Thanks
Here is the situation from what I understand:


H.264 will be excluded by default in Chromium builds, but Chrome builds will include it.
In Chrome the codec will be behind a runtime flag until it's fully tested and working correctly.

Any application using Chromium code can decide to enable the h.264 code and pay the licensing fees if it does.

Web applications are not responsible for licensing fees since that's handled by the vendor who is distributing the binary containing the h.264 implementation (Google distributing Chrome, or Cisco distributing the openh264 plugin in Firefox).
Comment 43 by juberti@google.com, Jan 14 2016
The summary in #42 is correct. Android/iOS apps using the standalone webrtc stack fall into the same bucket as Chromium (off by default).
Comment 44 by hbos@chromium.org, Jan 14 2016
Correct.

We have the H264 feature working locally (with few exceptions) but we missed the M49 cut, there are still reviews, testing and other TODOs to be addressed. I would be very surprised if this is not in M50 behind a flag.
Comment 45 by dsun...@gmail.com, Jan 19 2016
Does this mean that apps based on WebView using H.264 in WebRTC will need to pay the licensing fees?
Depends where the webview comes from. If you're using the system one, no. If you're distributing your own webview compiled from source (not allowed on iOS) then yes.
Be careful that some mobile app frameworks do bundle their own custom webview.
Comment 47 by hbos@chromium.org, Jan 27 2016
"The following revision refers to this bug:" (forgot to put chromium: in front of the bug number so it didn't auto-generate a message like this)
  https://chromium.googlesource.com/external/webrtc/+/bab934bffe5c4b7e5cd6e8fee2c9c2682002d59b

Landed H.264 video codec support using OpenH264/FFmpeg in WebRTC (follow-up CL needed to have it working in Chromium).
Is there a problem using the openh264 decoder? What were the reasons to choose the ffmpeg decoder instead? 
Are there plans, or work in progress to enable the openh264 decoder as well, or to have config, or compile options to choose which decoder to use - openh264, ffmpeg, HW, or something else? 
Comment 49 by hbos@chromium.org, Jan 29 2016
We already use FFmpeg in Chrome for decoding and have done so for a long time, meaning it is better tested, have gone through security reviews, and doesn't increase the binary size as much. There are no plans to enable an OpenH264 decoder given FFmpeg, or to have a config like you speak of. If you're interested in OpenH264 decoding you can look at earlier patch sets of the CL that landed (https://codereview.webrtc.org/1306813009), the decoder in patch set 16 still used OpenH264 (https://codereview.webrtc.org/1306813009/diff/470001/webrtc/modules/video_coding/codecs/h264/h264_decoder_impl.cc).
If Chrome will use ffmpeg for H264 decoding, does it mean Chrome could handle main or even high profile for only receiving and decoding video ? 
(Suppose we could put such non-baseline profile video into WebRTC and stream to Chrome)
Comment 51 by andj2...@gmail.com, Jan 29 2016
I assume google's webrtc can support H264 decoding on iOS using the HW decoder so ffmpeg support there isn't important?
Does HW decoded H264 on iOS still work ok with FEC? I assume FEC is fairly codec agnostic as you mentioned before but I just wanted to double check.
Comment 52 by hta@chromium.org, Jan 29 2016
If a sender wants to use high or main profile in WebRTC, it must negotiate it successfully using SetLocalDescription / SetRemoteDescription.

We have not tested such negotiation with a high profile sender, so it's unlikely to work straight off. If you want to encourage implementing and testing reception of high profile, please file a separate bug for that.

Comment 53 by hbos@chromium.org, Jan 29 2016
#51: I don't really know anything about FEC to be honest, I would assume so. It turns out FFmpeg does not work with iOS and Android, so we'll have to rely on native/hw support from the phone.
Comment 54 by andj2...@gmail.com, Jan 30 2016
Yes, the HW decoders are not known to be as resilient to packet loss as the software ones (e.g. long dropouts on the HW decocders vs. few missed frames on the software ones), and given FFmpeg won't be available on ios/android, this is why I ask about FEC. Is there anyone that does know about FEC that could chime in? Thanks.
Comment 55 by juberti@webrtc.org, Jan 30 2016
FEC is codec-agnostic. Any FEC is stripped and any packets repaired before the 264 bitstream hits the decoder.

Regarding high profile... please try it and let us know how it goes :-)
I compiled chromium with rtc_use_h264=1 use_openh264=1 , what's the runtime flag to enable now, as I cannot make h264 work yet?
Comment 57 by brian@highfive.com, Jan 30 2016
#56: I don't think the chrome flag is implemented yet.  I've set rtc_use_h264=1 and ffmpeg_branding=Chrome (in third_party/ffmpeg/ffmpeg.gyp) and gotten h264 enabled.  I haven't touched use_openh264, actually...@hbos is that still required for something? Or something vestigial?
I have set rtc_use_h264=1, ffmpeg_branding=Chrome and eventually use_openh264. This is the log when trying to decode the h264 incoming stream:
[1:21:0131/002312:ERROR:h264_decoder_impl.cc(226)] FFmpeg H.264 decoder not found.
Any idea?

Comment 59 by hbos@chromium.org, Feb 1 2016
rtc_use_h264 and ffmpeg_branding=Chrome is currently enough to enable it, but we will put it behind a runtime flag before we ship it (make rtc_use_h264=1 default in Chrome), and then remove that flag once we are confident H264 is working well.

use_openh264 is not needed anymore, all it does is make OpenH264 part of "All" targets in Chromium repo. (Still useful for testing compilation on the Chromium trybots.)

@sanmrtn96: Yes, you are more than likely getting that error because FFmpeg has not been initialized before WebRTC decoder code runs. You need something like this (which has not landed yet as I'm writing this): https://codereview.chromium.org/1641163002/. (You get the same error if ffmpeg_branding is something which does not incldue H264, but "Chrome" does.)
@hbos i tried filing a bug for this, but the bug submission page keeps giving me an error.  I'm running into a problem trying this on mac due to sem_open having insufficient permissions in the sandbox.  It works if I run with  --no-sandbox but not without it.

Repro steps:
1. Build chromium with h264 (rtc_use_h264=1) and ffmpeg (ffmpeg_branding=Chrome)
2. On a mac, join a webrtc conference that will use h264 (I did apprtc after commenting out support for vp8 & vp9 in source/talk/media/webrtc/webrtcvideoengine2.cc).  Make sure you are on a machine that will do multi-threaded slice encoding (has high enough quality/good enough cpu to have NumberOfThreads in third_party/webrtc/modules/video_coding/codecs/h264/h264_encoder_impl.cc return > 1.

Description: 
OpenH264 thread will exit due to not being able to wait on the semaphore.  This is because the semaphore was never created (via sem_open) due to having insufficient permissions.  If you pass "--no-sandbox" to chrome when starting it, it will work correctly.

OpenH264 error message: 
[OpenH264] this = 0x0x7ff2ed208020, Warning:[MT] CodingSliceThreadProc(), waiting pReadySliceCodingEvent[0] failed(-1) and thread0 terminated!

(Note: the above message is from the thread exiting when it tries to wait on the semaphore, however the reason it fails is because the semaphore was never initialized correctly.  This happens in WELS_THREAD_ERROR_CODE    WelsEventOpen (WELS_EVENT* p_event, const char* event_name) in openh264/src/codec/common/src/WelsThreadLib.cpp
Comment 61 Deleted
@hbos we found another workaround (fix?).  The diff pasted below will fix the semaphore issue.

diff --git a/content/renderer/renderer.sb b/content/renderer/renderer.sb
index 7e07985..c334196 100644
--- a/content/renderer/renderer.sb
+++ b/content/renderer/renderer.sb
@@ -40,3 +40,5 @@
     (literal "/usr/lib/libcurl.4.dylib")
     (literal "/usr/lib/libCoreStorage.dylib")
     (literal "/usr/lib/libutil.dylib")))
+
+(allow ipc-posix-sem)
Project Member Comment 63 by bugdroid1@chromium.org, Feb 2 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/c5a39c25919191cec1b838a7e83ac028bb2e9d85

commit c5a39c25919191cec1b838a7e83ac028bb2e9d85
Author: hbos <hbos@webrtc.org>
Date: Tue Feb 02 10:26:05 2016

H264: Thread-safe InitializeFFmpeg. Flag to control if InitializeFFmpeg should be called.

New flag: rtc_initialize_ffmpeg, default value = !build_with_chromium.

In WebRTC standalone we initialize FFmpeg by default, in Chromium we don't by default.
Chromium is an external project that also use FFmpeg. If both projects do FFmpeg initialization code things will break. The flag makes it possible for other external projects than chromium to decide whether or not WebRTC should initialize FFmpeg.

BUG=chromium:500605, chromium:468365, webrtc:5427

Review URL: https://codereview.webrtc.org/1639273002

Cr-Commit-Position: refs/heads/master@{#11456}

[modify] http://crrev.com/c5a39c25919191cec1b838a7e83ac028bb2e9d85/webrtc/build/common.gypi
[modify] http://crrev.com/c5a39c25919191cec1b838a7e83ac028bb2e9d85/webrtc/build/webrtc.gni
[modify] http://crrev.com/c5a39c25919191cec1b838a7e83ac028bb2e9d85/webrtc/modules/video_coding/BUILD.gn
[modify] http://crrev.com/c5a39c25919191cec1b838a7e83ac028bb2e9d85/webrtc/modules/video_coding/codecs/h264/h264.gypi
[modify] http://crrev.com/c5a39c25919191cec1b838a7e83ac028bb2e9d85/webrtc/modules/video_coding/codecs/h264/h264_decoder_impl.cc

Cc: sprang@chromium.org
Project Member Comment 65 by bugdroid1@chromium.org, Feb 2 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a10beae0043353c3215c3350ad877ff6689b5456

commit a10beae0043353c3215c3350ad877ff6689b5456
Author: hbos <hbos@chromium.org>
Date: Tue Feb 02 16:11:41 2016

WebRtcBrowserTest.RunsAudioVideoWebRTCCallInTwoTabs now has a VP8 and a VP9 version.
After this CL, we will easily be able to test H264 as well (when that CL lands).

WebRtcTestBase::NegotiateCall and friends get a new optional parameter to specify video_codec.

The javascript changes making this possible:
peerconnection.js/createLocalOffer: Ability to specify video codec by modifying the offer SDP string.
peerconnection.js/receiveOfferFromPeer: Verifying that the SDP answer string uses the desired codec.
All SDP helper functions in new file munge_sdp.js.

This should make it easy to add different codecs to the chrome_webrtc_perf_browsertest.cc and chrome_webrtc_video_quality_browsertest.cc tests in follow-up CLs.

BUG=chromium:500605, chromium:468365

Review URL: https://codereview.chromium.org/1645043004

Cr-Commit-Position: refs/heads/master@{#372953}

[modify] http://crrev.com/a10beae0043353c3215c3350ad877ff6689b5456/chrome/browser/media/chrome_webrtc_browsertest.cc
[modify] http://crrev.com/a10beae0043353c3215c3350ad877ff6689b5456/chrome/browser/media/webrtc_browsertest_base.cc
[modify] http://crrev.com/a10beae0043353c3215c3350ad877ff6689b5456/chrome/browser/media/webrtc_browsertest_base.h
[add] http://crrev.com/a10beae0043353c3215c3350ad877ff6689b5456/chrome/test/data/webrtc/munge_sdp.js
[modify] http://crrev.com/a10beae0043353c3215c3350ad877ff6689b5456/chrome/test/data/webrtc/peerconnection.js
[modify] http://crrev.com/a10beae0043353c3215c3350ad877ff6689b5456/chrome/test/data/webrtc/test_functions.js
[modify] http://crrev.com/a10beae0043353c3215c3350ad877ff6689b5456/chrome/test/data/webrtc/webrtc_audio_quality_test.html
[modify] http://crrev.com/a10beae0043353c3215c3350ad877ff6689b5456/chrome/test/data/webrtc/webrtc_jsep01_test.html
[modify] http://crrev.com/a10beae0043353c3215c3350ad877ff6689b5456/chrome/test/data/webrtc/webrtc_video_quality_test.html

Comment 66 by hbos@chromium.org, Feb 2 2016
Blockedon: chromium:583348
Comment 67 by hbos@chromium.org, Feb 2 2016
@brian: Thanks! I filed a bug for you (crbug.com/583348), will take a look at it when higher priority H264 stuff has landed. For now: not supported in sandbox.
Project Member Comment 68 by bugdroid1@chromium.org, Feb 3 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/9dc5928eb2b7653049b1c405485ca4351df28fbc

commit 9dc5928eb2b7653049b1c405485ca4351df28fbc
Author: hbos <hbos@webrtc.org>
Date: Wed Feb 03 13:09:37 2016

Ability to disable the effects of |rtc_use_h264| with DisableRtcUseH264.
Renamed the WEBRTC_THIRD_PARTY_H264 macro to WEBRTC_USE_H264 to match flag name.

The idea is to be able to turn off H264 from chromium with this function because...
1) The Chromium trybots will soon use this flag, we want to temporarily disable H264 from chromium even if flag is set in case something is broken. That way when we are ready to flip the switch the trybots will run our test code then and not after it is already enabled.
2) If feature is launched and we discover major problems we can easily disable H264 and merge with beta/stable.
3) Or, if feature is behind a *runtime* flag, this is how we would control if it is used or not.

The idea is to call DisableRtcUseH264 in chromium's PeerConnectionDependencyFactory.

BUG=chromium:500605, chromium:468365
NOTRY=True
NOPRESUBMIT=True

Review URL: https://codereview.webrtc.org/1657273002

Cr-Commit-Position: refs/heads/master@{#11474}

[modify] http://crrev.com/9dc5928eb2b7653049b1c405485ca4351df28fbc/webrtc/modules/video_coding/BUILD.gn
[modify] http://crrev.com/9dc5928eb2b7653049b1c405485ca4351df28fbc/webrtc/modules/video_coding/codecs/h264/h264.cc
[modify] http://crrev.com/9dc5928eb2b7653049b1c405485ca4351df28fbc/webrtc/modules/video_coding/codecs/h264/h264.gypi
[modify] http://crrev.com/9dc5928eb2b7653049b1c405485ca4351df28fbc/webrtc/modules/video_coding/codecs/h264/include/h264.h

@hbos not sure if this is known, but running into some h264 decode problems on mac.  Filed a bug here https://code.google.com/p/chromium/issues/detail?id=583704&thanks=583704&ts=1454519330
Project Member Comment 70 by bugdroid1@chromium.org, Feb 5 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/900f97534b8ce5de579f80f332cf674d78ac1679

commit 900f97534b8ce5de579f80f332cf674d78ac1679
Author: hbos <hbos@webrtc.org>
Date: Fri Feb 05 16:08:34 2016

H264: Improve FFmpeg decoder performance by using I420BufferPool.

Had to update I420BufferPool to allow zero-initializing buffers.

BUG=chromium:500605, chromium:468365, webrtc:5428

Review URL: https://codereview.webrtc.org/1645543003

Cr-Commit-Position: refs/heads/master@{#11505}

[modify] http://crrev.com/900f97534b8ce5de579f80f332cf674d78ac1679/webrtc/common_video/BUILD.gn
[modify] http://crrev.com/900f97534b8ce5de579f80f332cf674d78ac1679/webrtc/common_video/common_video.gyp
[modify] http://crrev.com/900f97534b8ce5de579f80f332cf674d78ac1679/webrtc/common_video/i420_buffer_pool.cc
[modify] http://crrev.com/900f97534b8ce5de579f80f332cf674d78ac1679/webrtc/common_video/include/i420_buffer_pool.h
[modify] http://crrev.com/900f97534b8ce5de579f80f332cf674d78ac1679/webrtc/common_video/include/video_frame_buffer.h
[modify] http://crrev.com/900f97534b8ce5de579f80f332cf674d78ac1679/webrtc/common_video/video_frame_buffer.cc
[modify] http://crrev.com/900f97534b8ce5de579f80f332cf674d78ac1679/webrtc/modules/video_coding/BUILD.gn
[modify] http://crrev.com/900f97534b8ce5de579f80f332cf674d78ac1679/webrtc/modules/video_coding/codecs/h264/h264.gypi
[modify] http://crrev.com/900f97534b8ce5de579f80f332cf674d78ac1679/webrtc/modules/video_coding/codecs/h264/h264_decoder_impl.cc
[modify] http://crrev.com/900f97534b8ce5de579f80f332cf674d78ac1679/webrtc/modules/video_coding/codecs/h264/h264_decoder_impl.h

Project Member Comment 71 by bugdroid1@chromium.org, Feb 5 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2b803417873274a16a0f6c3d5d116d3525026d13

commit 2b803417873274a16a0f6c3d5d116d3525026d13
Author: hbos <hbos@chromium.org>
Date: Fri Feb 05 16:19:46 2016

H264 is about to be supported in WebRTC behind flag, this
is preparation work for enabling it.

Background: The flag (from WebRTC) is |rtc_use_h264|.
Additionally, for H264 decoding to work an
|ffmpeg_branding| has to be used that includes H264 (for
example "Chrome").

If |rtc_use_h264| is used, this CL adds code to make sure
FFmpeg is initialized before any decoding happens
(otherwise H264DecoderImpl::InitDecode would fail). This
code is commented out however, due to the below reason.

When building with |rtc_use_h264|,
webrtc::DisableRtcUseH264() is called which disables the
effects of |rtc_use_h264| (disables that H264 enc/dec
implementation). We do this because we plan to default
|rtc_use_h264| to |proprietary_codecs| so that Chromium
trybots will use it. This also makes Chrome use it, but we
are not ready to launch this feature yet. We will remove
DisableRtcUseH264() in a follow-up CL that adds H264
browser tests. That way we have proper test coverage before
we enable it (otherwise it is only tested in webrtc repo,
not full call stack).

BUG=chromium:500605, chromium:468365

Review URL: https://codereview.chromium.org/1641163002

Cr-Commit-Position: refs/heads/master@{#373821}

[modify] http://crrev.com/2b803417873274a16a0f6c3d5d116d3525026d13/content/content.gyp
[modify] http://crrev.com/2b803417873274a16a0f6c3d5d116d3525026d13/content/content_renderer.gypi
[modify] http://crrev.com/2b803417873274a16a0f6c3d5d116d3525026d13/content/renderer/BUILD.gn
[modify] http://crrev.com/2b803417873274a16a0f6c3d5d116d3525026d13/content/renderer/media/webrtc/peer_connection_dependency_factory.cc

Project Member Comment 72 by bugdroid1@chromium.org, Feb 5 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/7cd94f66ebfe5bf808d7dcb8da069d35f4a2b31a

commit 7cd94f66ebfe5bf808d7dcb8da069d35f4a2b31a
Author: hbos <hbos@webrtc.org>
Date: Fri Feb 05 18:31:20 2016

Default build flag |rtc_use_h264| to |proprietary_codecs|
if not on Android/iOS.

This means proprietary_codecs=1 && ffmpeg_branding=Chrome
can be used to enable this H.264 enc/dec implementation
instead of rtc_use_h264=1 && ffmpeg_branding=Chrome.
This is used by both Chromium trybots (but not default
Chromium build) and offical Chrome build, meaning we will
be able to test and enable H.264 in chromium.

This change would otherwise be enough to launch this
feature in Chrome, but because we do not want to do that
before we have chromium browser tests and are ready to flip
the switch, this CL prevents chromium from using H.264 just
yet: https://codereview.chromium.org/1641163002/ (landing
this after that CL).

BUG=chromium:500605, chromium:468365

Review URL: https://codereview.webrtc.org/1660403004

Cr-Commit-Position: refs/heads/master@{#11506}

[modify] http://crrev.com/7cd94f66ebfe5bf808d7dcb8da069d35f4a2b31a/webrtc/build/common.gypi
[modify] http://crrev.com/7cd94f66ebfe5bf808d7dcb8da069d35f4a2b31a/webrtc/build/webrtc.gni

Project Member Comment 73 by bugdroid1@chromium.org, Feb 5 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/c09525a547ec1688fcd023ffc13a95115c63f884

commit c09525a547ec1688fcd023ffc13a95115c63f884
Author: hbos <hbos@webrtc.org>
Date: Fri Feb 05 19:02:42 2016

Revert of Default build flag |rtc_use_h264| to |proprietary_codecs| if not on Android/iOS. (patchset #1 id:1 of https://codereview.webrtc.org/1660403004/ )

Reason for revert:
Trybots red? Don't have time to intvestigate

Original issue's description:
> Default build flag |rtc_use_h264| to |proprietary_codecs|
> if not on Android/iOS.
>
> This means proprietary_codecs=1 && ffmpeg_branding=Chrome
> can be used to enable this H.264 enc/dec implementation
> instead of rtc_use_h264=1 && ffmpeg_branding=Chrome.
> This is used by both Chromium trybots (but not default
> Chromium build) and offical Chrome build, meaning we will
> be able to test and enable H.264 in chromium.
>
> This change would otherwise be enough to launch this
> feature in Chrome, but because we do not want to do that
> before we have chromium browser tests and are ready to flip
> the switch, this CL prevents chromium from using H.264 just
> yet: https://codereview.chromium.org/1641163002/ (landing
> this after that CL).
>
> BUG=chromium:500605, chromium:468365
>
> Committed: https://crrev.com/7cd94f66ebfe5bf808d7dcb8da069d35f4a2b31a
> Cr-Commit-Position: refs/heads/master@{#11506}

TBR=kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:500605, chromium:468365

Review URL: https://codereview.webrtc.org/1677623002

Cr-Commit-Position: refs/heads/master@{#11508}

[modify] http://crrev.com/c09525a547ec1688fcd023ffc13a95115c63f884/webrtc/build/common.gypi
[modify] http://crrev.com/c09525a547ec1688fcd023ffc13a95115c63f884/webrtc/build/webrtc.gni

Project Member Comment 74 by bugdroid1@chromium.org, Feb 7 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/10b9dd7ab1a8c3f80b2d2924be658e43131a4fbe

commit 10b9dd7ab1a8c3f80b2d2924be658e43131a4fbe
Author: hbos <hbos@webrtc.org>
Date: Sun Feb 07 22:40:40 2016

Default build flag |rtc_use_h264| to |proprietary_codecs|
if not on Android/iOS.

This means proprietary_codecs=1 && ffmpeg_branding=Chrome
can be used to enable this H.264 enc/dec implementation
instead of rtc_use_h264=1 && ffmpeg_branding=Chrome.
This is used by both Chromium trybots (but not default
Chromium build) and offical Chrome build, meaning we will
be able to test and enable H.264 in chromium.

This change would otherwise be enough to launch this
feature in Chrome, but because we do not want to do that
before we have chromium browser tests and are ready to flip
the switch, this CL prevents chromium from using H.264 just
yet: https://codereview.chromium.org/1641163002/ (landing
this after that CL).

Note: This is a re-land of
https://codereview.webrtc.org/1660403004/. Reverting it
was not necessary.

TBR=kjellander@webrtc.org
BUG=chromium:500605, chromium:468365

Review URL: https://codereview.webrtc.org/1674103002

Cr-Commit-Position: refs/heads/master@{#11517}

[modify] http://crrev.com/10b9dd7ab1a8c3f80b2d2924be658e43131a4fbe/webrtc/build/common.gypi
[modify] http://crrev.com/10b9dd7ab1a8c3f80b2d2924be658e43131a4fbe/webrtc/build/webrtc.gni

Project Member Comment 75 by bugdroid1@chromium.org, Feb 7 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/a81f6a3fc05378faa0e944c6c13d9beece2dac94

commit a81f6a3fc05378faa0e944c6c13d9beece2dac94
Author: hbos <hbos@webrtc.org>
Date: Sun Feb 07 23:05:22 2016

Revert of Default build flag |rtc_use_h264| to |proprietary_codecs| if not on Android/iOS. (patchset #1 id:1 of https://codereview.webrtc.org/1674103002/ )

Reason for revert:
Chromium FYI turns red.

Original issue's description:
> Default build flag |rtc_use_h264| to |proprietary_codecs|
> if not on Android/iOS.
>
> This means proprietary_codecs=1 && ffmpeg_branding=Chrome
> can be used to enable this H.264 enc/dec implementation
> instead of rtc_use_h264=1 && ffmpeg_branding=Chrome.
> This is used by both Chromium trybots (but not default
> Chromium build) and offical Chrome build, meaning we will
> be able to test and enable H.264 in chromium.
>
> This change would otherwise be enough to launch this
> feature in Chrome, but because we do not want to do that
> before we have chromium browser tests and are ready to flip
> the switch, this CL prevents chromium from using H.264 just
> yet: https://codereview.chromium.org/1641163002/ (landing
> this after that CL).
>
> Note: This is a re-land of
> https://codereview.webrtc.org/1660403004/. Reverting it
> was not necessary.
>
> TBR=kjellander@webrtc.org
> BUG=chromium:500605, chromium:468365
>
> Committed: https://crrev.com/10b9dd7ab1a8c3f80b2d2924be658e43131a4fbe
> Cr-Commit-Position: refs/heads/master@{#11517}

TBR=kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:500605, chromium:468365

Review URL: https://codereview.webrtc.org/1675113002

Cr-Commit-Position: refs/heads/master@{#11518}

[modify] http://crrev.com/a81f6a3fc05378faa0e944c6c13d9beece2dac94/webrtc/build/common.gypi
[modify] http://crrev.com/a81f6a3fc05378faa0e944c6c13d9beece2dac94/webrtc/build/webrtc.gni

Project Member Comment 76 by bugdroid1@chromium.org, Feb 8 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/62756ee41103b72377308a27d7abef0bda878231

commit 62756ee41103b72377308a27d7abef0bda878231
Author: hbos <hbos@webrtc.org>
Date: Mon Feb 08 10:57:00 2016

Default build flag |rtc_use_h264| to |proprietary_codecs|
if not on Android/iOS.

This is a re-land of https://codereview.webrtc.org/1674103002/.
The reason Chromium FYI turned red was due to deps not
being relative. See kjellander's CL:
https://codereview.webrtc.org/1681493002/.

This means proprietary_codecs=1 && ffmpeg_branding=Chrome
can be used to enable this H.264 enc/dec implementation
instead of rtc_use_h264=1 && ffmpeg_branding=Chrome.
This is used by both Chromium trybots (but not default
Chromium build) and offical Chrome build, meaning we will
be able to test and enable H.264 in chromium.

This change would otherwise be enough to launch this
feature in Chrome, but because we do not want to do that
before we have chromium browser tests and are ready to flip
the switch, this CL prevents chromium from using H.264 just
yet: https://codereview.chromium.org/1641163002/ (landing
this after that CL).

Third time's the charm?

TBR=kjellander@webrtc.org
BUG=chromium:500605, chromium:468365

Review URL: https://codereview.webrtc.org/1675143003

Cr-Commit-Position: refs/heads/master@{#11523}

[modify] http://crrev.com/62756ee41103b72377308a27d7abef0bda878231/webrtc/build/common.gypi
[modify] http://crrev.com/62756ee41103b72377308a27d7abef0bda878231/webrtc/build/webrtc.gni

Project Member Comment 77 by bugdroid1@chromium.org, Feb 9 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/0715a83a07a30fc19603cb25737671235e8fd9c6

commit 0715a83a07a30fc19603cb25737671235e8fd9c6
Author: hbos <hbos@webrtc.org>
Date: Tue Feb 09 10:34:29 2016

Avoid OpenH264 encoder bug for #threads > 1 on Mac and Chromium+Sandbox.

Until the bug has been further investigated, we're limiting the number
of threads to 1 to avoid problems. See crbug.com/583348.

BUG=chromium:500605, chromium:468365, chromium:583348

Review URL: https://codereview.webrtc.org/1677543002

Cr-Commit-Position: refs/heads/master@{#11536}

[modify] http://crrev.com/0715a83a07a30fc19603cb25737671235e8fd9c6/webrtc/modules/video_coding/codecs/h264/h264_encoder_impl.cc

Project Member Comment 78 by bugdroid1@chromium.org, Feb 11 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/1e01660899b2fdf45ea3fdaa7adfba85c17e66e9

commit 1e01660899b2fdf45ea3fdaa7adfba85c17e66e9
Author: stefan <stefan@webrtc.org>
Date: Thu Feb 11 12:13:54 2016

Add support for rtx with h264.

BUG=chromium:500605,webrtc:5516

Review URL: https://codereview.webrtc.org/1689543005

Cr-Commit-Position: refs/heads/master@{#11570}

[modify] http://crrev.com/1e01660899b2fdf45ea3fdaa7adfba85c17e66e9/webrtc/media/base/constants.cc
[modify] http://crrev.com/1e01660899b2fdf45ea3fdaa7adfba85c17e66e9/webrtc/media/base/constants.h
[modify] http://crrev.com/1e01660899b2fdf45ea3fdaa7adfba85c17e66e9/webrtc/media/webrtc/webrtcvideoengine2.cc

Comment 79 by andj2...@gmail.com, Feb 13 2016
I notice that Firefox uses payload id of 126 for H264 and Chrome is using 107. Why did Chrome choose 107 instead of 126?
Also, will this create interoperability problems between firefox/chrome?
Comment 80 by juberti@google.com, Feb 16 2016
The payload type numbers are not important. They are negotiated during call setup.
Comment 81 by hta@chromium.org, Feb 16 2016
Blocking: chromium:468365
Project Member Comment 82 by bugdroid1@chromium.org, Feb 19 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/82140fb2bbb534004ea49baa1f31aa8d9646775b

commit 82140fb2bbb534004ea49baa1f31aa8d9646775b
Author: hbos <hbos@chromium.org>
Date: Fri Feb 19 16:19:27 2016

Enable H.264 video WebRTC behind run-time flag and add
WebRtcBrowserTest for H.264.

The compile flag |rtc_use_h264| defaults to
|proprietary_codecs| which is used on some Chromium bots
and in the official Chrome build. The new run-time flag
|kWebRtcH264WithOpenH264FFmpeg| determines if the
|rtc_use_h264| encoder/decoder will be used at runtime.

The run-time flag is off by default.

This CL:
- Adds run-time flag and a new build target for it. It is
placed in content/public/renderer/media/webrtc/ because it
can't/shouldn't be placed in the webrtc repo and
peer_connection_dependency_factory.cc lives in
content/renderer/media/webrtc/.
- Moves renderer_features and its generated header file
target from content/renderer/ to content/public/renderer/
to not break include rules.
- Based on the run-time flag, enables or disables H.264 in
peer_connection_dependency_factory.cc.
- If flag is on, runs a new H.264 browser test.

BUG=chromium:500605, chromium:468365

Review URL: https://codereview.chromium.org/1673183002

Cr-Commit-Position: refs/heads/master@{#376451}

[modify] https://crrev.com/82140fb2bbb534004ea49baa1f31aa8d9646775b/chrome/browser/media/chrome_webrtc_browsertest.cc
[modify] https://crrev.com/82140fb2bbb534004ea49baa1f31aa8d9646775b/chrome/chrome_tests.gypi
[modify] https://crrev.com/82140fb2bbb534004ea49baa1f31aa8d9646775b/chrome/test/BUILD.gn
[modify] https://crrev.com/82140fb2bbb534004ea49baa1f31aa8d9646775b/content/content.gyp
[modify] https://crrev.com/82140fb2bbb534004ea49baa1f31aa8d9646775b/content/content_common.gypi
[modify] https://crrev.com/82140fb2bbb534004ea49baa1f31aa8d9646775b/content/content_renderer.gypi
[modify] https://crrev.com/82140fb2bbb534004ea49baa1f31aa8d9646775b/content/public/common/BUILD.gn
[add] https://crrev.com/82140fb2bbb534004ea49baa1f31aa8d9646775b/content/public/common/feature_h264_with_openh264_ffmpeg.cc
[add] https://crrev.com/82140fb2bbb534004ea49baa1f31aa8d9646775b/content/public/common/feature_h264_with_openh264_ffmpeg.h
[modify] https://crrev.com/82140fb2bbb534004ea49baa1f31aa8d9646775b/content/public/renderer/BUILD.gn
[modify] https://crrev.com/82140fb2bbb534004ea49baa1f31aa8d9646775b/content/renderer/BUILD.gn
[modify] https://crrev.com/82140fb2bbb534004ea49baa1f31aa8d9646775b/content/renderer/media/webrtc/peer_connection_dependency_factory.cc

Project Member Comment 83 by bugdroid1@chromium.org, Feb 19 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a6d8a47c53135c18b7c20065e9e2515eb011909f

commit a6d8a47c53135c18b7c20065e9e2515eb011909f
Author: guidou <guidou@chromium.org>
Date: Fri Feb 19 17:01:00 2016

Revert of Enable H.264 video WebRTC behind run-time flag and add WebRtcBrowserTest for H.264 (patchset #8 id:280001 of https://codereview.chromium.org/1673183002/ )

Reason for revert:
Caused compile error on WebRTC Win Builder Chromium bot:

https://build.chromium.org/p/chromium.webrtc/builders/Win%20Builder/builds/34506

FAILED: ninja -t msvc -e environment.x86 -- E:\b\build\goma/gomacc "E:\b\depot_tools\win_toolchain\vs2013_files\4087e065abebdca6dbd0caca2910c6718d2ec67f\VC\bin\amd64_x86\cl.exe" /nologo /showIncludes /FC @obj\content\public\common\feature_h264_with_openh264_ffmpeg.feature_h264_with_openh264_ffmpeg.obj.rsp /c ..\..\content\public\common\feature_h264_with_openh264_ffmpeg.cc /Foobj\content\public\common\feature_h264_with_openh264_ffmpeg.feature_h264_with_openh264_ffmpeg.obj /Fdobj\content\feature_h264_with_openh264_ffmpeg.cc.pdb
e:\b\build\slave\win_builder\build\src\content\public\common\feature_h264_with_openh264_ffmpeg.h(9) : fatal error C1083: Cannot open include file: 'content/public/common/common_features.h': No such file or directory
ninja: build stopped: subcommand failed.

Original issue's description:
> Enable H.264 video WebRTC behind run-time flag and add
> WebRtcBrowserTest for H.264.
>
> The compile flag |rtc_use_h264| defaults to
> |proprietary_codecs| which is used on some Chromium bots
> and in the official Chrome build. The new run-time flag
> |kWebRtcH264WithOpenH264FFmpeg| determines if the
> |rtc_use_h264| encoder/decoder will be used at runtime.
>
> The run-time flag is off by default.
>
> This CL:
> - Adds run-time flag and a new build target for it. It is
> placed in content/public/common/ because it
> can't/shouldn't be placed in the webrtc repo and
> peer_connection_dependency_factory.cc lives in
> content/renderer/media/webrtc/.
> - Moves renderer_features and its generated header file
> target from content/renderer/ to content/public/common/
> to not break include rules and renames it to
> common_features.
> - Based on the run-time flag, enables or disables H.264
> in peer_connection_dependency_factory.cc.
> - If flag is on, runs a new H.264 browser test.
>
> BUG=chromium:500605, chromium:468365
>
> Committed: https://crrev.com/82140fb2bbb534004ea49baa1f31aa8d9646775b
> Cr-Commit-Position: refs/heads/master@{#376451}

TBR=jochen@chromium.org,avi@chromium.org,jam@chromium.org,nick@chromium.org,phoglund@chromium.org,rkaplow@chromium.org,tommi@chromium.org,hbos@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:500605, chromium:468365

Review URL: https://codereview.chromium.org/1715753002

Cr-Commit-Position: refs/heads/master@{#376464}

[modify] https://crrev.com/a6d8a47c53135c18b7c20065e9e2515eb011909f/chrome/browser/media/chrome_webrtc_browsertest.cc
[modify] https://crrev.com/a6d8a47c53135c18b7c20065e9e2515eb011909f/chrome/chrome_tests.gypi
[modify] https://crrev.com/a6d8a47c53135c18b7c20065e9e2515eb011909f/chrome/test/BUILD.gn
[modify] https://crrev.com/a6d8a47c53135c18b7c20065e9e2515eb011909f/content/content.gyp
[modify] https://crrev.com/a6d8a47c53135c18b7c20065e9e2515eb011909f/content/content_common.gypi
[modify] https://crrev.com/a6d8a47c53135c18b7c20065e9e2515eb011909f/content/content_renderer.gypi
[modify] https://crrev.com/a6d8a47c53135c18b7c20065e9e2515eb011909f/content/public/common/BUILD.gn
[delete] https://crrev.com/857ad942692769a415dbd2d3b462d4e624e391ab/content/public/common/feature_h264_with_openh264_ffmpeg.cc
[delete] https://crrev.com/857ad942692769a415dbd2d3b462d4e624e391ab/content/public/common/feature_h264_with_openh264_ffmpeg.h
[modify] https://crrev.com/a6d8a47c53135c18b7c20065e9e2515eb011909f/content/public/renderer/BUILD.gn
[modify] https://crrev.com/a6d8a47c53135c18b7c20065e9e2515eb011909f/content/renderer/BUILD.gn
[modify] https://crrev.com/a6d8a47c53135c18b7c20065e9e2515eb011909f/content/renderer/media/webrtc/peer_connection_dependency_factory.cc

Project Member Comment 84 by bugdroid1@chromium.org, Feb 24 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/12f4cda0867b7264f0ad65b2b00e592de9a2a753

commit 12f4cda0867b7264f0ad65b2b00e592de9a2a753
Author: hbos <hbos@webrtc.org>
Date: Wed Feb 24 11:03:05 2016

Histograms for H264EncoderImpl/H264DecoderImpl
initialization and errors.

The stats are counts using enumeration, an instance of
H264EncoderImpl/H264DecoderImpl will report at most 1 Init
and 1 Error for its entire lifetime. This is to avoid
spamming reports if initialization or coding fails and it
retries in a loop. The Init stats will give us an idea of
usage counts for the encoder/decoder. The Error stats will
give us an idea of how many of these usages encounters some
type of problem, such as encode or decode errors.

- WebRTC.Video.H264EncoderImpl.Event:
  * kH264EncoderEventInit: Occurs at InitEncode.
  * kH264EncoderEventError: Occurs if any type of error
    occurs during initialization or encoding.
- WebRTC.Video.H264DecoderImpl.Event:
  * kH264DecoderEventInit: Occurs at InitDecode.
  * kH264DecoderEventError: Occurs if any type of error
    occurs during initialization, AVGetBuffer2 or decoding.

Chromium sibling CL:
https://codereview.chromium.org/1719273002/

BUG=chromium:500605, chromium:468365

Review URL: https://codereview.webrtc.org/1716173002

Cr-Commit-Position: refs/heads/master@{#11736}

[modify] https://crrev.com/12f4cda0867b7264f0ad65b2b00e592de9a2a753/webrtc/modules/video_coding/codecs/h264/h264_decoder_impl.cc
[modify] https://crrev.com/12f4cda0867b7264f0ad65b2b00e592de9a2a753/webrtc/modules/video_coding/codecs/h264/h264_decoder_impl.h
[modify] https://crrev.com/12f4cda0867b7264f0ad65b2b00e592de9a2a753/webrtc/modules/video_coding/codecs/h264/h264_encoder_impl.cc
[modify] https://crrev.com/12f4cda0867b7264f0ad65b2b00e592de9a2a753/webrtc/modules/video_coding/codecs/h264/h264_encoder_impl.h

Project Member Comment 85 by bugdroid1@chromium.org, Feb 25 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/88f1ea245bfd8d10dd4c247c076de41eac3acd06

commit 88f1ea245bfd8d10dd4c247c076de41eac3acd06
Author: hbos <hbos@chromium.org>
Date: Thu Feb 25 09:16:38 2016

Added WebRTC.Video.H264Encoder/DecoderImpl.Event histograms.

These histograms will be used to track how many times
this encoder/decoder is initialized/an error occurs.

WebRTC sibling CL:
https://codereview.webrtc.org/1716173002/

BUG=chromium:500605, chromium:468365

Review URL: https://codereview.chromium.org/1719273002

Cr-Commit-Position: refs/heads/master@{#377541}

[modify] https://crrev.com/88f1ea245bfd8d10dd4c247c076de41eac3acd06/tools/metrics/histograms/histograms.xml

Project Member Comment 86 by bugdroid1@chromium.org, Feb 25 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b43b719e4e54f569eeefd2beb85517d75bf6cbfd

commit b43b719e4e54f569eeefd2beb85517d75bf6cbfd
Author: hbos <hbos@chromium.org>
Date: Thu Feb 25 11:29:10 2016

Re-upload of https://codereview.chromium.org/1673183002/.

Enable H.264 video WebRTC behind run-time flag and add
WebRtcBrowserTest for H.264.

The compile flag |rtc_use_h264| defaults to
|proprietary_codecs| which is used on some Chromium bots
and in the official Chrome build. The new run-time flag
|kWebRtcH264WithOpenH264FFmpeg| determines if the
|rtc_use_h264| encoder/decoder will be used at runtime.

The run-time flag is off by default.

This CL:
- Adds run-time flag and a new build target for it. It is
placed in content/public/common/ because it
can't/shouldn't be placed in the webrtc repo and
peer_connection_dependency_factory.cc lives in
content/renderer/media/webrtc/.
- Moves renderer_features and its generated header file
target from content/renderer/ to content/public/common/
to not break include rules and renames it to
common_features.
- Based on the run-time flag, enables or disables H.264
in peer_connection_dependency_factory.cc.
- If flag is on, runs a new H.264 browser test.

BUG=chromium:500605, chromium:468365

Review URL: https://codereview.chromium.org/1718883002

Cr-Commit-Position: refs/heads/master@{#377556}

[modify] https://crrev.com/b43b719e4e54f569eeefd2beb85517d75bf6cbfd/chrome/browser/media/chrome_webrtc_browsertest.cc
[modify] https://crrev.com/b43b719e4e54f569eeefd2beb85517d75bf6cbfd/chrome/chrome_tests.gypi
[modify] https://crrev.com/b43b719e4e54f569eeefd2beb85517d75bf6cbfd/chrome/test/BUILD.gn
[modify] https://crrev.com/b43b719e4e54f569eeefd2beb85517d75bf6cbfd/content/content.gyp
[modify] https://crrev.com/b43b719e4e54f569eeefd2beb85517d75bf6cbfd/content/content_common.gypi
[modify] https://crrev.com/b43b719e4e54f569eeefd2beb85517d75bf6cbfd/content/content_renderer.gypi
[modify] https://crrev.com/b43b719e4e54f569eeefd2beb85517d75bf6cbfd/content/public/common/BUILD.gn
[add] https://crrev.com/b43b719e4e54f569eeefd2beb85517d75bf6cbfd/content/public/common/feature_h264_with_openh264_ffmpeg.cc
[add] https://crrev.com/b43b719e4e54f569eeefd2beb85517d75bf6cbfd/content/public/common/feature_h264_with_openh264_ffmpeg.h
[modify] https://crrev.com/b43b719e4e54f569eeefd2beb85517d75bf6cbfd/content/public/renderer/BUILD.gn
[modify] https://crrev.com/b43b719e4e54f569eeefd2beb85517d75bf6cbfd/content/renderer/BUILD.gn
[modify] https://crrev.com/b43b719e4e54f569eeefd2beb85517d75bf6cbfd/content/renderer/media/webrtc/peer_connection_dependency_factory.cc

Project Member Comment 87 by bugdroid1@chromium.org, Feb 26 2016
Labels: merge-merged-50
The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/12f4cda0867b7264f0ad65b2b00e592de9a2a753

commit 12f4cda0867b7264f0ad65b2b00e592de9a2a753
Author: hbos <hbos@webrtc.org>
Date: Wed Feb 24 11:03:05 2016

Histograms for H264EncoderImpl/H264DecoderImpl
initialization and errors.

The stats are counts using enumeration, an instance of
H264EncoderImpl/H264DecoderImpl will report at most 1 Init
and 1 Error for its entire lifetime. This is to avoid
spamming reports if initialization or coding fails and it
retries in a loop. The Init stats will give us an idea of
usage counts for the encoder/decoder. The Error stats will
give us an idea of how many of these usages encounters some
type of problem, such as encode or decode errors.

- WebRTC.Video.H264EncoderImpl.Event:
  * kH264EncoderEventInit: Occurs at InitEncode.
  * kH264EncoderEventError: Occurs if any type of error
    occurs during initialization or encoding.
- WebRTC.Video.H264DecoderImpl.Event:
  * kH264DecoderEventInit: Occurs at InitDecode.
  * kH264DecoderEventError: Occurs if any type of error
    occurs during initialization, AVGetBuffer2 or decoding.

Chromium sibling CL:
https://codereview.chromium.org/1719273002/

BUG=chromium:500605, chromium:468365

Review URL: https://codereview.webrtc.org/1716173002

Cr-Commit-Position: refs/heads/master@{#11736}

[modify] https://crrev.com/12f4cda0867b7264f0ad65b2b00e592de9a2a753/webrtc/modules/video_coding/codecs/h264/h264_decoder_impl.cc
[modify] https://crrev.com/12f4cda0867b7264f0ad65b2b00e592de9a2a753/webrtc/modules/video_coding/codecs/h264/h264_decoder_impl.h
[modify] https://crrev.com/12f4cda0867b7264f0ad65b2b00e592de9a2a753/webrtc/modules/video_coding/codecs/h264/h264_encoder_impl.cc
[modify] https://crrev.com/12f4cda0867b7264f0ad65b2b00e592de9a2a753/webrtc/modules/video_coding/codecs/h264/h264_encoder_impl.h

Does the current Canary build contain a functional run-time enabled version of H.264?
If not, when do you expect this to be available?
Comment 89 by hbos@chromium.org, Feb 29 2016
As of very recently, the latest canary version contain a run-time enabled version of H.264 provided you launch chrome with command line flag:

--enable-features=WebRTC-H264WithOpenH264FFmpeg

(It's currently not listed in chrome://flags/ yet so you have to use the command line.)

You can verify that it's supported and try it out at https://webrtc.github.io/samples/src/content/peerconnection/munge-sdp/. After "Create offer" you can verify that H264 is listed in the Offer SDP. You can modify the m=video line to put H264 (ID: 107 in chrome) first in the list of IDs, to set it up to use H264 video for the loopback call.

It is not entirely stable yet - delays, dropped frames and decode error may occur.
Comment 90 by pbos@chromium.org, Feb 29 2016
Labels: -merge-merged-50
Thanks of the info, I was able to download Canary and verify the SDP with H264. I noticed that there is no H264 fmtp format indicating support for packetization-mode=1, i.e. FF provides the following SDP entries:
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=rtpmap:126 H264/90000
a=rtpmap:97 H264/90000
Are you intending to support packetization-mode=1 in Chrome?
Project Member Comment 92 by bugdroid1@chromium.org, Mar 1 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/533bae44c5d341149e4f14b118c34750a5bd9d1a

commit 533bae44c5d341149e4f14b118c34750a5bd9d1a
Author: hbos <hbos@chromium.org>
Date: Tue Mar 01 11:25:56 2016

Waterfall to use run-time flag WebRTC-H264WithOpenH264FFmpeg.

Updated fieldtrial_testing_config file for chromeos, linux,
mac, win. (Feature not supported on android/ios.)

Note: The run-time flag was defined in:
https://codereview.chromium.org/1718883002/.

BUG=chromium:500605, chromium:468365

Review URL: https://codereview.chromium.org/1696383002

Cr-Commit-Position: refs/heads/master@{#378424}

[modify] https://crrev.com/533bae44c5d341149e4f14b118c34750a5bd9d1a/testing/variations/fieldtrial_testing_config_chromeos.json
[modify] https://crrev.com/533bae44c5d341149e4f14b118c34750a5bd9d1a/testing/variations/fieldtrial_testing_config_linux.json
[modify] https://crrev.com/533bae44c5d341149e4f14b118c34750a5bd9d1a/testing/variations/fieldtrial_testing_config_mac.json
[modify] https://crrev.com/533bae44c5d341149e4f14b118c34750a5bd9d1a/testing/variations/fieldtrial_testing_config_win.json

Project Member Comment 93 by bugdroid1@chromium.org, Mar 2 2016
Labels: Merge-Merged-master1
The following revision refers to this bug:
  https://chrome-internal.googlesource.com/bling/chromium.git/+/533bae44c5d341149e4f14b118c34750a5bd9d1a

commit 533bae44c5d341149e4f14b118c34750a5bd9d1a
Author: hbos <hbos@chromium.org>
Date: Tue Mar 01 11:25:56 2016

Comment 94 by hbos@chromium.org, Mar 4 2016
@hartjf.jobs: Thanks, yes, the standard says we must support packetization-mode=1. I created the following bug: https://bugs.chromium.org/p/chromium/issues/detail?id=591971
Comment 95 by hbos@chromium.org, Mar 4 2016
PSA about this being in Canary: https://groups.google.com/forum/#!topic/discuss-webrtc/8ov4YW6HLgo
Project Member Comment 96 by bugdroid1@chromium.org, Mar 4 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8018fbdf7bd32858d8926772e54c9ee20227d403

commit 8018fbdf7bd32858d8926772e54c9ee20227d403
Author: hbos <hbos@chromium.org>
Date: Fri Mar 04 14:38:51 2016

about_flags.cc entry for WebRTC-H264WithOpenH264FFmpeg
(base::Feature kWebRtcH264WithOpenH264FFmpeg).

This is a feature that enables a H.264 encoder/decoder in
WebRTC. The feature is off by default.

BUG=chromium:500605, chromium:468365

Review URL: https://codereview.chromium.org/1722283002

Cr-Commit-Position: refs/heads/master@{#379284}

[modify] https://crrev.com/8018fbdf7bd32858d8926772e54c9ee20227d403/build/common.gypi
[modify] https://crrev.com/8018fbdf7bd32858d8926772e54c9ee20227d403/chrome/app/generated_resources.grd
[modify] https://crrev.com/8018fbdf7bd32858d8926772e54c9ee20227d403/chrome/browser/BUILD.gn
[modify] https://crrev.com/8018fbdf7bd32858d8926772e54c9ee20227d403/chrome/browser/about_flags.cc
[modify] https://crrev.com/8018fbdf7bd32858d8926772e54c9ee20227d403/chrome/chrome_browser.gypi
[modify] https://crrev.com/8018fbdf7bd32858d8926772e54c9ee20227d403/tools/grit/grit_rule.gni

Project Member Comment 97 by bugdroid1@chromium.org, Mar 6 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/42c375980c81f9613eb5db60f135d845061c9b74

commit 42c375980c81f9613eb5db60f135d845061c9b74
Author: kjellander <kjellander@chromium.org>
Date: Sun Mar 06 11:44:21 2016

Revert "about_flags.cc entry for WebRTC-H264WithOpenH264FFmpeg"

Reason: This breaks WebRTC standalone from rolling chromium_revision
in the DEPS file. See https://codereview.webrtc.org/1765393002/ for examples.
The problem is that the Chromium build/common.gypi gets a hardcoded
dependency into ../third_party/webrtc/build/common.gypi, which doesn't
resolve when a standalone WebRTC checkout tries to process Chromium's
build/common.gypi.

For reland: Please move the rtc_use_h264 variable into Chromium's GYP chain
if it needs to be accessed from this context.

This reverts commit 8018fbdf7bd32858d8926772e54c9ee20227d403.
> about_flags.cc entry for WebRTC-H264WithOpenH264FFmpeg
> (base::Feature kWebRtcH264WithOpenH264FFmpeg).

> This is a feature that enables a H.264 encoder/decoder in
> WebRTC. The feature is off by default.

> BUG=chromium:500605, chromium:468365
> Committed: https://crrev.com/8018fbdf7bd32858d8926772e54c9ee20227d403
> Cr-Commit-Position: refs/heads/master@{#379284}

TBR=hbos@chromium.org, jochen@chromium.org, flackr@chromium.org, asvitkine@chromium.org, rkaplow@chromium.org,
BUG=chromium:500605, chromium:468365

Review URL: https://codereview.chromium.org/1770683002

Cr-Commit-Position: refs/heads/master@{#379488}

[modify] https://crrev.com/42c375980c81f9613eb5db60f135d845061c9b74/build/common.gypi
[modify] https://crrev.com/42c375980c81f9613eb5db60f135d845061c9b74/chrome/app/generated_resources.grd
[modify] https://crrev.com/42c375980c81f9613eb5db60f135d845061c9b74/chrome/browser/BUILD.gn
[modify] https://crrev.com/42c375980c81f9613eb5db60f135d845061c9b74/chrome/browser/about_flags.cc
[modify] https://crrev.com/42c375980c81f9613eb5db60f135d845061c9b74/chrome/chrome_browser.gypi
[modify] https://crrev.com/42c375980c81f9613eb5db60f135d845061c9b74/tools/grit/grit_rule.gni

Project Member Comment 98 by bugdroid1@chromium.org, Mar 7 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4b0a06a8f4c65caa3c2071e2ae00bf3252b148f7

commit 4b0a06a8f4c65caa3c2071e2ae00bf3252b148f7
Author: hbos <hbos@chromium.org>
Date: Mon Mar 07 17:25:40 2016

Added H264 to chrome_webrtc_perf_browsertest.cc.

Also updated the GYP and GN file for the browser_test target
to exclude chrome_webrtc_*_browsertest.cc in the case of
building with !enable_webrtc. This was previously only done
for some of these tests.

BUG=chromium:500605, chromium:468365

Review URL: https://codereview.chromium.org/1772613003

Cr-Commit-Position: refs/heads/master@{#379573}

[modify] https://crrev.com/4b0a06a8f4c65caa3c2071e2ae00bf3252b148f7/chrome/browser/media/chrome_webrtc_browsertest.cc
[modify] https://crrev.com/4b0a06a8f4c65caa3c2071e2ae00bf3252b148f7/chrome/browser/media/chrome_webrtc_perf_browsertest.cc
[modify] https://crrev.com/4b0a06a8f4c65caa3c2071e2ae00bf3252b148f7/chrome/chrome_tests.gypi
[modify] https://crrev.com/4b0a06a8f4c65caa3c2071e2ae00bf3252b148f7/chrome/test/BUILD.gn

Project Member Comment 99 by bugdroid1@chromium.org, Mar 8 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fd8c149beed9435fa64e82ffeb6b67dae2925594

commit fd8c149beed9435fa64e82ffeb6b67dae2925594
Author: hbos <hbos@chromium.org>
Date: Tue Mar 08 13:23:43 2016

Added H264 to chrome_webrtc_video_quality_browsertest.cc.

BUG=chromium:500605, chromium:468365

Review URL: https://codereview.chromium.org/1771323002

Cr-Commit-Position: refs/heads/master@{#379819}

[modify] https://crrev.com/fd8c149beed9435fa64e82ffeb6b67dae2925594/chrome/browser/media/chrome_webrtc_video_quality_browsertest.cc

Project Member Comment 100 by bugdroid1@chromium.org, Mar 8 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/18f5891498f7f1c90a7e1046bec1d933336db0a5

commit 18f5891498f7f1c90a7e1046bec1d933336db0a5
Author: hbos <hbos@chromium.org>
Date: Tue Mar 08 14:26:35 2016

about_flags.cc entry for WebRTC-H264WithOpenH264FFmpeg
(base::Feature kWebRtcH264WithOpenH264FFmpeg).

This is a feature that enables a H.264 encoder/decoder in
WebRTC. The feature is off by default.

This is a re-upload of
https://codereview.chromium.org/1722283002/. It was
reverted due to base/common.gypi depending on
../third_party/webrtc/build/common.gypi for rtc_use_h264.
In a webrtc standalone checkout, base/common.gypi is
processed such that this dependency does not get
resolved. Instead of finding a work-around where we can
get ahold of rtc_use_h264 in the base/common.gypi
context, I removed this use of it. This only affects the
generated_resources.grd file where rtc_use_h264 is not
used for the if. That means the two strings defined will
be included in the binary even when building without
h264 (the two strings will be unused).

BUG=chromium:500605, chromium:468365

Review URL: https://codereview.chromium.org/1774483002

Cr-Commit-Position: refs/heads/master@{#379824}

[modify] https://crrev.com/18f5891498f7f1c90a7e1046bec1d933336db0a5/chrome/app/generated_resources.grd
[modify] https://crrev.com/18f5891498f7f1c90a7e1046bec1d933336db0a5/chrome/browser/BUILD.gn
[modify] https://crrev.com/18f5891498f7f1c90a7e1046bec1d933336db0a5/chrome/browser/about_flags.cc
[modify] https://crrev.com/18f5891498f7f1c90a7e1046bec1d933336db0a5/chrome/chrome_browser.gypi

Project Member Comment 101 by bugdroid1@chromium.org, Mar 15 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3956fa1cac34dd5682c271d77463accdd7191102

commit 3956fa1cac34dd5682c271d77463accdd7191102
Author: emircan <emircan@chromium.org>
Date: Tue Mar 15 19:41:58 2016

H264 HW encode using VideoToolbox

This CL adds VTVideoEncodeAccelerator which enables H264 encode support using
VideoToolbox on mac. Also, it includes a refactor of common VideoToolbox classes
under video_toolbox_helpers.*.

Note that, this is the first CL and H264 codec is still behind a flag. More
patches will follow adding additional codec profiles and support for
bitrate adaptations.

Design Doc: https://docs.google.com/document/d/1oUTyZdNh8QstKRds-8wHEF_hqKryMiUpEOW8M57sUGU/edit?usp=sharing

BUG=500605
TEST= Tested AppRTC loopback with Chrome flag
"--enable-webrtc-hw-h264-encoding" on
https://apprtc.appspot.com/?debug=loopback&vsc=h264

Review URL: https://codereview.chromium.org/1636083003

Cr-Commit-Position: refs/heads/master@{#381286}

[modify] https://crrev.com/3956fa1cac34dd5682c271d77463accdd7191102/build/gn_migration.gypi
[modify] https://crrev.com/3956fa1cac34dd5682c271d77463accdd7191102/chrome/test/data/extensions/api_test/cast_streaming/end_to_end_sender.js
[modify] https://crrev.com/3956fa1cac34dd5682c271d77463accdd7191102/content/common/BUILD.gn
[modify] https://crrev.com/3956fa1cac34dd5682c271d77463accdd7191102/content/common/gpu/media/gpu_video_encode_accelerator.cc
[modify] https://crrev.com/3956fa1cac34dd5682c271d77463accdd7191102/content/common/gpu/media/gpu_video_encode_accelerator.h
[modify] https://crrev.com/3956fa1cac34dd5682c271d77463accdd7191102/content/common/gpu/media/video_encode_accelerator_unittest.cc
[add] https://crrev.com/3956fa1cac34dd5682c271d77463accdd7191102/content/common/gpu/media/vt_video_encode_accelerator_mac.cc
[add] https://crrev.com/3956fa1cac34dd5682c271d77463accdd7191102/content/common/gpu/media/vt_video_encode_accelerator_mac.h
[modify] https://crrev.com/3956fa1cac34dd5682c271d77463accdd7191102/content/content_common.gypi
[modify] https://crrev.com/3956fa1cac34dd5682c271d77463accdd7191102/content/content_tests.gypi
[modify] https://crrev.com/3956fa1cac34dd5682c271d77463accdd7191102/media/base/mac/BUILD.gn
[modify] https://crrev.com/3956fa1cac34dd5682c271d77463accdd7191102/media/base/mac/videotoolbox_glue.h
[modify] https://crrev.com/3956fa1cac34dd5682c271d77463accdd7191102/media/base/mac/videotoolbox_glue.mm
[add] https://crrev.com/3956fa1cac34dd5682c271d77463accdd7191102/media/base/mac/videotoolbox_helpers.cc
[add] https://crrev.com/3956fa1cac34dd5682c271d77463accdd7191102/media/base/mac/videotoolbox_helpers.h
[modify] https://crrev.com/3956fa1cac34dd5682c271d77463accdd7191102/media/cast/sender/h264_vt_encoder.cc
[modify] https://crrev.com/3956fa1cac34dd5682c271d77463accdd7191102/media/cast/sender/h264_vt_encoder.h
[modify] https://crrev.com/3956fa1cac34dd5682c271d77463accdd7191102/media/cast/sender/video_encoder.cc
[modify] https://crrev.com/3956fa1cac34dd5682c271d77463accdd7191102/media/media.gyp

Project Member Comment 102 by bugdroid1@chromium.org, Mar 15 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/36137188536e9e45a0033fe9edd0680a0dc267f6

commit 36137188536e9e45a0033fe9edd0680a0dc267f6
Author: dewittj <dewittj@chromium.org>
Date: Tue Mar 15 21:06:58 2016

Revert of H264 HW encode using VideoToolbox (patchset #22 id:620001 of https://codereview.chromium.org/1636083003/ )

Reason for revert:
This probably breaks Mac compile:
https://build.chromium.org/p/chromium/builders/Mac/builds/13208/steps/compile/logs/stdio

FAILED: /b/build/goma/gomacc ../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF obj/content/common/gpu/media/jpeg_decode_accelerator_unittest.jpeg_decode_accelerator_unittest.o.d -DV8_DEPRECATION_WARNINGS -DCLD_VERSION=2 -D__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORE=0 -DCHROMIUM_BUILD -DCR_CLANG_REVISION=263324-1 -DUSE_LIBJPEG_TURBO=1 -DENABLE_WEBRTC=1 -DENABLE_MEDIA_ROUTER=1 -DENABLE_PEPPER_CDMS -DENABLE_CONFIGURATION_POLICY -DENABLE_NOTIFICATIONS -DENABLE_TOPCHROME_MD=1 -DFIELDTRIAL_TESTING_ENABLED -DENABLE_TASK_MANAGER=1 -DENABLE_EXTENSIONS=1 -DENABLE_PDF=1 -DENABLE_PLUGIN_INSTALLATION=1 -DENABLE_PLUGINS=1 -DENABLE_SESSION_SERVICE=1 -DENABLE_THEMES=1 -DENABLE_AUTOFILL_DIALOG=1 -DENABLE_PRINTING=1 -DENABLE_BASIC_PRINTING=1 -DENABLE_PRINT_PREVIEW=1 -DENABLE_SPELLCHECK=1 -DUSE_BROWSER_SPELLCHECKER=1 -DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DENABLE_APP_LIST=1 -DENABLE_SETTINGS_APP=1 -DENABLE_SUPERVISED_USERS=1 -DENABLE_SERVICE_DISCOVERY=1 -DV8_USE_EXTERNAL_STARTUP_DATA -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DGTEST_HAS_POSIX_RE=0 -DGTEST_LANG_CXX11=0 -DMOJO_USE_SYSTEM_IMPL -DUNIT_TEST -DGTEST_HAS_RTTI=0 -DSK_SUPPORT_GPU=1 -DSK_IGNORE_LINEONLY_AA_CONVEX_PATH_OPTS -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DU_STATIC_IMPLEMENTATION -DMESA_EGL_NO_X11_HEADERS -DUSE_LIBPCI=1 -DUSE_OPENSSL=1 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -D_FORTIFY_SOURCE=2 -Igen -I../../third_party/libva -I../../third_party/libyuv -I../../third_party/khronos -I../../gpu -I../.. -I../../skia/config -Igen/angle -I../../third_party/WebKit/Source -I../../third_party/opus/src/include -I../../testing/gtest/include -I../../third_party/libyuv/include -I../../third_party/skia/include/core -I../../third_party/skia/include/effects -I../../third_party/skia/include/pdf -I../../third_party/skia/include/gpu -I../../third_party/skia/include/lazy -I../../third_party/skia/include/pathops -I../../third_party/skia/include/pipe -I../../third_party/skia/include/ports -I../../third_party/skia/include/utils -I../../third_party/skia/include/utils/mac -I../../skia/ext -I../../third_party/icu/source/i18n -I../../third_party/icu/source/common -I../../third_party/mesa/src/include -I../../third_party/WebKit -isysroot /Applications/Xcode5.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk -O2 -gdwarf-2 -fvisibility=hidden -Werror -mmacosx-version-min=10.6 -arch x86_64 -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wno-selector-type-mismatch -Wpartial-availability -Wheader-hygiene -Wno-char-subscripts -Wno-unneeded-internal-declaration -Wno-covered-switch-default -Wstring-conversion -Wno-c++11-narrowing -Wno-deprecated-register -Wno-inconsistent-missing-override -Wno-shift-negative-value -std=c++11 -stdlib=libc++ -fno-rtti -fno-exceptions -fvisibility-inlines-hidden -fno-threadsafe-statics -Xclang -load -Xclang /b/build/slave/Mac/build/src/third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.dylib -Xclang -add-plugin -Xclang find-bad-constructs -Xclang -plugin-arg-find-bad-constructs -Xclang check-templates -Xclang -plugin-arg-find-bad-constructs -Xclang follow-macro-expansion -fcolor-diagnostics -fno-strict-aliasing  -c ../../content/common/gpu/media/jpeg_decode_accelerator_unittest.cc -o obj/content/common/gpu/media/jpeg_decode_accelerator_unittest.jpeg_decode_accelerator_unittest.o
../../content/common/gpu/media/jpeg_decode_accelerator_unittest.cc:152:2: error: The JpegDecodeAccelerator is not supported on this platform.
#error The JpegDecodeAccelerator is not supported on this platform.
 ^
1 error generated.
ninja: build stopped: subcommand failed.

Original issue's description:
> H264 HW encode using VideoToolbox
>
> This CL adds VTVideoEncodeAccelerator which enables H264 encode support using
> VideoToolbox on mac. Also, it includes a refactor of common VideoToolbox classes
> under video_toolbox_helpers.*.
>
> Note that, this is the first CL and H264 codec is still behind a flag. More
> patches will follow adding additional codec profiles and support for
> bitrate adaptations.
>
> Design Doc: https://docs.google.com/document/d/1oUTyZdNh8QstKRds-8wHEF_hqKryMiUpEOW8M57sUGU/edit?usp=sharing
>
> BUG=500605
> TEST= Tested AppRTC loopback with Chrome flag
> "--enable-webrtc-hw-h264-encoding" on
> https://apprtc.appspot.com/?debug=loopback&vsc=h264
>
> Committed: https://crrev.com/3956fa1cac34dd5682c271d77463accdd7191102
> Cr-Commit-Position: refs/heads/master@{#381286}

TBR=sandersd@chromium.org,jfroy@chromium.org,mcasas@chromium.org,miu@chromium.org,posciak@chromium.org,dalecurtis@chromium.org,avi@chromium.org,thakis@chromium.org,emircan@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=500605

Review URL: https://codereview.chromium.org/1801343002

Cr-Commit-Position: refs/heads/master@{#381312}

[modify] https://crrev.com/36137188536e9e45a0033fe9edd0680a0dc267f6/build/gn_migration.gypi
[modify] https://crrev.com/36137188536e9e45a0033fe9edd0680a0dc267f6/chrome/test/data/extensions/api_test/cast_streaming/end_to_end_sender.js
[modify] https://crrev.com/36137188536e9e45a0033fe9edd0680a0dc267f6/content/common/BUILD.gn
[modify] https://crrev.com/36137188536e9e45a0033fe9edd0680a0dc267f6/content/common/gpu/media/gpu_video_encode_accelerator.cc
[modify] https://crrev.com/36137188536e9e45a0033fe9edd0680a0dc267f6/content/common/gpu/media/gpu_video_encode_accelerator.h
[modify] https://crrev.com/36137188536e9e45a0033fe9edd0680a0dc267f6/content/common/gpu/media/video_encode_accelerator_unittest.cc
[delete] https://crrev.com/ed7845a7d26f189fc161d93d6fabde9c8f73596e/content/common/gpu/media/vt_video_encode_accelerator_mac.cc
[delete] https://crrev.com/ed7845a7d26f189fc161d93d6fabde9c8f73596e/content/common/gpu/media/vt_video_encode_accelerator_mac.h
[modify] https://crrev.com/36137188536e9e45a0033fe9edd0680a0dc267f6/content/content_common.gypi
[modify] https://crrev.com/36137188536e9e45a0033fe9edd0680a0dc267f6/content/content_tests.gypi
[modify] https://crrev.com/36137188536e9e45a0033fe9edd0680a0dc267f6/media/base/mac/BUILD.gn
[modify] https://crrev.com/36137188536e9e45a0033fe9edd0680a0dc267f6/media/base/mac/videotoolbox_glue.h
[modify] https://crrev.com/36137188536e9e45a0033fe9edd0680a0dc267f6/media/base/mac/videotoolbox_glue.mm
[delete] https://crrev.com/ed7845a7d26f189fc161d93d6fabde9c8f73596e/media/base/mac/videotoolbox_helpers.cc
[delete] https://crrev.com/ed7845a7d26f189fc161d93d6fabde9c8f73596e/media/base/mac/videotoolbox_helpers.h
[modify] https://crrev.com/36137188536e9e45a0033fe9edd0680a0dc267f6/media/cast/sender/h264_vt_encoder.cc
[modify] https://crrev.com/36137188536e9e45a0033fe9edd0680a0dc267f6/media/cast/sender/h264_vt_encoder.h
[modify] https://crrev.com/36137188536e9e45a0033fe9edd0680a0dc267f6/media/cast/sender/video_encoder.cc
[modify] https://crrev.com/36137188536e9e45a0033fe9edd0680a0dc267f6/media/media.gyp

Project Member Comment 103 by bugdroid1@chromium.org, Mar 16 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ecfe5eced92b99fb8dc2351cd2afd533c2bfb953

commit ecfe5eced92b99fb8dc2351cd2afd533c2bfb953
Author: emircan <emircan@chromium.org>
Date: Wed Mar 16 01:02:17 2016

Reland: H264 HW encode using VideoToolbox

Reland CL: https://codereview.chromium.org/1636083003/

This CL adds VTVideoEncodeAccelerator which enables H264 encode support using
VideoToolbox on mac. Also, it includes a refactor of common VideoToolbox classes
under video_toolbox_helpers.*.

Note that, this is the first CL and H264 codec is still behind a flag. More
patches will follow adding additional codec profiles and support for
bitrate adaptations.

Design Doc: https://docs.google.com/document/d/1oUTyZdNh8QstKRds-8wHEF_hqKryMiUpEOW8M57sUGU/edit?usp=sharing

BUG=500605
TEST= Tested AppRTC loopback with Chrome flag
"--enable-webrtc-hw-h264-encoding" on
https://apprtc.appspot.com/?debug=loopback&vsc=h264
TBR=avi@chromium.org, jfroy@chromium.org, sandersd@chromium.org, thakis@chromium.org, posciak@chromium.org, miu@chromium.org

Review URL: https://codereview.chromium.org/1805723002

Cr-Commit-Position: refs/heads/master@{#381373}

[modify] https://crrev.com/ecfe5eced92b99fb8dc2351cd2afd533c2bfb953/build/gn_migration.gypi
[modify] https://crrev.com/ecfe5eced92b99fb8dc2351cd2afd533c2bfb953/chrome/test/data/extensions/api_test/cast_streaming/end_to_end_sender.js
[modify] https://crrev.com/ecfe5eced92b99fb8dc2351cd2afd533c2bfb953/content/common/BUILD.gn
[modify] https://crrev.com/ecfe5eced92b99fb8dc2351cd2afd533c2bfb953/content/common/gpu/media/gpu_video_encode_accelerator.cc
[modify] https://crrev.com/ecfe5eced92b99fb8dc2351cd2afd533c2bfb953/content/common/gpu/media/gpu_video_encode_accelerator.h
[modify] https://crrev.com/ecfe5eced92b99fb8dc2351cd2afd533c2bfb953/content/common/gpu/media/video_encode_accelerator_unittest.cc
[add] https://crrev.com/ecfe5eced92b99fb8dc2351cd2afd533c2bfb953/content/common/gpu/media/vt_video_encode_accelerator_mac.cc
[add] https://crrev.com/ecfe5eced92b99fb8dc2351cd2afd533c2bfb953/content/common/gpu/media/vt_video_encode_accelerator_mac.h
[modify] https://crrev.com/ecfe5eced92b99fb8dc2351cd2afd533c2bfb953/content/content_common.gypi
[modify] https://crrev.com/ecfe5eced92b99fb8dc2351cd2afd533c2bfb953/content/content_tests.gypi
[modify] https://crrev.com/ecfe5eced92b99fb8dc2351cd2afd533c2bfb953/media/base/mac/BUILD.gn
[modify] https://crrev.com/ecfe5eced92b99fb8dc2351cd2afd533c2bfb953/media/base/mac/videotoolbox_glue.h
[modify] https://crrev.com/ecfe5eced92b99fb8dc2351cd2afd533c2bfb953/media/base/mac/videotoolbox_glue.mm
[add] https://crrev.com/ecfe5eced92b99fb8dc2351cd2afd533c2bfb953/media/base/mac/videotoolbox_helpers.cc
[add] https://crrev.com/ecfe5eced92b99fb8dc2351cd2afd533c2bfb953/media/base/mac/videotoolbox_helpers.h
[modify] https://crrev.com/ecfe5eced92b99fb8dc2351cd2afd533c2bfb953/media/cast/sender/h264_vt_encoder.cc
[modify] https://crrev.com/ecfe5eced92b99fb8dc2351cd2afd533c2bfb953/media/cast/sender/h264_vt_encoder.h
[modify] https://crrev.com/ecfe5eced92b99fb8dc2351cd2afd533c2bfb953/media/cast/sender/video_encoder.cc
[modify] https://crrev.com/ecfe5eced92b99fb8dc2351cd2afd533c2bfb953/media/media.gyp

I tried running chrome with "--enable-webrtc-hw-h264-encoding" and going to sdp-munge, having it choose h264 first, but I get the following crash:

[81965:40479:0318/111251:FATAL:rtc_video_encoder.cc(628)] Check failed: thread_checker_.CalledOnValidThread().
0   Chromium Framework                  0x000000010729512f _ZN4base5debug10StackTraceC2Ev + 47
1   Chromium Framework                  0x00000001072952d3 _ZN4base5debug10StackTraceC1Ev + 35
2   Chromium Framework                  0x00000001073149e0 _ZN7logging10LogMessageD2Ev + 80
3   Chromium Framework                  0x0000000107312313 _ZN7logging10LogMessageD1Ev + 35
4   Chromium Framework                  0x0000000116c61d46 _ZN7content15RTCVideoEncoder10InitEncodeEPKN6webrtc10VideoCodecEim + 566
5   Chromium Framework                  0x000000011780a2e9 _ZN6webrtc35VideoEncoderSoftwareFallbackWrapper10InitEncodeEPKNS_10VideoCodecEim + 233
6   Chromium Framework                  0x0000000117850a67 _ZN6webrtc17VCMGenericEncoder10InitEncodeEPKNS_10VideoCodecEim + 343
7   Chromium Framework                  0x0000000117842be5 _ZN6webrtc16VCMCodecDataBase12SetSendCodecEPKNS_10VideoCodecEim + 1909
8   Chromium Framework                  0x000000011788cefc _ZN6webrtc3vcm11VideoSender17RegisterSendCodecEPKNS_10VideoCodecEjj + 380
9   Chromium Framework                  0x000000011788afee _ZN6webrtc12_GLOBAL__N_121VideoCodingModuleImpl17RegisterSendCodecEPKNS_10VideoCodecEjj + 62
10  Chromium Framework                  0x0000000117827c73 _ZN6webrtc10ViEEncoder10SetEncoderERKNS_10VideoCodecEi + 723
11  Chromium Framework                  0x0000000117817fb9 _ZN6webrtc8internal15VideoSendStream14EncoderProcessEv + 697
12  Chromium Framework                  0x00000001178161a6 _ZN6webrtc8internal15VideoSendStream21EncoderThreadFunctionEPv + 38
13  Chromium Framework                  0x000000010fc73c08 _ZN3rtc14PlatformThread3RunEv + 520
14  Chromium Framework                  0x000000010fc739d6 _ZN3rtc14PlatformThread11StartThreadEPv + 38
15  libsystem_pthread.dylib             0x00007fff8b8f7899 _pthread_body + 138
16  libsystem_pthread.dylib             0x00007fff8b8f772a _pthread_struct_init + 0
17  libsystem_pthread.dylib             0x00007fff8b8fbfc9 thread_start + 13
Comment 105 by hbos@chromium.org, Mar 22 2016
Cc: emir...@chromium.org
+emircan, see #104. Maybe create a separate bug for this?
pbos@, the issue has been discussed and addressed here[0].

brian@highfive.com, a fix has been applied as you can see on [0]. It was affecting all HW encoders on ToT unfortunately. Please update with the new WebRTc roll and let me know if you have any more problems.

[0] https://bugs.chromium.org/p/webrtc/issues/detail?id=5410 
Here is the correct bug where discussions are:
https://bugs.chromium.org/p/chromium/issues/detail?id=595308
Comment 108 Deleted
Thanks for that! Updated to the latest chrome and no longer see the crash.  I do see some issues though, let me know if I should file another bug:
1) The googAvgEncodeMs and googEncodeUsagePercent stats no longer seem to work
2) I'm getting a very shaky send framerate.  It'll stay at 30 if there's no movement, but even the slightest bit of movement drops googFrameRateSent framerate quite a bit (down to 10, 15fps)
Thanks Brian. We have some issues regarding bitrate and framerate that we are working on now. It would help a lot if you can file bugs for them and write the steps to reproduce. You can assign them to me directly.
Cool, thanks.  Filed https://bugs.chromium.org/p/chromium/issues/detail?id=597087 for the stat problem and https://bugs.chromium.org/p/chromium/issues/detail?id=597095 for the framerate problem.
Comment 112 Deleted
There appears to be an issue with the latest Canary on Windows that causes very long (>150ms) H264 decoder delays. I've filled a bug with repro steps here:
https://bugs.chromium.org/p/webrtc/issues/detail?id=5717
Comment 114 by hbos@chromium.org, Mar 31 2016
Thanks!
Comment 115 by hbos@webrtc.org, Mar 31 2016
Blockedon: webrtc:5717
Comment 116 by hbos@chromium.org, Mar 31 2016
Blockedon: 583704
Comment 117 by hbos@webrtc.org, Apr 4 2016
Blockedon: webrtc:5731
Comment 118 by hbos@webrtc.org, Apr 4 2016
Blockedon: webrtc:5730
Blocking: -468365
Blockedon: 468365
Blockedon: -584619
Blocking: -543540
Blockedon: 600399
Blockedon: 600254
Blockedon: 588423
Blockedon: 599580 599569 597729 599577
Pardon the spam, making this bug blocked on all H264 bugs related to this H264 encoder/decoder implementation I can think of. All of them does not necessarily have to be fixed before ready to launch.
Comment 128 by hbos@webrtc.org, Apr 4 2016
Blockedon: 5732
Any estimates when this will hit stable desktop Chrome? Could we expect it in 50?
Comment 130 by hbos@chromium.org, Apr 15 2016
Cc: pbos@chromium.org
Comment 131 by pbos@chromium.org, Apr 25 2016
Cc: hbos@chromium.org
Owner: pbos@chromium.org
Comment 132 by e...@younow.com, Apr 27 2016
At this time, is there any idea whether to remove the flag in 51, and open it for all?
Comment 133 by pbos@webrtc.org, May 3 2016
Blockedon: webrtc:5855
Labels: -Merge-Merged-master1
Comment 135 by pbos@webrtc.org, May 3 2016
Blockedon: webrtc:5857
Project Member Comment 136 by bugdroid1@chromium.org, May 10 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/487e16d68766a496d1174e880036e789c927b32d

commit 487e16d68766a496d1174e880036e789c927b32d
Author: pbos <pbos@chromium.org>
Date: Tue May 10 02:18:42 2016

Default-enable WebRTC-H264WithOpenH264FFmpeg.

Enables WebRTC H.264 by default in preparation for M52.

BUG=chromium:468365, chromium:500605
R=avi@chromium.org

Review-Url: https://codereview.chromium.org/1965513002
Cr-Commit-Position: refs/heads/master@{#392519}

[modify] https://crrev.com/487e16d68766a496d1174e880036e789c927b32d/content/public/common/feature_h264_with_openh264_ffmpeg.cc

Comment 137 by pbos@chromium.org, May 16 2016
Cc: blum@chromium.org
Project Member Comment 138 by bugdroid1@chromium.org, May 16 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ece1ceb03f53e76b2bc972def501661f57e82bc6

commit ece1ceb03f53e76b2bc972def501661f57e82bc6
Author: emircan <emircan@chromium.org>
Date: Mon May 16 18:59:19 2016

Bitrate controller for VideoToolbox Video Encode Accelerator

This CL adds WebRTC's bitrate adjuster to Chrome's H264 HW encoder
implementation.

Design Doc: https://docs.google.com/document/d/1oUTyZdNh8QstKRds-8wHEF_hqKryMiUpEOW8M57sUGU/edit?usp=sharing

BUG=500605
TEST= Tested AppRTC loopback with Chrome flag
"--enable-webrtc-hw-h264-encoding" on
https://apprtc.appspot.com/?debug=loopback&vsc=h264

Review-Url: https://codereview.chromium.org/1818903004
Cr-Commit-Position: refs/heads/master@{#393888}

[modify] https://crrev.com/ece1ceb03f53e76b2bc972def501661f57e82bc6/media/gpu/BUILD.gn
[modify] https://crrev.com/ece1ceb03f53e76b2bc972def501661f57e82bc6/media/gpu/DEPS
[modify] https://crrev.com/ece1ceb03f53e76b2bc972def501661f57e82bc6/media/gpu/ipc/media_ipc.gyp
[modify] https://crrev.com/ece1ceb03f53e76b2bc972def501661f57e82bc6/media/gpu/ipc/service/BUILD.gn
[modify] https://crrev.com/ece1ceb03f53e76b2bc972def501661f57e82bc6/media/gpu/vt_video_encode_accelerator_mac.cc
[modify] https://crrev.com/ece1ceb03f53e76b2bc972def501661f57e82bc6/media/gpu/vt_video_encode_accelerator_mac.h
[modify] https://crrev.com/ece1ceb03f53e76b2bc972def501661f57e82bc6/media/media.gyp
[modify] https://crrev.com/ece1ceb03f53e76b2bc972def501661f57e82bc6/media/media_gpu.gypi

Comment 139 by pbos@chromium.org, Jun 22 2016
Status: Fixed
Comment 140 by pbos@chromium.org, Jun 27 2016
Labels: M-52
Blockedon: 629546
Blockedon: -629546
Looks like H264 support is only available in desktop chrome 52. When will it be ready for mobile?
Hmm, you marked the feature as fixed for both desktop and android chrome in https://www.chromestatus.com/feature/6417796455989248

Apparently it's not available for android chrome.
FYI, see https://chromium.googlesource.com/external/webrtc/+/master/webrtc/build/webrtc.gni#116

What's going on here?
Comment 145 by pbos@chromium.org, Sep 30 2016
Cc: braveyao@chromium.org
That might be incorrect unless MediaCodec is wired up for the Chromium Android path.

braveyao@ is there a good bug to redirect Android H.264 efforts to instead of this centibug?
I want to build Chromium_51_0_2704_103 with h264 support enabled. What do I need to do?
As per @Comment 89 - Is it only a run time command for chromium as well (--enable-features=WebRTC-H264WithOpenH264FFmpeg)?
Do I need to enable any compile time flag? If so please let me know which is the final flag and where and which file I need to enable it?

Basically I want to build cefclient with h264 enabled. Please help as I am stuck after changing some flags here and there. As mentioned in @comment 59 : rtc_use_h264 and ffmpeg_branding=Chrome is currently enough to enable it, but we will put it behind a runtime flag before we ship it (make rtc_use_h264=1 default in Chrome), and then remove that flag once we are confident H264 is working well.

this above option doesn't work for me :(

It seems there is still no H.264 support in WebRTC on Android. Is there any resource where I can find more about a timeline when this will happen?
I made a bug https://crbug.com/719023 top track sw+h264_encoding+android
Sign in to add a comment