导读：随着互联网的倒退，越来越多人喜爱直播，百度直播也在疾速倒退中，为了晋升用户的应用体验，本文针对百度直播的简单流程进行了整体梳理，并具体阐明发展的一系列起播优化工作。

全文 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 说

百度官网技术公众号上线啦！

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

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

欢送各位同学关注