0

WebRTC编解码器vs媒体引擎-3

已有 235 阅读此文人 - - 媒体服务器,编解码 -

作者:AGOUAILLARD(原文链接

翻译:刘通

原标题:Webrtc Codec vs Media Engines: Implementation Status and why you should care.

前文链接:WebRTC编解码器vs媒体引擎-1WebRTC编解码器vs媒体引擎-2

抖动及丢包

这些是最难处理的问题。抖动比较容易解决,首先创建一个缓冲区,由于所有的数据包都是编了号的,所以你可以把它们恢复成原来的顺序。在实时状态下,你不希望抖动太严重,否则你可能会等待过久才能将抖动问题恢复,这就会让你超过了实时的界限(33ms端到端延迟)。使用大的抖动缓冲区可能会有帮助。

丢包通常是通过重发数据包(RTX)来解决。如果从发送端到SFU并且返回所需的时间(RTT)要短于33ms的约束。那么我们就有足够的时间在数据包过期之前进行重传。如果这么做还不够的话,或者网络不好(丢包率超过0.01%),则需要实施更高级的错误消除算法,如FEC。

一个更好的方法再次使用到了SVC 编解码器。由于各层交织的方式,以及只需要基础层来进行呼叫,你可以重传与基础层相对应的数据包的时间窗是RTT的几倍。这意味着只需要重新传输数据包就可以弥补非常差的网络状况(1%+的丢包率),并且不会丢失通话的连续性。虽然同播只是带宽管理的其中一种解决方案,SVC 编解码器是解决带宽波动和网络质量的解决办法。

4. 各种浏览器的当前状态

当涉及到媒体引擎时,Firefox和Safari 浏览器会跟Google保持一致。他们只是偶尔更新他们的libwebrtc的内部副本,而不会遵循Google Chrome的发布时间表(每6周)。他们可能有一点更新不同步,但是最后也都赶上了,除了Safari 浏览器中的VP8 编解码器。

你可以通过下面的表格来了解完整性,通常我们都会忽略Edge 浏览器。今天,你必须在支持 iOS Safari和高质量之间选择一个。 iOS Safari一方面只支持H.264,另一方面libwebrtc仅使用VP8和SVC与VP9实现同播。

当我们在 iOS中已经有正常的H.264支持时,同播有多重要?大多数情况下,客户不会原谅你在互操作性方面所做的降低质量的行为。如果你想以同级别的质量支持 iOS系统,那么请你立刻转用原生版本。

codec31

5. 未来

很显然,VP8将无法在Safari 浏览器中使用。同样可以推断VP9也没有什么可能。

虽然早些时间,通过支持HLS可以看出苹果似乎想要在WebRTC中加入H.265的支持。但是它最近嘉瑞了开放媒体联盟和一些其他小东西,让我认为AV1可能是接下来会出现的东西。这只是我的一个个人想法。

在任何情况下,AV1参考编码器离实时标准都差的比较远,参考硬件速度为0.3fps。虽然对于预先录制好的内容来说可能不会出现这样的问题,但是对于实时媒体而言这是绝对无法接受的。至少需要一年的时间才可能达到足以能在RTC中使用的速度。

同时,在非RTC用例中,由于采用了bitmovin(高延迟,非webrtc)流媒体技术,你可以在Firefox 浏览器中播放预编码的AV1文件。他们的创始人发明了MPEG-DASH,并宣布筹集3000万美元以准备下一代视频基础架构。





加入WebRTC技术交流群,免费获得学习资料,交流经验
群号:659922087
q群
期待你一针见血的评论,Come on!

不用想啦,马上 "登录"  发表自已的想法.