导读：随着互联网的倒退，越来越多人喜爱直播，百度直播也在疾速倒退中，为了晋升用户的应用体验，本文针对百度直播的简单流程进行了整体梳理，并具体阐明发展的一系列起播优化工作。
全文4216字，预计浏览工夫 9分钟。
一、背景
百度做直播有两个指标：
1、把事实世界照搬到线上，在线上和在线下有一样的体验，直播品种有媒体、征询、电商、秀场等；
2、是对美妙设想的一个完满塑造，随着5G、VR、AI到来，带给咱们设想的空间，把线下没有的货色超过这个时空，放到线上，超过线下的设想空间。
做直播首先要做的就是QOE（Quality of Experience），咱们作为技术同学在保障业务指标的同时，也要晋升用户的体验。
直播的体验有很多：首屏工夫、提早、画面质量、音画同步、清晰度、杂音、回声等。
从QOE角度登程，作为掂量的规范QOS（Quality of Service）也有很多：推流成功率、推流卡顿流、转推慢速比、端到端提早、CDN晦涩率、启播耗时、拉流卡顿率、视频码率、转推慢速比、内存耗费、CPU&GPU耗费等等。这些技术指标对立形成一个整体，作为掂量直播服务质量的规范。
然而从直播用户的角度登程，当用户点开直播后，用户心愿可能马上看到画面，也就是直播启播速度要快；当在沉迷式直播间高低滑动时，用户也会心愿以后屏幕要看到的直播迅速启播。启播耗时作为用户的首个直播感知，被放到了首要优化的指标。
二、现状
百度直播分中泛服务直播&泛娱乐直播，其中泛服务直播提供了媒体直播、征询直播、电商直播等服务，泛娱乐直播提供了秀场、音播、语音房等娱乐直播。
其中泛服务直播更为简单一些，对于启播流程有以下几个特点：
1、流程繁琐：分为内部跳转直播间&沉迷式直播间内跳转两套流程，其中流程流转环节也较多；
2、直播状态较多：蕴含了直播中，回放、回放生成中等状态
3、涉及面广：波及百度App多个团队：直播、播放器、内核、网络、CDN等
4、行驶汽车换轮子：百度极度器重直播，业务高速迭代，须要给行驶的汽车换轮子。
总结完了泛服务启播的特点，那么就要定量的去剖析整个启播的流程，用数据来掂量整个启播的环节。
三、数据分析
对整个启播流程进行数据分析，大抵将启播流程分为三个大阶段：直播业务耗时、播放器耗时、内核耗时。下图是大抵的划分：
在理论数据统计中，会对各个环节进行更精密的统计，简略说一下直播业务的数据统计和内核的数据统计：
直播业务的每个环节的进行数据量化，准确到每个步骤耗时，这样在数据的根底上进行剖析。
以内核为例：
而后就能够失去一份详尽对于内核的数据的图表。
从用户点击跳转到直播间或者沉迷式直播间内滑动切换直播间，到最终的直播播放胜利，预计会有60多个的点位进行一些列的追踪剖析。具体的数据表格出现启播过程中每一步骤的耗时，而后针对于耗时多的中央进行优化。
首先在报表外面占比最大的是业务场景的耗时，约占到60%以上，那么首先解决的就是这块耗时；
第二块耗时占比拟大的阶段是拉流的耗时；
当比拟大的耗时解决后，就须要针对于小的耗时进行针对性的优化。
业务场景的优化
百度App的媒体直播和全民的秀场直播交融之后，会在直播间内进行混合散发。从直播跳转角度来看，直播间的跳转分为两种：一种是内部通过scheme跳转到直播间，一种是沉迷式直播间内的滑动跳转；
上面是内部通过scheme跳转到直播间的简略流程：
通过scheme跳转直播间有两种状况：
1、无roomID的的状况，首先须要申请list接口，而后依据list中的roomId来持续申请以后直播间的相干信息，依据相干的信息进行组件&插件的的装置以及渲染操作，当页面渲染实现后，开始创立播放器，setURL，并初始化内核，开始播放直到播放胜利回调；
2、有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来创立播放器，并开始播放直播，与业务逻辑并行执行。
四、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%以上。
五、内核的一些优化
针对于报表外面耗时较多的阶段，进行了一系列针对的优化：
1、首屏强制渲染：次要就是视频的首帧解码进去就会强制走渲染流程，不会去做音画同步；
2、弱网状况下，启动低码率启播策略；
3、高端机型下加载下个播放器内核，并prepare，当切换直播时进行追帧操作。大略逻辑就是缓冲区延时超过3秒就每隔2秒就丢200ms音频，直到低于3秒内不丢，如果超过16秒，就会全副丢掉 间接重连。
六、直播起播优化
直播起播优化-媒体信息解析模块的优化
视频宽高、图像编码格局等信息是Android平台硬件解码器Mediacodec，IOS平台硬件解码器Video ToolBox必备信息，播放内核在配置平台硬件解码器之前，须要筹备好视频宽高、图像编码格局等信息。
一些封装格局(例如MP4)会在头部形容视频宽高、图像编码格局等信息，针对视频容器不蕴含上述信息的状况(例如FLV)，FFMPEG原生流程就循环的下载视频流，而后通过软件解码器解码视频，获取上述信息；
在H.264/AVC视频编码标准中，整个零碎框架被分为了两个层面：视频编码层面（VCL）和网络形象层面（NAL）。其中，前者负责无效示意视频数据的内容，而后者则负责格式化数据并提供头信息，以保证数据适宜各种信道和存储介质上的传输。NAL中的SPS，PPS中曾经宽高信息，图像编码格局的形容，能够通过解析SPS，PPS获取必要信息，省去软解视频的流程。
七、直播回放(HLS)m3u8预取
直播视频通常会被编码成HLS格局保留，咱们称此为直播回放，HLS封装格局的视频起播80分位为1250ms，起播速度是反馈播放体验的外围指标，直播回放起播性能显著差于直播(HTTP-FLV)的510ms。
HLS封装起播慢的次要起因是因为须要先下载视频索引文件(M3U8)，通过解析该索引文件才失去真正的视频文件，也就是说相比直播（HTTP-FLV）至多多了一次HTTP的申请。为了解决这个问题，通过提前预取HLS视频索引文件（M3U8）到本地sdcard；起播时省去了M3U8下载局部耗时，AB试验收益：比照命中和未命中预取M3U8实验组，命中预取收益为346ms。
参考文献：
https://chromium.googlesource...\_instructions.md
https://tools.ietf.org/html/r...
https://github.com/bilibili/i...
招聘信息：
百度-直播研发部-泛常识直播组，团队旨在建设业界一流的直播体验，技术驱动业务，并在直播场景中一直的翻新，联合 VR&AR&AI 等技术，一直摸索新的玩法。播放内核, 团队通过一直晋升内核的根底性能，加强内核能力，欠缺指标监控，进步服务能力，最终实现更好的用户体验和产品质量。
诚邀iOS & Android小伙伴，关注同名公众号百度Geek说，点击菜单栏“内推”即可退出搜寻架构部，咱们期待你的退出！
举荐浏览：
｜百度搜寻稳定性问题剖析的故事（下）
｜百度搜寻稳定性问题剖析的故事（上）
｜百度对于微前端架构EMP的摸索：落地生产可用的微前端架构
---------- END ----------
百度Geek说
百度官网技术公众号上线啦！
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边
欢送各位同学关注