WebRTC系列分享 | WebRTC视频QoS全局技术栈

最新推荐文章于 2024-07-18 17:48:23 发布

音视频开发老马

最新推荐文章于 2024-07-18 17:48:23 发布

阅读量207

点赞数

文章标签： webrtc 音视频

本文链接：https://blog.csdn.net/yinshipin007/article/details/134148783

版权

本文深入探讨了WebRTC中用于提升视频服务质量（QoS）的技术，包括NACK、FEC、SVC、JitterBuffer、IDR Request、Pacer、Sender Side BWE、Probe、动态帧率调整、音视频同步和动态分辨率调整策略。这些机制协同工作，以应对网络变化，确保视频通话的流畅性和质量。

摘要由CSDN通过智能技术生成

导语 | WebRTC真是一套让人既爱又恨的开源代码。一方面，WebRTC里面有一套很完善很系统的QoS策略。但另一方面，WebRTC代码庞大且版本更新迭代特别快，代码的阅读和学习难度很大。为了方便大家学习了解，我们在这里对WebRTC的QoS思想及算法实现做了一些梳理总结，以系列分享的方式呈现给大家，供大家参考。

概述

目前总结出WebRTC用于提升QoS的方法有：NACK、FEC、SVC、JitterBuffer、IDR Request、Pacer、Sender Side BWE、Probe、VFR（动态帧率调整策略）、AVSync（音视频同步）、动态分辨率调整。这几种方法在WebRTC架构分布如下：

具体实现原理

1. NACK

与NACK对应的是ACK，ACK是到达通知技术。以TCP为例，他可靠因为接收方在收到数据后会给发送方返回一个“已收到数据”的消息（ACK），告诉发送方“我已经收到了”，确保消息的可靠。

NACK也是一种通知技术，只是触发通知的条件刚好的ACK相反，在未收到消息时，通知发送方“我未收到消息”，即通知未达。

NACK是在接收端检测到数据丢包后，发送NACK报文到发送端；发送端根据NACK报文中的序列号，在发送缓冲区找到对应的数据包，重新发送到接收端。NACK需要发送端发送缓冲区的支持，RFC5104定义NACK数据包的格式。若在JB缓冲时间内接收端收到发送端重传的报文，就可以解决丢包问题。对应上图发送端的RTCP RTPFB。