本文主要是介绍【音视频】remb twcc原理，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
目录
WebRTC REMB
参考文档
twcc简介
TWCC全称是Transport wide Congestion Control，是webrtc的最新的拥塞控制算法。其原理是在接收端保存数据包状态，然后构造RTCP包反馈给发送端，反馈信息包括包到达时间、丢包状态等；在发送端进行带宽估计，进行拥塞控制。
发送方带宽估计有什么好处？谷歌解释的理论是，通过这种方式，所有的决策逻辑都在一个地方（发送方），因此可以轻松测试新算法，因为你不依赖两个端点。老实说，考虑到浏览器自动更新，我不认为这一点有什么大的优势，但它肯定更干净，即使它在带宽使用方面更昂贵。另一个优点是，发送者知道他正在发送的流量类型，并且可以在发送普通视频时使用不同的算法，例如在进行屏幕广播时。我们受到影响了吗？如果您正在构建的媒体服务器需要对任何内容进行带宽估计（例如，在使用simulcast时决定转发的质量），您将需要在某个时候升级您的实现。好消息是Chrome必须支持旧机制（REMB）一段时间，至少在Firefox支持之前是这样。但是REMB可能不会得到更多的改进，而且它现在更有可能出现bug，所以推迟更改可能不是一个好主意。Chrome 55的默认设置是发送端带宽估计，但这项工作仍在进行中，我们预计会有很多变化。官方标准化正在RMCAT集团的IETF中进行，但Chrome中可用的大部分实现都是谷歌自己版本的算法和反馈协议的进行中规范。（古斯塔沃·加西亚）
WebRTC REMB
WebRTC REMB（Receiver Estimated Maximum Bitrate）是一种带宽估计算法，用于在WebRTC中动态地调整视频发送端的码率，以适应网络带宽的变化。
在实时通信中，网络带宽的变化经常会影响视频的质量和流畅度。为了解决这个问题，WebRTC提供了一种带宽估计算法，即REMB。该算法基于接收端对视频数据的缓存情况和网络状况等信息，动态地估计可用的带宽，并向发送端发送估计值。发送端可以根据该估计值适当地调整视频的码率和分辨率，以达到最佳的视听体验。
具体来说，REMB算法的基本原理如下：
接收端监测缓存：接收端会定期监测自己的视频缓存情况，包括缓存的大小、缓存时间等指标。
发送端发送带宽估计值：当缓存情况较好时，接收端会向发送端发送一个带宽估计值，告诉发送端当前的可用带宽。
发送端根据估计值调整码率和分辨率：发送端会根据接收端发来的带宽估计值，适当地调整视频的码率和分辨率，以适应当前的网络带宽。
重复上述过程：整个过程会不断地重复执行，以实现动态的带宽估计和调整。
WebRTC REMB是一种常用的带宽估计算法，可以帮助实时通信系统在不同网络条件下保持最佳的视听体验。它基于接收端对视频缓存情况和网络状况的监测，动态地估计可用的带宽，并向发送端发送估计值，使得发送端可以根据估计值适当地调整视频的码率和分辨率
参考文档
WebRTC带宽估计_webrtc 带宽估计-CSDN博客
webrtc twcc接收端处理在Nginx RTC SFU 服务端的实现_webrtc_龙--技术总结分享-即构开发者社区 (csdn.net)
这篇关于【音视频】remb twcc原理的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
