现有的 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进行播放。

本文为原创稿件,版权归作者所有,如需转载,请注明出处:https://www.nxrte.com/jishu/webrtc/22099.html

(0)

相关推荐

发表回复

登录后才能评论