多路RTSP播放器直播与点播技术实现

水深无声 2024-02-22 07:02 137阅读 0赞

**1.综述**

RTSP协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据，在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。目前在流媒体传输技术中使用最多的就是基于RTSP/RTP的流媒体传输，在智能网络摄像机上也需要实现基于RTSP/RTP的H.264实时流的传输。

RTSP协议基于TCP完成RTSP请求报文和响应报文的传输，RTP协议基于UDP协议完成流媒体数据的实时传输，RTCP协议基于UDP协议提供客户端和服务器有关当前网络拥塞和以及实时流传输质量等信息。

**2.架构设计**

本文研究的流媒体播放器主要用来对遵循RTSP标准协议的码流以及AVI文件进行实时播放以及码流录制。播放器核心为两个 DLL，分别为网络 DLL 以及播放 DLL。网络库 基于 Live555 开发，主要对码流的获取以及链路的管理进行控制；播放库基于 ffmpeg 以及DirectX 开发，主要对实时码流以及本地的音视频的文件进行解码播放和控制。

该RTSP播放器实现了主流RTSP播放器的基本功能，并有所拓展：

（1）RTSP 标准码流（包括音视频）的实时预览播放；

（2）网络数据流的断线重连；

（3）对存储文件的解码播放以及控制；

（4）音视频码流的同步存储，文件存储时以当前系统的时间戳作为音视频 播放时的索引，方便在文件播放时以时间戳作为检索条件来点播文件；

（5）视频播放格式上支持 h.264、mpeg4、mpeg2 等，音频播放格式上支 持 AAC、AMR、G711 等；

（6）视频抓拍；

（7）视频显示角度旋转；

（8）画面填充控制显示比例。

**3.程序框架**

播放器整体设计参考VLC，MPLAYER等知名播放器，将整个数据的处理流程分为：input、demux、decode、output四个过程。其中input用来处理网络数据流的输入以及文件数据的读取；demux用来做数据流的解复用，将音频以及视频数据分离成ES流；decode用来解码视频以及音频ES流，并输出解码后的数据（视频为YUV数据，音频为PCM格式）；output用来处理YUV视频数据的显示以及PCM音频数据的输出。

为支持多路媒体数据并行解码输出，对于每路媒体数据分别设计了相应的engine引擎机制来进行管理，具体实现方案如下：

（1） 为实现多种输入方式的扩展性，将input、demux、decode、output四个过程划分为两个库来实现，分别为数据源解析库SourceSdk、播放库PlaySdk；

（2） SourceSdK的管理功能由SourceEngine引擎来完成，主要对input以及demux模块进行封装管理。SourceEngine从数据源（直播、点播、文件）获取数据，并解析数据将数据源分离成音频ES流和视频ES流，并将解析的数据以私有格式进行封装，通过回调函数的机制传递给应用层；

（3） PlaySdk的管理功能由PlayEngine引擎来完成，主要对decode以及output模块进行封装管理。PlayEngine提供了数据输入接口，通过该接口可以将从SourceEngine得到的数据传入该接口，放入PlayEngine缓存。PlayEngine从缓存中提取数据，并对数据按协议格式进行解析，将解析出的音视频数据分别回调；

（4） 为方便Engine对各模块的管理以及数据通讯，在内部设计了消息机制，可以通过Engine给模块发送消息控制各模块的正常运行；

（5） 在相互作用的模块之间，如decode与output之间采用高效的数据缓冲池机制来保证高效的内存分配，并通过队列机制将数据进行有效的传递；

**4.主要技术**

播放器在功能和性能上具有较高的要求，具体的实现上，需要主要解决的关键技术点主要包括有：多路高清解码、兼顾低时延与流畅性、音视频同步以及浏览器扩展。针对以上问题，实现上采用的相应解决办法如下：

####  4.1 多路高清解码 ####

多路高清解码播放每路都由多个线程配合来完成整个数据的处理流程，在多路播放的情况下则更为复杂。因此需要在系统的实现上具有高效的多线程管理机制，以及对各模块的组织、内部互联互通上做出良好的设计：

（1） 通过SourceSdk、PlaySdk的实现，将繁琐的数据处理流程统一成了标准的数据接口，控制管理上方便有效；

（2） 在SourceSdk、PlaySdk内部实现上通过engine机制，对单路数据以及播放的管理提供了统一接口，对于多路播放实际上只需要管理多个engine即可；

####  4.2 低时延与流畅 ####

在性能提高上通过减少对内存数据的拷贝以及额外的内存分配开销：

（1） 在PlaySdk中设计了回环数据缓冲机制，对应用层输入的数据进行高效的缓存，在传输decode模块时，避免了数据拷贝；

（2） 在数据解码中使用了ffmpeg的directbuffer机制，进一步的避免了数据的拷贝动作；

（3） 数据再各模块之间传递时使用数据缓冲池，避免了额外的内存分配操作，同时也减少了因内存分配操作而带来的内存碎片；

在低时延与流畅的平衡性上，通过设置最大缓冲帧数和最小缓冲帧数来实现控制，具体实现策略为：

通过比较待解码缓冲区和解码后还未来得及显示的缓冲区里数据包的个数的和值，如果该值大于最大缓冲帧数，说明有很多数据在缓存里，延迟大了，这时就要加快显示速度（减小output模块的休眠时间），最大缓冲帧数就是影响延迟的；反之一样， 最小缓冲帧数就是流畅的保证，该值越大就越流畅；通过改变这个最大值最小值就可以平衡延迟与流畅。

####  4.3 音视频同步 ####

由于声音对时间的敏感性，所以在同步的处理上，系统以声音作为基准来参考，对视频的输出来进行调整，从而保证音视频的同步性，具体实现为：

通过比较音频和视频的时间戳（pts）来对视频的显示速度进行调整，如当前的视频的pts比音频pts大于最小偏差值（目前设置为200MS），说明视频快了，就放慢是视频的显示速度；反之就加快视频的显示速度；但是，如果差距太大（目前设置为1000MS）， 大于最大偏差值时，加快视频的显示速度的效果不明显就采用丢帧方式，这个一般出现再刚开启的是时候。

####  4.4 WEB浏览器调用 ####

针对不同的浏览器需要来制作成不同的插件，即需要根据具体浏览器的插件接口来编写，可以根据相应的项目需求开发开发支持响应浏览器的插件，一般性需求主要是IE浏览器OCX控件。

RTSP直播与点播：多路视频并发实时预览，窗口布局可动态调整；可动态的设置视频输出的显示比例，调整音量的输出大小；支持对视频内容的时间点检索等操作。