【技术分享】如何实现功能完备性能优异的RTMP、RTSP播放器?

时间:2022-12-28 14:04:57


 技术背景

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

忙里偷闲,今天我们就再聊一聊老生常谈的问题:如何实现功能完备性能优异的RTMP、RTSP播放器?【技术分享】如何实现功能完备性能优异的RTMP、RTSP播放器?

【技术分享】如何实现功能完备性能优异的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播放器,设计的时候,更多考虑的应该是如何做的更灵活、更稳定、延迟更低、资源占用更小,单纯的几个接口,很难满足通用化的产品诉求,啰啰嗦嗦说了这么多,权当抛砖引玉,感兴趣的开发者,可以酌情参考。