标签：服务 ref 冗余 视频编码 如何 播放器 过渡 时间戳 环境
最成熟也是最复杂的解决音视频不同步的方法是修改时间戳，主要原理是：选择一个参考时间，在生成数据流时依据参考时间给每个数据块都打上时间戳；播放时，读取数据块上的时间戳，同时参考本地时间来安排播放。但如果源数据帧上打的时间戳本身就有问题，那么播放时再怎么调整也于事无补，所以解决音视频不同步问题，必须先从源上来解决。
通常，解决同步问题有三钟选择：同步音频到视频，同步视频到音频，或者都同步到外部时钟（例如系统时钟）。悟空 TV 使用同步视频到音频方案来保障音视频的同步，实现流程如上图。
ffmpeg 在编解码的过程：
秒开是指用户点击播放到看到画面的时间非常短，在 1 秒之内。
目前主流的直播协议是 RTMP，HTTP-FLV 和 HLS，都是基于 TCP 的长连接。在播放的过程中，若播放端所处的网络环境在一个较佳的状态，此时播放会很流畅。若网络环境不是很稳定，经常会发生抖动，如果播放端没有特殊处理，可能会经常发生卡顿，严重的甚至会出现黑屏。而移动直播由于其便捷性，用户可以随时随地发起和观看直播，我们无法保证用户的网络一直处于非常好的状态，所以，在网络不稳定的情况下保证播放的流畅度是非常重要的。
改写播放器逻辑让播放器拿到第一个关键帧后就给予显示。
GOP 的第一个帧通常都是关键帧，由于加载的数据较少，可以达到 "首帧秒开"。如果直播服务器支持 GOP 缓存，意味着播放器在和服务器建立连接后可立即拿到数据，从而省却跨地域和跨运营商的回源传输时间。
GOP 体现了关键帧的周期，也就是两个关键帧之间的距离，即一个帧组的最大帧数。假设一个视频的恒定帧率是 24fps（即 1 秒 24 帧图像），关键帧周期为 2s，那么一个 GOP 就是 48 张图像。一般而言，每一秒视频至少需要使用一个关键帧。
增加关键帧个数可改善画质（GOP通常为 FPS 的倍数），但是同时增加了带宽和网络负载。这意味着，客户端播放器下载一个 GOP，毕竟该 GOP 存在一定的数据体积，如果播放端网络不佳，有可能不是能够快速在秒级以内下载完该 GOP，进而影响观感体验。
如果不能更改播放器行为逻辑为首帧秒开，直播服务器也可以做一些取巧处理，比如从缓存 GOP 改成缓存双关键帧（减少图像数量），这样可以极大程度地减少播放器加载 GOP 要传输的内容体积。
比如提前做好 DNS 解析（省却几十毫秒），和提前做好测速选线（择取最优线路）。经过这样的预处理之后，在点击播放按钮时，将极大提高下载性能。
一方面，可以围绕传输层面做性能优化；另一方面，可以围绕客户播放行为做业务逻辑优化。两者可以有效的互为补充，作为秒开的优化空间。
播放器接入服务器请求数据的时间点的视频不一定是关键帧，那么需要等到下一个关键帧的到来，如果关键帧的周期是 2s 的话，那么等待的时间可能会在 0~2s 的范围内，这段等待的时间会影响首屏的加载时间。如果服务器有缓存，则播放端在接入的时候，服务器可以向前找最近的关键帧发给播放端，这样就可以省去等待的时间，可以大大的减少首屏的加载时间。
播放端请求到的第一帧数据肯定是关键帧，关键帧能够通过帧内参考进行解码。这样播放端就可以在接收到第一个关键帧的时候就立即开始解码显示，而不需要等到缓存一定数量的视频帧才开始解码，这样也能减少首屏画面显示的时间。
播放器的首屏过程中的几个步骤：
总结： 首先，加载 UI 可以以单例的方式进行，能够一定程度地提升首屏展示速度；其次，可以预设解码类型，减少数据类型检测时间；再次，设定合理的下载缓冲区大小，尽可能减少下载的数据量，当检测到 I 帧数据，立即开始解码单帧画面进行播放，提高首屏展示时间。
保证直播的流畅性是指在直播过程中保证播放不发生卡顿，卡顿是指在播放过程中声音和画面出现停滞，非常影响用户体验。造成卡顿的原因有几种情况：
由于从服务器到播放器的网络情况复杂，尤其是在 3G 和带宽较差的 WIFI 环境下，抖动和延迟经常发生，导致播放不流畅，播放不流畅带来的负面影响就是延时增大。如何在网络抖动的情况下保证播放的流畅性和实时性是保障直播性能的难点。
目前主流的直播协议是 RTMP、HTTP-FLV 和 HLS，都是基于 TCP 的长连接。在播放的过程中，若播放端所处的网络环境在一个较佳的状态，此时播放会很流畅。若网络环境不是很稳定，经常会发生抖动，如果播放端没有做特殊处理，可能会经常发生卡顿，严重的甚至会出现黑屏。而移动直播由于其便捷性，用户可以随时随地发起和观看直播，我们无法保证用户的网络一直处于一个非常好的状态，所以，在网络不稳定的情况下保证播放的流畅度是非常重要的。
为了解决这个问题，首先播放器需要将拉流线程和解码线程分开，并建立一个缓冲队列用于缓冲音视频数据。拉流线程将从服务器上获取到的音视频流放入队列，解码线程从队列中获取音视频数据进行解码播放，队列的长度可以调整。当网络发生抖动时，播放器无法从服务器上获取到数据或获取数据的速度较慢，此时队列中缓存的数据可以起到一个过渡的作用，让用户感觉不到网络发生了抖动。
当然这是对于网络发生抖动的情况所采取的策略，如果播放端的网络迟迟不能恢复或服务器的边缘结点出现宕机，则需要应用层进行重连或调度。
第一个策略时重传，很明确地丢什么数据重新传什么数据，不会浪费资源
所谓前向纠错，其实是数据冗余，是解决丢包问题的主要方案之一。可以分成两种类型：多媒体无关的前向纠错和多媒体相关的。本文主要介绍多媒体无关的前向纠错，它更多应用在网络上，同时该技术在存储领域也有应用。
前向纠错简称 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 的传输策略，这样一组数据丢掉，实际丢失在流媒体中间穿插的数据，播放程序可以在几乎不失真的状态下把视频恢复出来。
标签：服务 ref 冗余 视频编码 如何 播放器 过渡 时间戳 环境
原文地址：https://www.cnblogs.com/jimodetiantang/p/9165562.html
