来自Android App和Chrome的WebRTC P2P视频流每秒冻结一次

Question

我是WebRTC的新手，正在创建P2P视频通话。我对WebRTC Internals的结果不熟悉。

来自Android APP / Android Chrome的视频流每秒都冻结。来自桌面浏览器和Android Firefox的视频流没有此问题，它们运行得很好。

我尝试四处搜索并尝试了许多修复程序，但不幸的是，它们均无效。

例如，从Sdp中删除几行a = rtpmap：99 rtx / 90000不会解决冻结问题。

我可以知道如何解决此冻结问题吗？

谢谢。

下面是我的sdp示例和显示来自Android Chrome的流的WebRTC内部：

sdp: "v=0
↵o=- 3972593082164766939 2 IN IP4 127.0.0.1
↵s=-
↵t=0 0
↵a=group:BUNDLE 0 1
↵a=msid-semantic: WMS EtmQlEiR4ZAgQ38QPrvlsfqvIW6y5jIO4rlX
↵m=audio 9 UDP/TLS/RTP/SAVPF 111 103 9 0 8 105 13 110 113 126
↵c=IN IP4 0.0.0.0
↵b=AS:50↵a=rtcp:9 IN IP4 0.0.0.0
↵a=ice-ufrag:w412
↵a=ice-pwd:qGY+GHRYFr1xVUacGk0HTwAP
↵a=ice-options:trickle
↵a=fingerprint:sha-256 7C:8C:5F:60:AB:DA:D0:9F:3B:69:84:3E:E2:42:60:43:DC:D7:83:B4:FD:A9:63:57:F4:8E:F5:97:34:93:58:A8
↵a=setup:actpass
↵a=mid:0
↵a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
↵a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
↵a=extmap:13 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
↵a=extmap:14 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
↵a=sendrecv
↵a=msid:EtmQlEiR4ZAgQ38QPrvlsfqvIW6y5jIO4rlX 6b9a5836-9a1f-4f9d-b3ea-d6fc5767ed36
↵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:1792162923 cname:Nhh1YQUo6/iSppuB
↵a=ssrc:1792162923 msid:EtmQlEiR4ZAgQ38QPrvlsfqvIW6y5jIO4rlX 6b9a5836-9a1f-4f9d-b3ea-d6fc5767ed36
↵a=ssrc:1792162923 mslabel:EtmQlEiR4ZAgQ38QPrvlsfqvIW6y5jIO4rlX
↵a=ssrc:1792162923 label:6b9a5836-9a1f-4f9d-b3ea-d6fc5767ed36
↵m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 127 104
↵c=IN IP4 0.0.0.0
↵b=AS:300↵a=rtcp:9 IN IP4 0.0.0.0
↵a=ice-ufrag:w412
↵a=ice-pwd:qGY+GHRYFr1xVUacGk0HTwAP
↵a=ice-options:trickle
↵a=fingerprint:sha-256 7C:8C:5F:60:AB:DA:D0:9F:3B:69:84:3E:E2:42:60:43:DC:D7:83:B4:FD:A9:63:57:F4:8E:F5:97:34:93:58:A8
↵a=setup:actpass
↵a=mid:1
↵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=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
↵a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
↵a=extmap:10 http://tools.ietf.org/html/draft-ietf-avtext-framemarking-07
↵a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/color-space
↵a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
↵a=extmap:13 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
↵a=extmap:14 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
↵a=sendrecv
↵a=msid:EtmQlEiR4ZAgQ38QPrvlsfqvIW6y5jIO4rlX 2e2527ac-925e-4aca-8ffc-f33582d680a5
↵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 H264/90000
↵a=rtcp-fb:100 goog-remb
↵a=rtcp-fb:100 transport-cc
↵a=rtcp-fb:100 ccm fir
↵a=rtcp-fb:100 nack
↵a=rtcp-fb:100 nack pli
↵a=fmtp:100 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
↵a=rtpmap:101 rtx/90000
↵a=fmtp:101 apt=100
↵a=rtpmap:102 red/90000
↵a=rtpmap:127 rtx/90000
↵a=fmtp:127 apt=102
↵a=rtpmap:104 ulpfec/90000
↵a=ssrc-group:FID 1909059520 686539247
↵a=ssrc:1909059520 cname:Nhh1YQUo6/iSppuB
↵a=ssrc:1909059520 msid:EtmQlEiR4ZAgQ38QPrvlsfqvIW6y5jIO4rlX 2e2527ac-925e-4aca-8ffc-f33582d680a5
↵a=ssrc:1909059520 mslabel:EtmQlEiR4ZAgQ38QPrvlsfqvIW6y5jIO4rlX
↵a=ssrc:1909059520 label:2e2527ac-925e-4aca-8ffc-f33582d680a5
↵a=ssrc:686539247 cname:Nhh1YQUo6/iSppuB
↵a=ssrc:686539247 msid:EtmQlEiR4ZAgQ38QPrvlsfqvIW6y5jIO4rlX 2e2527ac-925e-4aca-8ffc-f33582d680a5
↵a=ssrc:686539247 mslabel:EtmQlEiR4ZAgQ38QPrvlsfqvIW6y5jIO4rlX
↵a=ssrc:686539247 label:2e2527ac-925e-4aca-8ffc-f33582d680a5
↵"

Answer 1

您的问题听起来与我几天来一直在尝试调试的问题类似。基本上，来自Android设备的VP8 WebRTC视频流在台式机浏览器上播放期间每1-2秒微冻结（不转弯，路由器不拥塞，尝试了多个网络）。

进行了几次实验后，我确信这是一个android设备问题。我有一个小米m2 lite，主要是我使用的。在尝试了S9，Pixel和其他亲朋好友的电话之后，我发现这些设备在从小米m2 lite发送邮件时看到1-2秒持续定格的相同条件下可以正常工作。

当我有机会的时候，我想进一步探究根本原因，但是尝试看看是否使用另一个Android设备为您解决了这个问题。