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

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.

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.

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?

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.

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

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.

#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.

Hello!
Sorry for asking, but I didn't yet understand it completely.
Are the bugfixes from Chromium somehow taken over to Chrome also? Because the issue still exists in the Chrome Webview and I can't manage to make my phone use the Chromium Webview.
Thank you for your help.
BR SB