问webRTC - JavaScript getUserMedia和RTCPeerConnection client:在5-10分钟后感知吞吐量延迟和崩溃问题与缩放

EN

这确实是一个初步的事实发现问题:在过去，我们一直使用Zoom来促进我们的音频/视频会议(实际上是教师:1次学生会议)。现在，我们已经开发了自己的内部JavaScript客户端来做同样的事情。我们有一个刚刚测试过的原型。在这次考试中(1名教师和1名学生)一开始似乎进展得很好。但是我们注意到，( a)发送方和接收方之间的音频和视频轨道接收似乎比Zoom应用程序滞后，b)在短时间间隔(5-10分钟会话持续时间)中，一方崩溃，需要再次启动音频/视频会话(getUserMedia，然后是RTCPeerConnection协议功能和onicecandidate，需要进行在线协商，并向我们的信令服务器进行在线回调)。显然，由于这是在原型阶段，因此需要修复错误，但我想知道像Zoom这样的应用程序是否确实使用了与我们相同的webRTC协议和功能，或者它是否正在通过自己的内部库来解决一些与预传输问题有关的相当复杂的问题，比如编解码和多媒体数据压缩，然后实际处理数据分组的udp传输。非常感谢对此有一些想法的人！

伊凡:非常感谢--了解一下这方面的背景是很有用的。我们知道组件，并在三年前使用它将.wav压缩为.mp3 (尽管使用了预先构建的wasm模块)。

伊凡:非常感谢。是的，我们知道关于组件-实际上我们做了一些工作在两年前使用预先构建的.wav模块将.mp3压缩成.mp3格式。移动设备不适用于我们的主要应用程序。关于受限网络，你所说的也是有用的，但我们认为主要问题是网络速度。我们对所有用户进行了快速检查，主要分为两组，网络速度分别为3-14 Mbps和100-120 kbps。主要而言，我们的用户是在家里工作的学生，他们要么在Wifi路由器后面工作，要么正在连接到移动电话。Wifi路由器似乎给出了Mps的范围，而与移动电话连接的Mps可能等于Mps的数字，但取决于一天中的时间或接近一个数据信号，可能下降到100-120 kbps，甚至更低。我们怀疑正在发生的情况是，那些发送视频/音频有问题的人是那些可用带宽下降到100 kbps以下的人(我们发现在这种情况下，发送方仍然可以看到和听到接收到的视频，但是他们的对手开始抱怨视频帧丢失-黑屏幕，然后没有音频)。有趣的是，Zoom应用程序似乎能更好地处理降级的情况，但我们真的不知道为什么。这促使我问webRTC是否需要最小带宽，以及它如何计算发送方/接收方的比特率--我猜想后者的计算将取决于前者，并考虑到网络摄像头的固有特性。是否有办法在考虑到这种退化情况下的网络条件的情况下，在运行中进行某种配置？

问这个问题的原因是试图在这些降级的情况下保持视频聊天(尽管是降低了比特率/分辨率/帧率)。