Hello,

Following the comment here (https://bugs.chromium.org/p/webrtc/issues/detail?id=8584#c7) and the thread here (https://github.com/BasqueVoIPMafia/cordova-plugin-iosrtc/issues/103#issue-121681960)

I attempted to replace the SDP offer/answer content to get an iPhone <=> Android call working, by replacing 42001f profile id to 42e01f, in addition to several other properties (like VP8/VP9 => H264), but was unsuccessful.

Is there any documentation covering what change (SDP munging) has to be made in order to force Android into the correct profile?

Can this be done in JS alone, until this fix lands?

Thank you

Generally, just need to promote H264 to be the first one in m=video line and replace H264 profile id with 42e01f. 
Yes it is JS alone and don't need this fix at all.

Hello,

I'm also facing this issue, when trying to send H.264 from Android Chrome to another Chrome on desktop or Safari on desktop, through a Janus SFU.

I tried munging the sdp on the android, replacing 42001f to 42e01f for outgoing sdp offers and answers, and 42e01f to 42001f for incoming offers and answers. This resulted in successful sdp negotiation, but the android video could not be decoded on Chrome neither Safari (I came to that result after also examining the webrtc session on chrome://webrtc-internals). However, the munging worked on the other way round, meaning I was able to view on the android device, the H.264 stream produced on either Chrome or Safari.

I'm attaching the sdp exchanges. The problematic scenario is in the android_to_chrome.txt file

Deleted: chrome_to_android.txt 7.0 KB

chrome_to_android.txt 7.0 KB View Download

Deleted: android_to_chrome.txt 6.2 KB

android_to_chrome.txt 6.2 KB View Download

pimenas@, what's the Chrome version on Android in your test? There is a regression in M62(https://bugs.chromium.org/p/chromium/issues/detail?id=761336) and the fix should be in M63+.

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

commit 45697ad699592cd7a7c23615aac7b7007da8782b
Author: Weiyong Yao <braveyao@chromium.org>
Date: Thu Dec 14 01:59:22 2017

[Android] Force HW H264 to advise ConstrainedBaseLine

Currently Chrome on Android can only advise BaseLine H264 for HW H264
encoder, while some third party peers only expect ConstrainedBaseLine
during negotiation. This will break down the intercommunication with
others a lot.
Changing the profile id in SDP to CBP can solve this problem, which means
the peer can actually decode the stream from Android HW H264.

So the easiest solution is to fake the H264 profile id to CBP on Android,
which will violate the spec a bit, but can solve major intercommunication
compatibility issues right now.

Bug:  793038 
Change-Id: I8480aa624c445f30c5defe75bdc378dca63e130a
Reviewed-on: https://chromium-review.googlesource.com/815294
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: Weiyong Yao <braveyao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523980}
[modify] https://crrev.com/45697ad699592cd7a7c23615aac7b7007da8782b/content/renderer/media/gpu/rtc_video_encoder_factory.cc

@braveyao, it's Chrome version 63.0.3239.83 on Android version 7.1.2

@braveyao, I just tested the same case without Janus, by munging manually the sdp's, leaving only H264, and I can confirm the media is working from android to desktop. 
So in my case, that is with Janus acting as an SFU, it must be something else, or maybe I've got a mistake somewhere.

It's really hard to say. Depending on whether Janus will do trans-coding or just relay, you need to check different things, stream packets or payload or anything else. Whatsoever, it's better to guarantee the stream received by desktop is same, with or without Janus. Good luck.

Hello

I could see that the bug is fixed so I retrieved Chrome Canary 65.0.3316.0 on Android and tested WebRTC communication between a Samsung S8 (Android 7.0) and IOS 11

If using Chrome Browser : the WebRTC communication is now fine (both users can see each other)
If using Chrome webview (after enabling it on Developper Options and enabling also hardware accelerated option on the webview) : for the IOS user everything is ok but for the Android user, he cannot see his callee

Profile id used is 42e01f

If doing the same test with Chrome 63, neither the IOS nor the Android user can see each other (so there is actually some progress with Chrome 65)

If doing the same test with Chrome 65 from Android to Android, the co

Can you see why there would be any difference between Chrome Browser and Chrome Webview on WebRTC using H264 (since it is supposed to be the same component on Android 7.0)

Do I need to open a specific bug on this issue ?

Thank you,

Didier

Didier@, sorry to hear that. I do get similar reports before that same version of chrome and webview behaviors differently, which usually works again in webview with later versions. So I guess it's same here.  

@braveyao, others, with respect to the issue with an SFU, you may want to check this report: https://bugs.chromium.org/p/monorail/issues/detail?id=3424 looks like H264 encoder is not sending SPS NALUs with the IDRs.

oscar@, as https://bugs.chromium.org/p/chromium/issues/detail?id=761336#c40 shows, it has been fixed in M64 and merged back to M63. Currently each key frame from HW H264 will have SPS/PPS NALUs contained.
The apprtc demo with H264 between Chrome Android and Chrome Desktop works well. Also you mentioned in https://bugs.chromium.org/p/monorail/issues/detail?id=3424 that P2P works too.

So is it problem of SFU, same as the case in comment#7? Does the SFU simply relay the stream packets or it will do some kind of trans-coding job?

No transcoding job in the tests I am performing, just forwarding.
I can test further but it seemed to me to fail in Chrome Android 65 too...

Traces of NALUs extracted at the bitstream level show only NALU 5 was present in the stream (on a Samsung s7).

Is it same in P2P case?

No, P2P is not a problem. The very first IDR carries an SPS Right before. 
But it is not the case for the following IDRs. In the SFU case the first IDR is not received by the receiving clients typically, as those connect later to the server, after the sender connected.

SPS will be appended to every key frame generated, https://cs.chromium.org/chromium/src/media/base/android/java/src/org/chromium/media/MediaCodecEncoder.java?l=97, as same as the first IDR. I can see those logs as the key frames are generated every 25s in a loopback test on Android, with a debug chromium building. Don't understand why you are seeing differently.

Where do you check the stream packets, Android device, SFU receiving side, SFU sending side or desktop?
And is the call from desktop to android through SFU working as expected? How about desktop-desktop and android-android with SFU cases?

Interesting @braveyao. 
Well:
Reproduced the problem basically for the case ChromeAndroid -> SFU -> AnythingElse
I.e.
ChromeAndroid -> SFU -> ChromeDesktop  :  NOT-OK
ChromeDesktop -> SFU -> ChromeAndroid  :  OK
ChromeDesktop -> SFU -> ChromeDesktop  :  OK
ChromeDesktop -> SFU -> Firefox        :  OK
ChromeAndroid -> SFU -> ChromeAndroid  :  NOT-OK
ChromeAndroid -> SFU -> Firefox        :  NOT-OK
ChromeAndroid -> SFU -> Safari         :  NOT-OK
Safari        -> SFU -> ChromeAndroid  :  OK

We are checking stream packets at the bitstream level within our SFU, where we have enabled inspection and logging of every NAL Unit type passing by, and while for every Browser working well NAL 7 and NAL 5 show up in response to every PLI, in the particular and specific case of Chrome Android, only NAL 5 shows up.

I got reported internally that the following log appears in Chromium 
[1:17:0119/111438.431971:WARNING:h264_sps_pps_tracker.cc(68)] No PPS with id << 0 received

Thanks oscar@ for the testing!
Now I see the problem. Even I append SPS/PSS to each KeyFrame on Android, but only the first on can carry it to peer. SPS/PPS is missing in following keyframes received at peer. Strange.
Have to go along the whole code path to double check if every keyframe contains the SPS/PPS as expected and if it's removed somewhere else.

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

commit 07f8bb44eb43b8dfccdc07d796d5ce0541466d4c
Author: Weiyong Yao <braveyao@chromium.org>
Date: Tue Jan 23 19:02:52 2018

[Android HW 264] append SPS/PPS NALUs to IDR correctly

HW H264 encoder on Android will output SPS/PPS packet separately, so we
need to cache and append it to all the IDR frames. During that processing,
the cache buffer isn't rewinded each time. Then currently only the first
IDR will have SPS/PPS appended correctly and all the followiing IDRs will
contain incorrect data.
In that case, if the first IDR is lost for some reason, the peer won't
get corrent SPS/PPS to start decoding.

This cl is to fix it by rewinding buffer of cached SPS/PPS each time and
add relevant unittest case.

Bug:  793038 
Change-Id: I53d3e6f40c37f4eb31e3c1ce348db19c523d9d95
Reviewed-on: https://chromium-review.googlesource.com/879590
Reviewed-by: Frank Liberato <liberato@chromium.org>
Commit-Queue: Weiyong Yao <braveyao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#531294}
[modify] https://crrev.com/07f8bb44eb43b8dfccdc07d796d5ce0541466d4c/media/base/android/java/src/org/chromium/media/MediaCodecEncoder.java
[modify] https://crrev.com/07f8bb44eb43b8dfccdc07d796d5ce0541466d4c/media/base/android/media_codec_bridge_impl_unittest.cc

Thanks oscar@ for your help!
It's all about how to use ByteBuffer in JAVA - need to rewind it after each copy from it. Learnt lesson and issue fixed.

A pleasure braveyao@.
Do we have a timeline of when the fix is going to be deployed and available?
Once tested in 65 (Canary), I think it would be good to get it rolled into earlier channels. 

Yes I'll try. Please let me know the Canary works at your side.

braveyao@ I checked the fixe working starting on 66.0.3334.0 Chrome Android. So looks to me that is the version your latest fix landed.

Any chance to get the fix land in earlier versions of Chrome Android ?
Current production version released appears to just be 64.0.3282.123 .

Asking for merge to M65. This fix resolves in interop issue between hardware h.264 encoders on Android and e.g., desktop browsers on the receive side.

Your change meets the bar and is auto-approved for M65. Please go ahead and merge the CL to branch 3325 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

commit 1a685e9c74eb9c6afb7aceee9a7b35eb175a0066
Author: Weiyong Yao <braveyao@chromium.org>
Date: Tue Jan 30 19:50:25 2018

[Android HW 264] append SPS/PPS NALUs to IDR correctly

HW H264 encoder on Android will output SPS/PPS packet separately, so we
need to cache and append it to all the IDR frames. During that processing,
the cache buffer isn't rewinded each time. Then currently only the first
IDR will have SPS/PPS appended correctly and all the followiing IDRs will
contain incorrect data.
In that case, if the first IDR is lost for some reason, the peer won't
get corrent SPS/PPS to start decoding.

This cl is to fix it by rewinding buffer of cached SPS/PPS each time and
add relevant unittest case.

Bug:  793038 
Change-Id: I53d3e6f40c37f4eb31e3c1ce348db19c523d9d95
Reviewed-on: https://chromium-review.googlesource.com/879590
Reviewed-by: Frank Liberato <liberato@chromium.org>
Commit-Queue: Weiyong Yao <braveyao@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#531294}(cherry picked from commit 07f8bb44eb43b8dfccdc07d796d5ce0541466d4c)
Reviewed-on: https://chromium-review.googlesource.com/893436
Reviewed-by: Weiyong Yao <braveyao@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#181}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/1a685e9c74eb9c6afb7aceee9a7b35eb175a0066/media/base/android/java/src/org/chromium/media/MediaCodecEncoder.java
[modify] https://crrev.com/1a685e9c74eb9c6afb7aceee9a7b35eb175a0066/media/base/android/media_codec_bridge_impl_unittest.cc