攻克视频技术
李江
声网 Agora 视频专家
7494 人已学习
新⼈⾸单¥59
登录后,你可以任选3讲全文学习
课程目录
已完结/共 19 讲
攻克视频技术
15
15
1.0x
00:00/00:00
登录|注册

10|带宽预测:3大算法准确预估网络带宽

你好,我是李江。
上一节我们详细地讲述了 RTP 和 RTCP 协议。RTP 协议用来封装传输的音视频数据并带上一些基本的信息,而 RTCP 协议则用来统计这些 RTP 包的传输情况。RTP 和 RTCP 一般是使用 UDP 协议作为传输层协议的。因为音视频数据需要比较高的实时性,TCP 协议不太适合,所以我们一般使用 UDP 协议。但是 UDP 协议没有实现拥塞控制算法。因此,我们使用 UDP 协议作为传输层协议的话,需要自己实现拥塞控制算法。
比如说,我们声网就是自己实现了一个全球实时通信网 SD-RTN,并研发了 Agora Universal Transport(AUT)传输算法。我们的 SD-RTN 和 AUT 内部实现了适合不同网络模型的拥塞控制和丢包重传等一整套高质量的传输算法和策略。如果你使用了我们的音视频 SDK,则无需自己关注拥塞控制和丢包重传等一系列弱网对抗算法,SD-RTN 和 AUT 会保证你在进行音视频通信时的流畅度和实时性要求。
一般情况下,音视频场景中的拥塞控制和丢包重传等算法的基础就是 RTP 和 RTCP 协议。我们需要通过 RTP 包的信息和 RTCP 包中传输的统计信息来做拥塞控制和丢包重传等操作。因此,我再强调一下,上一节课是我们之后几节课的基础,你需要完全掌握。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

音视频传输中的带宽预测算法是一项关键技术,本文深入探讨了基于延时和丢包的两种主要带宽预测算法。文章首先强调了RTP和RTCP协议在音视频场景中的重要性,以及使用UDP协议进行传输时需要自行实现拥塞控制算法的必要性。基于延时的带宽预测算法通过计算RTP包的发送时长和接收时长,判断当前延时的变化趋势,并根据趋势调整预测的带宽值。另外,基于丢包的带宽预测算法则根据Transport-CC报文反馈的信息计算丢包率,并根据丢包率的多少直接进行带宽调整更新。最大带宽探测算法则通过快速发送RTP包并统计发送和接收时间,计算出网络的最大带宽值。这些算法为音视频技术开发或研究人员提供了重要的参考价值。文章通过图示和实际案例,生动地展示了这些算法的工作原理和应用场景,为读者提供了清晰的技术概览。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《攻克视频技术》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(23)

  • 最新
  • 精选
  • Chris Zou
    老师除了原理,能否给一些可以实践上手的代码参考,或者开源代码的具体模块?

    作者回复: webrtc的带宽预测模块就是开源实现。webrtc的GoogCcNetworkController这个类主要是实现带宽预测算法的。OnTransportPacketsFeedback这个函数就是transport-cc报文反馈之后开始做基于延时和丢包的带宽预测以及最大带宽探测算法的。其实这一块的代码是很复杂的,所以我想通过口头讲述原理来减少一些看代码的难度。你可以对着课程看代码。

    2021-12-21
    3
  • Geek_9527
    最大带宽预测 一般多大间隔检测一次 是否网络带宽不同 检测间隔也需要做调整呢?

    作者回复: webrtc中在发送码率小于预估带宽的60%之后每5s探测一次。超过70%之后停止探测

    2021-12-14
    2
    2
  • Geek2014
    最终目的是尽量避免拥塞,充分利用有效的带宽资源

    作者回复: 回答的很好

    2021-12-14
    2
  • 翻山越岭
    根据带宽预测,实时调整码率,保证画面流畅

    作者回复: 点赞

    2021-12-13
    1
  • 播放技术部
    “最大带宽探测算法” 这块有个疑惑想请教下,就是定时发送额外的探测包不会消耗额外的网络带宽吗?其他拥塞控制算法(如bbr)带宽探测时也依赖发送端的发送量从而有类似“比较小的带宽调整上去需要一段时间”的问题吗?

    作者回复: 如果当前需要发送的数据量不够带宽探测的数据量的话是需要使用padding包的,所以是需要额外消耗一些网络带宽的,但是因为探测的时间是非常短的,所以影响不大。 bbr的探测是在probe_bw的周期用1.25倍的pacing_rate来上探的吧,如果数据量不够的话也是需要padding。 gcc有“比较小的带宽调整上去需要一段时间”这个问题是没有最大带宽探测的话有这个问题,因为受限于发送数据量。bbr应该会好很多,因为他很多时候都处于probe_bw的状态,会不断的探测最大的带宽

    2022-09-23归属地:浙江
  • 播放技术部
    “当前接收码率离最大带宽比较远”,想问下这里最大带宽是怎么获取的?怎么知道最大带宽是多少呢?

    作者回复: 课程中有介绍的。 “但是下降带宽的时候需要做另外一个事情就是更新当前网络的最大带宽。因为处于下降带宽的过程中,说明当前发送数据量已经达到甚至超过了网络的承受能力。这个时候适合更新网络的最大带宽,将当前的接收码率与之前的最大带宽做加权平均求得当前的最大带宽,并更新最大带宽的标准差。这两个值之后调高带宽的时候需要用。”

    2022-09-23归属地:浙江
  • Chris Zou
    请教老师,webrtc中的这些网络传输策略,包括带宽预测,NACK、FIR、FEC、PACER等,对于媒体网关服务器来说,是否有必要实现这些能力?

    作者回复: nack、FIR还有带宽预测肯定要的。fec服务器可以实现也可以只在发送端做。pacer会带来延迟可以根据实际情况是不是需要做。

    2022-01-11
  • 一身龙骨
    最大带宽探测算法,文字中说取发送方和接收方二者最大,后面图中又说取二者最小,到底是啥呢

    作者回复: 是最小值,笔误了。多谢兄弟提醒

    2021-12-19
  • 另外remb 里算mi实际使用中发现 锯齿状时延,平均在200ms上 锯齿幅度不是很大,丢包不多时,码率下降的很快,大佬这块除了设置最小码率拖住底,有什么好办法去优化一个更普适的机制么。

    作者回复: 码率下降快是因为时延抖动导致进入了过载了吗?如果抖动大我觉得需要看看是什么导致抖动大。

    2021-12-16
  • 写点啥呢
    请问老师,“最大带宽”这里指的是带宽资源最大值还是目前带宽达到过的最大值么?我的疑惑在上调的乘性和加性增加判断上,“码率大于最大带宽三倍方差”,如果最大带宽含义资源最大值的话此时应该无法继续调整了。请老师解惑,谢谢。

    作者回复: 指的是前面出现过载时的带宽,意思是到了这里要慢点加,防止又过载了。

    2021-12-13
收起评论
显示
设置
留言
23
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部