如何像百度直播同样优化用户体验(起播篇)

图片

导读:随着互联网的发展,愈来愈多人喜欢直播,百度直播也在快速发展中,为了提高用户的使用体验,本文针对百度直播的复杂流程进行了总体梳理,并详细说明开展的一系列起播优化工做。html

全文4216字,预计阅读时间 9分钟。前端

1、背景

百度作直播有两个目标:ios

一、把现实世界照搬到线上,在线上和在线下有同样的体验,直播种类有媒体、咨询、电商、秀场等;git

二、是对美好想象的一个完美塑造,随着5G、VR、AI到来,带给咱们想象的空间,把线下没有的东西超越这个时空,放到线上,超越线下的想象空间。github

作直播首先要作的就是QOE(Quality of Experience),咱们做为技术同窗在保证业务目标的同时,也要提高用户的体验。后端

直播的体验有不少:首屏时间、延迟、画面质量、音画同步、清晰度、杂音、回声等。缓存

图片

从QOE角度出发,做为衡量的标准QOS(Quality of Service)也有不少:推流成功率、推流卡顿流、转推慢速比、端到端延迟、CDN流畅率、启播耗时、拉流卡顿率、视频码率、转推慢速比、内存消耗、CPU&GPU消耗等等。这些技术指标统一构成一个总体,做为衡量直播服务质量的标准。网络

可是从直播用户的角度出发,当用户点开直播后,用户但愿可以立刻看到画面,也就是直播启播速度要快;当在沉浸式直播间上下滑动时,用户也会但愿当前屏幕要看到的直播迅速启播。启播耗时做为用户的首个直播感知,被放到了首要优化的目标。架构

图片

2、现状

百度直播分中泛服务直播&泛娱乐直播,其中泛服务直播提供了媒体直播、咨询直播、电商直播等服务,泛娱乐直播提供了秀场、音播、语音房等娱乐直播。框架

图片

其中泛服务直播更为复杂一些,关于启播流程有如下几个特色:

一、流程繁琐:分为外部跳转直播间&沉浸式直播间内跳转两套流程,其中流程流转环节也较多;

二、直播状态较多:包含了直播中,回放、回放生成中等状态

三、涉及面广:涉及百度App多个团队:直播、播放器、内核、网络、CDN等

四、行驶汽车换轮子:百度极度重视直播,业务高速迭代,须要给行驶的汽车换轮子。

图片

总结完了泛服务启播的特色,那么就要定量的去分析整个启播的流程,用数据来衡量整个启播的环节。

3、数据分析

对整个启播流程进行数据分析,大体将启播流程分为三个大阶段:**直播业务耗时、播放器耗时、内核耗时。**下图是大体的划分:

图片

在实际数据统计中,会对各个环节进行更精细的统计,简单说一下直播业务的数据统计和内核的数据统计:

图片

图片

直播业务的每一个环节的进行数据量化,精确到每一个步骤耗时,这样在数据的基础上进行分析。

之内核为例:

图片

而后就能够获得一份详尽关于内核的数据的图表。

从用户点击跳转到直播间或者沉浸式直播间内滑动切换直播间,到最终的直播播放成功,预计会有60多个的点位进行一些列的追踪分析。详细的数据表格呈现启播过程当中每一步骤的耗时,而后针对于耗时多的地方进行优化。

首先在报表里面占比最大的是业务场景的耗时,约占到60%以上,那么首先解决的就是这块耗时;
第二块耗时占比较大的阶段是拉流的耗时;
当比较大的耗时解决后,就须要针对于小的耗时进行针对性的优化。

业务场景的优化

百度App的媒体直播和全民的秀场直播融合以后,会在直播间内进行混合分发。从直播跳转角度来看,直播间的跳转分为两种:一种是外部经过scheme跳转到直播间,一种是沉浸式直播间内的滑动跳转;

下面是外部经过scheme跳转到直播间的简单流程:

图片

经过scheme跳转直播间有两种状况:

一、无roomID的的状况,首先须要请求list接口,而后根据list中的roomId来继续请求当前直播间的相关信息,根据相关的信息进行组件&插件的的安装以及渲染操做,当页面渲染完成后,开始建立播放器,setURL,并初始化内核,开始播放直到播放成功回调;

二、有roomID的状况,那么会直接请求当前直播间的相关信息,而后执行与步骤1相同的操做。

下面是沉浸式直播间内的滑动跳转:

图片

相对于外部跳转,沉浸式直播间内跳转多了用户的滑动操做,从滑停开始统计启播,直到播放成功回调,整个启播时长预计在1700ms左右,而在整个流程中,整个直播的业务耗时约为1000ms左右。
外部跳转:内部跳转 = 1: N;N要远远大于1,这样看的话,优先优化直播间内跳转。

定性定量分析后,制定针对的优化方案:

图片

基于页面卡顿的考虑,总体方案A&B两种:

A方案是在iphone8及以上的机型上面实施:在用户滑动开始时开始建立播放器,而且直接调用播放。

方案B是在iphone8如下的机型上面实施:在用户滑动时开始建立播放器而且准备好资源,在用户滑停以后销毁上个直播间,而且开始下个直播间的播放。

A&B方案的实施,使得卡顿率在这iphone8上下的机型都可以表现的不错,并不会给用户卡顿带来劣化的体验,针对于机型也是通过ABTest不断测试启播与卡顿之间的平衡,寻求的一个暂时的平衡点。后面也会针对于卡顿来作不断的优化来避免对象频繁的建立与销毁,来减小CPU的不断计算,以使方案A所适应的机型不断扩增。

有了直播间内部跳转的优化方案以后,那么外部scheme的跳转也就显而易见了:

图片

百度App的组件间通讯方案使用的scheme来通讯,那么在scheme里面添加直播的URL,在跳转进直播页面时直接经过scheme携带的URL来建立播放器,并开始播放直播,与业务逻辑并行执行。

4、DNS预解析

DNS(Domain Name System),它的做用是根据域名查出IP地址,它是HTTP协议的前提,只有将域名正确的解析成IP地址后,后面的流程才能进行。在内核处理直播流的时候,直播DNS耗时八十分位大约在60ms,这块的耗时也是比较多的。

在百度AppAPP中,防止DNS的劫持,同时也是为了下降网络时延,咱们采用了HTTPDNS的方案:

图片

为了优化直播DNS解析耗时,采用DNS预解析策略,提早缓存对应的IP,能够减小DNS解析的耗时时间。

在应用冷启10s、网络切换、先后台切换等时机,根据模型判断是否采起直播DNS预解析方案,模型的判断标准为:用户N天内浏览直播时长M、当前网络状态、后端控制等等。当模型断定经过时,会调用HTTPDNS异步发起直播域名的解析得到一个IP列表,对IP分别进行测速,测速后并非直接选用结果最优的那一个,而是在测试结果能够接受的必定范围内进行随机挑选并缓存预解析的结果。避免了大量用户都汇集到少数节点,致使的节点负载不均衡。

HTTPDNS缓存IP的有效时间是从服务端获取的,默认300s。当直播流域名解析开始时,查询缓存,若存在有效IP(缓存时间<300s)直接返回对应IP,并调用HTTPDNS异步发起请求更新。若不存在也会异步发起请求更新,此时会降级到LocalDNS解析。

当网络变化时(Wifi <-> 4G),清除当前的缓存IP,并从新发起域名列表内全部域名的预解析。

最终收益:使用HTTPDNS预解析后,直播DNS耗时小于3ms的PV占总直播PV的90%以上。

5、内核的一些优化

针对于报表里面耗时较多的阶段,进行了一系列针对的优化:

一、首屏强制渲染:主要就是视频的首帧解码出来就会强制走渲染流程,不会去作音画同步;

二、弱网状况下,启动低码率启播策略;

三、高端机型下加载下个播放器内核,并prepare,当切换直播时进行追帧操做。大概逻辑就是缓冲区延时超过3秒就每隔2秒就丢200ms音频,直到低于3秒内不丢,若是超过16秒,就会所有丢掉 直接重连。

6、直播起播优化

直播起播优化-媒体信息解析模块的优化

视频宽高、图像编码格式等信息是Android平台硬件解码器Mediacodec,IOS平台硬件解码器Video ToolBox必备信息,播放内核在配置平台硬件解码器以前,须要准备好视频宽高、图像编码格式等信息。

一些封装格式(例如MP4)会在头部描述视频宽高、图像编码格式等信息,针对视频容器不包含上述信息的状况(例如FLV),FFMPEG原生流程就循环的下载视频流,而后经过软件解码器解码视频,获取上述信息;

在H.264/AVC视频编码标准中,整个系统框架被分为了两个层面:视频编码层面(VCL)和网络抽象层面(NAL)。其中,前者负责有效表示视频数据的内容,然后者则负责格式化数据并提供头信息,以保证数据适合各类信道和存储介质上的传输。NAL中的SPS,PPS中已经宽高信息,图像编码格式的描述,能够经过解析SPS,PPS获取必要信息,省去软解视频的流程。

图片

7、直播回放(HLS)m3u8预取

直播视频一般会被编码成HLS格式保存,咱们称此为直播回放,HLS封装格式的视频起播80分位为1250ms,起播速度是反应播放体验的核心指标,直播回放起播性能显著差于直播(HTTP-FLV)的510ms。

HLS封装起播慢的主要缘由是由于须要先下载视频索引文件(M3U8),经过解析该索引文件才获得真正的视频文件,也就是说相比直播(HTTP-FLV)至少多了一次HTTP的请求。为了解决这个问题,经过提早预取HLS视频索引文件(M3U8)到本地sdcard;起播时省去了M3U8下载部分耗时,AB实验收益:对比命中和未命中预取M3U8实验组,命中预取收益为346ms。

图片

参考文献:

https://chromium.googlesource.com/chromium/src/+/HEAD/docs/ios/build_instructions.md

https://tools.ietf.org/html/rfc7858

https://github.com/bilibili/ijkplayer

招聘信息

百度-直播研发部-泛知识直播组,团队旨在建设业界一流的直播体验,技术驱动业务,并在直播场景中不断的创新,结合 VR&AR&AI 等技术,不断探索新的玩法。播放内核, 团队经过不断提高内核的基础性能,加强内核能力,完善指标监控,提升服务能力,最终实现更好的用户体验和产品质量。

诚邀iOS & Android小伙伴,关注同名公众号百度Geek说,点击菜单栏“内推”便可加入搜索架构部,咱们期待你的加入

推荐阅读:

|百度搜索稳定性问题分析的故事(下)

|百度搜索稳定性问题分析的故事(上)

百度关于微前端架构EMP的探索:落地生产可用的微前端架构

---------- END ----------

百度Geek说

百度官方技术公众号上线啦!

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢迎各位同窗关注

相关文章
相关标签/搜索