当前位置: 首页 > news >正文

【音视频第10天】GCC论文阅读(1)

A Google Congestion Control Algorithm for Real-Time Communication draft-alvestrand-rmcat-congestion-03论文理解
看中文的GCC算法一脸懵。看一看英文版的,找一找感觉。

目录

    • Abstract
    • 1. Introduction
      • 1.1 Mathematical notation conventions
    • 2. System model
    • 3.Feedback and extensions
    • 4. Delay-based control
      • 4.1 Arrival-time model

Abstract

本文档介绍了适用于webRTC两种拥塞控制算法。一种是== 基于时延(delay-based)== 一种是== 基于损失(loss-based)==。

1. Introduction

带宽变化很大,媒体的编码形式不能快速改变以适应变化的带宽。
编码对丢包是很敏感的,然而,媒体流出于实时性的要求会减少包的重传。

1.1 Mathematical notation conventions

2. System model

  • RTP packet - an RTP packet containing media data.
  • Packet group - 发送方发送的一组RTP包,由组出发时间和组到达时间(absolute send time)唯一标识。这些包可以是视频包、音频包或音频和视频包的混合。
  • Incoming media stream - a stream of frames(帧) consisting of RTP packets.
  • RTP sender - sends the RTP stream over the network to the RTP receiver. It generates the RTP timestamp and the abs-send-time header extension
  • RTP receiver - receives the RTP stream, marks the time of arrival.
  • RTP接收方的RTCP发送方–发送接收方报告、REMB消息和全运输范围的RTCP反馈消息。
  • RTP发送方的RTCP接收方–接收接收方报告和REMB消息以及整个运输范围内的RTCP反馈消息,将这些报告给发送方控制器。
  • RTP接收方的RTCP接收器,从发送方接收发送方报告。
  • Loss-based controller - 测量损失率、往返时间和REMB信息,并计算出目标发送比特率。
  • Delay-based controller - 从RTP接收方或RTP发送方收到的反馈中获取数据包到达信息,并计算出最大比特率,将其传递给loss-based的控制器。

3.Feedback and extensions

有两种方法来实现提出的算法,一种是两个控制器都在发送端运行,另一种是delay-based控制器在接收端运行,loss-based控制器在发送端运行。
第一种:RTP receiver会记录到达时间和每个收到的包的transport-wide sequence number,这些东西用transport-wide feedback message会定期发给发送端。【反馈的时间:时间每接收一次视频帧就反馈一次,如果只有音频或多流,至少每30毫秒一次反馈一次。如果反馈开销需要被限制,这个间隔可以增加到100ms。】RTP sender 把接收到的{序列号,到达时间}映射到“反馈报告所涵盖的每个包的发送时间”,并将这些时间戳提供给delay-based的控制器。它还会根据反馈信息中的序列号计算出一个损失率
第二种:接收端的delay-based控制器,用来监控和处理到达时间和入包大小。发送方使用abs-send-time RTP报头扩展使接收者能够计算组间延迟变化。从delay-based controller输出的是一个比特率,它将用REMB feedback message传给回发送者。丢包率通过RTCP接收器报告发送回来。
在发送端 REMB消息中的比特率和数据包的百分比损耗被输入loss-based控制器,该控制器输出一个终值目标比特率。当检测到拥塞时建议尽快发送REMB消息,或者至少每秒一次。

4. Delay-based control

基于延迟的控制算法可以进一步分解为三部分:到达时间过滤器(an arrival-time filter)、过度使用检测器(an over-use detector)和速率控制器(a rate controller)

4.1 Arrival-time model

本节介绍了一个自适应滤波器(an adaptive filter),它根据接收到的数据包的时间持续更新网络参数的估计值。
到达间隔时间inter-arrival time, t(i) - t(i-1):表示两个包或者两组包的到达时间不同. t(i)是对应于组中最后一个包被接收的时间。
出发间隔时间inter-departure time,T(i) - T(i-1):作为两个包或两组的出发时间的不同。其中T(i)是当前包组中最后一个包的出发时间戳
组间延迟变化inter-group delay variation,d(i):d(i) = t(i) - t(i-1) - (T(i) - T(i-1))
在接收端,我们观察一组一组的传入数据包,其中一组包定义如下:在burst_time间隔内发送的包序列组成一个小组。burst_time的建议值为5ms。此外,如果其inter-arrival time小于burst_time并且d(i)<0的数据包也被认为是当前组的一部分。 将这些数据包纳入组内的原因是为了更好地处理由"因与拥堵无关的原因,数据包排队"引起的延迟瞬变。任何无序接收的数据包都被Arrival-time model忽略。
t(i) - t(i-1) > T(i) - T(i-1) 网络有拥塞
由于在一条容量为C的路径上发送一组大小为L的数据包的时间ts大致为 ts = L/C
我们可以将组间延迟变化建模为:

d(i) = L(i)/C(i) - L(i-1)/C(i-1) + w(i) L(i)-L(i-1)= -------------- + w(i) = dL(i)/C(i) + w(i)C(i)

这里,w(i)是随机过程W的一个样本,它是容量C(i)、当前交叉流量和当前发送比特率的一个函数。 C被建模为常数,因为我们希望它比这个模型的其他参数变化更慢。 我们将W建模为一个白高斯过程。 如果我们过度使用信道,我们希望w(i)的平均值增加,如果网络路径上的队列被清空,w(i)的平均值将减少;否则w(i)的平均值将为零。

http://www.lryc.cn/news/59660.html

相关文章:

  • 如何进行移动设备资产管理
  • 使用国密SSL证书,实现SSL/TLS传输层国密改造
  • Oracle之增删改(六)
  • OJ练习第81题——岛屿数量
  • remote gdb 操作流程
  • STM32基础代码学习G070CB串口透传调试(出厂默认)代码
  • 介绍一款idea神级插件【Bito-ChatGPT】
  • pycharm 2021.2.2 版本之前试用期过了怎么办
  • 【通世智库】宁晓红:医疗更完整的样子
  • AD20打开PCB后找不到
  • RTC 基础
  • Quaternion插值方法
  • 如何配置Stash以便与4EVERLAND一起使用
  • webpack plugin源码解析(四) HashedModuleIdsPlugin
  • pytorch | 使用vmap对自定义函数进行并行化/ 向量化的执行
  • Docker部署RabbitMQ(单机,集群,仲裁队列)
  • 生活污水处理设备选购指南
  • 奥威BI数据可视化大屏分享|多场景、多风格
  • 超越时空:加速预训练语言模型的训练
  • 数据库管理系统PostgreSQL部署安装完整教程
  • 有学生问我,重构是什么?我应该如何回答?
  • 交际场合---英文单词
  • 【网络安全】文件上传漏洞及中国蚁剑安装
  • [Java]面向对象高级篇
  • 苹果应用商店上架流程
  • 基于Eclipse下使用arm gcc开发GD32调用printf
  • 5个降低云成本并提高IT运营效率的优先事项
  • 95-拥塞控制
  • Linux常见操作命令【二】
  • Linux驱动中断和定时器