找回密码
 立即注册
LiveVideoStack 首页 资讯 查看内容
  • QQ空间
  • 回复
  • 收藏

低延迟音视频传输技术在直播领域的应用(1)

2018-6-15 09:00

文 / 吴涛

整理 / LiveVideoStack




概览


我有幸曾在互联网、安防监控、广电音视频传输三大领域从事工作,感觉自己现在的水平应该仅够满足实战需求了,所以今天在这里不敢说为大家做分享,只能说为大家汇报一些自己在这三个领域工作的心得体会。


互联网直播的话题已经是老生常谈了,我们也很难再讲出来一些新的东西。我最早来到陌陌的时候,陌陌做音视频传输技术的只有四个人,一个做客户端,一个做支付,一个做后台,剩下一个由我来做音视频。可以说我见证了陌陌直播从襁褓之中成长为现在这样一个成熟直播平台的全过程。2017年Q4财报显示,陌陌现在月活跃用户数9910万人,收入是3.58亿美元,而陌陌视频收入约3.2亿美元,也就是说陌陌90%多的收入都是视频提供的,这是现在陌陌直播平台的发展情况。



今天我向大家分享的主要内容有:


  1. 基于CDN架构的直播应用

  2. 基于CDN架构的低延迟直播的应用

  3. CDN架构下非交互直播的问题

  4. 带有交互能力的直播

  5. 直播技术未来的发展


1.基于CDN架构的直播应用


这张图是陌陌APP直播界面去除礼物、动画等元素的效果图。一位主播在屏幕前为用户表演。主播能做的事,对着屏幕表演,用户除了给主播送礼物或发消息外无法与主播进行其他交互。有时用户会发现主播不会对自己发送的消息作出反馈,这是为什么?第一种原因可能是这位主播受关注度比较高,消息量比较大,无法一一进行回复;第二种原因可能是此时端对端延迟过大,使得主播响应无法及时送达到观众端。



以上是其中一种基于CDN架构的直播架构图。这个架构图很简单,主播把直播数据推到了一个CDN的边缘节点,用户再从CDN的另一端的边缘节点获取直播数据,这种架构在直播当中十分常见,为什么使用这种简单架构?


1.1优势


显而易见的是,其优势就是简单。使用这种架构意味着企业不需要开发者有多强的网络技术能力,只需要确定域名后把音视频传入即可完成。并且,简单意味着这种架构的开发效率非常高,也许只需编写几行代码或者进行配置即可完成。对于一个应用型公司来讲,这种方案的开发门槛很低,所需要的时间、人力资源成本都很低,这也是互联网直播使用CDN的好处之一。


1.2 劣势


当然这种方案也存在劣势。第一我们知道CDN是建立在TCP协议上的,这就导致CDN会受到TCP协议本身的约束,实时音视频数据传输TCP协议栈并不十分理想;第二是使用CDN质量差异较大;第三是使用CDN难以随需求进行定制化,CDN面对很多用户的需求都是非定制化的;第四是使用CDN架构端对端的延迟大,我特意使用虚线将主播与观众相连标记时间。虽然每家公司的CDN解决方案都号称端对端延迟只有三秒,实际上如果从用户良好体验的角度出发,经过测算端对端的延迟控制在5秒比较理想,低于5秒就可能会出现卡顿等影响体验的问题。


1.3 技术关键点


CDN架构是直播的基础方案,我们必须把这个方案做得足够完美才能在直播体验上有优势。除了以上叙述的关键点,在实际应用场景上CDN还会受到很多条件的约束:从用户体验的角度来讲,观众使用手机观看直播,无论是使用陌陌还是其他友商的APP,当使用这个应用进入感兴趣的直播间首先体验到的是能够快速呈现直播内容。如果用户点击某个直播间后需要等待一下或者获取视频失败,无疑是一个非常糟糕的体验;其次是画面的清晰度与流畅程度;再次是与主播间的延迟这些都是从用户体验的角度出发遇到的问题,我们需要使用技术手段来解决用户遇到的这些问题。

我们把遇到的这些问题大致分成两个方面并加以解决:一个是传输的前端,一个是传输的后端。


1.3.1 传输前端·推流器问题


首先需要解决的是传输的前端也就是主播端,在主播端需要解决的是推流器问题。



1)抗拥塞

对用户而言在直播体验上最糟糕的无疑是卡顿。用户希望能够看到流畅的直播,但是如果使用TCP协议就会出现拥塞问题,那么我们如何来抗拥塞呢?抗拥塞本质是是降低TCP协议拥塞构成的干扰,其原理比较简单,一种方案是减少在推流器上发送的数据,降低帧率、码率、分辨率等各种数据的传输量,数据的传输效率降低,拥塞对直播画面的影响就会减弱;另一种方案则更加简单粗暴,也就是一旦出现拥塞我们就丢弃数据或者重新建立链接,这样也会有效减弱拥塞对直播画面的影响。


2)秒开问题

第二点就是秒开问题,也许会有人认为使用CDN架构并不存在秒开问题,只要缓冲第一帧是关键帧就可解决。这个观点没错但是不全面,需要缓冲多少数据?是缓冲一个关键帧还是关键帧所在的一个完整的GOP?还是一个关键帧与一些P帧(对于直播而言很少有B帧,因为B帧的编解码耗时多,所以直播视频尽量不使用B帧)?具体缓冲多少?这便牵扯到如何对GOP进行设置,而GOP的设置必须由编码器决定,因为对于直播视频流而言,一个GOP中I帧的占比是非常大的,与同等参数下的体育直播不一样。体育直播P帧与I帧的大小实际上是近似的,因为体育直播受到场景画面变化剧烈的影响,也就是说GOP的具体参数需要根据直播场景与视频画面进行设置,并不能简单理解为在CDN边缘只缓存一个关键帧或者只缓存几个数据就能解决。也许一个GOP值设置的非常庞大导致一个GOP需要三秒钟,当用户打开直播画面时一个关键帧后画面出现一个跳转,这种的体验是非常糟糕的。我们根据直播的场景在编码器上设置GOP能够妥善处理秒开问题。


3)清晰度

用户需要能够快速打开视频并且流畅观看,也需要看到清晰的画面。以家庭影院为例,从最早的录像带,进化成VCD再进化到DVD,再进化到现在的蓝光4K等等,画面清晰度始终是用户所追求的一项重要指标。这里我有一份数据统计:陌陌在每年1月7号都会有一个盛典,直播舞台上进行的一些表演。我把直播画面清晰度进行了简单分类,第一个是960×540的标清分辨率,第二个是1280×720的高清分辨率,第三个是1080P的全高清分辨率。分辨率为960×540时传输需要1M的带宽,这时如果通过正常的互联网传输直播画面是很少卡顿的;而当分辨率提高到1280×720时就需要2.5M到3M左右的带宽进行传输,这时如果用户是在家里拿手机看直播画面便会出现一些卡顿;当分辨率提高到1080P时稳定传输需要5M以上带宽,在这种情况下除非用户家里宽带的网络质量非常好或者手机4G信号特别强,否则就会出现多次直播画面的卡顿。但根据用户反馈的数据来看:分辨率为720P的观看用户是最多的,使用1080P观看直播画面的用户占到了总用户量的10%,其中观看画面模糊但流畅的用户只占不到25%,也就是说清晰度对于用户而言非常重要。如何在推流器端优化清晰度呢?解决此问题不只依赖某个技术点,我们可以通过场景渲染、色彩增强等技术,也可根据直播环境背景色调整主播的着装、环境光照等等,这些都会决定画面的清晰度;我们可以将一路画面设置成不同的分辨率,对于两个不同的分辨率的视频我们可以使用光照去弥补,使得用户在不同的分辨率上看到近似清晰的效果。总而言之,我们可以对不同的场景进行调整与匹配,优化画面的清晰度。


1.3.2 传输后端·播放器问题



解决完推流器问题,接下来需要解决的是播放器问题。


1)抗卡顿

关于播放器首先需要解决的还是卡顿问题。抗卡顿是保证用户体验中最重要的方面,尤其是对于直播而言。那么如何在播放器端妥善解决卡顿问题?较为简单的方案是加缓冲,缓冲区的存在可以有效减少卡顿的次数与机率。


2)抗延迟

为什么用户给主播发消息给主播,隔了好厂一段时间才有反馈?因为直播画面存在延迟。卡顿与延迟是互相矛盾的条件,画面流畅意味着可能延迟增大,延迟减小画面又可能会因为网络不稳定等原因出现卡顿。关于这一点我们只能针对不同使用场景和业务环境进行动态调整,在减少延迟的同时尽量保证画面的流畅。


3)拉流成功率

关于这一点的问题比较少见,理论上CDN模式能够全球覆盖、全网覆盖,拉流肯定会成功,实际并非如此。举个极端的例子,西部偏远地区会经常出现拉流失败;而在在流量高峰时段,数据采集拉流成功率只有90%左右,这就会导致用户无法成功打开直播画面,直播清晰度流畅度也无从谈起了,所以拉流成功率也需要我们关注。关于拉流成功率还需要说明的一点是,因为一些规模较小的宽带运营商会做一些网带缓冲,也可以说是域名劫持。一旦出现域名劫持自然无法成功拉流或者拉到非线上直播的流,这比较麻烦。为解决这一问题,在陌陌我们可能不一定下发IP而是一个302的调度点。通过这些措施来保证客户端成功获取正确的视频流,确保拉流成功率。


2.基于CDN架构的低延迟直播的应用



讲完了CDN架构的简单应用,接下来讲一讲年初最火的直播答题。这张图是陌陌的一个直播答题界面,直播答题实际上有什么难点呢?


3.CDN架构下非交互直播的问题



延迟高、交互性差、表演内容相似度高、观众无法简单参与


为什么会有这些问题?因为此方案只是把播放器和CDN上的边缘缓冲全部去除,这种模式是最简单的。我们没有对现有的CDN架构进行重大调整而是将主播推到CDN变成将主播推到三体云,只需要调整SDK上的几行代码即可实现。


4.带有交互能力的直播


模式一:普通连线




虽然普通连线解决了最简单的问题,但在实际应用场景中基本已经没有厂商使用这种模式,因为通过这种模式达成的直播效果十分单调。


模式二:主播间连线


主播与主播之间的连线实际上是现在最受直播平台与主播欢迎的一种直播答题模式。对于平台而言可以通过这种模式让一些不知名的主播与知名主播进行PK,能够为提升主播知名度同时给直播平台带来流量;对于主播而言通过与别的主播进行PK可以推出新玩法,进一步的互动避免直播内容的同质化。这种模式的架构是数据从两位主播所在的手机编码器两端推到CDN,观众从CDN边缘获取直播数据;与此同时数据也由主播端推到中间的互动云服务器,主播与主播之间通过互动云进行连接。这种架构是最初搭建的一种,因为简单到不需要大的改动就能实现。但实际上这种架构也存在问题:也就是这需要双推主播端的直播数据,一路数据被推到CDN一路数据推到互动云。两路数据意味着两路编码,这对CPU、对带宽的消耗很大。根据简单测试在正常的环境或者在Wi-Fi的环境下,手机推流超过1.2M的时出现抖动的机率就会显著提高。两路编码会带来较高的CPU性能损耗,进而导致手机的发热问题。如果我们对这种架构进行优化:

WebRTC, 音频, 直播, 视频, WebRTCon, 吴涛

来自: LiveVideoStack
文章点评
相关文章