CN102118633A - 视频文件播放的方法、装置及系统 - Google Patents

Abstract

本发明的实施例提供了实现视频文件播放的方法、装置及系统，实现快速播放视频文件。一种视频文件播放的方法，包括：接收终端的播放请求，所述播放请求为请求播放预先处理过的视频文件；获取所述预先处理过的视频文件的打包关键信息；将所述打包关键信息和实际视频数据进行打包为数据包，并将所述数据包发送给所述终端。由于通过获取所述预先处理过的视频文件的打包关键信息实现对视频数据的读取，减少了CPU资源消耗，提升了系统规格；并且对于同一个视频文件，只需进行一次预处理，以后每次播放都不需再进行复杂的搜索，在需要反复播放同一文件的视频彩铃业务中，本发明可以极大的节省网络资源和系统资源。

Description

视频文件播放的方法、装置及系统

技术领域

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

背景技术

视频数据的编码格式主要使用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为本发明实施例的一种利用预先播放时对视频文件进行预处理对流程示意图；

图5为本发明实施例的一种视频文件播放的处理装置示意图；

图6为本发明实施例的另一种视频文件播放的处理装置示意图；

图7为本发明实施例的一种视频文件播放的处理系统示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

基于现有技术中，由于GOB起始码流的搜索和宏块边缘的确定是必不可少的，而因为起始码流是一段bit位，而宏块边缘需要根据上下文确定，这就需要在整个文件范围内进行位搜索和比较，导致较高的CPU资源消耗，严重限制了视频播放的规格。本发明的实施例提供了一种视频播放的方法及装置，通过对视频文件进行预处理，将视频流媒体播放时需要的打包关键信息提取出来，对视频文件结构(如avi或3gp)进行适当的符合标准的扩展，将提取出来的关键信息存入扩展的文件结构中(在AVI文件中使用可自定义的INFO Chunk来存储)，在实际打包时通过读取扩展段内容来获取关键信息，从而实现便捷播放，这样节省了CPU的系统资源，并且在视频彩铃业务中，同一个视频文件重复播放，无需每次进行起始码流的搜索和宏块边缘的确定，这提高了视频文件播放的处理速度，以及节省了视频文件播放的系统处理资源。

为了使本技术领域的人员更好地理解本发明实施例的方案，下面结合附图和实施方式对本发明实施例作进一步的详细说明。

图2为本发明实施例的另一种实现视频文件播放的方法的流程图，具体包括：

S201：服务器对视频文件进行预先处理。

对视频文件进行预先处理的过程，可以通过提取视频文件播放时需要的关键信息，这里可以称为打包关键信息，并将提取出来的打包关键信息存储到对标准视频文件结构扩展后的视频文件中；打包关键信息包括了净荷头和净荷相关信息。

媒体资源服务器或文件服务器可以在对视频文件进行录制时进行预先处理，或者媒体资源服务器或文件服务器可以在视频文件进行预先播放一次来进行预先处理。文件服务器处理，可以启动一个任务，即一个预先处理进程对视频文件进行预处理，或者在文件服务器安装一个预处理软件来进行预处理。

下面首先以AVI视频结构为例，说明媒体资源服务器在对视频文件录制时进行的预处理过程。

通过媒体资源服务器对视频文件进行预处理，可以获取到对视频文件进行打包时需要的打包关键信息，并将该打包关键信息存储到视频文件中，这样媒体资源服务器在向终端播放该视频文件时，可以直接从视频文件中获取到该打包关键信息进行打包，并发送给终端了。

视频录制的过程的，就是将一个个数据包流录制为avi视频文件的过程，主要是解析RTP数据包，并将RTP数据包的内容写入到avi视频文件中。

其中RTP报文结构包括三部分，RTP header+RTP payload header+RTPbitstream。其中RTP header为一固定结构，其中有一个比特位为Markerbit，其指示当前包是否一帧的最后一包。RTP bitstream是实际的数据码流，即实际的视频数据；RTP payload header就是静荷头数据，即进行RTP打包时需要提取的信息，静荷头数据可以包括：RTP打包模式、本包第一个字节高位无效比特个数、最后一个字节低位无效比特个数、是否I帧、视频编码相关的运动向量信息等。RTP打包模式包括三种，模式A、模式B、模式C，其中模式A：在GOB边缘开始打包，但是不一定包括完整的GOB，即需要知道GOB的边缘才可以实现打包。模式B：在宏块边缘打包，通常包含完整的宏块，不支持PB帧模式，则需要知道GOB的边缘和宏块的边缘才可以实现打包。模式C：在宏块边缘打包，与B模式相似，但是支持PB帧模式，由于PB帧模式需要引入B帧来增加重建图像的帧频，克服因要取样而带来的不利影响。所以模式C需要知道GOB的边缘、宏块的边缘以及各个宏块之间的关系才可以实现打包。

媒体资源服务器或者文件服务器开始进行视频文件录制时，创建一个avi视频文件，如record.avi。通过网口接收RTP数据包，并准备将RTP数据包包含的信息写入到avi视频文件中，如图3所示说明了媒体资源服务器在对视频文件录制时进行的预处理过程。

S2011：媒体资源服务器通过网口接收RTP数据包，并准备将RTP数据包包含的信息写入到avi视频文件中。

S2012：媒体资源服务器解析接收到的RTP数据包内容，获取RTP payloadheader信息后，将RTP payload header信息写入到avi视频文件的的打包关键字段中，例如INFO Chunk中，其中RTP payload header信息就是净荷数据对应的净荷头。

S2013：媒体资源服务器将获取到的RTP bitstream内容(即实际的视频数据)写入到avi视频文件的当前视频帧。

S2014：媒体资源服务器判断当前RTP数据包是否是某帧的结束，即RTPheader中的Marker bit是否为1。

S2015：如果当前RTP数据包不是某帧的结束，则媒体资源服务器继续获取下一个RTP数据包，重复S2012～S2014的步骤；

S2016：如果当前RTP数据包是某帧的结束，即RTP header中的Markerbit＝1，则计算当前视频帧总共包括几个RTP数据包，并根据当前帧包含的RTP数据包计算当前帧的帧长，在avi视频文件中改写帧长度字段。

如果当前数据帧完成后，媒体资源服务器开始写下一个视频帧，就这样循环下去，直至所有的RTP包都被媒体资源服务器解析完毕。

在视频文件录制过程中，媒体资源服务器从上述解析RTP包的过程中可以获取以下净荷相关信息，并将这些净荷相关信息存储在avi视频文件的打包关键字段中，例如INFO Chunk。这些净荷相关信息可以包括：用于确定视频文件中视频数据包起始位置的信息，方便播放时直接定位，如数据包起始位置相对于帧起始位置的偏移量；用于确定本包的包序号和数据长度，播放时就可直接根据此长度和包序号进行读取，如数据包长度、数据包序号；用于确定数据包是否为帧结束的信息，如视频Marker bit标志。

一个具体的例子是，INFO Chunk包含了净荷头和净荷相关信息，以下为INFO Chunk的数据结构；

typedef struct

{

DWORD uiSize；//整个数据包+本结构体的总长度

DWORD dwOffset；//数据包起始位置相对与帧起始位置的偏移量

DWORD dwLength；//数据包长度(不包括包静荷头长度)

WORD wPktNum；//数据包序号

BYTE bMFlag；//数据包Marker bit标志，标识是否帧结束

BYTE bPaldHdrLen；/*数据包静荷头长度*/

DWORD dwPayloadheader1；//静荷头1，modeA只需要这个字段信息DWORD dwPayloadheader2；//静荷头2，modeB需要静荷头1和2两个字段的信息

DWORD dwPayloadheader3；//静荷头3，modeC需要静荷头1、2和3两个字段的信息

}PKTINFO；

这样就在完成一个对视频文件录制过程的同时，获取了视频文件的打包关键信息，并将该打包关键信息存储到avi文件中。

下面以AVI视频结构的视频文件为例，介绍通过对运营商提供的视频文件进行预播放一次来进行预先处理。

首先将文件上传到文件服务器或者媒体资源服务器中，由文件服务器上启动一个预先处理进程对视频文件进行预先播放，一个具体的例子中，该预处理进程具体可以包括如下步骤，如果图4所示：

S2011’：文件服务器通过逐个读取各个视频帧，在视频帧数据中按照bit位搜索帧起始码，获取帧起始位置。

S2012’：文件服务器在该视频帧数据中继续按照bit位搜索时，判断搜索到的数据是否GOB的起始码，如果是数据为GOB的起始码，则执行2013’，否则执行2014’。

S2013’：如果搜索到的数据是GOB的起始码，则读取该GOB的序号和获取该GOB的长度，就可以获取GOB起始位置相对于帧起始位置偏移量，这样就获取GOB起始位置相对于帧起始位置的偏移量。

S2014’：如果搜索到的数据不是是GOB的起始码，则文件服务器在该视频帧数据中继续按照bit位搜索，获取各个宏块数据并确定宏块的边缘，由于宏块层包含多个字段，解析这些字段就可以获知宏块包含哪些内容，而这些字段代表的数据都是有固定长度的，解析完这些字段就可以获知宏块总共有多长和宏块的边缘，而获知这些宏块的内容就可以获知各个宏块的关系了，这样就获取各个宏块的长度和具体位置。

S2015’：判断当前视频帧是否结束时，如果没有结束，则循环上述S2012’～S2014’，当当前视频帧结束时，读取下一个视频帧，这样循环读下去，就可以将整个视频文件读取完毕。

从上述过程中，文件服务器可以获取到每一个视频帧的净荷数据的各个块组层GOB的起始码、序号和长度，以及获取各个宏块长度和具体位置，即净荷相关信息，然后构造这些净荷相关信息对应的净荷头，并将净荷头和净荷相关信息存储到avi文件的打包关键字段中，例如INFO Chunk，从而实现了对已视频文件进行预先处理。

需要说明的是，这里以avi格式的视频文件类型为例来说明对视频文件进行预先处理，该过程也可以适应对其它的视频文件类型的视频文件进行预先处理，如3gp类型。

该步骤只是预先处理的过程，对于同一个视频文件而言只要处理1次就可以了，以后播放该视频数据，媒体资源服务器直接读取打包关键信息进行视频播放。

S202：媒体资源服务器接收到某个终端用户的播放请求，该终端用户指定播放的视频即为已经进行过预先处理的视频文件。

S203：媒体资源服务器打开视频文件，并读取视频文件的数据包的INFOChunk，获取视频文件的打包关键信息。

S204：媒体资源服务器根据INFO chunk中净荷相关信息，读取实际视频数据，如：根据数据包起始位置相对于帧起始位置的偏移量、数据包长度和数据包序号，读取对应的实际视频数据；再从INFO chunk中取出净荷相关信息对应的静荷头数据，将净荷头、净荷相关信息和对应实际视频数据打包为数据包，并将该数据包发送给上述终端。

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

图5为本发明实施例一种视频文件播放的处理装置，包括：

请求接收单元31，用于接收终端的播放请求；

信息获取单元32，用于获取经过预先处理过的视频文件的打包关键信息；

数据包发送单元33，用于将所述打包关键信息和实际视频数据进行打包为数据包，并将所述数据包发送给所述终端。

一个具体的例子中，如果图6所示，上述视频文件播放的处理装置可以进一步包括：

视频文件预处理单元34，用于用于对视频文件进行预处理，获得打包关键信息。

一个具体的例子中，上述视频文件预处理单元34可以进一步用于在视频文件录制过程中，解析数据包获取净荷头和净荷相关信息，所述打包关键信息包括所述净荷头和净荷相关信息；将所述打包关键信息存储在视频文件的打包关键字段中。

一个具体的例子中，上述视频文件预处理单元34可以进一步用于将视频文件进行预先播放一次，在播放过程中，获取净荷头和净荷相关信息，所述打包关键信息包括所述净荷头和净荷相关信息，将所述打包关键信息存储在视频文件的打包关键字段中。

一个具体的例子中，上述视频文件预处理单元34可以进一步用于通过搜索视频帧，获取块组层GOB的起始码、序号和长度，以及获取各个宏块长度和具体位置，并得到所述净荷相关信息对应的净荷头。

图7为本发明实施例一种视频文件播放系统，包括：

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

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

需要说明的是，以上视频文件播放的处理装置的实施方式中，各功能模块的划分仅是举例说明，实际应用中可以根据需要，比如相应硬件的配置要求或者软件的实现的便利考虑，而将上述功能分配由不同的功能模块完成，即将所述的视频文件播放的处理装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。而且实际应用中，本实施例中的相应的功能模块可以是由相应的硬件实现，也可以由相应的硬件执行相应的软件完成，例如，前述的信息获取单元32，可以为具有执行前述功能的硬件，比如，具有该特定获取能力的接收器，以及其他通用的能够执行前述功能的接收装置，也可以是能够执行相应计算机程序从而完成前述功能的一般接收设备，或者其他硬件设备。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的硬件平台的方式来实现，当然也可以全部通过硬件来实施，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案对背景技术做出贡献的全部或者部分可以以软件产品的形式体现出来，所述的软件产品在可以用于执行上述的方法流程。该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。

虽然通过实施例描绘了本发明，本领域普通技术人员知道，本发明有许多变形和变化而不脱离本发明的精神，本发明的申请文件的权利要求包括这些变形和变化。

Claims (12)

1.一种视频文件播放的方法，其特征在于，包括：

接收终端的播放请求；

获取经过预先处理过的视频文件的打包关键信息；

将所述打包关键信息和实际视频数据进行打包为数据包，并将所述数据包发送给所述终端。

2.根据权利要求1所述的方法，其特征在于，还包括：对视频文件进行预处理，获取并记录打包关键信息。

3.根据权利要求2所述的方法，其特征在于，所述对视频文件进行预处理，获取并记录所述打包关键信息包括：

在对所述视频文件进行录制的过程中，解析数据包获取净荷头和净荷相关信息，将所述净荷头和净荷相关信息存储在视频文件的打包关键字段中。

4.根据权利要求2所述的方法，其特征在于，所述对视频文件进行预处理，获取并记录所述打包关键信息包括：

对所述视频文件进行预先播放，在播放过程中，获取净荷头和净荷相关信息，将所述净荷头和净荷相关信息存储在视频文件的打包关键字段中。

5.根据权利要求4所述的方法，其特征在于，所述获取净荷头和净荷相关信息包括：通过搜索视频帧，获取块组层GOB的起始码、序号和长度，以及获取各个宏块长度和具体位置，并得到所述净荷相关信息对应的净荷头。

6.根据权利要求2-5任一所述的方法，其特征在于，所述净荷相关信息包括：用于确定视频文件中视频数据包起始位置的信息，用于确定本包的包序号和数据长度的信息，以及用于确定数据包是否为帧结束的信息。

7.一种视频文件播放的处理装置，其特征在于，包括：

请求接收单元，用于接收终端的播放请求；

信息获取单元，用于获取经过预先处理过的视频文件的打包关键信息；

数据包发送单元，用于将所述打包关键信息和实际视频数据进行打包为数据包，并将所述数据包发送给所述终端。

8.根据权利要求7所述的处理装置，其特征在于，还包括：视频文件预处理单元，用于对视频文件进行预处理，获取并记录所述打包关键信息。

9.根据权利要求8所述的处理装置，其特征在于，所述视频文件预处理单元具体用于在对所述视频文件进行录制的过程中，解析数据包获取净荷头和净荷相关信息；将所述净荷头和净荷相关信息存储在视频文件的打包关键字段中。

10.根据权利要求8所述的处理装置，其特征在于，所述视频文件预处理单元具体用于对视频文件进行预先播放，在播放过程中，获取净荷头和净荷相关信息，将所述净荷头和净荷相关信息存储在视频文件的打包关键字段中。

11.根据权利要求10所述的方法，其特征在于，所述视频文件预处理单元具体用于通过搜索视频帧，获取块组层GOB的起始码、序号和长度，以及获取各个宏块长度和具体位置，并得到所述净荷相关信息对应的净荷头。

12.一种视频文件播放的处理系统，其特征在于，包括：

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

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

Images