Add support for H264 software encoding in Android
Project Member Reported by firstname.lastname@example.org, May 5 2017
Splinter from all the discussions in https://bugs.chromium.org/p/chromium/issues/detail?id=500605 The gist: Android has no H264 software encoder, neither using OpenH264 nor any other library. Some more info in the i2s/pSA https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/rsokc4bi8R4
May 5 2017,
Jun 15 2017,
Are there any plans to work on this? With iOS 11 and Safari supporting h264 it would open up opportunities for interoperability
Jun 15 2017,
email@example.com, one of the easiest ways to get this ball rolling is to star this issue, and get other interested developers to do the same.
Sep 28 2017,
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.
Oct 6 2017,
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
Oct 27 2017,
> 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
Nov 27 2017,
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
Nov 28 2017,
That is the issue yes. Good summary!
Nov 28 2017,
Are there plans to add software support to Android Chrome in the near future? e.g. by March 2018?
Nov 28 2017,
Re. #7: > making it difficult to inter-operate with Safari on WebRTC. The lack of AVC1 software encoder also affects e.g. MediaRecorder.
Feb 9 2018,
Any progress on this?
Mar 26 2018,
Apr 12 2018,
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.
Sign in to add a comment