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

这篇具有很好参考价值的文章主要介绍了【音视频第10天】GCC论文阅读(1)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

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

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)的平均值将为零。文章来源地址https://www.toymoban.com/news/detail-410895.html

到了这里,关于【音视频第10天】GCC论文阅读(1)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • windows10|音视频剪辑|FFMPEG录屏和网络推流源初步的生成

    FFMPEG的功能强大是毋庸置疑的,那么录屏的需求大家在某些时候大家可能是非常需要的,例如,现有的项目需要演示,因此录制一段演示视频;亦或者做内容分发直播的,比如游戏主播,需要录制在玩某个游戏的精彩片段,以创建一个后期的视频素材库; 亦或者通过FFMPEG抓取

    2024年02月20日
    浏览(55)
  • 音视频学习-音视频基础

    ` ◼ 像素:像素是一个图片的基本单位,pix是英语单词picture的简写,加上英语单词“元素element”,就得到了“pixel”,简称px,所以“像素”有“图像元素”之意。 ◼ 分辨率:是指图像的大小或尺寸。比如1920x1080。 ◼ 位深:是指在记录数字图像的颜色时,计算机实际上是用

    2024年02月12日
    浏览(41)
  • 音视频 FFmpeg音视频处理流程

    推荐一个零声学院项目课,个人觉得老师讲得不错,分享给大家: 零声白金学习卡(含基础架构/高性能存储/golang云原生/音视频/Linux内核) https://xxetb.xet.tech/s/VsFMs

    2024年02月12日
    浏览(44)
  • 【音视频】ffplay解析-音视频同步

    主要解析:以音频为基准,让视频同步音频 思路 视频慢了则丢掉部分视频帧(视觉-画⾯跳帧) 视频快了则继续渲染上⼀帧 具体实现 ffplay具体源码

    2024年02月07日
    浏览(40)
  • 音视频学习—音视频理论基础(2)

      音频是一种模拟信号,它是由声波转化而来的电信号。声波是通过气体、液体或固体传播的机械波,代表了声音的震动。在录制过程中,声音被转换成电信号,然后被储存在数字格式中。   声音的三要素是频率、振幅和波形   频率是指声波的振动次数,通常使用赫

    2024年04月29日
    浏览(26)
  • ffmpeg@音视频工具@音视频合并

    FFmpeg中文网 (github.net.cn) FFmpeg 是一款强大的开源跨平台音视频处理工具集,它包含了一系列命令行工具以及用于音频和视频编码解码、格式转换、抓取、流化等功能的库。FFmpeg 支持多种视频、音频格式和编解码器,能够进行音视频的压缩、封装、转码、分割、合并、过滤、抓

    2024年03月17日
    浏览(53)
  • 音视频 ffmpeg命令提取音视频数据

    保留封装格式 提取视频 提取音频 推荐一个零声学院项目课,个人觉得老师讲得不错,分享给大家: 零声白金学习卡(含基础架构/高性能存储/golang云原生/音视频/Linux内核) https://xxetb.xet.tech/s/VsFMs

    2024年02月10日
    浏览(45)
  • WebRTC音视频通话(二)简单音视频通话

    本篇不详细介绍websocket,只针对websocket整合rtc。 webrtc是P2P通信,也就是实际交流的 只有两个人 ,而要建立通信,这两个人需要 交换一些信息来保证通信安全 。而且, webrtc必须通过ssh加密 ,也就是使用https协议、wss协议。 借用一幅图 1.1 创建端点的解析 以下解析不包括we

    2023年04月09日
    浏览(48)
  • linux 音视频架构 linux音视频开发

    转载 mob6454cc65110a 2023-07-26 22:27:01 文章标签 linux 音视频架构 ci QT 视频教程 文章分类 架构 后端开发 阅读数 117 目录 前言 1、软件工具准备 a. 录音软件 b. 录屏软件 c. 摄像头软件 d. 安卓屏幕操作软件 e. 视频剪辑软件

    2024年02月07日
    浏览(49)
  • 抖音视频解析,无水印解析下载抖音视频

    抖音视频解析,你是否经常遇到这样的情况,看到一些非常精彩的抖音视频,想要保存下来,但因为下载速度慢或者视频带有水印而感到困扰?那么,这款(抖音无水印解析工具)将是你的得力助手!它可以轻松解决这些问题,使你能够更轻松、更便捷地批量解析和下载抖音

    2024年01月20日
    浏览(40)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包