【音视频第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)的平均值将为零。

你可能感兴趣的:(音视频,音视频,论文阅读)