来自安卓应用和Chrome的WebRTC P2P视频流每秒冻结

Question

我是WebRTC的新手，创建一个P2P视频通话。我不熟悉WebRTC内部的结果。

来自Android应用程序/ Android Chrome的视频流每秒都在冻结。来自桌面浏览器的视频流& Android Firefox没有这个问题，它们工作得很好。

我试着用谷歌搜索，尝试了很多修复方法，不幸的是，没有一个有效。

例如，从Sdp中删除几行a=rtpmap:99 rtx/90000对冻结情况没有帮助。

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

提前谢谢。

下面是我的sdp示例和WebRTC内部代码，展示了Android Chrome的流媒体：

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

你的问题听起来和我几天来一直在尝试调试的东西很相似。基本上，来自安卓设备的VP8 WebRTC视频流在桌面浏览器上播放时每1-2秒就有一次微冻结(没有转弯，路由器没有拥塞，尝试了几个网络)。

在做了一些实验之后，我确信这是一个android设备的问题。我有一个小米m2 lite，这是我主要使用的。在尝试了S9，像素和其他朋友和家人的手机后，我发现这些设备在同样的条件下工作得很好，当我从我的小米m2 lite发送时，我会看到1-2秒的持续冻结。

当我有机会的时候，我想挖掘更多的潜在原因，但试着看看使用另一个android设备是否能为你解决这个问题。