iOS 12 WebRTC stream 与 H264 High Profile 一起发送，即使双方同意 Base Profile

Question

I am developing a WebRTC streaming application that uses Wowza to create calls. I got problems connection between two clients whilst one of them is using iOS 12 or iOS 11 and the other one is using Chrome Browser on PC.

I have noticed in wowza logs that even though I have mundged SDP to contain only H264 base profile it stills appear as a=fmtp:97 packetization-mode=1;profile-level-id=64C01F;sprop-parameter-sets=J2QAH6xWgKA9puBAQEDaCIRqAA==,KO48sA== on server.

I have found a bug in webkit radar https://bugs.webkit.org/show_bug.cgi?id=195124 that matches the aforementioned behaviour.

I wonder though is there anyway that I will be able to workaround it and force the Chrome on the other side to decode the video?

Here's the local SDP:

o=- 9001760195467366328 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video
a=msid-semantic: WMS 5113e7f1-363b-406e-bc68-3ae57daa0d1a
m=video 9 UDP/TLS/RTP/SAVPF 99
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:n8Ba
a=ice-pwd:2NwRnFdR5IvWpNRPiA9UqL6Q
a=ice-options:trickle
a=fingerprint:sha-256 C3:B0:13:62:B2:96:27:6F:4B:F6:97:B4:BE:3C:46:00:98:D1:98:ED:57:80:96:E9:6E:9C:33:9F:3F:2A:70:22
a=setup:actpass
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:3gpp:video-orientation
a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=sendrecv
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:99 H264/90000
a=rtcp-fb:99 ccm fir
a=rtcp-fb:99 nack
a=rtcp-fb:99 nack pli
a=rtcp-fb:99 goog-remb
a=rtcp-fb:99 transport-cc
a=fmtp:99 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=fmtp:97 apt=96
a=fmtp:100 apt=99
a=ssrc-group:FID 138058512 1765676750
a=ssrc:138058512 cname:1qSotaZJYR/SLq+u
a=ssrc:138058512 msid:5113e7f1-363b-406e-bc68-3ae57daa0d1a 6f3574c4-06ca-49fe-812f-f4e9b9d3cdbf
a=ssrc:138058512 mslabel:5113e7f1-363b-406e-bc68-3ae57daa0d1a
a=ssrc:138058512 label:6f3574c4-06ca-49fe-812f-f4e9b9d3cdbf
a=ssrc:1765676750 cname:1qSotaZJYR/SLq+u
a=ssrc:1765676750 msid:5113e7f1-363b-406e-bc68-3ae57daa0d1a 6f3574c4-06ca-49fe-812f-f4e9b9d3cdbf
a=ssrc:1765676750 mslabel:5113e7f1-363b-406e-bc68-3ae57daa0d1a
a=ssrc:1765676750 label:6f3574c4-06ca-49fe-812f-f4e9b9d3cdbf

The remote one:

o=WowzaStreamingEngine-next 2021784490 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video
a=msid-semantic: WMS *
m=video 9 UDP/TLS/RTP/SAVPF 99
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:55de6aa9
a=ice-pwd:60187779305a687c507cef701c99a6d2
a=ice-options:trickle
a=fingerprint:sha-256 35:5A:C1:C8:57:EB:46:2C:1E:98:9D:14:B8:4F:80:59:CF:7A:35:4D:57:71:47:8C:6A:9B:76:CA:EE:A9:E5:BC
a=setup:passive
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:3gpp:video-orientation
a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:99 H264/90000
a=rtcp-fb:99 ccm fir
a=rtcp-fb:99 nack
a=rtcp-fb:99 nack pli
a=rtcp-fb:99 goog-remb
a=rtcp-fb:99 transport-cc
a=fmtp:99 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f

Answer 1

It seems that regardless of the user's choice, the first profile is unconditionally selected when calling the supportedCodecs method. In my case, I solved it by modifying the supportedCodecs method in the RTCVideoEncoderFactoryH264.mm file of Google WebRTC framework to make the base profile appear first. However, I solved this because I only needed to support the baseline profile, but it would require a little more modification to make the profile selectable.