问题描述
解决方法
并非没有改变。
内部，WebRTC的内部音频/视频管道直接与编码器/解码器绑定。
PeerConnectionFactory允许您提供视频解码器/编码器工厂，因此您可以在此处短路逻辑，获取编码的帧，模拟流并将其直接作为中继传递给它，从而创建新的PeerConnection和将这些流设置到上面。
音频端比较困难。没有编解码器工厂，因此您可能必须通过更改libwebrtc来缩短那里的逻辑。
最后一个问题是RTCP终止，以及如何覆盖质量/带宽控制机制以不创建“一个出去，他们都出去”。情况。
由于libwebrtc将成为SFU，它将从其远程对等方收到RTCP反馈，以获取正在代理的内容，反之亦然。
对于1-1情况，它必须能够将RTCP反馈转发到远程对等端。
对于多点，它需要执行一些逻辑以确定对等端之一是否有问题，并停止向其发送视频，关闭其视频源或尝试切换到较低比特率的视频流。基本上，它需要充当一种管道，试图预测发生分组丢失的原因/方式，并保持尽可能多的音频/视频馈送以每个对等端的最高质量正常运行。
如何精确劫持libwebrtc中的RTCP反馈机制，我认为再次可能需要对libwebrtc进行一些自定义/挂钩
,我认为尝试使用WebRTC的GStreamer实现会更容易。尽管它仍在“不良插件”中，但它更容易获得或提供编码的音频和视频。实际上，在实现此功能时就考虑到了这一点-使MFU和SFU的实现更加容易。