背景技术
随着移动终端的集成度越来越高,其对信息的处理能力也越来越强,比如终端上能够提供具有一定分辨率和色彩的彩色屏幕、摄像头等。无线接入技术的出现,又使得网络能够支持足够的数据传输带宽。在这种条件下,与流媒体相关的各种应用就很自然地出现在移动终端上,比如多媒体短消息业务、PS域视频流业务、可视电话业务、多媒体广播多播业务等。
在流媒体的应用中,越来越多的业务要求采用点到多点的方式传输,比如多媒体广播多播业务就是一种点到多点业务。多媒体广播多播业务的种类繁多,手机电视业务就是其中一种,定制该业务的手机能够直接接收电视,使得用户可以随时随地收看到节目,故这类业务对用户很有吸引力。
然而,3GPP协议的R99和R4版本都没有提供在网络上承载点到多点业务的方法。在R6版本中,UMTS网络的接入网和核心网在功能上都有较多增加,从而能够提供点到多点的传输承载,具体为:核心网之外新增BM-SC节点,令该节点与GGSN相连,以提供多媒体广播多播业务并对其进行控制,该BM-SC节点还能实现对移动终端的接入控制和计费管理。由于增加了BM-SC节点,GGSN、SGSN、RAN和移动终端的用户面和控制面也增加了相应功能,以协助BM-SC提供点到多点业务。但是,R6版本目前还没有制定完成,故基于R6版本协议的成熟产品要推向市场还需要较长时间。为此,只能基于已经商用的R99和R4版本,通过点对点方式逐个为用户提供流媒体直播和点播服务。
现有技术中,能为用户提供媒体应用的流媒体传输***如图1所示,包括内容提供商(CP/SP)、流媒体服务器和终端用户。其中CP/SP通过Internet上载包含流媒体数据的源文件到流媒体服务器,再由所述流媒体服务器根据终端用户的业务定制请求,将对应的流媒体数据通过移动网络等下发给终端用户。
所述流媒体服务器包括会话管理模块101、存储模块102和流调度模块103,CP/SP将流媒体数据上载到流媒体服务器的存储模块102时,会将上述操作通知会话管理模块101。当终端用户要求获得某段流媒体数据时,该终端用户将向会话管理模块101发出请求,会话管理模块101就会向流调度模块103下达指令。此后,流调度模块103从存储模块102获取包含相应流媒体数据的源文件,并将上述源文件打成RTP包后,下发给终端用户。
流调度模块103封装RTP包的过程具体为:首先,流调度模块从存储模块获得索引轨道(Hint Track)信息并解码。
然后,流调度模块根据Hint Track信息在Video Track或Audio Track中查找对应的采样(Sample),并将每个Sample按照RTP协议封装成Packet发送。所述Sample是源文件中流媒体数据的基本数据单元,可以是视频流或音频流。
在上述数据发送过程中,流调度模块每获取一个Sample,就要对存储模块进行一次或多次访问,故存储模块的磁盘控制器吞吐量很低。
再有,现有技术只有在获得Hint Track信息后,才能在源文件中查找到Sample,故大大降低硬件的处理效率,而且Hint Track信息的数据量较大,将Hint Track信息解码到内存需要占用大量空间。
此外,在将源文件封装为RTP包的过程中,由于不同的媒体类型设置的格式互不相同,常用的有ASF格式、MOV格式和MP4格式等,故某个流媒体服务器只能专门处理一种媒体类型,兼容性差。
从上述描述看出,现有的流媒体服务器处理效率低,会大大提高业务提供的成本,使得流媒体业务的资费昂贵,从而限制手机电视等多媒体广播多播业务的用户数目,降低其商业价值,业务的发展迫切需要提出一种效率较高的流媒体传送方法和服务器。
发明内容
有鉴于此,本发明的主要目的在于提供一种流媒体服务器,减少该服务器在流媒体数据发送时的磁盘读取次数,提高硬件的处理效率。
本发明的又一目的在于提供一种流媒体传送方法,使得流媒体数据的发送更为方便、快捷。
本发明的再一目的在于提供一种流媒体数据的存储方法,使得同一个HMF文件中能够记录任意媒体类型的流媒体数据,提高数据存储的兼容性。
为达到上述目的,本发明的技术方案具体是这样实现的:
一种流媒体服务器,包括会话管理模块、流调度模块和存储模块,所述会话管理模块分别对流调度模块和存储模块进行控制,该服务器还包括包封装模块;
所述会话管理模块接收到内容提供商的流媒体上载指令后,向包封装模块下达格式转换通知;
包封装模块根据上述通知从存储模块获取内容提供商上载的源文件,将其转化为HMF格式的流媒体数据保存在存储模块中;
流调度模块根据终端用户的流媒体获取请求,按照HMF文件的设置格式从存储模块查找到对应的流媒体数据发送给终端用户。
一种流媒体传送方法,该方法包括以下步骤:
流媒体服务器接收到内容提供商的流媒体上载指令后,获取内容提供商上载的源文件,将其转化为HMF格式的流媒体数据保存;
当终端用户发出流媒体获取请求时,流媒体服务器按照HMF文件的设置格式,在自身查找到对应的流媒体数据发送给终端用户。
所述源文件包括索引参数和数据内容,则所述格式转化的方法具体为:流媒体服务器通过解析源文件判定其媒体类型,根据对应类型源文件的固定封装格式,从所述源文件获取数据内容保存为HMF文件体,并将源文件中获取的索引参数保存为HMF文件头,通过HMF文件头索引HMF文件体。
所述将索引参数保存为HMF文件头的方法为:预先在HMF文件头中设置媒体描述对象和流描述对象,所述媒体描述对象设置媒体类型域和流映射表域,所述流描述对象设置流标识域、媒体类型域、码速率域、Mage位置域和Mage数量域,将所获得的索引参数保存在上述描述对象的对应域中。
所述按照HMF格式查找并发送流媒体数据的方法具体为:
首先,流媒体服务器查找HMF文件的媒体描述对象,并根据媒体描述对象中记录的流映射表获知HMF流标识与流描述对象的对应关系;
然后,根据所述对应关系查找流描述对象,并从中获得流媒体数据的位置信息,再从对应位置取得所需的流媒体数据发送。
所述HMF文件头进一步设置文件描述对象,用于记录Mage尺寸和播放时间。
所述HMF文件头进一步设置文件头描述对象,用于记录对象标识、版本标识、对象大小和子对象个数。
所述HMF文件头进一步设置:流索引表对象和扩展信息对象;
所述流索引表对象用于记录媒体格式和码速率,所述扩展信息对象用于记录以下至少一项内容:版权信息、内容简介、维护信息和更新信息。
所述通过HMF文件头索引HMF文件体的方法具体为:
流媒体服务器生成HMF流标识,并设置该HMF流标识与源文件中视频流标识/音频流标识的对应关系;
将上述对应关系记录在媒体描述对象的流映射表域中,同时将HMF流标识记录在对应流描述对象的流标识域中;
将至少一个源文件中所述视频流标识/音频流标识对应的数据包保存在HMF文件体的Mage基本单元中,并在流描述对象的Mage位置域记录每个Mage的存储地址,在Mage数量域中记录所生成的Mage个数。
所述Mage基本单元包括Mage头和Mage体;
所述Mage头至少记录以下参数:播放时间、数据包数量、每个包的偏移量、数据包长度、时间戳和关键帧指示。
所述包封装模块将数据内容保存为HMF文件体时,对所述数据内容中的每个数据包逐一进行RTP封装;
则接收到流媒体获取请求后,流媒体服务器直接将HMF文件体中的流媒体数据发送给终端用户。
接收到流媒体获取请求后,所述发送流媒体数据的方法具体为:流媒体服务器将查找到的流媒体数据按照RTP协议进行封装后发送给终端用户。
所述媒体类型为ASF格式,或MP4格式,或MOV格式。
一种流媒体数据的存储方法,该方法包括:
将待存储的每条流媒体数据划分为至少一个基本单元,保存在HMF文件体中,并获取所述流媒体数据的特征参数保存为HMF文件头,通过HMF文件头索引HMF文件体,形成HMF文件。
所述HMF文件头包括至少一个媒体描述对象,所述媒体描述对象设置媒体类型域和流映射表域;
每个媒体描述对象至少索引一个流描述对象,所述流描述对象设置流标识域、媒体类型域、Mage数量域和Mage位置域,每个流描述对象与每条流媒体数据对应;
则所述获取特征参数的方法具体为:为待存储的每条流媒体数据生成对应的HMF流标识,并将其记录在该条流媒体数据的流描述对象的流标识域;
检测每条流媒体数据中包含的Mage基本单元个数,将其记录在Mage数量域,并将所述Mage基本单元的存储地址逐个保存在Mage位置域;
确定待存储流媒体数据的媒体类型,并将其记录在流描述对象的媒体类型域,再将具有相同媒体类型的流描述对象的HMF流标识记录在同一个媒体描述对象的流映射表域,并在所述媒体描述对象的媒体类型域保存该媒体类型。
所述Mage基本单元包括Mage头和Mage体;
所述Mage头至少记录以下参数:播放时间、数据包数量、每个包的偏移量、数据包长度、时间戳和关键帧指示。
所述HMF文件头进一步包括文件描述对象,用于记录Mage尺寸和播放时间。
所述HMF文件头进一步包括文件头描述对象,用于记录对象标识、版本标识、对象大小和子对象个数。
所述HMF文件头进一步包括流索引表对象和扩展信息对象;
所述流索引表对象用于记录媒体格式和码速率,所述扩展信息对象用于记录以下至少一项内容:版权信息、内容简介、维护信息和更新信息。
由上述技术方案可见,本发明的这种流媒体服务器设置包封装模块,专门用于将各种媒体类型的源文件封装为统一的HMF格式文件,所述HMF格式将描述数据信息的索引参数与对应的流媒体数据捆绑封装,使得流调度模块不必通过多次读取磁盘,就能直接从存储模块定位到所需的流媒体数据下发给终端用户,从而提高硬件的处理效率和兼容性。
本发明的流媒体数据存储方法,能在同一个HMF文件中记录不同媒体类型的流媒体数据,从而提高数据存储的兼容性,并且所述HMF文件的格式设置使得流媒体数据的读取和传送更为方便、快捷。
进一步地,在将源文件转化为HMF格式文件时,可以对源文件中的基本数据单元直接进行RTP封装,比如对源文件中的每个Sample都执行一次RTP封装,再将封装后的Packet保存到HMF文件体中。流调度模块在获得上述流媒体数据后,能够直接发送给终端用户,故该方法令流调度模块专注于流媒体数据的调度和发送,提高了流调度模块的执行速度,使得流媒体数据的发送更为方便、快捷。
此外,设置HMF文件体时,在其Mage基本单元中同时封装多个Packet。这样,流调度模块对存储模块执行一次访问,就能同时获得多个Sample,从而提高存储模块I/O端口的吞吐量。
具体实施方式
为使本发明的目的、技术方案及优点更加清楚明白,以下参照附图并举实施例,对本发明进一步详细说明。
图2显示的是本发明中流媒体服务器的组成结构,包括会话管理模块(Session Management)101、存储模块102、流调度模块(Stream Scheduler)103和包封装模块(Stream Packetization)204。
所述会话管理模块101是流媒体服务器的管理中心,用于控制流调度模块103和包封装模块204,该模块可以采用CPU实现。
所述包封装模块204根据会话管理模块101创建的包封装会话,执行相应的数据格式转换。比如,当有MP4格式的源文件上载时,会话管理模块为其创建一个会话,包封装模块根据所述会话信息,将MP4文件转换成HMF格式文件保存在存储模块102。其中,包封装模块204在进行格式转换时,将源文件中的每个Sample打成一个Packet,并将多个Packet封装在同一个Mage中,以Mage为基本单位执行HMF格式的文件读取,每个Mage的大小为512K/256K/128K/64K。
所述流调度模块103从存储模块102读取HMF格式的流媒体数据,并将其发送给终端用户。
HMF格式包括HMF文件头(HMF Header)和HMF文件体(HMF Body)这两部分,其中文件头包含文件描述、媒体描述、流描述等信息,文件体包含实际的流媒体数据,即语音内容和/或视频画面等。HMF文件体以Mage为基本单位存放,其中Mage是文件读取的最小单位,大小为几十K到几百K。根据码速率的不同,一个Mage中可能包含几毫秒到几秒的流媒体数据。
在存储HMF格式文件时,可以将文件头和文件体存放在同一个文件中,也可以用两个文件分别存放。HMF文件结构的一个具体实例参见表一,其中流媒体数据Stream1包含Mage1、Mage2、Mage3和Mage4这四个基本单元,每个基本单元都记录有自身的Mage Header和Mage body。
说明 |
文件内容 |
Header |
Header Section |
Stream1 |
Mage1 |
Mage Header |
Mage body |
|
Mage2 |
Mage Header |
Mage body |
|
Mage3 |
Mage Header |
Mage body |
|
Mage4 |
Mage Header |
Mage body |
Stream2 |
Mage5 |
Mage Header |
Mage body |
|
Mage6 |
Mage Header |
Mage body |
|
Mage7 |
Mage Header |
Mage body |
|
Mage8 |
Mage Header |
Mage body |
Stream3 |
Mage9 |
Mage Header |
Mage body |
|
Mage10 |
Mage Header |
Mage body |
|
Mage11 |
Mage Header |
Mage body |
|
Mage12 |
Mage Header |
Mage body |
|
Mage13 |
Mage Header |
Mage body |
表一
在每个HMF格式文件中,HMF文件头是用于存放流媒体数据的描述信息的,比如Mage尺寸、播放时长、媒体类型和流ID等。在终端用户和流媒体服务器建立连接的过程中,所述服务器只需逐个读取HMF文件头,就能获知存储模块中保存的流媒体数据信息。
为了更好地满足上述要求,需要设计出结构清晰、便于查找、维护方便,且兼容性好的HMF文件头格式,使得HMF文件头能够包含足够的信息,并能对MMS、RTP/RTSP等多种协议进行兼容,保证所述服务器能够流畅地处理自身保存的HMF文件。
图3显示的是本发明一个较佳实施例中HMF文件头的逻辑结构,在该结构中,文件头被划分为文件信息、媒体信息和流信息这三类,并按照树状结构建立联系。其中,文件信息包含每个HMF文件的全局信息,比如文件大小、创建日期等。媒体信息包括该HMF文件中记录的某种类型的媒体公共信息,比如流映射表等。根据媒体类型的不同,所述媒体信息又分为ASF媒体信息、MOV媒体信息和MP4媒体信息等。所述流信息中记录的是每个具体流数据的信息,比如码速率、媒体格式、该流数据在HMF文件体中的位置等。
从图3看出,HMF文件头的逻辑结构具有很强的扩展性。比如,如果需要在某个HMF文件中增加ASF格式的流,只需在ASF媒体信息中添加ASF STREAM4节点。再比如,如需进一步存放内容简介、版权信息、维护信息或广告等扩展信息,可以在结构树中添加专门的分支加以保存。此外,为了简便起见,可以设置流索引表来记录所有流数据的基本信息,索引表中的每条记录仅包含对应流数据的媒体格式和码速率。
在具体实现图3所示的逻辑结构时,引入对象(Object)这个现有的概念作为HMF文件的基本结构单元。所述对象指的是具有共同结构的一种数据体,该数据体便于扩充以存储新的数据和操作,并且扩充出来的对象保留原有的数据和操作。其中,扩充是指在原有数据结构的后面添加新的成员。如果改变原有成员的内容,则不能称为扩充。
不同类型的对象设置不同的Object_ID加以区分,对于同一类型对象的不同扩充形式,可以用版本标识区别开来。当某个对象被扩充时,所有由其扩充而得的对象的版本号都必须更新。由于扩充出来的对象仍拥有原来的数据和操作,故旧版文件仍然可以处理新版文件中属于原来的数据和操作,只是不能支持扩充出来的功能,而新版文件能够完全处理旧版文件,从而将文件格式变动的影响减至最低限度。
整个HMF文件头由若干个不同类型的Object组成,每个Object的基本结构是相同的,但是其中存放的内容不同。所有类型的Object共用一个总体结构,便于维护和管理。各个Object又分别在总体结构上进行扩充,用自身特有的数据结构存放相关信息。Object的总体结构如表二所示,所定义的所有多字节域都采用Intel格式,即低位字节在前,高位字节在后。
域 |
长度(字节) |
说明 |
Object ID |
4 |
标明对象类型,已定义的类型如下:“HMHD”:HMF文件头对象(HMF Header Object);“HMFD”:HMF文件描述对象(HMF File Description Object);“HMMD”:媒体描述对象(HMF Media Description Object);“HMSD”:流描述对象(HMF Stream Description Object);“STTB”:流索引表对象(Stream Table Object);“INFO”:扩展信息对象(Information)。 |
Version |
4 |
对象类型的版本标识(全0为基本版本) |
Object Size |
4 |
对象大小(单位为字节)包括Object_ID、Version、Object_Size和Object Data等域 |
Object Data |
Variable |
由各个对象自行定义,根据对象具体内容的不同,该部分的长度和格式是可变的。 |
表二
在图3中,文件头对象(Header Object)是一个容器,包含若干个子对象,分别是文件描述对象(HMFD)、媒体描述对象(HMMD)、流描述对象(HMSD)、流索引表对象(STTB)和扩展信息对象(INFO)。根据实际设置,HMF文件头对象可能包含一个或多个HMMD、一个或多个HMSD,而STTB和INFO则是可选的。在存储HMF文件头时,可以按图4所示将结构树中的每个节点独立存储,所有子对象在文件头中的存储位置是任意的,并在解析HMF文件头时再行恢复上述子对象之间的树状结构,下面将逐一对树状结构中的每类节点详加说明。
1、文件头对象(HMHD),用于对HMF文件头进行标识。如表三所示,所有的子对象将作为HMHD的数据内容存放在其Object data域中,HMHD的Object Size域记录的是整个HMF文件头的总长度。
域 |
长度 |
说明 |
Object ID |
4B |
“HMHD” |
version |
4B |
版本标识 |
Object Size |
4B | |
Sub_object_Number |
4B |
包含的子对象个数。如果域值为0,表明该域无效,并不代表子对象个数为0。 |
Data Field |
Variable |
子对象 |
表三
2、文件描述对象(HMFD),用于描述HMF文件的全局信息,包括该文件中包含的所有媒体类型以及每种类型流数据的公共信息等,各个媒体类型或流数据的具体信息设置在对应的HMMD或HMSD中,并不存放在HMFD中。HMFD各个域的定义见表四,其中Mage尺寸(Mage size)、播放时间(Play Duration)是该对象必不可少的参数。
域 |
长度 |
说明 |
Object ID |
4B |
“HMFD” |
Version |
4B | |
Object Size |
4B | |
Data File Size |
8B |
媒体文件的数据大小 |
Mage size |
4B |
Mage尺寸(以字节为单位,并设为64K的整倍数) |
File Version |
4B |
文件版本 |
Play Duration |
8B |
播放时间,单位为毫秒(ms) |
Creation Date |
8B |
创建时间(yyyy-mm-dd:hh-mm-ss-00,末位为空) |
Modified Data |
8B |
修改时间(yyyy-mm-dd:hh-mm-ss-00,末位为空) |
表四
3、媒体描述对象(HMMD),用于记录对应媒体类型的描述信息和流映射表,上述信息是从源文件提取出来的。HMMD的定义见表五,其中“\0”为转义字符,表示值为0的ASCII码字符。在表五的所有参数中,子类型(SubType)是必不可少的参数,该参数按照文件媒体类型域进行设置。
域 |
长度 |
说明 |
Object ID |
4B |
“HMMD” |
Version |
4B | |
Object Size |
4B | |
Sub Type |
4B |
目前定义的有“ASF0”、“MOV0”和“MP40”。如果需要支持新的媒体类型,可以为该类型生成对应的媒体描述对象,并在此域中定义类型标识。 |
Data Section |
Variable |
数据区,不同媒体类型的具体内容有所不同。 |
表五
对于不同的媒体类型,其Data Section域的内容是不同的。表六显示的是ASF格式的Data Section结构。
域 |
长度 |
说明 |
Header Packet Size |
4B |
下一个域的长度 |
Header Packet |
Variable |
需要发送给终端用户的Header Packet |
Stream Table Size |
4B |
流映射表的长度 |
Stream Table Item1 |
4B | |
Stream Table Item2 |
4B | |
Stream Table Item... |
4B | |
表六
表六中的Stream Table Item结构详见表七,所述视频流标识(VideoStream ID)、音频流标识(Audio Stream ID)和HMF流标识(HMF StreamID)都是必不可少的参数,其中HMF流标识是在格式转换时由包封装模块自动分配的。
域 |
长度 |
说明 |
Video Stream ID |
1B |
ASF文件中的Video Stream ID |
Audio Stream ID |
1B |
ASF文件中的Audio Stream ID |
HMF Stream ID |
2B |
对应HMF文件的ID |
表七
MOV格式的Data Section结构没有Header Packet域,其Stream TableItem结构见表八。同样地,表八中列出的三个参数也都是必不可少的。MP4格式的Data Section结构与MOV格式类似,此处不再赘述。
域 |
长度 |
说明 |
Video Track ID |
1B |
MOV文件中的Video Track ID |
Audio Track ID |
1B |
MOV文件中的Audio Track ID |
HMF Stream ID |
2B |
对应HMF文件的ID |
表八
从上述表六~表八看出,在使用MMS协议时,传送流数据之前需要通过Header Packet域向终端用户发送媒体描述信息,而在使用RTP/RTST协议传送MOV和MP4文件时,不必执行上述过程。
造成上述差别的原因在于:使用MMS协议时,是由终端用户提供流数据的选择项,再由服务器最终决定提供哪个流数据,因此在进行流媒体数据传输之前,需要先将媒体描述信息传送给终端用户。而在RTP/RTST协议中,服务器能够直接决定提供哪路流数据给终端用户,故省去了媒体描述信息的交互过程。
此外,不论是ASF格式、MOV格式或是MP4格式都要设置流映射表,所述流映射表均是为了实现源文件的视/音频流ID到HMF流ID的映射。
4、流描述对象(HMSD),用于提供每个具体的流媒体数据的描述信息。所述HMSD的定义如表九所示,其中的Temporal Index域记录的是该流媒体数据每隔一定时间(一般是一秒钟)所建立关键帧的位置信息,用于指明关键帧在HMF文件体中的位置。表九中,流标识(Stream ID)、媒体类型(Media Type)、码速率(Bit Rate)、位置信息(Position)和Mage数量(Mage Number)都是必不可少的参数,其中的流标识与HMMD中设置的Stream ID相对应。
域 |
长度 |
说明 |
Object ID |
4B |
“HMMD” |
Version |
4B | |
Object Size |
4B | |
Stream ID |
4B |
HMF文件体中的流编号,低两位字节有效。其中编号0和0xFFFF有特殊意义,故平常情况不使用。 |
Flags |
4B | |
说明 |
Seekable | |
是否支持拖动,位置掩码为0x 00 00 00 01 |
|
HaveVideo | |
是否有视频,位置掩码为0x 00 00 00 02 |
|
HaveAudio | |
是否有音频,位置掩码为0x 00 00 00 04 |
Media Type |
4B |
“ASF0”、或“MOV0”、或“MP40”,并可扩充定义 |
Bit Rate |
4B |
码速率(单位为bps) |
Position |
8B |
第一个Mage在文件中的位置 |
Stream Size |
8B |
流媒体数据的大小,具体为Mage Number×Magesize,域值为0表明该域无效,不表示长度为0。 |
Mage Number |
4B |
包含的Mage数量 |
Session Data |
SDP数据域 |
说明 |
Size |
4B |
SDP数据长度(单位为字节,不包括本身的4B长度) |
|
Data |
Variable |
SDP数据 |
Temporal Index |
索引,用于快速查找关键帧 |
说明 |
Size |
4B |
Index数据长度(单位为字节,不包括本身的4B长度) |
|
Item Size |
4B |
数据项的长度,一般为8B |
|
Interval |
4B |
两个Item之间的时间间隔,单位为毫秒 |
|
Index Item 1 |
Item Size |
Index数据项,媒体类型不同、格式不同 |
| |
Mage No. |
4B |
流数据中的第几个Mage |
| |
Offset |
4B |
在该Mage中的偏移量(即相对第一个字节的位置) |
| |
Reserved | |
如果Item Size域的值小于8,该域不存在 |
|
Index Item 2 |
Item Size |
Index数据项,媒体类型不同、格式不同 |
|
Index Item... |
Item Size |
同上 |
表九
5、流索引表对象(STTB,可选)的定义见表十,该STTB用于对HMF文件体中提供的多个流数据进行索引,从而为查找到适合的流数据提供方便,HMHD中只设置一个STTB。
域 |
长度 |
说明 |
Object ID |
4B |
“STTB” |
Version |
4B |
保留,供扩充使用 |
Object Size |
4B | |
Item Number |
4B |
表项个数 |
Item 1 |
12B |
第1个索引项 |
Item 2 |
12B |
第2个索引项 |
Item... |
12B |
第...个索引项 |
表十
其中,每个索引项的结构如表十一所示:
域 |
长度 |
说明 |
Bit Rate |
4B |
码速率 |
Media Type |
4B |
媒体类型为“ASF0”,或“MOV0”,或“MP40”等 |
Stream ID |
4B |
低两位字节有效 |
表十一
6、扩展信息对象(INFO,可选)的定义见表十二,该INFO用于存放HMF文件的一些扩展描述,比如版权信息、内容简介、维护信息和更新信息等,一个HMF文件头可以设置0个到多个INFO。
域 |
长度 |
说明 |
Object ID |
4B |
“INFO” |
Version |
4B | |
Object Size |
4B |
保留,供扩充使用 |
Sub Type |
8B |
子类型,已定义的有:“COPYRIGT”版权信息、“CONTENT”内容简介等 |
Data Field |
Variable |
具体格式根据子类型定义 |
表十二
由上述定义看出,由于设置有以对象为基本结构单元的HMF文件头,整个HMF文件更加具有规整性、可扩充性以及兼容性,从而提高HMF文件的操作和维护效率。
由于HMF格式能够保存不同类型的流媒体数据,且这些媒体类型在传输时使用的协议各不相同,故服务器响应终端用户的流程也有所不同。
当终端用户请求一个ASF文件时,服务器首先查看HMF文件头确定某个HMF文件中是否存在ASF格式的HMMD。如果没有则告知终端用户所请求的文件不存在,否则服务器将HMMD存放的对应流媒体数据发送给终端用户。当终端用户选择播放某路视频流和/或某路音频流时,服务器通过HMMD中设置的流映射表查找到对应的HMF流ID,通过上述HMF流ID从HMSD获得所述流数据的详细信息,并根据上述信息定位到HMF文件体的确切位置获取该流媒体数据。
当终端用户请求一个MOV或MP4文件时,流媒体服务器可以直接根据HMMD中的Track映射表定位到HMSD,并进入点播过程开始传送流媒体数据。
在HMF文件头之后保存有HMF文件体(HMF Body),该文件体由若干个流媒体数据组成,每个流数据包含若干Mage,每个Mage的大小都相同,Mage里存放着多个媒体数据包(Packet)。为了便于流调度模块直接进行Packet分发,Mage中的每个Packet都预先按照最终的发送格式进行设置。在本发明一个具体实例中,每个Mage又包括Mage Header和Mage Body这两部分。
1、Mage头(Mage Header)。不同Mage中的Mage Header长度可以各不相同,这要视实际需要而定,表十三显示的是Mage Header的结构,包括播放时长(Duration)、包数量(Packet Number)、偏移量(Offset)、Packet长度(Length)、时间戳(Time Stamp)和关键帧指示(Is KeyFrame)等必要参数。
域 |
长度(字节) |
说明 |
Version |
4 |
版本号 |
Mage Size |
4 |
每个Mage长度必须是16K的整数倍 |
Header Size |
4 |
以字节为单位 |
Media Type |
4 |
媒体类型(参考HMF文件头的域定义) |
Protocol Type |
4 |
使用的传输协议 |
Duration |
4 |
Mage的播放时长 |
Packet Number |
4 |
Mage中包含的Packet数量 |
Param Table |
PacketNumber×12 | |
说明 |
Offset |
4 |
偏移量,用于指明Packet在Mage中的位置。 |
|
Length |
4 |
Packet长度,具体为Sample长度+RTP包头长度 |
|
Time Stamp |
4 |
时间戳,用于指明播放时刻 |
|
Instruction |
2 |
每个Packet有两个指令字节,其中0x0000为空指令 |
|
Flags |
2 |
每个Packet有两个标志字节 |
|
Is KeyFrame |
1bit |
最低位,掩码为0x0001 |
Padding(Optional) |
Variable |
根据需要用0在Header和流数据之间填充若干字节 |
表十三
在初次获取某个HMF文件中的packet时,流调度模块需要对HMF文件头进行解析。此后,流调度模块能够直接从Mage header解析出下一个packet位置。
2、Mage体(Mage body)。流媒体数据以packet为单位顺序排列在Mage body中,每个packet的位置由Mage header中的Packet index指明。
如果一个Mage body中的剩余字节不够再放置一个完整的Packet,则以0填充,不能将同一个Packet分开放置在两个Mage中。表十四显示的是Mage body中存放Packet的结构。
域 |
长度 |
说明 |
Packet 1 |
Variable |
第1个媒体数据包 |
Packet 2 |
Variable |
第2个媒体数据包 |
Packet 3 |
Variable |
第3个媒体数据包 |
Packet... |
Variable |
第...个媒体数据包 |
Padding |
Variable |
剩余字节(以0填充) |
表十四
采用上述方式定义的HMF格式能将不同的媒体类型存放在同一个文件中,通过HMF文件头对不同媒体类型的不同流数据进行索引和管理,故本发明的HMF格式具有足够的开放性和可扩充性,易于维护,并且服务器在获取流媒体数据时的开销也小。
根据上述定义,将流媒体数据按照HMF格式存储的方法具体为:将待存储的每条流媒体数据划分为至少一个基本单元,保存在HMF文件体中,并获取所述流媒体数据的特征参数保存为HMF文件头,通过HMF文件头索引HMF文件体,形成HMF文件。
其中,获取特征参数的一个具体实例为:为待存储的每条流媒体数据生成对应的HMF流标识,并将其记录在该条流媒体数据的流描述对象的流标识域;
检测每条流媒体数据中包含的Mage基本单元个数,将其记录在Mage数量域,并将所述Mage基本单元的存储地址逐个保存在Mage位置域;
确定待存储流媒体数据的媒体类型,并将其记录在流描述对象的媒体类型域,再将具有相同媒体类型的流描述对象的HMF流标识记录在同一个媒体描述对象的流映射表域,并在所述媒体描述对象的媒体类型域保存该媒体类型。
基于图2所述的流媒体服务器和预先设置的HMF格式,本发明中流媒体传送的方法如图5所示,包括以下步骤:
步骤501、会话管理模块通知包封装模块初始化预先设置的包封装队列,包封装模块在执行完初始化操作后,返回成功响应给会话管理模块。
步骤502、CP/SP将包含流媒体数据的源文件上载到存储模块后,向会话管理模块发送包封装请求。
其中,CP/SP上载的源文件可以是任意的媒体类型,比如ASF格式、MP4格式或MOV格式等。所述源文件一般包括两部分:数据内容和索引参数,所述数据内容指的是实际的多媒体语音、画面等数据,以数据包为基本单元,而索引参数多为描述信息,比如Hint Track信息等,用于提供数据内容的相关信息,以便对数据内容进行定位。
步骤503、会话管理模块收到上述包封装请求后,通知包封装模块创建包封装会话。包封装模块在成功创建会话后,返回成功响应给会话管理模块。
步骤504、包封装模块在自身的包封装队列中查找等待处理的包封装会话,并根据所述会话的指示从存储模块取得CP/SP上载的源文件,按照预先设置将其转换为HMF格式保存到存储模块中。某个包封装会话一旦处理完毕,包封装模块就会自动删除该会话。
该步骤中,包封装模块执行格式转换的过程具体为:
首先,包封装模块根据源文件内容判断出该源文件的媒体类型后,按照其封装格式读取索引参数和数据内容。
比如所述源文件为MP4格式,则按照MP4文件的封装格式对源文件进行解析。其它类型的处理方式与此类似,故不再一一描述。
然后,包封装模块将数据内容按照RTP协议逐个封装成Packet,将所述Packet设置为HMF文件体的Mage基本单元保存。
最后,包封装模块根据提取出来的索引参数设置HMF文件头的HMFD、HMMD和HMSD等对象,并通过HMF文件头索引HMF文件体。
比如,预先在HMF文件头中设置HMMD和HMSD,所述HMMD设置媒体类型域和流映射表域,所述HMSD设置流标识域、媒体类型域、码速率域、Mage位置域和Mage数量域。
在进行格式转换时,流媒体服务器会生成HMF流标识,并设置该HMF流标识与源文件中视频流标识/音频流标识的对应关系;然后,将上述对应关系记录在媒体描述对象的流映射表域中,同时将HMF流标识记录在对应流描述对象的流标识域中;再将至少一个源文件中所述视频流标识/音频流标识对应的数据包保存在HMF文件体的Mage基本单元中,并在流描述对象的Mage位置域记录每个Mage的存储地址,在Mage数量域中记录所生成的Mage个数。
步骤505、会话管理模块在包封装会话完成后,通知CP/SP流媒体数据上载成功。
在步骤501~505中,通过包封装队列管理包封装会话只是一种较佳的实现方式,也可以不必设置该包封装队列,故步骤501为可选步骤。
步骤506、会话管理模块通知流调度模块初始化流调度队列,流调度模块完成初始化后返回成功响应。
步骤507~508、终端用户发送点播请求给会话管理模块,会话管理模块收到上述请求后,通知流调度模块创建流调度会话,流调度模块在所述会话创建完毕后返回成功响应给会话管理模块,并由会话管理模块将所述成功响应送至终端用户。
步骤509、流调度模块通过检索流调度队列取得待处理的流调度会话,并根据所述会话从存储模块取得终端用户要求点播的HMF文件,发送给终端用户。
该步骤中,流调度模块会从HMF文件中逐个获取Mage发送,直到该HMF文件发送完毕,具体为:首先,流媒体服务器查找HMF文件的媒体描述对象,并根据媒体描述对象中记录的流映射表获知HMF流ID与流描述对象的对应关系;然后,根据所述对应关系查找流描述对象,并从中获得流媒体数据的位置信息,再从对应位置取得所需的流媒体数据发送。上述过程执行完毕后,流调度模块把已完成的流调度会话从流调度队列中删除,结束本次流媒体服务。
如果在步骤504中,HMF文件体中的每个数据包都执行过RTP封装,则步骤509中,流媒体服务器可以直接将HMF文件体中的流媒体数据发送给终端用户,即流调度模块只专注于流媒体数据的调度和发送。
如果RTP封装过程在步骤504没有执行,则步骤509中,流媒体服务器将查找到的流媒体数据按照RTP协议封装后发送给终端用户,这个过程与现有技术相同,此处不再赘述。
同样地,在步骤506~509中,通过流调度队列管理流调度会话是一种较佳的实现方式,也可以不必设置该流调度队列,故步骤506为可选步骤。
此外,本发明所述的流媒体传送方法可以仅执行步骤501~505,即将源文件从CP/SP发送到流媒体服务器,并对所述源文件进行格式转换。进一步地,还可以执行步骤506~509,将HMF格式文件从流媒体服务器发送给终端用户。
由上述的实施例可见,本发明的这种流媒体服务器以及传送和存储方法能将各种媒体类型的源文件封装为统一的HMF格式文件,并将索引参数与对应的流媒体数据捆绑封装,使得流媒体数据能够直接下发给终端用户,从而提高硬件的处理效率和兼容性。