技术揭秘 | 服务于130+客户的直播SDK是怎样炼成的?(二)

导语:2016年互联网市场什么最火?直播绝对是绕不开的话题。

在上篇《技术揭秘 | 服务于130+家客户的直播SDK是怎样炼成的》文章中,我们介绍了音视频实验室互动直播SDK的秒开技术、高音质连麦技术、领先的视频引擎,及实时质量监控与运营系统。今天,我们将讨论高网络抗性技术与低延迟连麦技术

众所周知,听音频、观视频、看文字图片等是互动直播平台最主要的交流方式。也因此,音视频技术成为了最直观的、能够直接影响用户体验的技术。

那么,一个好的直播平台至少需要有什么样的音视频技术能力呢?

音质好、图像清晰流畅、延迟低、网络适应性好,这些是一个直播平台做到有趣好玩、互动性强的基础。而要获得良好的音视频体验效果,需确保音视频端到端的各个环节都做得足够好,这样才能形成一个有机、高效的系统。

音视频端到端技术主要包括前端采集、前处理、编码、流控、网络传输、转码、解码、后处理,显示播放等模块。

依托于QQ音视频长期的技术积累,由腾讯音视频实验室联合腾讯即通平台部推出的互动直播SDK解决方案无论是在音视频效果、低延迟、网络适应性、维护性和易用性方面都有非常好的效果:

  • 秒进房间
  • 自适应的网络延迟抖动控制
  • 最低低于400ms延迟的连麦体验
  • 高达65%的下行丢包、35%的上行丢包网络抗性
  • 最高可达1.5M 25fps 720p高清视频
  • 高品质低损伤的音频效果
  • 智能的音视频上下行拥塞避免策略
  • 可视化的运营质量数据监控平台

目前该技术在公司内外部应用广泛,合作客户包括:

音视频实验室的互动直播SDK支持基于私有UDT协议的音视频传输技术,获得低延迟、高抗性、秒进房的优秀体验,同时也支持基于旁路转码的RTMP、HLS、FLV推流观看;独有的音视频流控服务器能够实时监控网络状态,对音视频编码、传输及时做出符合当前网络状态的响应,大大加强了音视频的网络适应性,能够很好地保证音视频质量和用户体验。

下面,我们将重点介绍音视频实验室互动直播SDK的两个关键技术:高网络抗性特性和低延迟连麦特性

PartOne 高网络抗性特性

在互动直播中,媒体传输常常用到RTMP、HLS、FLV、RTP/UDP等协议。RTMP、HLS和FLV协议基于TCP,它本身的延迟较大,当处在较差的网络下时,延迟更不可控(一般大于1s)。HLS的延迟更大(超过10s)。

相比之下,RTP/UDP协议具有很高的实时性,不需要建立预链接。但它也存在相应缺点:没有QoS保障机制,容易产生丢包和乱序,造成音视频质量的损伤。

为了获得低延迟、高抗性的直播体验,音视频实验室互动直播SDK的音视频媒体传输协议不采用上述协议,而是基于UDP的基础上,开发了一套私有的UDT传输协议,在保证了实时性的同时,也拥有优秀的网络QoS保障。

UDT协议的网络QoS保障机制主要体现在三个方面:信道、信源、流控

1 信道QoS

信道的保障即网络传输的保障。音视频实验室互动直播SDK从几个方面对音视频码流进行保护。

首先是信道码流的FEC(前向纠错),它包括普通的逻辑运算FEC和RS码FEC(RS码原理请问度娘谷哥):

FEC抗丢包能力和冗余率成正比:冗余越高,抗性越好。它的优点是延迟低(单帧内FEC引入的延迟可以忽略),但它的最大缺点是需要占用网络带宽,这样会导致音视频编码的有效码率的降低,从而导致音视频质量的下降。

因此UDT协议引入了丢包重传技术。在上行和下行端,SDK会通过探测算法,实时监测网络情况,根据当前网络的上行、下行的延迟、抖动、丢包和可用带宽等情况,自适应地调制重传BUF大小、重传延迟、重传次数、重传间隔、一次重传包数等。下行端还加入了智能jitterbuf,根据网络的丢包和抖动情况,它能够自动调整抗抖能力和延迟大小,从多方面保证最优的重传效率,减少无效的重传,避免带宽的浪费。

其次,音频还有PLC机制,通过前后帧插值、复制pitch、带内冗余编码参数、基于混响滤波器等手段,在解码端进行纠错。

2 信源QoS

信源QoS保障机制主要应用于视频中。我们知道,视频的端到端传输需要经过采集-前处理-编码-传输-解码-显示,其中关键点在于发送端的编码和接收端的解码

视频的编码是把一帧一帧的采集图像数据用一定的压缩算法压缩为比原来小几百几千倍的码流。在编码压缩图像帧时,需要用到空间上的邻域参考和时间上的前后域参考关系。如果被参考的数据丢失或者损坏,那么参考了这些数据的图像帧在解码端就无法解码,视频就会出现卡顿、花屏等现象,导致用户体验很差。

在视频的H264/H265编码中,一般的帧类型有I帧、P帧、B帧(各种帧类型的详细情况请问度娘谷哥,参考H264/H265协议)。I帧是帧内自参考、P帧是帧间前向参考、B帧可以前向后向参考。一帧I帧和若干帧P帧或B帧,组成了一个编码GOP。解码器解码一组GOP,必须先解码出为首的I帧。

实时视频通讯一般采用IPPPPPP的GOP模式

原因:B帧有后向参考,需要等待后面的帧到来才能解码,这样会引入延时;I帧也不能刷太频繁,因为I帧码率大、占带宽,且容易出现图像发虚现象。

小科普:

I帧一般质量较好,P帧质量相对较差。I帧过密时,会察觉到I帧和P帧替换时的图像质量的明显差异,这种现象又叫做呼吸效应

网络良好的实时视频会议,一般采用GOP无限大的模式。但该模式有个缺点:如果其中某一帧因为丢包或其他原因导致有损,那么同一个GOP内它后面所有的帧都无法解码。所以该模式下每一帧都同样重要,做QoS保护时也需要同等对待。由于该模式过分依赖信道QoS的保护,导致QoS机制的灵活性不够、网络适应性不好。

鉴于此,我们利用H264/H265编码的多参考帧机制,对编码GOP模式进行了针对性的优化,使得视频帧的抗网络丢包能力大大提高,同时有利于对不同的帧类型划分不同的重要程度,以此来进行不对等的信道抗丢包保护。

3 流控QoS

音视频实验室互动直播SDK还在流控层面上保证音视频的质量,客户端分析统计当前接收和发送的媒体流信息和网络状态,上报给流控服务器,流控服务器根据当前上行和下行的网络状态(丢包大小、抖动大小、延迟大小、可用带宽大小等)自动调节当前编码和传输参数,比如配置合适的编码帧率、码率、分辨率、GOP类型、GOP大小、编码QP等等;配置合适的UDT重传参数和延迟参数;配置合适的FEC参数(冗余率、FEC方法、分组策略等),从多方面避免网络丢包和拥塞恶化,主动调节网络的带宽负担

需要强调的是,上述三个层面的QoS机制并不是独立运行的,而是通过流控服务器和客户端的交互有机地结合在一起,形成一个统一的音视频媒体QoS保障机制

比如,流控服务器根据网络状态,配置编码的各种参数的同时,会配置当前的抗丢包方式,可能只用信道保护或者信源保护,也可能信道和信源同时使用;也可能根据不同的帧类型和不同的GOP类型对视频帧使用不同的FEC方法、不同的FEC冗余率;客户端也会根据当前接收到的码流情况,来决定当前丢包用丢包重传,还是用FEC恢复;可能还会配置当前是否需要主动FEC等等。三个层面的QoS是个比较复杂的关系

通过三层QoS机制,音视频实验室互动直播SDK能够获得高达65%的下行丢包、35%的上行丢包的网络抗性

Part Two 低延迟连麦技术

目前大多数的互动直播都是主播与观众的一对多模式,观众与主播的互动主要通过使用文字、点赞、礼物等方式进行。在这种模式下,主播和观众的互动性不够直观和及时。考虑到直播时观众若能与主播进行实时的音视频互动,将会大大提高用户的参与感、增加用户粘性,目前很多直播平台都支持或者正在开发支持观众和主播连麦互动的功能,这也是目前各直播平台主要的竞争技术点之一。

连麦的简单过程如下:

  1. 主播正常开始直播,观众进入房间观看主播直播画面(普通直播);
  2. 直播过程中,想要连麦互动的观众发起连麦请求,进入连麦申请列表;
  3. 主播从连麦申请列表中选择一名或多名观众进行连麦互动,主播可以看到并听到连麦观众的声音画面;观众也可以看到并听到主播和其他观众的声音画面(连麦直播);
  4. 连麦结束,恢复原来的主播单人直播模式。

由此可知,“连麦”要求主播和上麦的观众能够展开实时的音视频互动,这对音视频的延时和同步提出了很高的要求。

那么它该如何实现呢?

音视频实验室互动直播SDK针对以下几个方面持续地进行优化

首先,在上麦时刻,基于SDK的秒进房特性(在另外一篇SDK介绍文章《音视频实验室:服务于130+客户的直播SDK是怎样炼成的》中有详细介绍),连麦观众能够实现快速进房间,主播也能够快速看到上麦观众的音视频画面。

其次,在编解码端,我们对编码器效率的持续优化使得编码器耗时更小,在同等质量下码率更低,从而需要传输的数据量更小,更有利于延迟的减少;对于视频编码,我们支持IOS、Android、PC三端的硬件编解码,使得编码耗时更低;同时也支持软、硬件编码实时互相切换,调整更灵活,响应及时

接着,在传输端,我们采用基于实时性很高的UDP协议而优化的私有的UDT协议,而不是直播行业常用的RTMP、HLS、FLV等方式,从而减小了延迟,适合于对实时性要求高的应用场景

小科普:

RTMP、HLS、FLV等传输协议是基于TCP的上层协议。TCP协议的几次握手挥手过程和丢包重传特性都会使得延迟无法降到很低,尤其当网络有丢包和抖动时,延迟变得更加不可控。

UDP协议就没有这些繁琐的过程,因此它有非常高的实时性,延迟能够达到1s以下,因此一般用在视频会议、监控、IP电话等实时场景。但UDP是简单不可靠的传输方式,本身没有QoS的保障机制,存在丢包和乱序现象,必须要额外增加网络QoS机制来保证传输的质量。

我们自研的UDT协议通过一系列策略优化,既保证了网络QoS抗性,也保证了连麦场景下能够有较高的实时性

流控层,连麦场场景下,专门调测一组低延迟的、对音视频质量无明显影响的编解码参数和网络传输控制参数。

接入层,依托腾讯在全球强大的服务器部署,利用智能的接入分配策略,实现最优的就近接入、跨地域、跨运营商优化接入。

基于上述几个方面的优化,音视频实验室互动直播SDK的连麦场景实现了最低可达到400ms,普通网络下平均600+ms的低延迟连麦体验,在兼顾低延迟的同时还能保证抗性能抗最大45%的网络丢包:

Part Three 结 语

本文简单介绍了最近很火的互动直播基本情况和技术特性,接着对音视频实验室互动直播SDK及其音视频核心技术特点进行了分享(点击阅读原文按钮,可查看上篇直播SDK技术揭秘)。

针对音视频实验室互动直播SDK现有的高性能,我们还将持续深入地优化、精益求精,以实现更丰富多样的功能性、更强的网络适应性,和更优质的音视频体验

原文发布于微信公众号 - 腾讯音视频实验室(TencentAVLab)

原文发表时间:2017-03-10

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏智能算法

最令程序员沮丧的十件事

er双旦快乐~! 软件开发是一个伟大的工作——和任何其他工作一样,它也有它的缺点。下面的十件事就是大多数程序员关于编程所无法苟同的。 对于非软件开发人员来说,...

2875
来自专栏java一日一条

最令程序员沮丧的 10 件事

软件开发是一个伟大的工作——和任何其他工作一样,它也有它的缺点。下面的10件事就是大多数程序员关于编程所无法苟同的。

1113
来自专栏大数据和云计算技术

超融合方案分析系列(7)思科超融合方案分析

引言 作者是国内研究超融合相当早的专家,有非常强的理论基础和实战经验。上几篇分析文章,对nutanix/VSAN/深信服/H3C/EMC等厂家的深入分析,引起了...

5256
来自专栏云计算D1net

云计算网络中混合WAN和SD-WAN的不同

1995
来自专栏开源优测

推荐些自动化测试入门的书

最近一直被追着问,要给推荐一些自动化测试入门的书籍,其实只要把公众号里近200篇文章都翻上那么一遍,大致应该知道了自动化测试需要哪方面的技术了。 同时把所有文章...

3234
来自专栏媒矿工厂

新的开源编码器XVC,AV1和HEVC之外的另外选项?

简介: 视频数据是目前互联网流量中最大的一部分,占用的带宽比重较大。而通常在视频流媒体应用中,播放端可以达到的最高质量水平与可用带宽直接相关,因此高效的视频编码...

5604
来自专栏鹅厂网事

数据中心网络中的hash问题研究

"鹅厂网事"由深圳市腾讯计算机系统有限公司技术工程事业群网络平台部运营,我们希望与业界各位志同道合的伙伴交流切磋最新的网络、服务器行业动态信息,同时分享腾讯在网...

3796
来自专栏AI科技评论

如何评价微软在数据中心使用FPGA代替传统CPU的做法?

编者按:本文系微软亚洲研究院实习生李博杰在知乎上针对“如何评价微软在数据中心使用FPGA代替传统CPU的做法?”问题的回答。AI科技评论已获得转载授权。 首先,...

63411
来自专栏SDNLAB

白盒交换机操作系统混战

白盒交换机的出现给了用户选择最佳软硬件平台的权利,它仅仅提供交换机硬件和ONIE(开放网络安装环境),用户可以自行选择最合适的交换机芯片,降低成本实现最大效益。...

4022
来自专栏SDNLAB

SDN交换机在云计算网络中的应用场景

SDN的技术已经发展了好几年了,而云计算的历史更长,两者的结合更是作为SDN的一个杀手级应用在近两年炒得火热,一些知名咨询公司的关于SDN逐年增加的市场份额的论...

4284

扫码关注云+社区

领取腾讯云代金券