未命名SFU-用于教学/会议的开源一对多视频会议

以下服务器端功能已规划，但尚未实现：在客户端、→和服务器方向完成基于REMB的拥塞控制(比当前基于丢失的算法对拥塞的反应更早)；当服务器负载过重时动态降低视频质量(易于实现，但难以调整)；同时广播，能够拥有不同质量的多个流，并根据拥塞指示动态选择哪个流去往哪个客户端；服务器联合(能够在欧洲有一台服务器，在北美有一台服务器，并且只有一个流。

我不确定我是否知道如何实现以下功能：传输控制拥塞控制(可能需要更改我正在使用的服务器端WebRTC库Pion WebRTC)；动态调整NACK缓冲区的大小(需要准确的RTT信息，我们有吗？)。

与服务器不同，客户端相当原始(虽然我更喜欢Javascript，但我非常讨厌CSS)。它有以下功能：计划中的功能包括一个基本的白板和不依赖窗口共享的流式幻灯片的能力(因为Wayland)。我们在5美元的VPS上举办了一个有12位同时发言的人的会议(音频和视频各有12个上行数据流和132个下行数据流)。我们不需要人为地限制视频质量。60%的CPU，120Mbit/s流量，占用的RAM不到200MB(主要用于NACK恢复的缓冲区)。在4核CPU上的测试表明，该服务器可以很好地扩展到4核。除了4个内核之外，我没有做过任何测试。与端到端加密所有媒体并将服务器视为不受信任通道的(未命名SFU)不同，(未命名SFU)假定服务器是受信任的：所有媒体在发送到客户端之前都由服务器解密并重新加密。据我所知，使用WebRTC使用的安全机制DTLS-SRTP，这是不可避免的。另一方面，由于客户端不受信任，客户端代码中的任何错误都不应该造成安全问题。因此，使用Web开发人员倾向于喜欢的难以理解的Javascript框架构建用户友好的客户端是合理的。但是请注意，我既不是安全专家，也不是胜任的系统管理员，我可能弄错了；不要对关键数据使用(未具名的SFU)。现在还不行。