iOS 12 WebRTC stream 與 H264 High Profile 一起發送，即使雙方同意 Base Profile

Question

我正在開發一個使用 Wowza 創建調用的 WebRTC 流應用程序。 我在兩個客戶端之間的連接出現問題，其中一個使用 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

Answer 1

似乎無論用戶的選擇如何，在調用supportedCodecs方法時都會無條件地選擇第一個配置文件。 就我而言，我通過修改 Google WebRTC 框架的 RTCVideoEncoderFactoryH264.mm 文件中的 supportedCodecs 方法來解決它，使基本配置文件首先出現。 但是，我解決了這個問題，因為我只需要支持基線配置文件，但需要進行更多修改才能使配置文件可選。