弹起式地面插座直播常见⾯试题
1. ⾳频信号压缩编码的标准主要有 G.7xx 系列、MPEG-x 系列、AC-x 系列。
2. ⾳频编解码中常⽤的技术包括：AD/DA转换、压缩编码、数字信号处理、信道编码/调制。 3. 经采样、编码但未压缩的语⾳信号（对应G.711编码）为：PCM。
4. ⾳频编码⽅法包括三⼤类：波形编码、参数编码、混合编码。
1.1 ⾳视频同步算法
主要原因：显⽰时间戳 PTS 和解码时间戳 DTS 其他原因：采样率速度、设备⽀持的分辨率，码率，帧率、以及服务器拉流
1.2 解决⾳视频不同步的思路：从根源上解决
最成熟也是最复杂的解决⾳视频不同步的⽅法是修改时间戳，主要原理是：选择⼀个参考时间，在⽣成
数据流时依据参考时间给每个数据块都打上时间戳；播放时，读取数据块上的时间戳，同时参考本地时间来安排播放。但如果源数据帧上打的时间戳本⾝就有问题，那么播放时再怎么调整也于事⽆补，所以解决⾳视频不同步问题，必须先从源上来解决。 1.3 同步视频到⾳频保证⾳视频同步
通常，解决同步问题有三钟选择：同步⾳频到视频，同步视频到⾳频，或者都同步到外部时钟（例如系统时钟）。悟空 TV 使⽤同步视频到⾳频⽅案来保障⾳视频的同步，实现流程如上图。
2. 编解码处理时遇到什么困难？
ffmpeg 在编解码的过程：
使⽤ ffmpeg 的 libavcoder，libavformat 的库及可能性编解码
编码过程：
采集出来的视频、⾳频数据使⽤ ffmpeg 进⾏压缩
进⾏按连续的视频，⾳频进⾏分组打包，为了区分各种包，也要包加上包头，包头写上显⽰时间戳 PTS，解码时间戳 DTS，通过⽹络传输到播放端
解码过程：生铁冶炼
通过 TCP 协议接收到媒体流，FFmpeg 解封装，解码
最终获取到原始视频 YUV，⾳频 PCM 格式，利⽤播放器进⾏播放
3. 如何秒开视频？什么是秒开视频？
喉管
3.1 什么是秒开视频？
秒开是指⽤户点击播放到看到画⾯的时间⾮常短，在 1 秒之内。
3.2 为什么需要秒开？
⽬前主流的直播协议是 RTMP，HTTP-FLV 和 HLS，都是基于 TCP 的长连接。在播放的过程中，若播放端所处的⽹络环境在⼀个较佳的状态，此时播放会很流畅。若⽹络环境不是很稳定，经常会发⽣抖动，如果播放端没有特殊处理，可能会经常发⽣卡顿，严重的甚⾄会出现⿊屏。⽽移动直播由于其便捷性，⽤户可以随时随地发起和观看直播，我们⽆法保证⽤户的⽹络⼀直处于⾮常好的状态，所以，在⽹络不稳定的情况下保证播放的流畅度是⾮常重要的。
3.3 解决思路
3.3.1 获取关键帧后显⽰
改写播放器逻辑让播放器拿到第⼀个关键帧后就给予显⽰。
GOP 的第⼀个帧通常都是关键帧，由于加载的数据较少，可以达到 "⾸帧秒开"。如果直播服务器⽀持 GOP 缓存，意味着播放器在和服务器建⽴连接后可⽴即拿到数据，从⽽省却跨地域和跨运营商的回源传输时间。
GOP 体现了关键帧的周期，也就是两个关键帧之间的距离，即⼀个帧组的最⼤帧数。假设⼀个视频的恒定帧率是 24fps（即 1 秒 24 帧图像），关键帧周期为 2s，那么⼀个 GOP 就是 48 张图像。⼀般⽽⾔，每⼀秒视频⾄少需要使⽤⼀个关键帧。
增加关键帧个数可改善画质（GOP通常为 FPS 的倍数），但是同时增加了带宽和⽹络负载。这意味着，客户端播放器下载⼀个 GOP，毕竟该 GOP 存在⼀定的数据体积，如果播放端⽹络不佳，有可能不是能够快速在秒级以内下载完该 GOP，进⽽影响观感体验。
烟雾净化如果不能更改播放器⾏为逻辑为⾸帧秒开，直播服务器也可以做⼀些取巧处理，⽐如从缓存 GOP 改成缓存双关键帧（减少图像数量），这样可以极⼤程度地减少播放器加载 GOP 要传输的内容体积。
3.3.2 app 业务逻辑层⾯优化
⽐如提前做好 DNS 解析（省却⼏⼗毫秒），和提前做好测速选线（择取最优线路）。经过这样的预处理之后，在点击播放按钮时，将极⼤提⾼下载性能。
⼀⽅⾯，可以围绕传输层⾯做性能优化；另⼀⽅⾯，可以围绕客户播放⾏为做业务逻辑优化。两者可以有效的互为补充，作为秒开的优化空间。
3.4 秒开视频⽅案
3.4.1 优化服务器策略
播放器接⼊服务器请求数据的时间点的视频不⼀定是关键帧，那么需要等到下⼀个关键帧的到来，如果关键帧的周期是 2s 的话，那么等待的时间可能会在 0~2s 的范围内，这段等待的时间会影响⾸屏的加载时间。如果服务器有缓存，则播放端在接⼊的时候，服务器可以向前最近的关键帧发给播放端，这样就可以省去等待的时间，可以⼤⼤的减少⾸屏的加载时间。
3.4.2 优化播放端策略
播放端请求到的第⼀帧数据肯定是关键帧，关键帧能够通过帧内参考进⾏解码。这样播放端就可以在接收到第⼀个关键帧的时候就⽴即开始解码显⽰，⽽不需要等到缓存⼀定数量的视频帧才开始解码，这样也能减少⾸屏画⾯显⽰的时间。
3.5 播放端⾸屏时长的优化
播放器的⾸屏过程中的⼏个步骤：
⾸屏时间，指的是从进⼊直播间开始到第⼀次看到直播画⾯的时间。⾸屏时间过长极易导致⽤户失去对直播的耐⼼，降低⽤户的留存。
但游戏直播对画⾯质量和连贯性的要求⾼，对应推流端编码后的数据量和其他类型直播相⽐⼤的多，如何降低⾸屏时间是⼀个不⼩的难题。
在播放端的⾸屏过程中，主要有以下三个操作需要进⾏：加载直播间 UI（包括播放器本⾝）、下载直播数据流（未解码）和解码数据播放。其中数据解码播放⼜细分为以下⼏个步骤：
检测传输协议类型（RTMP、RTSP、HTTP 等）并与服务器建⽴连接接收数据；
视频流解复⽤得到⾳视频编码数据（H.264/H.265、AAC 等）；
⾳视频数据解码，⾳频数据同步⾄外设，视频数据渲染都屏幕，⾄此，视频开始播放，⾸屏时间结束。
透水混凝土施工总结： ⾸先，加载 UI 可以以单例的⽅式进⾏，能够⼀定程度地提升⾸屏展⽰速度；其次，可以预设解码类型，减少数据类型检测时间；再次，设定合理的下载缓冲区⼤⼩，尽可能减少下载的数据量，当检测到 I 帧数据，⽴即开始解码单帧画⾯进⾏播放，提⾼⾸屏展⽰时间。
4. 如何降低延迟？如何保证流畅性？如何解决卡顿？解决⽹络抖动？
4.1 产⽣原因
保证直播的流畅性是指在直播过程中保证播放不发⽣卡顿，卡顿是指在播放过程中声⾳和画⾯出现停滞，⾮常影响⽤户体验。造成卡顿的原因有⼏种情况：
推流端⽹络抖动导致数据⽆法发送到服务器，造成播放端卡顿；
播放端⽹络抖动导致数据累计在服务器上拉不下来，造成博凡卡顿。
由于从服务器到播放器的⽹络情况复杂，尤其是在 3G 和带宽较差的 WIFI 环境下，抖动和延迟经常发⽣，导致播放不流畅，播放不流畅带来的负⾯影响就是延时增⼤。如何在⽹络抖动的情况下保证播放的流畅性和实时性是保障直播性能的难点。
4.2 流畅度优化
⽬前主流的直播协议是 RTMP、HTTP-FLV 和 HLS，都是基于 TCP 的长连接。在播放的过程中，若播放端所处的⽹络环境在⼀个较佳的状态，此时播放会很流畅。若⽹络环境不是很稳定，经常会发⽣抖动，如果播放端没有做特殊处理，可能会经常发⽣卡顿，严重的甚⾄会出现⿊屏。⽽移动直播由于其便捷性，⽤户可以随时随地发起和观看直播，我们⽆法保证⽤户的⽹络⼀直处于⼀个⾮常好的状态，所以，在⽹络不稳定的情况下保证播放的流畅度是⾮常重要的。
为了解决这个问题，⾸先播放器需要将拉流线程和解码线程分开，并建⽴⼀个缓冲队列⽤于缓冲⾳视频数据。拉流线程将从服务器上获取到的⾳视频流放⼊队列，解码线程从队列中获取⾳视频数据进⾏解码播放，队列的长度可以调整。当⽹络发⽣抖动时，播放器⽆法从服务器上获取到数据或获取数据的速度较慢，此时队列中缓存的数据可以起到⼀个过渡的作⽤，让⽤户感觉不到⽹络发⽣了抖动。
当然这是对于⽹络发⽣抖动的情况所采取的策略，如果播放端的⽹络迟迟不能恢复或服务器的边缘结点出现宕机，则需要应⽤层进⾏重连或调度。
5. 丢包处理⽅案
第⼀种⽅案：重传
第⼀个策略时重传，很明确地丢什么数据重新传什么数据，不会浪费资源
第⼆种⽅案：前向纠错 FEC
定义
nidd所谓前向纠错，其实是数据冗余，是解决丢包问题的主要⽅案之⼀。可以分成两种类型：多媒体⽆关的前向纠错和多媒体相关的。本⽂主要介绍多媒体⽆关的前向纠错，它更多应⽤在⽹络上，同时该技术在存储领域也有应⽤。
前向纠错简称 FEC（Forward Error Correction），其原理是：发送⽅将要发送的数据附加上⼀定的冗余纠错码⼀并发送，接收⽅则根据纠错码对数据进⾏差错检测，如发现差错，由接收⽅进⾏纠正，特点：使⽤纠错码（纠错码编码效率低且设备复杂）、单向信道、发送⽅⽆需设置缓冲器。
原理
分层数据保护是前向纠错对于分层的⽅案。分层指的是数据包⾥⾯有不同重要程度的数据，对于不同程度的数据分段对它进⾏保护。
前向纠错的数据包是基于 RTP 标准上设计的。前⾯是 RTP 包头，后⾯是前向纠错的数据包的格式。
FEC 算法其中⼀个称之为异或。假如有 4 个数据，那么它们可以取 4 个异或值，其中每⼀个数据都可
以由另外 4 个异或值计算出来。还可以把 ABCD 和 E 想象成⼀个数据包，如果我们传输 ABCD 这四个数据包，第五个数据包传输的是 E，这五个数据包可以丢失任何 1 个数据包。接收⽅收到数据之后，能够把它丢的数据恢复出来。前向纠错算法能处理的是连续数据⾥只丢 1 个包。同时丢失 A 和 B，这个算法不能解决。
第三种⽅案：交叉传输 -- 处理连续丢包的情况
最后⼀个策略是交叉传输，我们⽇常看到多媒体可能是按照时序的，⼀个多媒体⽚断是由 1 到 10 组成。如果此过程当中有丢包，⽐如3456 连续丢失，那么此次丢包的影响可能表现在视频播放出现停顿。若丢的是关键帧那么影响⾮常⼤，会导致后⾯⼀⼤⽚的花屏。因此当连续丢包对流媒体伤害特别⼤的情况下，可以采⽤交叉传输策略。1 到 10，原来是 3 个 3 个传，如 123、456、789 各传⼀次，那么现在可以改变传输策略，采⽤ 147、280 和 369 的传输策略，这样⼀组数据丢掉，实际丢失在流媒体中间穿插的数据，播放程序可以在⼏乎不失真的状态下把视频恢复出来。
