H264 not supported in Chrome on Android devices (with JS sdk 2.7.0 and Chrome 83.XXX)

[jackychow]

I am using small-group rooms and just forced my room video-codecs to H264 yesterday in order to support Safari 11.
Then my android devices stops showing and receiving videos from others on Chrome.
Remote debugging on Android Chrome shows error :

TwilioError: No supported codec

So I found a prior issue thread that was solving similar problem in Chrome 81.XXX for H264.

I then created a codepen to check for the H264 profiles for my failing devices. Instead of having anything relating to wrong profile-level-id, the tested devices actually did not have any profile-level-id at all, nor is there mentioning of H264 support.
I found an SO thread that could be related to this issue
All of them are using Chrome 83.XXXX, the dump of the description from createOffer() is below:

(Note: I [Masked] the lines with ids)

v=0
o=- [----] 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=msid-semantic: WMS
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 9 0 8 105 13 110 113 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:[Masked]
a=ice-pwd:[Masked]
a=ice-options:trickle
a=fingerprint:sha-256 [Masked]
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:- [Masked]
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:1344795239 cname:dLGPUyF/ref3iMVi
a=ssrc:1344795239 msid:- [Masked]
a=ssrc:1344795239 mslabel:-
a=ssrc:1344795239 label:[Masked]
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:[Masked]
a=ice-pwd:[Masked]
a=ice-options:trickle
a=fingerprint:sha-256 [Masked]
a=setup:actpass
a=mid:1
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://tools.ietf.org/html/draft-ietf-avtext-framemarking-07
a=extmap:9 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:- [Masked]
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 profile-id=0
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 red/90000
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:102 ulpfec/90000
a=ssrc-group:FID [Masked]
a=ssrc:3200688521 cname:[Masked]
a=ssrc:3200688521 msid:- [Masked]
a=ssrc:3200688521 mslabel:-
a=ssrc:3200688521 label:[Masked]
a=ssrc:3231526776 cname:dLGPUyF/ref3iMVi
a=ssrc:3231526776 msid:- [Masked]
a=ssrc:3231526776 mslabel:-
a=ssrc:3231526776 label:[Masked]

The Android Devices we've tested so far are Huawei P30, Pixel 3, Oneplus 5T, Samsung Galaxy A70
I know at least the Huawei P30 ships with H.264 hardware decoder

• I have verified that the issue occurs with the latest twilio-video.js release and is not marked as a known issue in the CHANGELOG.md.
• I reviewed the Common Issues and open GitHub issues and verified that this report represents a potentially new issue.
• I verified that the Quickstart application works in my environment.
• I am not sharing any Personally Identifiable Information (PII)
  or sensitive account information (API keys, credentials, etc.) when reporting this issue.

Code to reproduce the issue:

https://codepen.io/jackychow/pen/oNbyvqB

Expected behavior:

H.264 encoding/decoding supported on android devices with H.264 hardware capability

Actual behavior:

twilio-video unable to use H.264 on Android devices

Software versions:

• Browser(s): Chrome 83.XXXX
• Operating System: Androids
• twilio-video.js: 2.7.0
• Third-party libraries (e.g., Angular, React, etc.): ReactJS

[anna-vasilko]

Hi @jackychow Thanks for reporting this!
Our QE team tried reproducing this with two following scenarios:

1. Create H264 only room via REST API and join that room from Android Chrome browser
2. Create an ad-hoc room and pass H264 as preferred codec client-side.

In both cases validated that video track is using H264 using getStats()
Results:

• Samsung Galaxy S7 (Android 7.0/Chrome 83) - not reproducible
• Moto G (Android 4.4.4/Chrome 74) - not reproducible
• Google Pixel 2 XL (Android 10/ Chrome 83) - not reproducible

Basically no luck reproducing the problem so far. It does seem like the devices you used indeed did not support H264. Could you please share a couple of room sids and ideally a debug browser log for us to be able to investigate further?

[jackychow]

Hi @anna-vasilko what kind of browser debug log would be useful? I do have console logs from but that's nothing but twilio error with no supported codec.

This is an example Room session id that I setup with the following conditions:

• Using the python api client and created the room with video_codecs=["H264"]
• And the clients using JS SDK connecting with preferred codec set to only H264

The room session id is RM93531d7234990228a07fee24b319c40f

I probably doubt we would find anything from the room's log because I got clear error on the chrome console that there is no supported codec.

Were you able to open the codepen link I posted and find offers description that are different?
I modifed the code there based on the other issue that I referred created by @manjeshbhargav

[jackychow]

Hi @anna-vasilko upon further testings, I probably found what's the problem.
It seems that although the getOffers call didn't return the profile id for the H264 codec, some of the phones tested did have hardware H264 codec installed (Pixel and A70).

In the case of the OnePlus and Huawei I think it's the hardware decoder that's not recognized by webRTC in chrome as H264. those are shipped with the hisilicon chips and it seems webrtc only recognize those made by qcom and a few others.