如何设计一款跨平台低延迟的 RTMP|RTSP 直播播放器

​开发背景

2015 年，当我们试图在市面上找一款专供直播播放使用的低延迟播放器，来配合测试我们的 RTMP 推送模块使用时，居然发现没有一款好用的，市面上的，如 VLC 或 Vitamio，说白了都是基于 FFMPEG，在点播这块支持格式很多，也非常优异，但是直播这块，特别是 RTMP，延迟要几秒钟，对如纯音频、纯视频播放，快速启播、网络异常状态处理、集成复杂度等各方面，支持非常差，而且因为功能强大，bug 很多，除了行业内资深的开发者能驾驭，好多开发者甚至连编译整体环境，都要耗费很大的精力。

我们的直播播放器，始于 Windows 平台，Android 和 iOS 同步开发，基于上述开源播放器的各种缺点，我们考虑全自研框架，确保整体设计跨平台，再保障播放流程度的前提下，尽可能的做到毫秒级延迟，接口设计三个平台统一化，确保多平台集成复杂度降到最低。

整体方案架构 RTMP 或 RTSP 直播播放器，目标很明确，从 RTMP 服务器（自建服务器或 CDN）或 RTSP 服务器（或 NVR/IPC/编码器等）拉取流数据，完成数据解析、解码、音视频数据同步、绘制。

具体对应下图“接收端”部分：

初期模块设计目标

• 自有框架，易于扩展，自适应算法让延迟更低、解码绘制效率更高；

• 支持各种异常网络状态处理，如断网重连、网络抖动等控制；

• 有 Event 状态回调，确保开发者可以了解到播放端整体的状态，从纯黑盒不可控，到更智能的了解到整体播放状态；

• 支持多实例播放；

• 视频支持 H.264，音频支持 AAC/PCMA/PCMU；

• 支持缓冲时间设置（buffer time）；

• 实时静音。

经过迭代后的功能

• [支持播放协议]RTSP、RTMP；

•  [多实例播放]支持多实例播放；

•  [事件回调]支持网络状态、buffer 状态等回调；

•  [视频格式]支持 RTMP 扩展 H.265，H.264；

•  [音频格式]支持 AAC/PCMA/PCMU/Speex；

•  [H.264/H.265 软解码]支持 H.264/H.265 软解；

•  [H.264 硬解码]Windows/Android/iOS 支持 H.264 硬解；

•  [H.265 硬解]Windows/Android/iOS 支持 H.265 硬解；

•  [H.264/H.265 硬解码]Android 支持设置 Surface 模式硬解和普通模式硬解码；

•  [缓冲时间设置]支持 buffer time 设置；

•  [首屏秒开]支持首屏秒开模式；

•  [低延迟模式]支持类似于线上娃娃机等直播方案的超低延迟模式设置(公网 200~400ms)；

•  [复杂网络处理]支持断网重连等各种网络环境自动适配；

•  [快速切换 URL]支持播放过程中，快速切换其他 URL，内容切换更快；

•  [音视频多种 render 机制]Android 平台，视频：surfaceview/OpenGL ES，音频：AudioTrack/OpenSL ES；

•  [实时静音]支持播放过程中，实时静音/取消静音；

•  [实时快照]支持播放过程中截取当前播放画面；

•  [只播关键帧]Windows 平台支持实时设置是否只播放关键帧；

•  [渲染角度]支持 0°，90°，180°和 270°四个视频画面渲染角度设置；

•  [渲染镜像]支持水平反转、垂直反转模式设置；

•  [实时下载速度更新]支持当前下载速度实时回调(支持设置回调时间间隔)；

•  [解码前视频数据回调]支持 H.264/H.265 数据回调；

•  [解码后视频数据回调]支持解码后 YUV/RGB 数据回调；

•  [解码后视频数据缩放回调]Windows 平台支持指定回调图像大小的接口(可以对原视图像缩放后再回调到上层)；

•  [解码前音频数据回调]支持 AAC/PCMA/PCMU/SPEEX 数据回调；

•  [音视频自适应]支持播放过程中，音视频信息改变后自适应；

•  [扩展录像功能]支持 RTSP/RTMP H.264、扩展 H.265 流录制，支持 PCMA/PCMU/Speex 转 AAC 后录制，支持设置只录制音频或视频等；

RTMP、RTSP 直播播放开发设计考虑的点

1. 低延迟：大多数 RTSP 的播放都面向直播场景，所以，如果延迟过大，严重影响体验，所以，低延迟是衡量一个好的 RTSP 播放器非常重要的指标，目前我们设计的 RTSP 直播播放延迟比开源播放器更优异，而且长时间运行下，不会造成延迟累积；

2. 音视频同步处理：有些播放器为了追求低延迟，甚至不做音视频同步，拿到 audio video 直接播放，导致 a/v 不同步，还有就是时间戳乱跳等各种问题，我们提供的播放器，具备好的时间戳同步和异常时间戳矫正机制；

3. 支持多实例：提供的播放器支持同时播放多路音视频数据，比如 4-8-9 窗口，大多开源播放器对多实例支持不太友好；

4. 支持 buffer time 设置：在一些有网络抖动的场景，播放器需要支持 buffer time 设置，一般来说，以毫秒计，开源播放器对此支持不够友好；

5. TCP/UDP 模式设定、自动切换：考虑到好多服务器仅支持 TCP 或 UDP 模式，一个好的 RTSP 播放器需要支持 TCP/UDP 模式设置，如链接不支持 TCP 或 UDP，可自动切换，，开源播放器不具备自动切换 TCP/UDP 能力；

6. 实时静音：比如，多窗口播放 RTSP 流，如果每个 audio 都播放出来，体验非常不好，所以实时静音功能非常必要，开源播放器不具备实时静音功能；

7. 视频 view 旋转：好多摄像头由于安装限制，导致图像倒置，所以一个好的 RTSP 播放器应该支持如视频 view 实时旋转(0° 90° 180° 270°)、水平反转、垂直反转，开源播放器不具备此功能；

8. 支持解码后 audio/video 数据输出：接触到好多开发者，希望能在播放的同时，获取到 YUV 或 RGB 数据，进行人脸匹配等算法分析，开源播放器不具备此功能；

9. 实时快照：感兴趣或重要的画面，实时截取下来非常必要，一般播放器不具备快照能力，开源播放器不具备此功能；

10. 网络抖动处理(如断网重连)：稳定的网络处理机制、支持如断网重连等，开源播放器对网络异常处理支持较差；

11. 长期运行稳定性：不同于市面上的开源播放器，提供的 Windows 平台 RTSP 直播播放 SDK 适用于数天长时间运行，开源播放器对长时间运行稳定性支持较差；

12. log 信息记录：整体流程机制记录到 LOG 文件，确保出问题时，有据可依，开源播放器几无 log 记录。

13. 实时下载速度反馈：提供音视频流实时下载回调，并可设置回调时间间隔，确保实时下载速度反馈，以此来监听网络状态，开源播放器不具备此能力；

14. 异常状态处理、Event 状态回调：如播放的过程中，断网、网络抖动、等各种场景，大牛直播 SDK 提供的播放器可实时回调相关状态，确保上层模块感知处理，开源播放器对此支持不好；

15. 关键帧/全帧播放实时切换：特别是播放多路画面的时候，如果路数过多，全部解码、绘制，系统资源占用会加大，如果能灵活的处理，可以随时只播放关键帧，全帧播放切换，对系统性能要求大幅降低。

总结

总的来说，无论是基于开源播放器二次开发，还是全自研，一个好的 RTMP 播放器或 RTSP 播放器，设计的时候，更多考虑的应该是如何做的更灵活、稳定，单纯的几个接口，很难满足通用化的产品诉求。

以下共勉：厚积薄发，登上山顶，不是为了饱览风光，是为了寻找更高的山峰！

​