[发明专利]视频文件播放的方法、装置及系统

说明书

技术领域

本发明涉及通信技术领域，尤其涉及视频文件播放技术。

背景技术

视频数据的编码格式主要使用H.263编码或(Moving Picture ExpertsGroup-4，MPEG4)运动图像专家组-4编码，下面以H.263为例简要说明视频数据的基本构成：

H.263编码的视频数据结构为层次结构，包括图像层、块组层(group ofblocks layer，GOB)、宏块层、块层。比如：一帧(Common IntermediateFormat，CIF)公用中间格式图像视频帧分为18个GOB，1个GOB分为22个宏块；一帧(Quarter Common Intermediate Format，QCIF)四分之一公用中间格式图像视频帧可分为9个GOB，1个GOB分为11个宏块。在视频文件中视频数据以块(Chunk)的形式存放，一个Chunk存储一帧的视频数据，图1所示为一个视频帧的码流结构。

其中图像层和块组层的边缘确定是通过起始码来确定的，起始码是一段bit码流00000000000000001xxxxxb，后五比特是GOB序号(GOB number)，如果xxxxx＝00000，即是图像起始码，GOB头信息包括GOB number和量化因子；宏块没有起始码，宏块的边缘依赖上下文数据确定。

随着(3rd Generation，3G)第三代移动通信业务的开展，视频彩铃业务的应用越来越多，视频流媒体的播放就是把视频帧数据读取后进行(RealTime Protocol，RTP)实时协议打包的过程，一个RTP报文的大小是有限制的，一般设置为一个包最大不能超过1.5K，而一个视频帧可能大于1.5K，这样就需要把一个视频帧拆分成多个RTP数据包来发送。这个拆分不是一个简单的数据分割过程，视频数据封装的最小单位是宏块，宏块数据不能分割，同一个宏块的数据必须在同一个RTP数据包中。这就要求媒体资源服务器播放视频文件时需要知道各个宏块在视频数据中的位置。因此在视频彩铃业务视频播放过程中，媒体资源服务器逐块读取视频帧数据，在读取的视频帧数据中进行bit位搜索和比较，获得图像头信息和各个GOB的起止位置，确定各个宏块的边缘，这样就可以把一个视频帧分成多个RTP数据包，每个RTP数据包可以包含1个或多个宏块，然后拷贝数据流进行RTP打包后发送给终端，实现视频流媒体播放业务流程，

发明人在发明过程中发现，现有技术中，GOB起始码流的搜索和宏块边缘的确定是必不可少的，而因为起始码流是一段bit位，而宏块边缘需要根据上下文确定，这就需要在整个文件范围内进行位搜索和比较，导致较高的CPU资源消耗，严重限制了视频播放的规格。

发明内容

本发明的实施例提供了实现视频文件播放的方法及装置，以及系统，实现快速播放视频文件。

一种视频文件播放的方法，包括：

接收终端的播放请求，所述播放请求为请求播放预先处理过的视频文件；获取所述预先处理过的视频文件的打包关键信息；将所述打包关键信息和实际视频数据进行打包为数据包，并将所述数据包发送给所述终端。

一种视频文件播放的处理装置，包括：请求接收单元，用于接收终端的播放请求，所述播放请求为请求播放预先处理过的视频文件；信息获取单元，用于获取所述预先处理过的视频文件的打包关键信息；数据包发送单元，用于将所述打包关键信息和实际视频数据进行打包为数据包，并将所述数据包发送给所述终端。

一种视频文件播放的处理系统，包括：

文件服务器，用于对视频文件进行预处理，获取并记录打包关键信息；

媒体资源服务器，用于接收终端的播放请求；从所述文件服务器获取经过预先处理过的视频文件的打包关键信息；将所述打包关键信息和实际视频数据进行打包为数据包，并将所述数据包发送给所述终端。

由于通过获取所述预先处理过的视频文件的打包关键信息实现对视频数据的读取，而无需通过对整个视频文件进行逐位搜索、比较和计算来获取各个数据包的各个宏块和GOB的位置，减少了CPU资源消耗，提升了系统规格；并且对于同一个视频文件，只需进行一次预处理，以后每次播放都不需再进行复杂的搜索，在需要反复播放同一文件的视频彩铃业务中，本发明可以极大的节省网络资源和系统资源。

附图说明

图1为H263的一个视频帧的码流结构示意图；

图2为本发明实施例的一种视频文件播放的方法的流程图；

图3为本发明实施例的一种在录制过程中对视频文件的进行预处理流程示意图；

图4为本发明实施例的一种利用预先播放时对视频文件进行预处理对流程示意图；