该文章系总结性文章,主要参考一下文章:
1、webrtc视频jitterbuffer原理机制(描述版) - 简书
http://www.jianshu.com/p/bd10d60cebcd
2、WebRTC视频接收缓冲区基于KalmanFilter的延迟模型 - 简书
http://www.jianshu.com/p/bb34995c549a
3、WebRTC基于GCC的拥塞控制(上) - 算法分析 - 简书
http://www.jianshu.com/p/0f7ee0e0b3be

此三篇文章共同构成WebRTC带宽自适应的算法体系(以下简称自适应算法)!之所以作总结,是因为这三篇文章针对不同的侧重点进行叙述,而又互相影响,很容易搞混这里面的相关概念、作用、关系是什么。本篇文章通过把这三篇文章做一个串讲,并加上自己的理解,进而还原一个更加清晰的完整的算法流程,而不是针对某一个点来理解。

开始之前,首先要了解RTP/RTCP协议,简答来说就是,TCP有丢包重传机制保证包的的可靠性,但是UDP没有,于是引入RTP/RTCP,通过把UDP封装成RTP包,添加各种其他信息,由RTCP的来控制RTP包的乱序、丢包、抖动等等,其实是TCP的会话的“中庸版本”,为的就是在保证一定延时的情况下,增加数据包的可靠性!具体细节请参考其他文章,本文不做详述!

好,开始进入正题!

一、
首先要理解自适应算法的目的是什么?简单来讲就是“拥塞控制”!
但是具体点呢?优化延时、丢包、抖动的平衡!
再具体呢?调整发端速率、修正接收缓冲

其中优化丢包策略包括:
1、通过降低码率,缓解拥塞来实现;
2、发起重传来解决!——>将增大延时
3、增大接收等待延时!——>将增大延时
而优化延策略包括:
1、降低码率,缓解拥塞;
最后优化抖动的策略包括
1、降低码率,缓解拥塞!
2、为了对抗已经产生的延时抖动带来的影响,需要增加接收缓冲区。

我们可以到:优化丢包和抖动是在牺牲延时的基础上进行的!

二、
了解了目的,我们开始讲解实际优化的方法!

对于码率:
GCC算法使用发端基于丢包的算法来计算当前带宽,在接收端基于排队延时的算法来计算当前呆卵。然后接收端把自己估计的带宽返回给发端,发端通过比较来选取合适的算法;
对于抖动:
基于排队延时等参数(后续详述)计算抖动时延,从而确认接收缓冲区大小和等待渲染时间,以消除抖动带来的影响!

所以收端其实做了两件事:带宽估计、抖动优化!其中带宽估计本身就优化了发送码率,降低下一时刻的网络抖动,而抖动优化是为了对上一时刻受抖动影响的数据包进行优化,使其平稳渲染!

那么怎么计算带宽和抖动延时呢?
这里面的算法的有两层:一层是谷歌自己提出的计算公式;另一层是卡尔曼滤波!

首先谷歌建立了一个模型,认为两帧之间的延迟具有下列关系:

/////////////////////////////////////////////////////////////////
d(i) = t(i) – t(i-1) – (T(i) – T(i-1)) = [t(i) - T(i)] - [t(i-1) - T(i-1)]=FrameSize(i)/c(i) - FrameSize(i-1)/c(i-1)
/////////////////////////////////////////////////////////////////

T(i)是第i个数据包组中第一个数据包的发送时间,t(i)是第i个数据包组中最后一个数据包的到达时间,它们的差就是从发端开始到收端接收完需要的时间,正好等于(数据包长度 除以 信道速率)——联想火车过桥的数学问题就是这样计算的;于是问题就来了,信道长度和信道速率是个时变的函数,即每时每刻都不是一个定值,这个时候就用到随机过程了。此时我们假设链路长度和速率在i时刻和i-1时刻是相等的,那么:

/////////////////////////////////////////////////////////////= [FrameSize(i)- FrameSize(i-1)]/C + w(i)= deltaFSBytes/C + m(i) + v(i)
/////////////////////////////////////////////////////////////

其中w(i)就是为了修正我们的假设导致的不正确而引入的白色高斯过程,也就是由于链路状态不稳定带来的随机延时:这里我们认为,白色高斯过程由两部分组成:排队时延m(i)+白色噪声v(i)(0均值噪声)

这里我们就看到了一个很重要的参数:排队时延!基于延时的带宽估计就根据这个值来算出来的。而这个值得计算过程就是卡尔曼滤波计算出来的——卡尔曼滤波请移步相关参考文档!

这里面通过卡尔曼滤波计算出来的m(i)结合阈值γ等参数来确定当前网络的三种状态:过载、空闲、保持,从而调整速率!——具体调整算法移步相关参考文档!

但是,卡尔曼滤波计算出来的值、以及计算的带宽值不仅仅用在这里,还用在抖动延时的优化计算中了!也就是JitterDelay的计算,在GCC算法中,JitterDelay由两部分延迟造成:传输大帧引起的延迟和网络噪声引起的延迟:

///////////////////////////////////////////////////////////////
JitterDelay =  (MaxFS – AvgFS)/c + noise=    (MaxFS – AvgFS)/c + [noiseStdDevs * sqrt(varNoise) – noiseStdDevOffset]
//////////////////////////////////////////////////////////////

C已经由上述带宽估计算法估算出来,MaxFS是自会话开始以来所收到的最大帧大小,AvgFS表示平均帧大小
noiseStdDevs表示噪声系数2.33,varNoise表示噪声方差,noiseStdDevOffset是噪声扣除常数30。
所以,我们求JitterDelay实际上即使求noise——>实际上就是求varNoise!

///////////////////////////////////////////////////////////////
varNoise = alpha*varNoise + (1 – alpha)*(residual – avgNoise)^2
residual = d – (deltaFSBytes/c + m)
avgNoise = alpha*avgNoise + (1-alpha)*residual
alpha = pow(399/400, 30/fps)
////////////////////////////////////////////////////////////////

其中alpha表示概率系数,受帧率fps影响:当fps变低时,alpha会变小,表示当前噪声变大,噪声方差受当前噪声影响更大一些。实时帧率越接近30 fps越好。residual计算延迟残差(反映网络噪声的大小),avgNoise表示自开始以来的平均噪声。deltaFS表示帧间大小差值,c表示信道传输速率,m表示网络排队延迟。( d – (c * deltaFSBytes + m)就是上文的 d(i) = deltaFSBytes/C + m(i) + v(i)引入的),通过上述计算,我们更新了“当前”JitterDelay,从而调整渲染等待时间、缓冲区大小,进而消除抖动带来的不平滑渲染,但这是一牺牲延时为代价的!——具体调整方法请移步参考文档!

所以可以看出,卡尔曼滤波是极其重要的一环:一方面计算出来的m(i)值(排队时延)用于调整发送速率c(i);另一方面要通过排队时延m(i),和由排队时延计算出来的发送速率c(i)计算JitterDelay,来调整等待渲染后时间!

再次注意!!!!!本文为了减少不必要的重复性,卡尔曼滤波、带宽估计(包括发端和收端)、Jitterbuffer等知识都没有叙述!本文只是搭建了这几个重要算法的桥梁联系作用,用于读者明白这几个算法之间是如何相互影响的。

WebRTC自适应控制算法相关推荐

  1. 四轴自适应控制算法的一些尝试开源我的山猫飞控和梯度在线辨识自适应等算法—(转)...

    本文的最主要目的在于抛砖引玉,阿莫论坛真的是非常好的一个论坛,没有这个论坛,没有那么多这个论坛上的前人无私的奉献和热烈的讨论,我想我是怎么也无法入门四轴的控制的.只是论坛上已经很多年都没有看到过新东西 ...

  2. 四轴自适应控制算法的一些尝试开源我的山猫飞控和梯度在线辨识自适应等算法—(转)

    本文的最主要目的在于抛砖引玉,阿莫论坛真的是非常好的一个论坛,没有这个论坛,没有那么多这个论坛上的前人无私的奉献和热烈的讨论,我想我是怎么也无法入门四轴的控制的.只是论坛上已经很多年都没有看到过新东西 ...

  3. 四轴自适应控制算法的一些尝试开源我的山猫飞控和梯度在线辨识自适应等算法

    这篇文章被同时发在这里和 阿莫论坛的四轴飞行器区 http://www.amobbs.com/thread-5539404-1-1.html 本文的最主要目的在于抛砖引玉,阿莫论坛真的是非常好的一个论 ...

  4. 永磁同步电机的MRAS模型参考自适应控制算法,matlab,仿真模型。

    永磁同步电机的MRAS模型参考自适应控制算法,matlab,仿真模型. ID:6965667815721072

  5. 小议WebRTC拥塞控制算法:GCC介绍

    网络拥塞是基于IP协议的数据报交换网络中常见的一种网络传输问题,它对网络传输的质量有严重的影响,网络拥塞是导致网络吞吐降低,网络丢包等的主要原因之一,这些问题使得上层应用无法有效的利用网络带宽获得高质 ...

  6. WebRTC拥塞控制算法——GCC介绍

    刘心坤 网易资深研发工程师 对高性能网络设备.系统软件的开发等领域有浓厚的兴趣 作者简介 网络拥塞是基于IP协议的数据报交换网络中常见的一种网络传输问题,它对网络传输的质量有严重的影响, 网络拥塞是导 ...

  7. 基于自适应控制算法的温控系统研究

    第1章 前言 1.1 问题描述 上图是一个温度虚拟被控对象和虚拟输入输出通道示意图. 虚拟被控对象的数学模型结构为: 其中y为热电偶测量输出(测量范围最大300℃),u为输入蒸汽阀门开度(数据范围0至 ...

  8. 单神经元自适应控制算法,bp神经网络缺点及克服

    为什么BP神经网络是有限自适应的? 算法都是有自身的缺陷的吧,要不也不会出现这么多的神经网络改进的算法,但是BP神经网络对大多数的问题都是有一定的处理能力的,只是处理的精度不一定能够达到要求. 优化初 ...

  9. webrtc拥塞控制算法对比-GCC vs BBR vs PCC

    1.前言 现有集成在webrtc中的拥塞控制算法有三种, 分别是: 谷歌自研发的gcc, 谷歌自研发的BBR算法, 斯坦福大学提出的基于机器学习凸优化的PCC算法. 本文将探讨一下三个算法的区别和优缺 ...

  10. 单神经元自适应控制算法,神经网络自校正控制

    神经网络参数如何确定 神经网络各个网络参数设定原则:①.网络节点  网络输入层神经元节点数就是系统的特征因子(自变量)个数,输出层神经元节点数就是系统目标个数.隐层节点选按经验选取,一般设为输入层节点 ...

最新文章

  1. java最长同值路径_687.最长同路径值
  2. 第十章 优先级队列 (b3)完全二叉堆:删除与下滤
  3. FFmpeg non-existing PPS 0 referenced问题描述
  4. linux如何查看nohup日志大小,linux下nohup日志输出过大问题解决方案
  5. 马斯克又又又套现了:120亿美元到手
  6. 小米 OV 联合起来才不是为了对抗 Google!
  7. sql2008 评估期过期解决办法
  8. 怎样使用Google chrome播放 .swf 文件
  9. 模拟I2C怎么用--教你使用GPIO口模拟I2C总线协议
  10. ubuntu20.04 开机速度非常慢
  11. 软件编程推荐书籍目录
  12. 页面可视化搭建工具技术要点
  13. 我来侃手机--连载二之四十岁的女人,风韵犹存
  14. 支持全球游戏加速 飞鱼星发烧级玩家路由G7上市
  15. 无胁科技-TVD每日漏洞情报-2022-12-14
  16. 图像暗角阴影去除算法
  17. java ipa签名,iOS APP重签名ipa流程、步骤及工具介绍
  18. 女朋友问小灰:什么是数据仓库?什么是数据湖?什么是智能湖仓?
  19. 2020“黄鹤杯”网络安全人才与创新峰会圆满成功
  20. 18、iOS底层分析 - GCD(一)基本概念与简单使用

热门文章

  1. 51单片机8位数码管时钟c语言,基于c51单片机8位数码管显示电子时钟程序
  2. matlab积分器的工作原理,转 Simulink积分器详解(图)
  3. 第 11 章 Harddisk
  4. java rtf读取,java读取rtf
  5. 3dmax linux版本,如何安装Linux版FLOW-3D及注意事项
  6. LaTeX 中的花体字母
  7. 简单集成华为PUSH
  8. 什么是android原生系统版本,定制安卓和原生Android到底有哪些不同之处?彻底真相了...
  9. 计算机机设应用基础,计算机机应用基础–word.ppt
  10. Build-dep linux 知乎,apt-get安装和apt-get build-dep有什么区别?