你想知道的直播技术都在这里了

概述

2016年基本上能够说一个直播年,各大互联网挣相进入直播行业,成就了直播技术的发展。以前咱们也对直播连麦技术作了一个简单的分析,可是没有从总体上介绍,今天咱们就组一个总体的介绍(本文部分资料来源于网络)。
咱们先来看看视频直播的5个关键的流程:录制->编码->网络传输->解码->播放。每一个环节对于直播的延迟都会产生不一样程度的影响,这里重点分析移动设备的状况。针对移动场景总结出直播延迟优化的4个点:网络、协议、编解码、移动终端,达到UCloud直播云实现低延迟、秒开的技术细节。nginx

直播技术分析

UCloud直播云

1)全局负载均衡-就近接入

实现就近接入的技术比较广为人知,就是CDN即Content Delivery Network (内容分发网络)。CDN包含两大核心技术:负载均衡和分发网络,随着10多年的演进,对负载均衡和分发的实现方式已多种多样,分发网络的构建策略一般是通过日积月累的总结出一套最合适的分发路由,而且也不是一成不变,需时刻关注调整,动态运营。这里重点介绍下CDN的负载均衡技术。
负载均衡是如何实现让用户就进访问的呢?比较广泛的实现方式:经过用户使用的DNS服务器来判断客户端所在的网络位置,从而返回对应的服务IP。有点相似于网络的优先选路算法(这里不作过多的介绍)。以下图示例:
这里写图片描述
HTTPDNS是实现更精准的调度一种方式:
这里写图片描述
如图所示,HTTPDNS的好处显而易见:一可精准得到用户端的IP,有效避免用户配错Ldns(有时是网络中心配错DNS)的状况,可更精准定位用户所在网络位置。二可避免DNS解析劫持。web

2)BGP中转架构-最短传输路径

BGP即Border Gateway Protocol (边界网关协议),业内简称BGP。为何BGP中转架构对直播加速和分发如此重要?不得不提国内复杂的网络情况,较广为人知的是“南电信北联通”的宽带用户分布。那一个简单的问题,电信主播发起了直播,联通的用户想看怎么办呢? 从结构上讲,确定是有有限个电信联通两个运营商的交汇点,至关于信息桥梁。 这就会带来两个问题:一、路程要绕远,网络延迟高且不稳定;二、高峰期拥堵,致使直播流卡顿。
BGP的技术原理往简单的说就是容许同一IP在不一样网络中广播不一样的路由信息,效果就是同一个IP,当电信用户来访问时走电信网内的路由,联通用户来访问时走的联通的路由(即IP惟一性)。因此BGP技术对跨运营商的访问带来了巨大的便利,特别是直播场景。不一样于传统的文件缓存场景,一个图片哪怕第一次是跨了遥远的距离从源站获取后,本地网络进行缓存,后面的访问都走本地网络。直播加速是流式的,而且当要作到低延迟的时候,中间的缓存要尽量少。 BGP至关于给跨网的用户就近搭建了一坐桥梁,没必要绕远路,延时和稳定性都大大提升了。原理运行图以下:
这里写图片描述
通过BGP的优化以后,咱们还须要对网络的机房选路有一个优化。在国内通常而言相同的接入运营商(电信、联通、移动)而且地理位置最近的状况网络延迟最优,小于15ms。跨省同运营商的网络延迟25~50ms,跨运营商状况更复杂一些,在50~100ms。总结起来,直播当中每一个包的延时能够缩短100ms,因为网络的叠加效果,反射到上层是秒级的延迟缩减。算法

直播协议的选择

直播技术涉及不少的协议,如RTMP、HLS、HDL(HTTP-FLV)、RTP,你们见得比较多的就是rtmp协议,如今国内不少的直播平台还在使用,HLS用的也是比较多的,接下来咱们分别对上面的协议作一个简单的介绍。后端

RTMP协议

是Adobe的专利协议,如今大部分国外的CDN已不支持。在国内流行度很高。缘由有几个方面:浏览器

一、开源软件和开源库的支持稳定完整。如斗鱼主播经常使用的OBS软件,开源的librtmp库,服务端有nginx-rtmp插件。缓存

二、播放端安装率高。只要浏览器支持FlashPlayer就能很是简易的播放RTMP的直播,协议详解能够Google了解。相对其余协议而言,RTMP协议初次创建链接的时候握手过程过于复杂(底层基于TCP,这里说的是RTMP协议自己的交互),视不一样的网络情况会带来给首开带来100ms以上的延迟。基于RTMP的直播通常内容延迟在2~5秒。
这里写图片描述服务器

HTTP-FLV协议

即便用HTTP协议流式的传输媒体内容。相对于RTMP,HTTP更简单和广为人知,并且不担忧被Adobe的专利绑架。内容延迟一样能够作到2~5秒,打开速度更快,由于HTTP自己没有复杂的状态交互。因此从延迟角度来看,HTTP-FLV要优于RTMP。微信

HLS 协议

HLS即Http Live Streaming,是由苹果提出基于HTTP的流媒体传输协议。HLS有一个很是大的优势:HTML5能够直接打开播放;这个意味着能够把一个直播连接经过微信等转发分享,不须要安装任何独立的APP,有浏览器便可,因此流行度很高。社交直播APP,HLS能够说是刚需,下来咱们分析下其原理 。
基于HLS的直播流URL是一个m3u8的文件,里面包含了最近若干个小视频TS(一种视频封装格式,这里就不扩展介绍)文件,如 http://www.ucloud.cn/helloworld.m3u8 是一个直播留连接,其内容以下:
这里写图片描述
假设列表里面的包含5个TS文件,每一个TS文件包含5秒的视频内容,那么总体的延迟就是25秒。固然能够缩短列表的长度和单个TS文件的大小来下降延迟,极致来讲能够缩减列表长度为1,1秒内容的m3u8文件,可是极易受网络波动影响形成卡顿。那么咱们怎么解决这个问题呢?后面将专门为你们讲解优化方案。网络

RTP协议

RTP即Real-time Transport Protocol,用于Internet上针对多媒体数据流的一种传输层协议。实际应用场景下常常须要RTCP(RTP Control Protocol)配合来使用,能够简单理解为RTCP传输交互控制的信令,RTP传输实际的媒体数据。
RTP在视频监控、视频会议、IP电话上有普遍的应用,由于视频会议、IP电话的一个重要的使用体验:内容实时性强。架构

对比与上述3种或实际是2种协议,RTP和它们有一个重要的区别就是默认是使用UDP协议来传输数据,而RTMP和HTTP是基于TCP协议传输。为何UDP 能作到如此实时的效果呢?关于TCP和UDP差异的分析文章一搜一大把,这里不在赘述,简单归纳:
UDP:单个数据报,不用创建链接,简单,不可靠,会丢包,会乱序;
TCP:流式,须要创建链接,复杂,可靠 ,有序。
实时音视频流的场景不须要可靠保障,所以也不须要有重传的机制,实时的看到图像声音,网络抖动时丢了一些内容,画面模糊和花屏,彻底不重要。TCP为了重传会形成延迟与不一样步,如某一截内容由于重传,致使1秒之后才到,那么整个对话就延迟了1秒,随着网络抖动,延迟还会增长成2秒、3秒,若是客户端播放是不加以处理将严重影响直播的体验。
总结一下:在直播协议的选择中,若是选择是RTMP或HTTP-FLV则意味着有2~5秒的内容延迟,可是就打开延迟开,HTTP-FLV 要优于RTMP。HLS则有5~7秒的内容延迟。选择RTP进行直播则能够作到1秒内的直播延迟。但就目前所了解,各大CDN厂商没有支持基于RTP直播的,因此目前国内主流仍是RTMP或HTTP-FLV。

Google的WebRTC视频方案

HLS的优势点是显而易见的:移动端无需安装APP使用兼容HTML5的浏览器打开便可观看,全部主流的移动端浏览器基本都支持HTML5,在直播的传播和体验上有巨大的优点。

而看起来惟一的缺点:内容延迟高(这里也有不少HLS限制没有提到,好比必须是H264+AAC编码,也可认为是“缺点”之一)。若是能获得解决,那将会是直播技术很是大的一个进步。或者换个说法,有没有更低延迟可直接用连接传播的直播方案?不局限于HLS自己。
对于浏览器直接的视频互动,Google一直在推WebRTC,目前已有很多成型的产品出现,能够浏览器打开即实时对话、直播。可是目前覆盖还不是很普遍,从测试结果看,该项目的代码相对较薄,还没达到工业级的成熟度,须要大规模应用估计须要自填很多坑,有兴趣的同窗能够学习研究。

流媒体内容缓存与传输策略优化

基础知识:I帧、B帧、P帧

I帧表示关键帧。你能够理解为这一帧画面的完整保留;解码时只须要本帧数据就能够完成。
P帧表示这一帧跟以前的一个关键帧(或P帧)的差异。解码时须要用以前缓存的画面叠加上本帧定义的差异,生成最终画面。
B帧是双向差异帧。B帧记录的是本帧与先后帧的差异(具体比较复杂,有4种状况)。换言之,要解码B帧,不只要取得以前的缓存画面,还要解码以后的画面,经过先后画面的与本帧数据的叠加取得最终的画面。
注:B帧压缩率高,可是编解码时会比较耗费CPU,并且在直播中可能会增长直播延时,所以在移动端上通常不使用B帧。
这里写图片描述

关键帧缓存策略

如:一个典型的视频帧序列为IBBPBBPBBP……
对于直播而言,为了减小直播的延时,一般在编码时不使用B帧。P帧B帧对于I帧都有直接或者间接的依赖关系,因此播放器要解码一个视频帧序列,并进行播放,必须首先解码出I帧,其后续的B帧和P帧才能进行解码,这样服务端如何进行关键帧的缓存,则对直播的延时以及其余方面有很是大的影响。
比较好的策略是服务端自动判断关键帧的间隔,按业务需求缓存帧序列,保证在缓存中存储至少两个或者以上的关键帧,以应对低延时、防卡顿、智能丢包等需求。

延迟与卡顿的方案选择

直播的延时与卡顿是分析直播业务质量时,很是关注的两项指标。
然而,这两项指标从理论上来讲,是一对矛盾的关系——须要更低的延时,则代表服务器端和播放端的缓冲区都必须更短,来自网络的异常抖动容易引发卡顿;业务能够接受较高的延时时,服务端和播放端均可以有较长的缓冲区,以应对来自网络的抖动,提供更流畅的直播体验。因此咱们须要在延迟与卡顿选择一个比较折中的方案。
这里一般有两种技术来平衡和优化这两个指标:
服务端提供灵活的配置策略,对于延时要求更敏感的,则在服务端在保证关键帧的状况下,对每一个链接维持一个较小的缓冲队列;对于卡顿要求更高的直播,则适当增长缓冲队列的长度,保证播放的流畅。
服务端对全部链接的网络状况进行智能检测,当网络情况良好时,服务端会缩小该链接的缓冲队列的大小,下降延迟;而当网络情况较差时,特别是检测到抖动较为明显时,服务端对该链接增长缓冲队列长度,优先保证播放的流畅性。

丢包策略

何时会形成丢包?对于一个网络链接很好,延时也比较小的链接,丢包策略永远没有用武之地的。而网络链接比较差的用户,由于下载速度比较慢或者抖动比较大,这个用户的延时就会愈来愈高。另一种状况是,若是直播流关键帧间隔比较长,那么在保证首包是关键帧的状况下,观看这个节目的观众,延迟有可能会达到一个关键帧序列的长度。上述两种状况,都须要启用丢包策略,来调整播放的延时。
丢包的解决方案:
一是正确判断什么时候须要进行丢包;
二是如何丢包以使得对观众的播放体验影响最小。较好的作法是后端周期监控全部链接的缓冲队列的长度,这样队列长度与时间造成一个离散的函数关系,后端经过自研算法来分析这个离散函数,判断是否须要丢包。
因此在使用丢包策略的时候为了给用户更好的体,而应该是后台采用逐步丢帧的策略,每一个视频帧序列,丢最后的一到两帧,使得用户的感知最小,平滑的逐步缩小延时的效果。

客户端解析优化

基于可控和容灾的须要,移动端代码通常不会hardcode 推流、播放的服务器IP地址,而选用域名代替。在IP出现宕机或网络中断的状况下,还能够经过变动DNS来实现问题IP的剔除。而域名的解析时间须要几十毫秒至几秒不等,对于新生成热度不高的域名,通常的平均解析延迟在300ms,按上图的各个环节只要有一个通路网络产生波动或者是设备高负载,会增长至秒级。几十毫秒的状况是ISP NS这一层在热度足够高的状况下会对域名的解析进行缓存。以下图:
这里写图片描述
按咱们上面分析的状况,本省延迟大概是15ms左右,那么域名解析最低也能够作到15ms左右。但因为直播场景的特殊性,推流和播放使用的域名使用的热度较难达到ISP NS缓存的标准,因此常常须要走回Root NS进行查询的路径。
客户端解析优化:本机缓存域名的解析结果,对域名进行预解析,每次须要直播推流和播放的时候再也不须要再进行DNS过程。

播放优化

直播流程以下:这里写图片描述
如图所示:直播技术涉及到直播延时、首屏时间(指从开始播放到第一次看到画面的时间)、音视频同步、软解码、硬解码等技术。
播放步骤分析:

  1. 根据协议类型(如RTMP、RTP、RTSP、HTTP等),与服务器创建链接并接收数据
  2. 解析二进制数据,从中找到相关流信息;
  3. 根据不一样的封装格式(如FLV、TS)解复用(demux);
  4. 分别获得已编码的H.264视频数据和AAC音频数据;
  5. 使用硬解码(对应系统的API)或软解码(FFMpeg)来解压音视频数据;
  6. 通过解码后获得原始的视频数据(YUV)和音频数据(AAC);
  7. 由于音频和视频解码是分开的,因此咱们得把它们同步起来,不然会出现音视频不一样步的现象,好比别人说话会跟口型对不上;
  8. 最后把同步的音频数据送到耳机或外放,视频数据送到屏幕上显示。
    针对视频播放的流程,咱们作如下的优化:
    首屏时间优化
  9. 从步骤2入手,经过预设解码器类型,省去探测文件类型时间;
  10. 从步骤5入手,缩小视频数据探测范围,同时也意味着减小了须要下载的数据量,特别是在网络很差的时候,减小下载的数据量能为启动播放节省大量的时间,当检测到I帧数据后就立马返回并进入解码环节。

    延时优化
    视频缓冲区或叫视频缓存策略,该策略原理是当网络卡顿时增长用户等待时间来缓存必定量的视频数据,达到后续平滑观看的效果,该技术能有效减小卡顿次数,可是会带来直播上的内容延时,因此该技术主要运用于点播,直播方面已去掉该策略,以此尽量去掉或缩小内容从网络到屏幕展现过程当中的时间。
    下载数据探测池技术,当用户下载速度不足发生了卡顿,而后网络忽然又顺畅了,服务器上以前滞留的数据会加速发下来,这时为了减小以前卡顿形成的延时,播放器会加速播放探测池的视频数据并丢弃当前加速部分的音频数据,以此来保证当前观看内容延时稳定。
    推流优化
    推流流程图:
    这里写图片描述

优化一:适当的Qos(Quality of Service,服务质量)策略。
推流端会根据当前上行网络状况控制音视频数据发包和编码,在网络较差的状况下,音视频数据发送不出去,形成数据滞留在本地,这时,会停掉编码器防止发送数据进一步滞留,同时会根据网络状况选择合适的策略控制音视频发送。
好比网络不好的状况下,推流端会优先发送音频数据,保证用户能听到声音,并在必定间隔内发关键帧数据,保证用户在必定时间间隔以后能看到一些画面的变化。
优化二:合理的关键帧配置。
合理控制关键帧发送间隔(建议2秒或1秒一个),这样能够减小后端处理过程,为后端的缓冲区设置更小创造条件。

软硬编解选择

推流编码: 推荐Andorid4.3(API18)或以上使用硬编,如下版本使用软编;iOS使用全硬编方案;

播放解码:Andorid、iOS播放器都使用软解码方案,通过咱们和大量客户的测试以及总结,虽然牺牲了功耗,可是在部分细节方面表现会较优,且可控性强,兼容性也强,出错状况少,推荐使用。
软编码硬编码优缺点对比:
这里写图片描述

总结

分析不少直播后端、终端的关于低延迟、秒开的优化技术,在UCloud直播云上都已有了相关的实践,都是一些较“静态”的技术。实际提供稳定、低延迟、流畅的直播服务,是平常中很是大量细致的监控、算法和动态运营的结果,并非实现了某些的技术点,就能坐享一套稳定的直播服务,咱们须要根据实际状况作一个最好的适合本身的视频直播方案。

本文同步分享在 博客“xiangzhihong8”(CSDN)。
若有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一块儿分享。

相关文章
相关标签/搜索