我正在开发一个WebRTC流应用程序，它使用Wowza来创建调用。我在两个客户端之间的连接中遇到问题，而其中一个客户端使用的是iOS 12或iOS 11，另一个客户端使用的是PC上的Chrome浏览器。
我在 wowza 日志中注意到，即使我已经将 SDP 修改为仅包含 H264 基本配置文件，它仍然在服务器上显示为a=fmtp:97 packetization-mode=1;profile-level-id=64C01F;sprop-parameter-sets=J2QAH6xWgKA9puBAQEDaCIRqAA==,KO48sA==。
我在 webkit 雷达 https://bugs.webkit.org/show_bug.cgi?id=195124 中发现了一个与上述行为匹配的错误。
我想知道无论如何我是否能够解决它并强制另一侧的 Chrome 解码视频？
以下是本地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
远程的：
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
似乎无论用户的选择如何，在调用支持的编解码器方法时都会无条件选择第一个配置文件。就我而言，我通过修改Google WebRTC框架 RTCVideoEncoderFactoryH264.mm 文件中支持的Codecs方法来解决它，以使基本配置文件首先出现。但是，我解决了这个问题，因为我只需要支持基线配置文件，但它需要更多的修改才能使配置文件可选。