大良招聘网站建设,互联网行业 英文,家装公司网站建设,南京汽车企业网站建设技术背景
这几年#xff0c;我们对接了太多有RTSP或RTMP直播播放器诉求的开发者#xff0c;他们当中除了寻求完整的解决方案的#xff0c;还有些是技术探讨#xff0c;希望能借鉴我们播放端的开发思路或功能特性#xff0c;完善自己的产品。
忙里偷闲#xff0c;今天我…技术背景
这几年我们对接了太多有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播放器设计的时候更多考虑的应该是如何做的更灵活、更稳定、延迟更低、资源占用更小单纯的几个接口很难满足通用化的产品诉求啰啰嗦嗦说了这么多权当抛砖引玉感兴趣的开发者可以酌情参考。
