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 124 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Feature

Blocked on:
issue webrtc:8538

Blocking:
issue 719024



Sign in to add a comment
link

Issue 719023: Add support for H264 software encoding in Android

Reported by mcasas@chromium.org, May 5 2017 Project Member

Issue description

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
 

Comment 1 by mcasas@chromium.org, May 5 2017

Blocking: 719024

Comment 2 by mich...@cache.works, 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

Comment 3 by mcasas@chromium.org, Jun 15 2017

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.

Comment 4 by vkantc...@primosoftware.com, 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.

Comment 5 by ua.san.a...@gmail.com, 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

Comment 6 by hthet...@gmail.com, 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

Comment 7 by mmong...@gzero.ca, 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

Comment 8 by vkantc...@primosoftware.com, Nov 28 2017

That is the issue yes. Good summary!

Comment 9 by mmong...@gzero.ca, Nov 28 2017

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

Comment 10 by mcasas@chromium.org, 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.

Comment 11 by tgabi...@gmail.com, Feb 9 2018

Any progress on this?

Comment 12 by thomasanderson@chromium.org, Mar 26 2018

Labels: -OS-Linux

Comment 13 by rajusn....@gmail.com, 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.

Comment 14 by nonononoki@gmail.com, Jun 14 2018

Any news on this subject?

Comment 15 by hthet...@gmail.com, Jun 14 2018

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.

Comment 16 by pbos@chromium.org, Jun 14 2018

Cc: -pbos@chromium.org

Comment 17 by hta@chromium.org, Jul 23 2018

Cc: huib@chromium.org
Adding Huib as responsible PM.
This might be a dup of one he's following.

Comment 18 by dbedouil...@gmail.com, Aug 14

Any news on this issue ?

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

Comment 19 by dagi...@confrere.com, Aug 20

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.

Comment 20 by nonononoki@gmail.com, Aug 20

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.

Comment 21 by mcasas@chromium.org, Aug 23

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

Comment 23 by hta@chromium.org, Aug 27

Blockedon: webrtc:8538

Comment 24 by hthet...@gmail.com, Aug 27

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

Comment 25 by magjed@chromium.org, Sep 3

Cc: magjed@chromium.org
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?

Comment 26 by caplabati@gmail.com, Nov 20

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

Comment 27 by att...@artit.io, Dec 1

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.

Comment 28 by hta@chromium.org, Dec 2

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.

Comment 29 by att...@artit.io, Dec 2

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

Comment 30 by amat...@gmail.com, Dec 2

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/).

Comment 31 by att...@artit.io, Dec 3

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

I haven't found anything official about iOS though.

Comment 32 by bugdroid1@chromium.org, Jan 4

Project Member
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

Comment 33 by bugdroid1@chromium.org, Jan 4

Project Member
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

Comment 34 by bugdroid1@chromium.org, Jan 7

Project Member
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

Comment 35 by bugdroid1@chromium.org, Jan 7

Project Member
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

Comment 36 by tolga.ka...@gmail.com, Jan 8

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

Comment 37 by phistuck@gmail.com, Jan 8

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.

Comment 38 by hta@chromium.org, Jan 8

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.

Comment 39 Deleted

Comment 40 Deleted

Comment 41 by tolga.ka...@gmail.com, Jan 8

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

Comment 42 by tolga.ka...@gmail.com, Jan 8

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

Comment 43 by bugdroid1@chromium.org, Jan 9

Project Member
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

Comment 44 by boeck.sa...@gmail.com, Feb 20 (2 days ago)

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

Sign in to add a comment