Are there any plans to work on this?
With iOS 11 and Safari supporting h264 it would open up opportunities for interoperability

michael@cache.works, one of the easiest ways to get this ball 
rolling is to star this issue, and get other interested developers
to do the same.

This needs to be addressed either by Apple adding VP8 to WebRTC in Safari 11(iOS 11) or Google adding H264 to WebRTC in Chrome for Android. 

As it is right now calls between Safari 11 (iOS 11) and Chrome (Android) are not possible because Android cannot send H264 video.

Adding support for the VP8 codec in Safari will not solve the problem of the lack of H.264 in Chrome on Android.

There are a lot of equipment (IP cameras, NVR recorders, etc) that can only give H.264 and Chrome must be able to decode this video.

Now we recommend all our clients to use Firefox on Android for WebRTC, they have a working H.264 software decoder.

I hope in the future we will be able to recommend using Chrome on Android for WebRTC

> Shao Changbin
> Added 01/Dec/14 11:41 PM
> We have landed two patches for this in Chromium upstream to support H264 VEA for Android. However, there are still needs discussion with upstream upon codec negotiation of H264. Will update the bug after reach agreement with upstream discussion.


Original work on H264 on Android date 2014 by Crosswalk. Any reasons or blocker that explains this has not been merge to may be solved them.


https://crosswalk-project.org/jira/plugins/servlet/mobile#issue/XWALK-2310

So The issue seems to be (In November 2017) that there is no software support within Chrome for Android for H.264. 
There may be hardware support on some devices but not within the browser itself, making it difficult to inter-operate with Safari on WebRTC.
Some devices (with hardware support) will work. Others will not.
Is this correct?

Thanks 

That is the issue yes. Good summary!

Are there plans to add software support to Android Chrome in the near future? e.g. by March 2018?

Re. #7:
> making it difficult to inter-operate with Safari on WebRTC.
The lack of AVC1 software encoder also affects e.g. MediaRecorder.

Any progress on this?

vp8 support on iOS might be an issue because of the battery consumption for cases like SFU based video call. Support of H.264 support on Android / Chrome eco system would be great.

Any news on this subject?

I had successfull video and audio calls on android 8 and ios 11 safari and viscera, few days ago.

I can provide URL for cross test via email, I was surprised of the result, knowing the existence of this issue, I now think h264 flag is available on android chrome by default, could depend device if.so also or less possible that safari is now taking vpX but I have not investigated in details the SDP, may be I miss-tested.

Adding Huib as responsible PM.
This might be a dup of one he's following.

Any news on this issue ?

@hthet : I think that the problem concerns H264 software encoding (since there is no hardware encoding on some devices)

I was sent here by https://bugs.chromium.org/p/webrtc/issues/detail?id=4957#c23.

We are seeing increasing amount of failures for calls between Chrome for Android and Safari on iOS in Confrere lately due to the lack of SW H.264 support. For now our only option is to fall back to an audio only call.

iOS to Android is more likely in our case as a significant amount of our users use our product on the mobile web, and we can't fall back to an app in our case.

I am disappointed with the Chromium team and recently switched to Bromite (https://github.com/bromite/bromite), which is a Chromium fork that supports H.264 software encoding and includes an adblocker. 

huib@, hta@, is this bug in anyone's radar?

Yes, https://bugs.chromium.org/p/webrtc/issues/detail?id=8538 may go first though

@Monorail Bromit does not support webrtc on android 8+ when I tested it, could be missing new android permission at runtime.

Thx for update @hub

Please keep working on this issue. Thx.

Re: https://bugs.chromium.org/p/webrtc/issues/detail?id=8538. We are not working on this and it's not in our radar.

I think your best bet to add H264 SW support is through MediaCodec with the Google software encoder/decoder: OMX.google.h264.encoder/decoder. Actually, doesn't Chrome support them already?

Please fully address this issue as it can compromise Web interconnectivity!  Thanks

Yes, it's a huge problem in emergency services for example, when the operator heavily relies on a stable connection. Before Safari 11 they just used VP8 and used facetime for ios but know the whole industry switched to h.264 and this has to be fixed SAP.

It can literally cost lives.

note to #27: the interoperability standard for browsers (https://tools.ietf.org/html/rfc7742) specifies that all browsers should support VP8 and H.264 - one of the reasons for this requirement was so that equipment that did not choose to implement license-burdened codecs would be able to interoperate in the Web ecosystem.

It's taken a while before Safari conformed to this requirement (it used to not support VP8); now that it does, the remaining outstanding issue is with Chrome on low-powered Android devices (H.264 encoding not supported).

Chrome on non-Android devices and Chrome on Android devices with good H.264 hardware encoders have supported H.264 encoding for a long time already.

There is no vp8 support in Safari on desktop or mobile as far as I know.

Support for VP8 has recently landed in Safari (https://bugs.webkit.org/show_bug.cgi?id=189976) and should be available on macOS and iOS soon. It was already included in Safari Technology Preview 68 (see: https://webkit.org/blog/8475/release-notes-for-safari-technology-preview-68/).

Sorry, you are right. Safari on desktop supports it.

I haven't found anything official about iOS though.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/919d2dee2bb2c4e6f9cbffdf94265378c312ffb0

commit 919d2dee2bb2c4e6f9cbffdf94265378c312ffb0
Author: Miguel Casas <mcasas@chromium.org>
Date: Fri Jan 04 22:05:12 2019

MediaRecorder: only announce h264/avc1 support if RTC_USE_H264

Support for AVC1 encoding (a.k.a. H264) is dependent on RTC_USE_H264 [1],
but due to an omission, this was not tested when enumerating the video
codecs. This CL fixes that.

[1] https://cs.chromium.org/chromium/src/third_party/webrtc/webrtc.gni?type=cs&q=rtc_use_h264&sq=package:chromium&g=0&l=156

TBR=emircan@chromium.org

Bug:  809980 , 719023
Change-Id: I03a375b269b042cb8cf64680153b878f60ea723f
Reviewed-on: https://chromium-review.googlesource.com/c/1395887
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#620078}
[modify] https://crrev.com/919d2dee2bb2c4e6f9cbffdf94265378c312ffb0/content/renderer/media_recorder/media_recorder_handler.cc
[modify] https://crrev.com/919d2dee2bb2c4e6f9cbffdf94265378c312ffb0/content/renderer/media_recorder/media_recorder_handler_unittest.cc
[modify] https://crrev.com/919d2dee2bb2c4e6f9cbffdf94265378c312ffb0/third_party/blink/web_tests/TestExpectations

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/612831555b5130eccfa8c6e783a4744c2362dec2

commit 612831555b5130eccfa8c6e783a4744c2362dec2
Author: Matthew Wolenetz <wolenetz@chromium.org>
Date: Fri Jan 04 23:22:49 2019

Revert "MediaRecorder: only announce h264/avc1 support if RTC_USE_H264"

This reverts commit 919d2dee2bb2c4e6f9cbffdf94265378c312ffb0.

Reason for revert: Strongly suspected as culprit in regressed blink web_tests:

https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/WebKit%20Linux%20Trusty%20ASAN/19960:
media_capabilities/encodingInfo.html

https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/WebKit%20Linux%20Trusty%20Leak/28348:
media_capabilities/encodingInfo.html
fast/mediarecorder/MediaRecorder-isTypeSupported.html

Original change's description:
> MediaRecorder: only announce h264/avc1 support if RTC_USE_H264
> 
> Support for AVC1 encoding (a.k.a. H264) is dependent on RTC_USE_H264 [1],
> but due to an omission, this was not tested when enumerating the video
> codecs. This CL fixes that.
> 
> [1] https://cs.chromium.org/chromium/src/third_party/webrtc/webrtc.gni?type=cs&q=rtc_use_h264&sq=package:chromium&g=0&l=156
> 
> TBR=emircan@chromium.org
> 
> Bug:  809980 , 719023
> Change-Id: I03a375b269b042cb8cf64680153b878f60ea723f
> Reviewed-on: https://chromium-review.googlesource.com/c/1395887
> Commit-Queue: Miguel Casas <mcasas@chromium.org>
> Reviewed-by: Miguel Casas <mcasas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#620078}

TBR=mcasas@chromium.org,mbarowsky@chromium.org

Change-Id: I59b3a89c5a2e6c41c589617a3ab4d3f66b53dfa2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  809980 , 719023
Reviewed-on: https://chromium-review.googlesource.com/c/1396716
Reviewed-by: Matthew Wolenetz <wolenetz@chromium.org>
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#620100}
[modify] https://crrev.com/612831555b5130eccfa8c6e783a4744c2362dec2/content/renderer/media_recorder/media_recorder_handler.cc
[modify] https://crrev.com/612831555b5130eccfa8c6e783a4744c2362dec2/content/renderer/media_recorder/media_recorder_handler_unittest.cc
[modify] https://crrev.com/612831555b5130eccfa8c6e783a4744c2362dec2/third_party/blink/web_tests/TestExpectations

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e79591b31f7374edbdd23c4b3c0b27301ba58475

commit e79591b31f7374edbdd23c4b3c0b27301ba58475
Author: Miguel Casas <mcasas@chromium.org>
Date: Mon Jan 07 20:33:38 2019

RELAND: MediaRecorder: only announce h264/avc1 support if RTC_USE_H264

The original CL got reverted because:
- It broke media_capabilities/encodingInfo.html
- It broke the MediaRecorder LayoutTests on non-Android bots
when RTC_USE_H264 is not defined (which is pretty pervasive, it turns
out). This CL then adds the necessary TestExceptions.


Original CL description ------------------------------------------------
Support for AVC1 encoding (a.k.a. H264) is dependent on RTC_USE_H264 [1],
but due to an omission, this was not tested when enumerating the video
codecs. This CL fixes that.

[1] https://cs.chromium.org/chromium/src/third_party/webrtc/webrtc.gni?type=cs&q=rtc_use_h264&sq=package:chromium&g=0&l=156

TBR=emircan@chromium.org

Bug:  809980 , 719023
Change-Id: I0a1778adb0f5657ca1f06054d62a1a64b9d40ad6
Reviewed-on: https://chromium-review.googlesource.com/c/1395887
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#620078}
Reviewed-on: https://chromium-review.googlesource.com/c/1396452
Cr-Commit-Position: refs/heads/master@{#620453}
[modify] https://crrev.com/e79591b31f7374edbdd23c4b3c0b27301ba58475/content/renderer/media_recorder/media_recorder_handler.cc
[modify] https://crrev.com/e79591b31f7374edbdd23c4b3c0b27301ba58475/content/renderer/media_recorder/media_recorder_handler_unittest.cc
[modify] https://crrev.com/e79591b31f7374edbdd23c4b3c0b27301ba58475/third_party/blink/web_tests/TestExpectations
[add] https://crrev.com/e79591b31f7374edbdd23c4b3c0b27301ba58475/third_party/blink/web_tests/fast/mediarecorder/MediaRecorder-isTypeSupported-avc1.html
[modify] https://crrev.com/e79591b31f7374edbdd23c4b3c0b27301ba58475/third_party/blink/web_tests/fast/mediarecorder/MediaRecorder-isTypeSupported.html

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6cac8286d5c5b95d187e83f1aa74d2490e1f7ae2

commit 6cac8286d5c5b95d187e83f1aa74d2490e1f7ae2
Author: Matthew Wolenetz <wolenetz@chromium.org>
Date: Mon Jan 07 21:26:52 2019

Revert "RELAND: MediaRecorder: only announce h264/avc1 support if RTC_USE_H264"

This reverts commit e79591b31f7374edbdd23c4b3c0b27301ba58475.

Reason for revert: Unfortunately, the RELAND still regressed
mediacapabilities/encodingInfo.html on
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/WebKit%20Linux%20Trusty%20ASAN/20082

Original change's description:
> RELAND: MediaRecorder: only announce h264/avc1 support if RTC_USE_H264
> 
> The original CL got reverted because:
> - It broke media_capabilities/encodingInfo.html
> - It broke the MediaRecorder LayoutTests on non-Android bots
> when RTC_USE_H264 is not defined (which is pretty pervasive, it turns
> out). This CL then adds the necessary TestExceptions.
> 
> 
> Original CL description ------------------------------------------------
> Support for AVC1 encoding (a.k.a. H264) is dependent on RTC_USE_H264 [1],
> but due to an omission, this was not tested when enumerating the video
> codecs. This CL fixes that.
> 
> [1] https://cs.chromium.org/chromium/src/third_party/webrtc/webrtc.gni?type=cs&q=rtc_use_h264&sq=package:chromium&g=0&l=156
> 
> TBR=emircan@chromium.org
> 
> Bug:  809980 , 719023
> Change-Id: I0a1778adb0f5657ca1f06054d62a1a64b9d40ad6
> Reviewed-on: https://chromium-review.googlesource.com/c/1395887
> Commit-Queue: Miguel Casas <mcasas@chromium.org>
> Reviewed-by: Miguel Casas <mcasas@chromium.org>
> Cr-Original-Commit-Position: refs/heads/master@{#620078}
> Reviewed-on: https://chromium-review.googlesource.com/c/1396452
> Cr-Commit-Position: refs/heads/master@{#620453}

TBR=mcasas@chromium.org,emircan@chromium.org,mbarowsky@chromium.org

Change-Id: Ibbe8fe769d0e2da553fe0d68ffa9d3a0b766d8e2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  809980 , 719023
Reviewed-on: https://chromium-review.googlesource.com/c/1399292
Reviewed-by: Matthew Wolenetz <wolenetz@chromium.org>
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#620477}
[modify] https://crrev.com/6cac8286d5c5b95d187e83f1aa74d2490e1f7ae2/content/renderer/media_recorder/media_recorder_handler.cc
[modify] https://crrev.com/6cac8286d5c5b95d187e83f1aa74d2490e1f7ae2/content/renderer/media_recorder/media_recorder_handler_unittest.cc
[modify] https://crrev.com/6cac8286d5c5b95d187e83f1aa74d2490e1f7ae2/third_party/blink/web_tests/TestExpectations
[delete] https://crrev.com/50ac726b54030cf0ea8058ba0e9c4d98ea2af4a5/third_party/blink/web_tests/fast/mediarecorder/MediaRecorder-isTypeSupported-avc1.html
[modify] https://crrev.com/6cac8286d5c5b95d187e83f1aa74d2490e1f7ae2/third_party/blink/web_tests/fast/mediarecorder/MediaRecorder-isTypeSupported.html

Hi all,

I modified some flags as below and it works fine in Android WebView like in the regular Android Chrome browser.
Firstly I checked all build flags by using this command: gn args out/Debug --list for both of Chromium and  Android Webview. After that, I realized some flags are different. Therefore I decided to set Android Webview build flags like  Android Chromium build flags. After set them, you need to recompile Android Webview.

Need to modify  some flags  below before build for the solution:

- Set gn arguments as below gn gen out/Debug --args='target_os="android" ffmpeg_branding="Chrome" enable_ffpmeg_video_decoders=true proprietary_codecs=true use_gold=false use_lld=true'

- Comment out kDisableWebRtcHWDecoding flag in aw_main_delegate.cc (https://cs.chromium.org/chromium/src/android_webview/lib/aw_main_delegate.cc?l=86)  as below;
   // cl->AppendSwitch(switches::kDisableWebRtcHWDecoding);

- enable_ffmpeg_video_decoders in media_options.gni (https://cs.chromium.org/chromium/src/media/media_options.gni?q=enable_ffmpeg_video_decoders+&dr=C&l=120) which is build flags needs to set true. It can’t be changed with gn argument. Therefore, it should be altered as below;
     Before modified : enable_ffmpeg_video_decoders = media_use_ffmpeg && !is_android   
     After modified    : enable_ffmpeg_video_decoders = media_use_ffmpeg && is_android
- Check these flags as below;
     gn args out/Debug --list

I am not a lawyer, but you might have to pay H.264 royalties if you enable the software encoding of it not using OpenH264, though.

the modification of is_android in #36 will remove H.264 from non-android builds, and is probably not what's intended.

The intended modification is probably to:

enable_ffmpeg_video_decoders = media_use_ffmpeg

Warning: Untried.

#37, I looked into logs after this solution. It seems to be using HW codec.

#38, I need only the Android WebView which is added h264 decoder support. That's why non-android builds not important for me. But if there is such a need, it would be more accurate to use enable_ffmpeg_video_decoders = media_use_ffmpeg.  But it is still needed to test.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/90022e36fddcafdb31ac5bd090215bbea22472c2

commit 90022e36fddcafdb31ac5bd090215bbea22472c2
Author: Miguel Casas <mcasas@chromium.org>
Date: Wed Jan 09 15:06:51 2019

RELAND2: MediaRecorder: only announce h264/avc1 support if RTC_USE_H264

The relanded CL got reverted as well (!) because it still broke
media_capabilities/encodingInfo.html; this CL splits the avc1/h264
parts in a file on its own, and rewrites all of those tests to not
use generate_tests (see comment in crrev.com/c/1393538). Only the
-avc1.html tests are marked as [Pass Failure] in TestExpectations.

Original 2nd CL description --------------------------------------------

The original CL got reverted because:
- It broke media_capabilities/encodingInfo.html
- It broke the MediaRecorder LayoutTests on non-Android bots
when RTC_USE_H264 is not defined (which is pretty pervasive, it turns
out). This CL then adds the necessary TestExceptions.

Original CL description ------------------------------------------------
Support for AVC1 encoding (a.k.a. H264) is dependent on RTC_USE_H264 [1],
but due to an omission, this was not tested when enumerating the video
codecs. This CL fixes that.

[1] https://cs.chromium.org/chromium/src/third_party/webrtc/webrtc.gni?type=cs&q=rtc_use_h264&sq=package:chromium&g=0&l=156

Bug:  809980 , 719023
Change-Id: I865e9007ffce810998f62d1e187bf4ecf499badd
Reviewed-on: https://chromium-review.googlesource.com/c/1395887
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Cr-Original-Original-Commit-Position: refs/heads/master@{#620078}
Reviewed-on: https://chromium-review.googlesource.com/c/1396452
Cr-Original-Commit-Position: refs/heads/master@{#620453}
Reviewed-on: https://chromium-review.googlesource.com/c/1399823
Reviewed-by: Emircan Uysaler <emircan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#621142}
[modify] https://crrev.com/90022e36fddcafdb31ac5bd090215bbea22472c2/content/renderer/media_recorder/media_recorder_handler.cc
[modify] https://crrev.com/90022e36fddcafdb31ac5bd090215bbea22472c2/content/renderer/media_recorder/media_recorder_handler_unittest.cc
[modify] https://crrev.com/90022e36fddcafdb31ac5bd090215bbea22472c2/third_party/blink/web_tests/TestExpectations
[add] https://crrev.com/90022e36fddcafdb31ac5bd090215bbea22472c2/third_party/blink/web_tests/fast/mediarecorder/MediaRecorder-isTypeSupported-avc1.html
[modify] https://crrev.com/90022e36fddcafdb31ac5bd090215bbea22472c2/third_party/blink/web_tests/fast/mediarecorder/MediaRecorder-isTypeSupported.html
[add] https://crrev.com/90022e36fddcafdb31ac5bd090215bbea22472c2/third_party/blink/web_tests/media_capabilities/encodingInfo-avc1.html
[modify] https://crrev.com/90022e36fddcafdb31ac5bd090215bbea22472c2/third_party/blink/web_tests/media_capabilities/encodingInfo.html