1 建立线性模型
使用RTP 包发送 RTCP包回馈拿到延时时间，计算抖动，什么是抖动呢，多个数据包之间的延时不相同就叫抖动，非常简单，第一次发送延时20ms， 第二次发送延时10ms， 第三次发送延时 15ms，抖动约为5毫秒，如果抖动的数据增多，是可以给抖动增加一个模型验算的。Google Congestion Control（WebRTC中所用），SCReAM以及SPROUT算法都是控制算法。
a1 * x + a2 = y
基本都是线性模型，这里是算法的IETF文档描述
现在的webrtc使用发送端带宽估计，这样做的话，所有的决定逻辑都会在一个地方（发送端），让测试新算法变得更简单，因为你不需要同时取决于两个端点，不过，在测试过程中，的确没有发现什么多大的改变，该卡还是卡，也就是说代码和实际其实是两回事。真正可用的，只有在实际会议中所用，使用探测带宽的1/2 , 这样不用在网络发生改变的时候改变策略，从而减少抖动。
2 回馈计算发送时间延时
2 发送一定是从大的数据流到小的数据流，生成数据后RTP报头的序列号和时间戳使用正确的序列，可以同时发送多个流的RTP包，可以同时验算是否可以同时发送多路流
如视频的按照增量算法时间戳 ，基数时钟 90000 ，如时间戳间隔 3600，根据rtp协议 m位 的判断，很容易就知道是25帧的视频，间隔如果为3000，立刻知道是30帧的视频，根据时间戳可以生成对端发送的物理时钟点，毫秒级别，如果有np 时间服务器对时，是可以推算整个的时间延时的。反馈包使用RTCP的扩展包进行传送，也可以自已定义，协议就是如此，协商就行。
3 不对称性和丢包
注意发送带宽和接收带宽的不对称性，一般探测的是发送带宽，视频会议这种发送随着人数的增加有不确定性，需要带宽预留。 丢包
无论是h264 h265 opus等算法发送都需要探测序列号的丢失，丢包等等影响解码，不然花屏等等影响体验，m 位和FU 分包的丢失判断是一个技巧，webrtc使用算法来决定发送，怎么做？难道你还能把帧率发送变慢？势必带来延时，发送端的丢包和接收端的丢包如果做？如果接收端丢包，只不过是体验提高罢了，发送端如果做才是关键。
3.1 丢弃非参考帧，保留参考帧
3.2 准备多路编码器，在带宽下降的情况下，使用小分辨率，同时丢弃大分辨率，并且准备下一个更小的分辨率，这就是我们的做法。
4 极致
极致效果下，可以使用边缘检测来发送图像，不行全部丢弃，直留音频
5 webrtc 中的多路码流示意
const SimulcastFormat kSimulcastFormats[] = {
{1920, 1080, 3, 5000, 4000, 800},
{1280, 720, 3, 2500, 2500, 600},
{960, 540, 3, 900, 900, 450},
{640, 360, 2, 700, 500, 150},
{480, 270, 2, 450, 350, 150},
{320, 180, 1, 200, 150, 30},
{0, 0, 1, 200, 150, 30}
};
webrtc无疑给大众开发者带来很多便利，但是代码太多，编译不便，修改也不是很简便，从底层开发，使用plain RTP 和FEC算法，对端探测，无疑更为简便，更好的是，可以非常容易地接上webrtc，webrtc使用srtp，只需要在rtp上加入secure ，就可以非常容易地接上webrtc的SFU，这是一条思路，在实验中，我们已经成功地将plainRTP 和 webrtc成功对接，webrtc 也可以转成RTMP，flv等常规直播流。
说句实话，是算法决定网络，还是网络决定算法。就像人的思想和身体一样。