【知识库专访】亲加CTO郝飞:直播技术架构解密与优化之道

中国已在2016年进入直播+时代,这种成本低廉、互动性高、部署便捷、稳定可靠的娱乐方式,最初仅仅局限于游戏直播和在线聊天,而随着互联网的逐渐发展,泛生活类、娱乐类直播也开始逐渐流行。

CSDN知识库特地邀请到亲加通讯云CTO郝飞绘制了直播技术知识图谱,创建直播技术知识库,帮助广大开发者更加系统、全面的学习直播技术。

CSDN:请先简单介绍一下自己

郝飞:有5年移动互联网创业经历,15年软件开发经验,在流媒体,音视频编解码,VOIP和视频会议方面有丰富的产品和研发经验。2011年作为联合创始人成立了亲加团队,带领团队创建了国内首个即时通讯云平台服务。

CSDN:请问你是如何与直播技术结缘的?

郝飞:我一直在从事音视频相关的工作。最开始主要做音视频编解码器的优化,也涉及到Windows 平台下的多媒体开发。当时公司开发的无线数字电视接收棒,在2008奥运期间很好的满足了移动办公者看奥运的需求。后来到百视通,也主要负责移动智能手机的点播直播业务。亲加通讯云成立后,我们的服务首先覆盖了文本,图片,语音短信的即时通讯需求,随着行业的继续发展,很多应用迫切需要视频的交互,因此亲加尽快提升了平台能力,目前支持包括实时音视频,直播等视频交互方案。

CSDN:分享一下直播相关的技术及架构

郝飞:直播涉及到很多环节,从音视频采集,编码,媒体流封装,网络转发,再到播放端接收,解码,播放,其中每个环节都涉及很多细节,其基本的结构图如下:

直播技术结构图

具体解释如下:

  • 音视频数据分别进行采集和编码;视频数据的采集方式包括摄像头,桌面,图片,视频文件,以及带视频采集的各类设备;

  • 音视频数据经过编码后根据封装格式进行复用处理,然后封包后发到流媒体服务器;目前通用的直播协议采用的是RTMP;

  • 云端的数据分发使用CDN网络,CDN的作用主要包括两点:第一是保证用户请求流媒体的网络质量,CDN 会选择离用户最近的节点为其提供服务; 第二是通过流媒体服务器的级连方式保证大并发用户的支持;

  • 媒体流在云端除了进行转发,还要进行转码,切片(HLS)和录制等处理;转码可以支持多种分辨率格式,从而满足不同屏幕对不同分辨率码流的要求;转HLS协议主要是为了支持手机H5 端观看;同时,码流会被录制下来,供以后点播使用;

  • 观看直播的用户根据接入运营商信息和位置信息会得到就近的CDN 节点,后续的流媒体数据就是通过此服务节点进行拉取的。

CSDN:请你谈谈有关直播技术架构的改进思考

郝飞:目前普遍使用的直播技术是一种单向的流媒体传输技术;因此,互动在直播的场景中就显得格外重要,这也是聊天和连麦等互动技术浅浅成为直播标配的原因。其中,聊天是独立于直播的单独服务,对直播架构没有影响;但连麦功能,其实会影响到直播本来的架构,支持了多人连麦后,其架构如下:

具体说明如下:

  1. 主播端加入视频会议系统;此处注意,主播端不再直接推视频给CDN;

  2. 视频会议系统把主播的视频流推向CDN,观众通过CDN观看主播视频;

  3. 参与连麦的观众登录到与主播端同一个视频会议频道中,此时主播端和连麦者通过实时的视频会议进行交互;主播与连麦者的视频,经过服务端混合后输出给CDN;

  4. 其他用户通过CDN观看主播与连麦者的交互。

大家可以看到,在流媒体服务器之外,整个架构中多了一个Conference Server,这个服务实现了连麦者之间实时音视频交互的功能,同时,它还要把这个交互的画面合成后分发给CDN; 这是对传统直播流程的一个改进;

另外,目前的直播普遍采用的是RTMP等协议,其系统延迟在3秒左右,但越来越多的直播业务期望更低的延迟,这样就不会出现直播视频与聊天信息不同步等尴尬的事情。如果用户端与媒体服务器的传输协议修改成UDP协议,并且做好纠错与丢包补偿等处理,这样就可以大大减少系统的延迟,能够控制在一秒以内,同时,再通过负载分配支持大量级用户的接入,相信这样低延迟的CDN方案是很多用户所期望的。

CSDN:直播过程中,如何防止丢帧和卡顿的发生,提高QoS?

郝飞:目前国内的直播大多使用RTMP和Http-FLV协议,它们都是基于TCP的,因此不会出现丢帧的现象。但卡顿是很有可能出现的,卡顿产生的主要原因是播放端拉取的媒体流不足以满足流畅播放所需要的数据量,这往往是网络原因导致的。可能出现的环节包括:

  1. 主播端上传的网络:如果主播端上传网络出现问题,不能保证流媒体即时的发送,则所有观看端都会出现卡顿的问题;

  2. CDN分发:CDN节点之间需要转发流媒体数据,如果某一个转发节点的网络出现问题,将会影响所有连接此节点用户的播放质量;

  3. 播放端网络:如果播放端自身网络不够好,那么即使CDN已经分配了就近节点,这个用户依然会出现卡顿的情况。

因此,如果要避免卡顿,需要同时监测以上几个环节。主播端和播放端都可以通过监测客户端网络,把实际网络发送接收情况上报给服务器,从而在服务端快速定位到卡顿情况的发生。同时,以第三方CDN监控服务作为辅助,监测CDN节点的服务质量和稳定性,这样就可以尽早发现和定位卡顿问题,提高QoS了。

CSDN:分享一下视频直播秒开背后都运用到了哪些技术?

郝飞:所谓的秒开就是从点击直播节目开始到出现第一帧图像的时间控制在一秒以内,有了这种体验,用户使用起来才会感觉足够顺畅; 如何才能达到秒开的效果呢?首先我们来分析下第一帧视频显示前需要哪些步骤。

视频显示前的准备步骤
  1. 播放器首先通过DNS解析来获取流媒体访问节点;

  2. 播放器与最近的流媒体节点建立连接,然后根据所使用的协议进行握手;

  3. 从CDN节点接收流媒体数据后,Demux从流数据中区分出音频和视频的数据信息,分别交给音视频解码器;

  4. 音视频解码器进行解码操作;对于视频来说,由于B帧和P帧都要参考I 帧,因此解码器解码的第一帧必须是I 帧;第一个I 帧以前的视频数据都称为无效数据;

  5. 音视频解码后的数据发送给上层player进行同步播放。

从以上流程中,大家可以了解到,通过以下方面的优化可以减少第一帧图像显示的时间:

(1)DNS解析优化

可以考虑在空闲的时候使用Ping 命令获得域名对应的IP,从而减少域名解析时间。

(2)传输层使用UDP

使用UDP的优点是连接建立速度快,流传输效率高;缺点是应用层需要解决网络丢包的问题;目前大部分CDN 不支持UDP 协议的直播。

(3)使用Http-FLV协议替代RTMP协议

目前播放端直播协议主要包括HLS,RTMP,HTTP-FLV,其中HLS延迟比较大,直播类App 更倾向于使用RTMP 和HTTP-FLV协议,他们的延迟基本上在一个数量级;从满足秒开的体验来看,建议使用HTTP-FLV 协议,相比于RTMP,FLV的握手协议要简单很多,下图为两种握手协议的对比:

RTMP和HTTP-FLV对比图

(4)服务端GOP数据缓存,减少播放端拿到无效流数据

由于播放端必须拿到I帧后才能够开始解析,因此服务端缓存GOP 数据后,可以避免与播放端无效数据的传递;从而减少秒开的时间。

CSDN:谈谈WebRTC在音频通话开发中的使用?

郝飞:以下为音频通话的基本原理图:

CSDN:直播的美颜和水印等预处理都有哪些方案?

郝飞:目前的美颜效果主要就是磨皮和美白。磨皮的本质就是模糊,常使用的算法包括高斯模糊和双边滤波,后者在边缘上的处理效果会更好些。这些算法的实现在GPUImage这个开源项目中都有,可以很容易的集成到应用中,但是简单的滤波算法还不足以满足大家对美颜的要求。亲加的美颜经过了三个版本:

  1. 第一个版本的实现就是使用双边滤波,其特点是运行速度很快,但是效果一般;

  2. 第二个版本使用了双边滤波+肤色检测+轮廓识别+亮度调节的滤波组合; 其美颜效果很不错,但问题是性能开销太大了,中档以下机型会有些卡顿,并且发热量大;

  3. 最后的版本采用的单滤镜+亮度肤色调节,此版本兼顾了性能与效果,性能上与第一个版本类似,效果上与第二个版本类似。

以下是三个版本的美颜效果对比:

水印是直播中常见的功能之一,它可以用于简单的版权保护和广告设置。目前,国家出于监管的需要,也规定视频直播必须打上水印。其实现一般是在主播端或者服务端实现,很少在观看端实现。因为如果放在观看端,可能会有些恶意竞争者直接拿到未加水印的视频流,这样就起不到数字保护的作用了;视频内嵌水印的实现比较简单,就是水印图片与视频图片的合成,大部分图像处理的库中都包含这个功能。

CSDN:在直播中如何做到完美的交互体验?

郝飞:直播是数据的单向流动,而在很多应用场景中,只有让用户参与起来,形成主播与用户,用户与用户之间的交互,这样才更能体现直播的价值; 在实际应用中,不同场景对交互有不同的需求,以下几种交互满足了大部分场景的交互需求;

  1. 支持超大用户群的,内容可监管的互动聊天室

    聊天室目前已经成为了直播的标配功能,简单的实现一个聊天室并不难,但如果要支持几十万人同时在线的低延迟聊天场景就会比较困难了。同时,对于很多场景来说,聊天内容是一定需要监管的,传统的监管手段包括关键词过滤,踢人,禁言等,其中关键词过滤属于事前监管,踢人和禁言属于事后处理。而事前监管中,还有一种称为“审核”的功能,也是非常有用的。在审核的流程中,用户的发言必须通过审核员的检查,通过审核的其它用户才能看到。

  2. 连麦功能

    在一对多直播中,用户只能观看,无法参与,而连麦功能使视频不再只是单向的输出,而变成了双向交互的升级形态,从而给用户带来更多的参与感,其流程如下:

     

    正在直播中的节目进入到了互动的环节,节目需要选出在线观看的一位观众参与到互动中;在线观看直播的用户申请参与互动;主持人同意用户的申请,这时用户与主持人实时进行音视频交互,交互过程直播给所有其他观众。
    3.基于视频内容的互动
    之前提到的互动方式都是独立于视频的单独的交互系统,基于内容本身的交互更能吸引用户的参与。例如在直播美妆的过程中,当某一个品牌的化妆品出现后,同时弹出此化妆品相关的介绍和购买链接,对此化妆品感兴趣的用户可以立刻进行购买。这种交互的实现原理就是在流媒体中嵌入附加信息,
    为了保证用户观看时附加信息能够与画面进行严格的同步,这种附加信息最好嵌入在流媒体中(可以在视频编码或者流媒体协议封装环节),而不是通过消息通道通知到观看端,因为每个观看端的进度不一样,很容易出现不同步的情况。

用户可以根据直播场景的不同,选择以上几种交互方式,从而让直播体验更加完美。

CSDN:在移动直播过程中遇到过哪些坑及如何优化?

郝飞:移动直播开发中,经常会碰到以下几类问题:

1.系统延迟大,特别是累积延迟高,播放时间越长,延迟越大

影响延迟的环节包括音视频预处理,编码,CDN分发,拉流,解码等;其中预处理,编码和解码引入的延迟与设备硬件相关,可以通过提升设备性能优化。而CDN分发和拉流所引入的延迟则是网络环境决定的,CDN转发的节点越多,则延迟越大;播放端与CDN节点之间的出现丢包,网络抖动等,也会导致延迟增加。针对于累积延迟,播放端可以采用动态追帧的方法,在尽量不影响视频质量的前提下进行丢帧处理;同理,主播端如果发现也有视频帧累积的现象,也可以考虑丢帧处理,前提也是尽量不要影响视频质量。

2.播放出现卡顿情况,影响用户体验

视频的卡顿主要是客户端和CDN之间的网络环境导致的。如果主播端上行网络环境不好,则所有观看端都会受影响,可以考虑通过减少帧率或者动态调节码率的方式保证主播端推流稳定;如果CDN的某个分发节点出现问题,则路由到此节点下的所有客户端都会观看都会受到影响;这种情况可以通过采用第三方监控,或者收集客户端卡顿报告的方式尽早发现并修复;如果某个客户端的网络环境不好,则主要影响此用户观看体验,一般的视频流在服务端都会转成不同码率的几路视频,播放端可以动态的切换到低码率,从而保证观看的流畅性。

3.视频启动慢,用户体验差

播放启动慢会严重影响用户体验;解决办法可以参考以上提到的秒开的实现。

4.Android机器适配不够,出现崩溃,闪退等现象

Android 机型比较多,各种品牌机器的硬件参差不齐,同时,直播还会使用到硬件编解码,而这些硬件特性也依据Android的版本和机器的不同而各有差异。 因此,建议大家在选择直播SDK的时候,尽量选用被广泛使用的,能够提供现有手机适配列表的版本,这类SDK已经经过市场证明,出现崩溃和闪退的概率会低很多。

5.主播手机发烫,画面卡顿,特别是增加美颜特性后

直播涉及到音视频预处理,编码,特别是美颜功能等耗CPU资源的操作,因此会出现手机发烫等情况,特别是低端的手机。 建议主播端尽量采用高端些的手机,这些手机不仅仅是CPU能力强,同时还支持硬件的编解码功能,可以大大降低手机的功耗。同时,美颜实现的不同对于发热的减少也很有帮助,具体可以参考上面的美颜介绍。

CSDN:您觉得直播技术的入门门槛高吗?

郝飞:如果是在应用中嵌入直播功能,仅从应用的角度理解直播的流程,这个技术门槛并不高,一般的应用开发者,通过调用直播平台的接口就可以很快速的把直播功能嵌入到系统中了。 但如果希望从事直播相关系统的开发,就需要学习很多相关知识了,具体可参考CSDN出品的关于直播技术知识库。

CSDN:关于技术学习您有什么心得?我们上线了知识库系统化学习的方法,您会怎么应用呢?

郝飞:总的来说,技术学习应该从深度和广度两方面来不断加强。技术的细分领域很多,任何人都不可能精通所有技术,所以首先要根据自己的实际情况确定一个技术方向,然后通过看书,网上找资料,实际工作中的项目等方式来建立起自己在这个领域的知识结构图。在这个过程中,你会发现有些学到的知识在实际工作中使用不到,那这部分就仅仅停留在理论层面,没有充分了解和吸收,这时候可以考虑参与相关的开源项目并进行知识总结分享。通过这样的方式与更多的开发者互动起来,对自己的知识结构可以起到重构和完善的作用,到了一定程度后,对于如何学习,学习什么这些问题你就有自己的答案了。当某一个领域研究的比较深入后,可以横向扩展一下,把与这个领域相关的其他知识也涉猎一下,这样你会对整体流程的把握更加清晰,会从更全面的视角审视你开发的系统。

文章标签: CTO 直播 架构


关注微信公众号“架构说”,加入Q群微群,让架构师带你飞︿( ̄︶ ̄)︿。


原文链接: 阅读原文
免责申明: 架构说任何转载的文章都会明确标注原文链接。如有侵权,请与本站联系。
转载说明: 架构说原创文章转载时请务必注明文章作者、链接和来源。