技术背景

这几年，我们对接了太多有RTSP或RTMP直播播放器诉求的开发者，他们当中除了寻求完整的解决方案的，还有些是技术探讨，希望能借鉴我们播放端的开发思路或功能特性，完善自己的产品。

忙里偷闲，今天我们就再聊一聊老生常谈的问题：如何实现功能完备性能优异的RTMP、RTSP播放器？

 

技术剖析

这里我们说的播放器，系直播播放，确切的说，是如何在保障播放体验的情况下，实现低延迟的RTMP或RTSP播放模块。

一个播放器，常规的关注点，主要有几个方面：延迟、资源占用率（特别是性能一般的机器多路播放场景下）、多实例支持、异常网络处理（非常稳定的网络环境不太现实）、实时状态回调、长时间运行稳定性等，下面，我就大概聊聊，我们关注的一些点：

1. 低延迟：这个功能诉求不再赘述，大多直播场景或有交互诉求的场景，对延迟的要求非常高，如果延迟过大，体验大打折扣。无论是RTMP还是RTSP播放器，我们目前都是毫秒级的体验。更重要的长时间运行，不会发生内存泄漏或其他异常。

2. 音视频同步处理：在极端低延迟下，音视频同步是可以忽略的，如果超过200ms的音视频时间差值，感官体验还是很差的，除此之外，还有些前端RTMP或RTSP时间戳会乱跳，这种也需要很好的兼容和矫正。

3. 支持多实例：多实例播放，这里分两块，一块Windows平台的，一块移动端，移动端一般来说多实例，建议控制在4个以内，Windows平台一般来说设备性能不会太差，但是随着音视频这块配套设备的提升和产品诉求，越来越多的场景下，开始对高分辨率高码率提出了要求，这对多实例的播放，就有很大挑战，解一路绘一路一般机器，只要程序写的不是太差，也不会太大性能瓶颈，但如果是同时4路8路甚至12或16路呢？我想大多自己拿开源改的播放器，都已经没法正常使用了；

4. 支持buffer time设置：buffer time设置，这里都可以理解，说白了就是为了异常网络环境下，尽可能缓冲点数据，提升播放流畅度，buffer time我们一般是按照毫秒设置，还有按照帧的，确切的说应该叫buffer frame，大家觉得哪种更好一些？

5. RTSP TCP/UDP模式设定、自动切换：TCP、UDP模式设定这个好理解，好多设备在特定网络环境下，可能仅支持单模式，甚至有些服务器转出来的RTSP流，服务端就做了限定，如果一个通用的RTSP播放器，你就需要考虑，TCP、UDP模式自动切换的问题，比如RTSP TCP模式下收不到数据，达到超时时间后，你需要能自动切到UDP。

6. 实时静音、实时音量调节：实时静音，特别在多实例播放下，非常重要，实时音量调节，不再赘述，依赖系统音量调节，无法针对单个实例的audio音量做调整，好多播放器不支持实时音量调节；

7. 视频view旋转、水平反转、垂直反转：好多摄像头或一些移动单兵设备，由于安装或场景限制，导致图像倒置或旋转，一个像样的RTMP或RTSP播放器应该支持如视频view实时旋转(0° 90° 180° 270°)、水平反转、垂直反转；

8. 支持解码后audio/video数据输出：牛哥接触到好多开发者，希望能在播放的同时，获取到YUV或RGB数据，进行视觉算法的处理，这块就显得非常关键，特别是，回调需要尽量不影响性能；

9. 实时快照：实时快照的重要性不言而喻，这个我觉得应该是好多场景的标配；

10. 网络抖动处理(如断网重连)：我们遇到好多开发者在做播放器选型的时候，说你们的RTMP和RTSP播放器除了非常低，长时间跑不挂，也没什么内存泄漏，资源占有低点，和我外面找的播放，其他也也测不出什么问题，那是因为大多测试是在内网稳定的网络环境下，网络抖动等异常处理做不好，很难经受得住现场奇奇怪怪网络环境的考验；

11. 长期运行稳定性：长时间稳定性适用于比如一些智能设备或监控等场景，几乎常开的，如果资源占用持续升高、莫名crash等问题，非常恼火，问题也非常难定位；

12. log信息记录：为什么要有日志？日志的目的，就是在发现问题的时候，不至于两眼一抹黑，便于之前的问题还原，一般播放器，可能对这块记录并不成体系。

13. 实时下载速度反馈：为什么需要音视频流实时下载回调？其实就是为了确保实时下载速度反馈，以此来监听网络状态，当然，如果不需要，我们也快设置关闭，也可以设置回调时间间隔；

14. 异常状态处理、Event状态回调：好的播放器，不止服务稳定的网络环境，一些断网、网络抖动、等异常场景，我们可以实时回调相关状态，确保上层模块感知处理；

15. 关键帧/全帧播放实时切换：移动端，一般对只播放关键帧真正场景，需求不大，但是window端，好多场景下，因为需要播放非常多路，但是又不想占用太多的系统资源，如果全帧播放，路数过多，全部解码、绘制，系统资源占用会加大，如果能灵活的处理，可以随时只播放关键帧，全帧播放切换，对系统性能要求大幅降低，想全帧播放的时候，随时切换全帧绘制。

16. 特定机型硬解码：无论是Windows还是Android、iOS平台，如果需要播放高分辨率或多实例场景，硬解码的支持非常必要，

17. 跨平台，接口尽可能统一：跨平台这块，这个看开发者所服务的场景，像我们，是直接支持Windows、Linux、Android、iOS平台，一般开发者，可能只需要支持一两个平台即可，如果涉及到多个平台，尽可能的接口相对统一。

18. 可扩展：比如，我们RTMP、RTSP播放器，针对Unity平台的配套解决方案，Unity环境下调用我们原生的RTMP、RTSP播放模块，通过回调YUV/RGB数据，在Unity绘制，实现Unity环境下低延迟播放的友好体验，此外，移动端，也可以用于Flutter框架下。

总结

不管是基于开源播放器二次开发，还是全自研内核，一个好的RTMP播放器或RTSP播放器，设计的时候，更多考虑的应该是如何做的更灵活、更稳定、延迟更低、资源占用更小，单纯的几个接口，很难满足通用化的产品诉求，啰啰嗦嗦说了这么多，权当抛砖引玉，感兴趣的开发者，可以酌情参考。