[发明专利]一种分布式播放器流量控制方法及系统

说明书

技术领域

本申请涉及互联网应用技术领域，具体地说，涉及一种分布式播放器流量控制方法及系统。

背景技术

当前，视频播放器，通常是指能播放以数字信号形式存储的媒体文件的软件，也指具有播放媒体文件功能的电子器件产品。除了少数波形文件外，大多数视频播放器携带视音频解码器和显示部件以还原经过压缩媒体文件，视频播放器还要内置一整套转换以及缓存的算法。当然大多数的视频播放器还能支持播放单音频文件或者单视频文件。

一般的处理过程为：

输入。从文件或网络等读取原数据，如x.avi，x.mov，rtsp://xxx，对原数据进行解析，比如文件，首先要分析文件格式，从文件中取得音视频编码参数，媒体时间长度等信息，然后要从其中取出音频编码数据和视频编码数据送到解码部分，这里暂称这种编码源数据块为packet。

解码。初始化时，利用输入端从源数据中取得的信息调用不同的解码库初始化；然后接收输入端传送来的音视频编码数据，分别进行音频解码和视频解码，视频解码出来的数据一般是YUV或RGB数据，这里暂称为picture，音频解码出来的数据是采样数据，是声卡播放的数据，这里暂称为sample。解码所得的数据接下来送到输出部分。

输出。接收解码部分送来的picture和sample并显示。视频显示一般使用某个图形库，如SDL，Xlib，DirectDraw，OpengGL，FrameBuffer等，音频输出是把sample写入系统的音频驱动，由音频驱动送入声卡播放，可用的音频输出有ALSA，OSS，SDL，DirectSound，WaveOut等。

现有技术中，通过分布式播放器在一个终端(播放器1)播放另外一个终端(播放器2)上面的媒体文件，播放器1需要先和播放器2建立连接，通过网络传递各种控制命令，播放过程中传递的视音频数据也会跟这些控制命走相同的通道。视音频数据量很大，开始播放以后下行通道内的视音频数据会源源不断的涌入，堵塞下行通道。这时如果要发出Pause、Seek、Stop等控制动作时，上行通道将控制命令发出去，但控制命令响应从下行通道返回时，就会被大量的视音频数据堵塞。只有下行通道中大量的数据被消耗完，才能接收到控制命令的响应，整个过程相当漫长甚至永远阻塞，用户体验会非常不好，而且还会浪费带宽。

发明内容

有鉴于此，本申请所要解决的技术问题是提供了一种分布式播放器流量控制方法及系统，其能够解决现有技术中播放器播放存在的流量控制问题，能够提高播放媒体文件的速度和效率，避免控制命令的堵塞，提高用户满意度。

为了解决上述技术问题，本申请有如下技术方案：

一种分布式播放器流量控制方法，包括：

播放器1控制层和播放器2控制层建立连接；

播放器1控制层向播放器2控制层发送解复用命令Cmd_prepare；

播放器2控制层收到Cmd_prepare后，根据所述解复用命令中的媒体文件信息构建解复用模块和数据发送模块；向播放器1控制层回复消息解复用Ready消息；

播放器1控制层收到所述解复用Ready消息后，根据所述解复用Ready消息包含的媒体信息构建数据接收模块、解码模块和渲染模块；并通知UI播放；

所述UI操作播放后，播放器1控制层向播放器2控制层发送命令Cmd_demux；

播放器2控制层收到Cmd_demux命令后，启动解复用模块，解复用模块开始从IO中读取媒体文件数据，解复用分离出原始流数据，并通过数据发送模块把原始流数据发送出去；向播放器1回复解复用Play消息；

播放器1控制层收到Play消息后，启动数据接收模块、解码模块和渲染模块；数据接收模块接收到原始流数据交给解码模块，解码模块解码输出的数据发送给渲染模块，渲染模块完成渲染输出。

所述播放器1和播放器2控制层在建立播放连接时要核对起始时钟，保证两端的计时时钟T_g的同步。

所述解复用模块和数据发送模块初始化完成后，播放器2处于Ready状态之后，播放器2控制层会向播放器1控制层回复消息解复用Ready消息。

所述解码模块和渲染模块初始化完成后，所有的播放模块都处于Ready状态，此时通知所述UI播放。

所述方法还包括：

播放的视音频数据流在解复用完毕以后根据视频音频信息打上时间戳信息T_f；