音视频播放器的 核心业务逻辑总结
总结音视频播放器的一些核心业务，帮助后续业务深入思考。
本文主要讨论的是一个播放器个底层核心业务逻辑，及其思路，主要是内部逻辑，并不涉及UI，用户操作逻辑层面。
文章目录
播放器基础业务逻辑框架—解析/解压/渲染/同步
任何一个平台的播放器，都可以简化到下面的整体的示意图。
1、source：表示源文件，可以是本地文件或者网络流媒体。是播放器的输入。
2、demux：封装解析分流器，主要用于把音视频文件进行解封装分流，生成独立的视频压缩文件和音频压缩文件。
3、video decorder && audio decorder：视频解压和音频解压，如字面含义，分别把对应的视频压缩文件如h264，音频压缩文件如ACC 解压为非压缩的视频YUV数据和音频PCM数据。这里涉及各种视频音频的解压协议。
4、video render && audio render：视频渲染和音频渲染。拿到要显示的视频和音频帧后，利用平台的API，对视频进行绘制转换和音频播放转化，比如视频的缩放、裁剪、比例调整等，音频的特效添加。渲染结束后一般调用平台API直接通过输出设备进行输出。
5、sync：同步模块，这里一般就指视频和音频时间的同步，一般情况以音频时间戳为主（人对声音变化敏感），对视频进行丢帧和重复帧调整视频位置信息，保证视听同步。
6、video output device && audio output device：音视频输出设备，如显示器，音响设备，在渲染过程 平台API提供输出功能，平台API最终会调到对应设备的底层系统驱动，通过硬件设备驱动控制输出设备，把画面和声音传播出来。
播放器关键设计 缓存帧—模块特效需求/并行效率/抗抖动
进一步细化设计，各个模块处理速度有差异，渲染模块取决于输入帧实际帧率（如25hz视频源，理论上每40ms消耗一帧，如果时在50hz刷新输出设备上，相当于每2次刷新更新一个输入帧），解码模块通常取决与 解码性能（如过硬件解码 看硬件解码逻辑性能如何，软件解码依赖CPU性能），通常情况（在支持的视频输入范围内）解码效率一定是优于渲染间隔的，此时 解码工作往往会被 渲染反压（等待渲染模块把 解码后的内容使用完成 归还后再作为输出buffer继续处理）。
各个模块之间都会存在一些fifo缓存，用来保留上一级别模块送过来的数据包。这种设计主要有几方面的述求：
1、抗轮转抖动：实际的系统环境较复杂，比如 网络流 如果 网络不稳定，那么demux处理可能较慢，同样的解码器也可能由于总线争抢某个时刻耗时较长，如果没有这些fifo存在，就容易出现某个时刻 渲染 需求的帧不足，引入卡顿。
2、sync视音同步：前面已经提到，sync模块常常会以声音的时间戳信息去控制视频渲染模块 丢帧 或者 重复帧，如果没有视频渲染模块的缓存帧区域，丢帧后很难保证前级即时送帧过来，也会引起卡顿。
3、模块特效的需求：理想状态下 每个模块 最少需要一帧就可以进行处理输出，实际上会要求更多，举个例子：视频解码模块 解压视频帧的时候 有前后级别参考关系，要解压出一帧 需要持有多帧才能处理，具体数量还得看协议。视频渲染模块也是类似的，渲染过程涉及大量算法处理，很多算法模型天然设计时候 就需要前后时域上参考帧，也就需要持有更多输入才能输出。
缓冲区大小设计
缓冲区越大，优点是那么抗抖动能力越强，缺点是内存需求更多，同时从输入到显示的延时会更大。
缓冲区大小设计原则：把前后级模块 作为生产者和消费者，至少需要满足：生产者生产最低输出需求 + 消费者最低工作输入需求数 + 1帧轮转，比如 生产者 视频解码（输入ok情况）输出1帧就可以解码，渲染模块 需要持有 2帧 才能正常渲染，那么最小就是 1（解码需求）+2（渲染需求）+1（轮转）= 4 帧。但要注意这样基本没有抗抖动能力，实际会针对特定业务场景 对通路 效果/延时/平滑/输入场景特性/甚至码流特性 做更细化的缓冲方案。