现有的 WebRTC 对于广播用例来说并不出色

WebRTC最初是为与少数参与者进行实时通信而设计的，其中对延迟的要求极为严格（通常<250ms）。然而，它也被利用于广播用例，如YouTube Studio或Cloudflare CDN，过去使用的协议是不同的，通常是Adobe的RTMP和基于HTTP的协议。

WebRTC提供了一系列新的广播用例，特别是那些需要超低延迟的用例，如那些具有观众互动性的用例，例如用户反应或拍卖用例。然而，选择WebRTC是有代价的，包括增加的复杂性、可扩展性挑战或较低的质量。虽然有可能通过足够的时间和努力来解决前两个问题，但首要问题应该是如何获得尽可能好的质量。

为什么我们在使用WebRTC时质量较低？

首先，要澄清一下。 在一个拥有无限带宽的完美网络中，质量没有太大差别，但在其他受限或不稳定的网络中，这些是WebRTC比基于RTMP和HTTP的解决方案提供较低质量的一些原因：

• 较小的缓冲区： WebRTC实现通过使用小的缓冲区来优先考虑延迟而不是质量，这些缓冲区有时会太小而无法及时接收重传。基于TCP的协议采用大的缓冲区，将质量放在优先于延迟的位置，不会面临这个问题。

• 积极的拥堵控制： WebRTC采用了积极的拥堵控制，在检测到拥堵时迅速减少视频传输，以防止延迟增加和潜在的数据包丢失。 这有助于拥有更多的预测性低延迟，但在许多情况下，不那么积极会以更高的延迟为代价保持更高的质量。

• 只有实时的可靠性： 如果你失去连接几秒钟，WebRTC不会在你恢复时排队传送媒体。 同样，它也不会在一个新的帧被解码后恢复先前的帧。 这方面最明显的影响是在服务器端录音的情况下。

• 快速编码：WebRTC编解码器的配置针对速度进行了优化，不使用双通编码或双向预测帧，而是使用保守的设置来确保快速编码。然而，这意味着编码效率不如广播应用，导致在给定的比特率下，编码效果略差。

• 不可预测的比特率： WebRTC不能使用2次编码的事实使得编解码器的质量/比特率决定不那么理想和不稳定。

说实话，如果你能控制WebRTC的实现（例如在移动或桌面原生应用中），这些限制中的一些可以得到解决，但对于WebRTC协议栈嵌入浏览器的网络应用来说，这并不容易，甚至不可能。

我们应该为交互式广播做什么？

理想情况下，我们需要一个协议，我们可以在从实时（<250ms）到传统广播（5-10秒）的范围内配置可接受的延迟。 一旦这个限制被设定，协议就需要在这些条件下提供尽可能好的质量。 这是可以做到的，我们可能会以其中一种或两种方式看到它：

更加可调谐的WebRTC。 随着WebRTC APIs的一些更多的灵活性，应该可以克服上一节中描述的限制。 例如，像RTCPeerConnection.congestionControl = “low latency “这样的可配置的拥堵控制，或新的WebCodecs API中的一些较低级别的API。

通过UDP工作的新协议，重新使用一些WebRTC技术，但提供更多的灵活性（例如，像RUSH这样的新QUIC协议）。 使用这些从头开始创建的协议的实现可以克服大部分的限制，因为他们把部分问题（缓冲或编码）留给了应用程序。 尽管他们也需要有控制拥堵控制行为的能力。

那么，我是否应该使用WebRTC？

我只有在真正需要的时候才会使用它，并且提供足够的商业价值，使它值得额外的复杂性和潜在的质量下降。 对于传统的足球比赛流媒体来说，可能不需要它，而对于与观众互动的流媒体来说，它可以提供真正的价值，质量的损失可能值得在参与方面的好处。

此外，我们需要记住，我们不需要有一个端到端的WebRTC。 例如，在一些情况下，如果只需要在发言人之间有低延迟，那么使用WebRTC进行摄取，但继续使用HLS进行播放，可能是有意义的。 或者在某些情况下，使用RTMP从具有良好连接性的广播公司摄取，并使用RUSH进行播放。