作者:网易智企云信资深音视频引擎开发工程师 王兴鹤

随着AI和5G的到来,音视频应用将变得越来越广泛,人们对音视频的品质需求也越来越高,视频分辨率已经从高清发展为超高清、VR,视频帧率也已出现60fps、120fps等应用,交互式的应用对端到端延时也提出了更高的要求。与此同时,设备的硬件性能也突飞猛进。可以预见,随着5G的到来网络中传输的数据将会呈现爆发式增长,大量数据将会给网络传输带来巨大的挑战。因此,如何保证用户高品质的音视频体验?传输将会是一个重要环节。

网络中常见的问题有丢包、抖动、拥塞、延时。以下将分别介绍这些问题对视频体验带来的影响。

视频帧往往是拆成一个个分组包进行传输,当网络发生丢包时,接收端无法成功组帧,不仅影响这一帧的数据解码,从这一帧开始的整个GOP都将无法解码显示,用户看到的画面将出现卡顿,直到完整的I帧到达接收端才能恢复画面。

抖动同样是造成卡顿的杀手锏,抖动分为发送数据抖动、网络传输抖动、接收丢包恢复抖动。在端到端全链路上,任何环节都会引入抖动而影响画面的流畅性。接收端的Jitter Buffer缓冲区负责消除抖动,提供稳定的解码帧率,但是Jitter Buffer是牺牲延时作为代价的。

网络发生拥塞时,音视频的播放情况将变得更加恶劣,拥塞造成的直接影响是突发丢包或者突发抖动,如果不及时预测拥塞的发送降低发送数据量,接收端将会出现卡顿、延时大、画质差等等问题。

发生丢包、抖动、拥塞时往往会伴随着延时的增大,ITU StandardG.114对延时的定义是,端到端延时大于400ms时绝大数的交互体验都将不能接受。

我们用QoE表示用户在接收端的主观体验,而QoS是指通过一些量化指标衡量网络的传输质量并提供优质网络的服务。

那么对抗以上这些网络问题,QoS都有哪些武器呢?

1 FEC

FEC是常用的抗丢包手段,又叫前向纠错码,是在发送端额外发送一些冗余数据,用于抵抗网络丢包。当接收端检测到媒体数据发生丢包时,就可以利用接收到的冗余数据进行丢包恢复。FEC的优点是丢包恢复延时低,缺点是冗余数据占用额外带宽,在带宽受限场景会挤压视频原始码率,导致画质变低。影响FEC的丢包恢复能力除了冗余数据数量之外,还跟分组大小有关,分组越大,抗丢包能力越强,但是对应的丢包恢复延时也会变大。

分组大小与抗丢包能力示意

FEC的编解码算法有XOR、RS等,衡量FEC算法的指标主要有计算性能、抗丢包能力、恢复延时。其中基于柯西矩阵的RS(里德-所罗门码)是目前比较流行的FEC算法。该算法结合合适的分组策略在以上三个指标上都有较好的表现。对于不同的应用场景也有不同的FEC算法有更好的表现,比如喷泉码、卷积码等等,喷泉码结合接收端反馈机制对无线信道等丢包波动大的场景有较好的表现。

总的来说,FEC是一种用码率流量交换抗丢包能力的技术,相比重传FEC的优点是恢复延时低。FEC技术的关键点是如何设计合理的冗余策略和分组大小,达到抗丢包能力、视频码率、恢复延时三者的有效平衡。

2 丢包重传

有别于FEC的抗丢包技术,重传不需要浪费太多的码率,只有当接收端检测到丢包时通过反馈给发送端丢包信息(NACK)才进行相应数据的重传,接收端每隔1个RTT对同1个包发起重传请求,直到成功接收到相应的数据包。重传最大的好处是码率利用率高,缺点是会引入额外的丢包恢复抖动从而拉大延时,显然,网络RTT越大重传的恢复效果越差。

考虑到双向丢包的场景,对于同一个包,接收端可以以1/2 RTT间隔发送重传请求,以应对重传请求包可能丢失的情况。发送端对同一个seq的包响应间隔按照RTT间隔控制,防止重传码率过多浪费。发送和接收按照以上间隔处理重传请求和重传响应,可以在码率和抗丢包能力上达到有效的平衡,实现收益最大化。一个好的重传策略设计还需要考虑是否需要容忍乱序,合理控制重传码率。

3 Jitter Buffer

接收侧一个重要环节是Jitter Buffer。Jitter Buffer的作用是以最低的缓冲延时代价消除数据抖动,提供流畅的播放帧率。因为视频是按帧解码播放,所以Jitter Buffer的延时计算也是按视频帧为最小计算单元,而不是按视频包,输入Jitter Buffer的参数是每一帧视频数据的抖动。造成帧抖动的因素有很多,有采集抖动、编码抖动、发送抖动、网络抖动、丢包修复引入的抖动等,总之,在解码之前的任何环节引入的数据抖动会汇总到Jitter Buffer模块处理抖动消除。

有效发挥重传的抗丢包能力需要有Jitter Buffer的拉伸策略加以配合。因为重传只是保证数据能够到达接收端,此外接收端还需要有足够大的Jitter Buffer等待这些晚到的数据帧,否则即便重传到达接收端的数据由于滞后性原因将被丢弃。

重传结合Jitter Buffer拉伸策略是一种用延时交换抗丢包能力的技术,其中影响这种交换性价比的关键因素是RTT,RTT越小重传收益越大,反之收益越差,更多需要FEC实现抗丢包。

4 长期参考帧

除了重传、FEC等常规手段之外,长期参考帧技术即选择参考帧技术,是一种网络模块和编码器共同配合完成的技术。在RTC场景下一般的编码参考策略是向前一帧参考,因为参考的距离越近压缩效果越好,出于实时的考虑编码只有I帧和P帧,没有B帧。而长期参考帧是一种可跨帧的参考帧选择策略,这种策略打破了传统的向前一帧的参考的规则,可以更加灵活地选择参考帧。

长期参考帧策略的目的是在有丢包的场景下,接收端不需要等待丢包恢复也能继续显示画面,其最大的好处是低延时,不需要等待重传恢复,但是带来了压缩率的牺牲,在相同码率下表现为图像质量的牺牲,但是这种牺牲和收益的交换在某些场景下是值得的。此外,常态的长期参考帧技术在抵抗突发丢包能力上有很大提升,当网络突然出现丢包,FEC和重传的立即恢复效果一般是比较差的,尤其是有基础RTT的网络。而长期参考帧可以饶过丢失的帧,利用丢失帧之后任何一个恢复的帧进行解码显示,从而提升突发丢包时的流畅性。

根据长期参考帧的特点和目的,实现长期参考帧技术应用需要有接收端侧反馈信息,编码器根据接收端反馈的帧信息选择参考帧编码,在有丢包的场景下,接收端通过短时的帧率牺牲将很快恢复画面。由于存在接收反馈,高RTT时反馈延时较大将会导致参考距离变大,而参考距离超出了编码器的编码缓冲限制将会导致编码找不到参考帧,所以长期参考帧比较适合低RTT场景。在多人会议场景中,下行人数太多也会制约长期参考帧的参考帧选择。

综合来看,长期参考帧适合1V1的通信场景,适合低RTT伴随丢包或者拥塞的弱网场景,这样的场景下长期参考帧比传统的向前一帧参考有更好的实时性和流畅性,同时结合重传和FEC的抗丢包贡献,其抗弱网能力将大大提升。

5 大小流和SVC

长期参考帧比较适合1V1的场景,而多人场景时,需要大小流和SVC发挥作用。

大小流是指上行同时传输两条不同分辨率的流,媒体服务器可以根据下行实际的带宽情况转发相应质量的流,如果带宽足够转发高质量的大流,带宽不足转发低质量的小流。这种大小流机制的好处如下: 1)无需调节源端码率就能向媒体服务器提供两种规格的视频码率; 2)在下行接收者有不同的带宽时,可灵活转发,避免只有一个编码源相互影响的情况。

SVC跟大小流的特点一样,区别在于SVC提供了不同帧率的可选规格,媒体服务可以选择不同的SVC层进行转发,通过降低帧率达到降低码率的目的。

在带宽不足时,不同用户对清晰优先和流畅优先的需求不一样,SVC和大小流提供了灵活的机制满足不同应用的需求。

6 场景差异化

我们把我们的应用场景简单地分为两大类,通信场景和直播场景。通信场景简单的比如视频会议、主播连麦交流,在线面试等等,这种交互性的应用场景对实时性要求较高,它的特点是低延时、流畅优先。而直播场景比如主播直播卖货,老师在线授课,这种场景的特点是大部分时间都是主播或者老师一个人在讲,因此它的特点是高延时、清晰优先。在这两种场景下有不同的策略倾向,通信场景更多的是用FEC,重传作为辅助,提升实时性。直播场景更多是用重传,FEC作为辅助,提升清晰度。

结束语

本文主要介绍了对抗弱网的基本QoS策略,除了以上技术之外还有很多模块涉及到延时、清晰、流畅三个维度的平衡。很少有一种技术能做到完美无缺,鱼和熊掌不可兼得,我们要做的平衡策略就是取长补短,趋利避害,在不同的网络条件下,不同的应用场景下,结合每种技术的自身特点,将其进行组合打出一套组合拳,实现受益最大化。

网络QoS的平衡之道——音视频弱网对抗策略介绍的更多相关文章

  1. 阿里云 RTC QoS 弱网对抗之 LTR 及其硬件解码支持

    LTR 弱网对抗由于需要解码器的反馈,因此用硬件解码器实现时需要做一些特殊处理.另外,一些硬件解码器对 LTR 的实现不是特别完善,会导致出现解码错误.本文为 QoS 弱网优化系列的第三篇,将为您详解 ...

  2. C#专业的音视频采集录制类库SharpCapture介绍

    SharpCapture是高性能.轻量级.接口清晰.使用简单的C#语言编写的.NET音视频采集.屏幕录制类库.本类库可以采集系统声卡.麦克风.摄像头.屏幕画面,支持声卡和话筒混音采集. 可以应用到直播 ...

  3. 阿里云 RTC QoS 弱网对抗之变分辨率编码

    本文为 QoS 弱网优化系列的第二篇 作者|安基程.田伟峰 审校| 泰一 视频编码中的变分辨率问题及解决 变分辨率在弱网场景的实际应用中非常常见,网络状况不好的时候降低分辨率可以降低码率,减少块效应, ...

  4. 腾讯技术分享:微信小程序音视频技术背后的故事

    1.引言 微信小程序自2017年1月9日正式对外公布以来,越来越受到关注和重视,小程序上的各种技术体验也越来越丰富.而音视频作为高速移动网络时代下增长最快的应用形式之一,在微信小程序中也当然不能错过. ...

  5. WebRTC 音视频开发

    WebRTC 音视频开发 webrtc   Android IOS WebRTC 音视频开发总结(七八)-- 为什么WebRTC端到端监控很关键? 摘要: 本文主要介绍WebRTC端到端监控(我们翻译 ...

  6. 转:Android IOS WebRTC 音视频开发总结 (系列文章集合)

    随笔分类 - webrtc   Android IOS WebRTC 音视频开发总结(七八)-- 为什么WebRTC端到端监控很关键? 摘要: 本文主要介绍WebRTC端到端监控(我们翻译和整理的,译 ...

  7. Android 音视频开发(五):使用 MediaExtractor 和 MediaMuxer API 解析和封装 mp4 文件

    一个音视频文件是由音频和视频组成的,我们可以通过MediaExtractor.MediaMuxer把音频或视频给单独抽取出来,抽取出来的音频和视频能单独播放: 一.MediaExtractor API ...

  8. 腾讯技术分享:微信小程序音视频与WebRTC互通的技术思路和实践

    1.概述 本文来自腾讯视频云终端技术总监rexchang(常青)技术分享,内容分别介绍了微信小程序视音视频和WebRTC的技术特征.差异等,并针对两者的技术差异分享和总结了微信小程序视音视频和WebR ...

  9. 了不起的WebRTC:生态日趋完善,或将实时音视频技术白菜化

    本文原文由声网WebRTC技术专家毛玉杰分享. 1.前言 有人说 2017 年是 WebRTC 的转折之年,2018 年将是 WebRTC 的爆发之年,这并非没有根据.就在去年(2017年),WebR ...

随机推荐

  1. 调试HotSpot源代码(配视频)

    本文将详细介绍在Ubuntu16.04 LTS上对OpenJDK8进行编译,为了方便大家快速搭建起OpenJDK8的调试开发环境,我还录制了对应的视频放到了B站上,大家可以参考. 视频地址:https ...

  2. .Net核心依赖项注入:生命周期和最佳实践

    在讨论.Net的依赖注入(DI)之前,我们需要知道我们为什么需要使用依赖注入 依赖反转原理(DIP): DIP允许您将两个类解耦,否则它们会紧密耦合,这有助于提高可重用性和更好的可维护性 DIP介绍: ...

  3. linux 更改mysql 数据存储目录

    https://www.cnblogs.com/hellangels333/p/8376177.html  参考位博主的文章,稍做改动 1.检查mysql数据库存放目录 mysql -u root - ...

  4. C++运行时类型判断dynamic_cast和typeid

    dynamic_cast dynamic_cast < Type-id > ( expression ) dynamic_cast<类型>(变量) 在运行期间检测类型转换是否安 ...

  5. 维吉尼亚密码-攻防世界(shanghai)

    维吉尼亚密码 维吉尼亚密码是使用一系列 凯撒密码 组成密码字母表的加密算法,属于多表密码的一种简单形式. 加密原理 维吉尼亚密码的前身,是我们熟悉的凯撒密码. 凯撒密码的加密方式是依靠一张字母表中的每 ...

  6. 微软开源的 AI 工具,让旧照片焕发新生

    原文地址:Bringing Old Photos Back to Life 原文作者:Ziyu Wan 译者 & 校正:HelloGitHub-小鱼干 & 鸭鸭 写在前面 在 GitH ...

  7. 使用Camtasia来给视频或者图片调色

    喜欢摄影和制作视频的朋友可能知道,一张好看的照片或一段精美视频的构成要素很多,取景本身就是很重要的条件,相机的硬件水平也是一个重要因素,接下来的就是后期的编辑和处理了,而在后期处理过程中调色是十分重要 ...

  8. guitar pro系列教程(一):Guitar Pro主界面之记谱功能的详细解析【上】

    相信弹吉他的朋友们对guitar pro这款软件并不陌生,也有很多朋友用它来看谱制谱.而GP有很多实用功能,能够使我们看谱更清晰,制谱更便捷,所以让我们一起来看看吧 Guitar Pro对初学作曲,特 ...

  9. keras实现MobileNet

    利用keras实现MobileNet,并以mnist数据集作为一个小例子进行识别.使用的环境是:tensorflow-gpu 2.0,python=3.7 , GTX-2070的GPU 1.导入数据 ...

  10. Linux的硬盘挂载

    一·前言 我朋友买了一个香港的服务器,可用总容量为60G,实际只有15.4G,剩下的容量需要硬盘挂载.他尝试无果,向我求助.我帮他解决了问题,想回顾一下整理写此随笔. 二·运行环境 Linux系统版本 ...