实时视频传输中的BBR拥塞控制

  • 时间:
  • 浏览:5
  • 来源:uu快3输钱_uu快3赢钱诀窍_豹子

3.2 Feedback

*文 / 袁荣喜

下发 / LiveVideoStack*

1.2 实时视频的困扰



实时视频传输中常见的问题主要有卡顿、延迟、抖动、视频模糊和断线重连四种 。造成那此问题的意味着着是多种多样的,但其中最不可不能否 忽视的有有一个 意味着着所以网络拥塞。

2.1 模型

RTT在实际应用中设计的是记忆帧的反馈,原来 减少了反馈数量的一同也提升了下行强度 ,通过上图中的公式时要得到RTT的反馈序列。

3.7 多路竞争测试

网络拥塞是指发送的数据超过了网络能承载的传输能力,但人的需求无限,即使新技术在不断地发展,网络拥塞的情形在未来还是会不断有有一个 劲出现。

远端packet feedback反馈信息输送到BBR前一天,经过一系列运算得到拥塞控制的窗口大小(TCP发送端口)和发送码率。

在探测最高下行强度 时,使用pacer的padding来满足BBR的probe_bw情形最大下行强度 探测要求。

BBR的比较豪放激进,具有不容易被许多应用抢占下行强度 、码率调节实时性高,能很好应对网络变化、时要对应各种类型的网络丢包和技术性心智性性性性性性开花结果的句子等优势。



但BBR的不够也表现在,评估最小RTT前会减小窗口,原来 会使发送码率下降,极端情形下会使实时视频瞬间质量变差。BBR在诞生之初并完正都是用做小下行强度 传输,有时候在小码率视频传输过程中,BBR的效果并不明显。最重要的问题还有padding计算流量不经济实用,时要在使用过程中重点考量。BBR所有的下行强度 统计和实效性完正都是基于RTT,可能RTT过大会意味着着下行强度 的条件不太平滑。

BBR是及时发送的码率而完正都是编码器时要采用的码率,原来 会意味着着网络拥塞问题更加比较复杂,有时候设计了AIMD码率决策来控制video码率的机制。可能BDPinfight_size时,并不用采用即时码率所以用和式加来对码率进行控制,通过加在有有一个 固定倍数码率来平滑地控制整个运作的反馈机制,正确处理网络恶化。

3.6 BBR与GCC比较

3.3 Pacer

3.5 拥塞控制与QoS

网络指在拥塞的意味着着大致有以下几点,WiFi/4G信号衰减、核心传输链路衰减、网络出口竞争、重发风暴和设备性能衰减等问题前会带来网络拥塞的问题,其中WiFi/4G信号衰减意味着着信号被污染,意味着着传输信道的吞吐率下降,最终造成网络拥塞。

1.1 传输三角关系

QoS和拥塞控制是有有一个 概念,QoS是在拥塞控制的范畴之下进行的,码率和拥塞控制的窗口大小会制约QoS的行为。FEC/NACK之间是制约关系,所以一定要基于决策码率来做。

针对网络拥塞的问题,业界也有有一个 劲在提出不同的拥塞控制算法,拥塞算法的核心包括判断拥塞情形和决策大概的发送码率,你这种 个我我觉得是map和reduce模型,把网络上返回的数据进行map,通过网络情形ruduce出有有一个 合理的发送码率。



GCC是四种 基于延迟预估和丢包的拥塞控制算法,算法分为在接收端进行卡尔曼算法预估后返回发送端进行码率调整两累积。Transport CC是基于发送端线性预测的拥塞控制算法,与GCC一样主体完正都是基于下行强度 的拥塞控制判断。这四种 算法指在不同程度上的不够,在实现算法的过程中过于学术,比如GCC包含有有一个 丢包率2%/10%的预值,但我我觉得拥塞指在并不前会产生丢包,有时候丢包所以一定意味着着指在拥塞,你这种 情形对于GCC是失效的。GCC基于下行强度 估算的主体在现阶段来看与下行强度 的记忆丢包没法争抢率,斯坦福大学提出的Salsify算法是基于视频帧之间的下行强度 去估算整个编码器的编码下行强度 ,但它一定要在编码器的基础上执行,无法满足将视频传到sever上进行下发的要求,可能只做分段拥塞控制就时要在sever上进行重解码和重编码,无法满足目前实时视频领域的应用。

2.2 网络FIFO概念

实时传输理想的拥塞控制算法要满足有有一个 特点,第一要相对激进,算法不可不能否 抢过流氓软件和许多基于丢包的算法。第二要对百毫秒级可能是毫秒级的码率进行实时调整,间隔尽量减小,尽量快的适应传输条件,原来 卡顿时间不用太长,就说 用可不能否 带来更好的用户体验。第三是不可不能否 应对延迟型和丢包型的拥塞,一同不用可不能否 进行分段计算。

上图是关于BBR多路竞争的测试,测试过程是在500kBps的下行强度 下分时间段引入三路BBR数据流,最终观察发送码率与否 平均分配的。

BDP中网络周期性最小延迟和网路周期性最大下行强度 是通过BBR的十个 情形机来计算的,第有有一个 情形是STARTUP,BBR刚进入STARTUP前会进行慢启动,慢启动不断地增加下行强度 到下行强度 不再增长可能指在丢包问题就会切入DRAIN排空情形,进入排空情形是可能BPD已满,飞行数据指在堆积。DRAIN情形会在发送数据小于BDP时进入重新评估下行强度 的过程,可能持续一定周期还没法探测到最小RTT的值,就时要进行最小RTT的探测工作,BBR将窗口设置为有有一个 miss大小可能保留3/4的大小去估算最小延迟,估算开始后重新回到STARTUP情形。

实时传输领域指在着四种 三角关系,其中成本一般认为是硬件、软件和通讯下行强度 所带来的成本,延迟是指获得整个流媒体的下行强度 ,比如实时视频中的双端延迟和观看长视频时的首帧延迟,质量时要理解为视频清晰度和数据完备性,你这种 三角关系均是以保证其中一角而牺牲其余两角的方案来建立实时传输方案。随着互联网的发展,设备的成本没法低,手持设备没法方便,但由此也带来所以在实时视频传输过程中的问题。

发送出去会有pace sender通过平滑发送发到接收端,接收端会把有有一个 有有一个 的包返回给发送端,发送端通过事件时要加快强度得到最小延迟和最大下行强度 的样本,结合一定的算法得到相对应的BDP,由BDP时要得到pacing rate,最后不断调整下行强度 形成循环,达成拥塞控制的目的。

网络协议进入网络接收器前一天,通过RTCP的方式获得feedback信息直接输入BBR,再通过一系列情形机计算出下行强度 和窗口大小,码率分配器会根据各种情形对码率进行重新分配,调节视频编码器使码率达到缩放自如的反馈。实时视频有非持续性的特点,关键帧之间流量不均匀,帧间指在下行强度 ,有有一个 劲发送实时视频会意味着着顶端为空的情形,为了正确处理原来 的情形指在设计了pacer用来平滑发送。

3.4 AIMD码率决策

首先整个网络分为正在传输和指在堆积两累积,BBR在构建模型中只计算网络正在传输的累积,计算过程中引入了BDP(拥塞控制窗口)的概念。当前路由器的吞吐和缓冲能力大大加强,包在发送到路由器时我我觉得会指在拥塞,但在足够的内存和磁盘存储空间的条件下不用指在丢包问题,记忆延迟对网络更加敏感,但记忆丢包可能不指在丢包码率就不用下降,在你这种 情形下记忆延迟抢不过丢包。

pacer的发送机制基于BDP发送数据和pacing rate发送数据,可能发送数据可能超过了BDP的吞吐量,此时pacer不用再向外发送数据加重网络拥塞,pacing是间隔5毫秒的间隔发送,pacing rate是基于5毫秒发送的数据量,基于你这种 个条件就时要构建出定时发送的pacer。

3.1 实时视频传输与BBR相结合

上图中时要明显看完BBR在网络限速的情形下表现要比GCC良好许多,不用有大幅度的网络抖动和衰减。

讲到音视频的传输可能实时传输,就时要要了解传输和拥塞的关系。

即时下行强度 是通过发送的数据和接收/发送端的相互统计,可能网络指在抖动会使send bitrate变得非常大,即时下行强度 不可不能否 超过发送端四种 的下行强度 ,所以要在两值中取最小值以减少误差。

让让当我们好,我是来自差生君的袁荣喜,本次分享内容的核心是BBR在实时视频传输中的实践。BBR我我觉得是基于TCP的四种 拥塞算法,在实时音视频中的运用也是四种 全新的尝试,接下来我可能为让让当我们逐一介绍你这种 尝试所带来的优缺点。

BDP/RTT所以让让当我们认为时要发送的码率。

BDP的计算方式是网络周期性最小延迟*网路周期性最大下行强度 。

在比较复杂的网络环境中,要我实现实时视频传输,拥塞控制算法是尤为重点的一环。本文下发自差生君高级技术总监袁荣喜在LiveVideoStackCon 2019上海大会中的分享,完正介绍了BBR拥塞控制算法在实时视频传输中新的实践以及优缺点。

BBR是基于接收端反馈和发送端调节码率的拥塞控制算法。

1.3 网络拥塞