CN101494655B - Rtp分布式流媒体服务***及方法 - Google Patents

Abstract

本发明涉及一种RTP分布式流媒体服务***，包括：流媒体节目源；中心转发服务器，按照RTP协议对原始节目内容打包，扩展包头包括RTP包中的视频数据的位置信息及标识信息，并发送到网络中；边缘节点，接收中心转发服务器转发的RTP流，并录制到本地，在录制时按照扩展包头对视频数据进行分段和保存；终端，接收中心转发服务器转发的RTP流，并按照扩展包头对RTP流中需要的视频数据进行播放。本发明还涉及一种RTP分布式流媒体服务方法。本发明在RTP协议扩展基础上，给出了完善的流媒体处理机制，指明了大规模网络情况下各种复杂情况下的传输、分发调度的实现方法，也为内容的再次调度和重新组织也提供了良好的实现机制。

Description

RTP分布式流媒体服务***及方法

技术领域

本发明涉及流媒体领域，尤其涉及一种RTP分布式流媒体服务***及方法。

背景技术

随着IPTV、网络视频等各种视频类业务的迅速发展，人们对各种视频的功能需求不断增加，流媒体***也随之不断演进，尤其作为大规模、大容量的流媒体分发***因为自身特性，不断对对流媒体数据的传输提出新的需求。对于大范围网络下组播，录制，重传，互相调度等一系列需求，现有RFC标准由于其所采用的RTP传输方式和机制，已经不能满足业务的发展要求了。

现有的大部分流媒体***中采用了RTP传输机制来完成丢包重传，快进快退的有效处理等，来适应流媒体业务中的点播，时移等需求。但是这些原有的标准RTP传输机制只能解决点到点，或者点到多点的媒体传输和服务，它只负责解决流媒体服务器或者网络设备直接到终端传输的最后这一个服务环节。而如果希望在当前IP网络基础上提供大容量、大并发的服务，并保证较好的QoS，为用户提供良好的观看体验，保证良好的音视频质量，仅仅依靠这些机制是远远不够的。

如图1所示，为现有的IPTV流媒体服务***的实际部署示意图，在图中现有的RTP传输机制只能解决图中粗实线所示部分的传输问题，而对于更加复杂，更加重要的后台传输和分发***没有考虑，如上图虚线部分所示。而随着电信级流媒体网络***，比如IPTV的发展和演进，该后台网络也日趋复杂和庞大，现有的流媒体***在内容分发，存储和调度等方面日趋困难。

发明内容

本发明的目的是提出一种RTP分布式流媒体服务***及方法，能够负责从节目的源头开始，对节目进行各种处理和分发，或者录制，并且保证处理，分发和录制的及时性、有效性，并能适应IP网络各种苛刻的网络条件，将节目数据分发到不同的地域，分发到距离用户最近的服务器为用户提供服务，并能应付各种突发事件，某些情况下，能够从不同地域重新组合节目数据，保证节目完整性。

为实现上述目的，本发明提供了一种RTP分布式流媒体服务***，包括：

流媒体节目源，用于提供流媒体形式的原始节目内容；

中心转发服务器，用于接收所述原始节目内容，并按照RTP协议对所述原始节目内容进行打包，其中RTP包的扩展包头包括该RTP包中的视频数据的位置信息及标识信息，然后将打包后的RTP流发送到网络中，供边缘节点录制和/或供终端播放；

边缘节点，用于接收网络中所述中心转发服务器转发的RTP流，并将RTP流中需要的数据录制到本地，在录制时按照所述扩展包头对视频数据进行分段和保存；

终端，用于接收网络中所述中心转发服务器转发的RTP流，并按照所述扩展包头对RTP流中需要的视频数据进行播放。

进一步地，所述中心转发服务器可以具体包括：

源接收模块，用于接收流媒体节目源提供的流媒体形式的原始节目内容；

RTP打包模块，用于按照RTP协议对所述原始节目内容进行打包，其中RTP包的扩展包头包括该RTP包中的视频数据的位置信息及标识信息；

RTP流发送模块，用于将打包后的RTP流发送到网络中，供边缘节点录制和/或供终端播放。

进一步地，所述边缘节点具体包括：

RTP流接收模块，用于接收网络中所述中心转发服务器转发的RTP流；

RTP流分析模块，用于分析所述RTP流的扩展包头中的位置信息及标识信息；

录制存储模块，用于将RTP流中需要的数据录制到本地，在录制时按照所述扩展包头对视频数据进行分段和保存。

进一步地，所述终端具体包括：

RTP流接收模块，用于接收网络中所述中心转发服务器转发的RTP流；

RTP流分析模块，用于分析所述RTP流的扩展包头中的位置信息及标识信息；

第一播放模块，用于按照所述扩展包头对RTP流中需要的视频数据进行播放。

进一步地，所述边缘节点还包括：数据重传模块，用于根据所述扩展包头检查RTP流中的视频数据存在缺失时，与周围边缘节点通信，获取存在缺失的视频数据对应的完整视频数据。

进一步地，所述边缘节点还包括：流服务模块，用于为所述终端提供视频数据服务。

进一步地，所述终端还包括：第二播放模块，用于对所述边缘节点的流服务模块提供的视频数据服务按照所述扩展包头进行播放。

为实现上述目的，本发明还提供了一种基于前述RTP分布式流媒体服务***的RTP分布式流媒体服务方法，包括：

中心转发服务器接收流媒体节目源提供的流媒体形式的原始节目内容，并按照RTP协议对所述原始节目内容进行打包，其中RTP包的扩展包头包括该RTP包中的视频数据的位置信息及标识信息；

所述中心转发服务器将打包后的RTP流发送到网络中，供边缘节点录制和/或供终端播放；

所述边缘节点接收网络中所述中心转发服务器转发的RTP流，并将RTP流中需要的数据录制到本地，在录制时按照所述扩展包头对视频数据进行分段和保存。

进一步地，在所述边缘节点录制视频数据时，如果根据所述扩展包头检查RTP流中的视频数据存在缺失，则与周围边缘节点通信，获取存在缺失的视频数据对应的完整视频数据。

进一步地，在所述边缘节点将RTP流中需要的数据录制到本地后，为所述终端提供视频数据服务。

进一步地，在所述边缘节点为所述终端提供视频数据服务之后，所述终端对所述边缘节点提供的视频数据服务按照所述扩展包头进行播放。

进一步地，还包括：所述终端接收网络中所述中心转发服务器转发的RTP流，并按照所述扩展包头对RTP流中需要的视频数据进行播放。

基于上述技术方案，本发明在RTP协议扩展的基础上，给出了完善的流媒体处理机制和方法，并通过几个实施例分别指明了大规模网络情况下，在组播、点播、录制等各种复杂情况下的传输、分发调度的实现方法，还提供了丢包重传的解决机制，从而为内容的再次调度和重新组织也提供了良好的实现机制。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为现有的IPTV流媒体服务***的实际部署示意图。

图2为本发明RTP分布式流媒体服务***的第一实施例的结构示意图。

图3为本发明RTP分布式流媒体服务***的第二实施例的结构示意图。

图4为本发明RTP分布式流媒体服务***的第三实施例的结构示意图。

图5为本发明RTP分布式流媒体服务***的第四实施例的结构示意图。

图6为本发明RTP分布式流媒体服务方法的第一实施例的流程示意图。

图7为本发明RTP分布式流媒体服务方法的第二实施例的信令示意图。

图8为本发明RTP分布式流媒体服务方法的第三实施例的信令示意图。

具体实施方式

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

本发明提供了一个有效的后台服务体系，该体系负责从节目的源头开始，对节目进行处理、分发，并提供给边缘节点进行录制，保证处理、分发和录制的及时性、有效性，以适应IP网络各种苛刻的网络条件，将节目数据分发到不同的地域，分发到距离用户最近的服务器为用户提供服务，并能应付各种突发事件，某些情况下，能够实现从不同地域重新组合节目数据以及保证节目完整性等。

本发明给出了在RFC3550规定的基础之上，以RFC3550为基础进行扩展的例子。按照RFC的规定，RTP包头可以分为两部分，第一部分是固定格式部分，第二部分是扩展部分，下面分别进行说明。

RTP包头固定格式部分如下图所示：

0                   1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V＝2|P|X|     CC      |M|     PT    |      sequence number     |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                                 timestamp                     |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|               synchronization source(SSRC)identifier          |

+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+＝+

|                contributing source(CSRC)identifiers           |

|                        ·  ·  ·  ·                         |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

该格式遵循RFC3550的规定，以下为各个字段的意义和说明：

a)version(V)

位数：2bits

意义：RTP的版本号

说明：遵循RFC3550，在RFC3550中，规定该值为2。

b)padding(P)

位数：1bit

意义：表明该RTP包后面是否有加密用的填充数据。0表示无，1表示有。

说明：无。

c)extension(X)

位数：1bit

意义：扩展标识，表明该RTP的固定格式包头后是否跟有扩展部分包头。0表示无，1表示有。

说明：本发明由于采用了扩展RTP的方式进行实现，因此在该字段中取值为1来表示。

d)CSRC count(CC)

位数：4bits

意义：CSRC的个数，表示该包头中包含的CSRC数量

说明：IPTV中，一般为0。

e)marker(M)

位数：1bit

意义：不同的profile有不同的意义，一般表示是否是帧边界

说明：IPTV中，一般为0。

f)payload type(PT)

位数：1bit

意义：RTP负荷类型

说明：当前IPTV采用H.264编码，TS流封装。但是H264编码出现的时间较晚，在原有的在RFC中并没有对应的规定，因此可以规定字段直接使用原有RFC中MPEG2的取值，该值为33。

g)sequence number

位数：16bits

意义：RTP包的序列号

说明：该值表示当前RTP包的序列号，从0开始，每次加1，到尾循环。

h)timestamp

位数：32bits

意义：RTP包传输的时间戳

说明：无

i)SSRC：32bits

位数：32bits

意义：发送流的源标识，ID

说明：无

j)CSRC list

位数：32bits为单位，可能多个

意义：流数据中间穿插者标识，0-15个

说明：IPTV服务中，一般不用。

这里介绍得RTP包头的固定格式主要是在本发明的发明构思的基础上，提供一个比较完整的技术方案，但这部分内容不应视为本发明的限制，各个字段及取值均可以根据现有RFC标准进行选择。

下面介绍与本发明更为相关的扩展格式部分，本发明按照RFC3550规定的方法对RTP包头进行了扩展，该扩展实例如下：

0                   1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| V |  FT | FP |  SP |    rev   |    length                     |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                            segment Id                         |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                            segment offset                     |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                            reserve field                      |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

a)version(V)

位数：2bits

意义：扩展格式的版本号

b)frame_type(FT)

位数：2bits

意义：帧类型指示，表明该帧的类型，指明当前RTP负荷中的视频数据是属于I帧还是P帧或者B帧。

说明：该值取值范围和意义如下下表：

取值	含义
		0	I帧
1	P帧
		2	B帧
3	预留

意义：帧类型指示，表明该帧的类型，指明当前RTP负荷中的视频数据是属于I帧还是P帧或者B帧。

c)frame_pos(FP)

位数：2bits

意义：帧位置指示，表明当前RTP包中的视频数据处于当前帧的位置，是开始还是中间，或者结尾。

说明：该值取值范围和意义如下：

取值	含义
		0	开始
1	中间
		2	结尾
3	开始和结尾(完整)

在本发明中，一个RTP包通常只包含一个帧的数据，但是一个帧可以分为多个RTP包，因此这里用FP来表示当前的RTP中的数据是当前帧的开始，还是结束，或者是中间，还是头尾都包含。

d)segment_pos(SP)

位数：2bits

意义：存储片段位置指示，表明当前RTP包中的视频数据处于当前存储片段的位置，是开始还是中间，或者结尾。

说明：该值取值范围和意义如下：

取值	含义
		0	开始
1	中间
		2	结尾
3	开始和结尾(完整)

关于存储片段的描述，请参见下面的segment_Id相关介绍。

e)reserve(rev)

位数：8bits

意义：保留字段

说明：无意义

f)length

位数：16bits

意义：该RTP包头扩展部分长度，以32bit为单位，不包括前面16个bits和length本身

说明：无

g)segment_Id

位数：32bits

意义：当前存储片段标识。

说明：当前存储片段标识号，32位无符号整数，从0开始，每个片段加一，到尾循环。

h)segment_offset

位数：32bits

意义：当前RTP包负荷数据相对于本存储片段的偏移地址。

说明：该字段主要是为了保证在进行节目录制时，如果出现了丢包，服务器仍然可以正常进行录制。如下所述：

在IP网络中传输数据，经常出现丢包，或者顺序不一致，有可能先发的RTP包后到，或者中间发送的一个RTP包出现了丢失，重传还没有完成，但是后续的RTP包已经达到了，在这种情况，后来的RTP数据也需要进行保存。这个时候，就需要为中间丢失的那些数据保留一定的磁盘空间，而segment_offset就指出了保留的位置。

该segment_offset值包含了RTP包头和TS流数据中的媒体数据大小，如果在录制时，不保存RTP包头，要进行换算才能得出实际的存储偏移量。

i)reserve field

位数：32bits

意义：保留字段。

说明：该字段主要是为了适应当前IPTV发展的实际情况，预留给厂商自己使用，不同的厂商可以自己定义这些字段，但前提是要保证遵循上述的所有规定，同时不同厂商之间的设备和***将忽略该字段。

上面对扩展RTP包头的扩展部分的实例的说明主要是在本发明的发明构思的基础上，提供一个比较完整的技术方案，但这部分内容不应视为本发明的限制，各个字段及取值均可以根据现有RFC标准进行选择，对于后面的各个具体实施方式，可能只需要上述各个字段中部分字段就可以实现，如果需要，还可以增加新的扩展字段。

下面对本发明的RTP分布式流媒体服务***进行介绍。如图2所示，为本发明RTP分布式流媒体服务***的第一实施例的结构示意图。在本实施例中，RTP分布式流媒体服务***包括：流媒体节目源1、中心转发服务器2、边缘节点3和边缘节点4和终端5。

流媒体节目源1用来提供流媒体形式的原始节目内容。中心转发服务器2能够直接接收所述原始节目内容，并按照RTP协议对所述原始节目内容进行打包，其中RTP包的扩展包头包括该RTP包中的视频数据的位置信息及标识信息，然后将打包后的RTP流发送到网络中，供边缘节点录制和/或供终端播放。边缘节点3和边缘节点4的基本功能均可以负责接收网络中所述中心转发服务器转发的RTP流，并将RTP流中需要的数据录制到本地，在录制时按照所述扩展包头对视频数据进行分段和保存。终端5用于接收网络中所述中心转发服务器2转发的RTP流，并按照所述扩展包头对RTP流中需要的视频数据进行播放。

在上述技术方案中，RTP包的扩展包头包括该RTP包中的视频数据的位置信息及标识信息，这些信息可以分别由前面介绍的FP、SP、segment_Id及segment_offset中的部分或全体来表示，也可以根据要求增加新的字段进行表示。

通过本实施例，实现了在整个分布式流媒体网络中所有接口的流数据均采用扩展包头所要求的格式进行传输和处理，从而使得在各个服务节点保证数据处理、分发和录制等操作的及时性和有效性，能够应对大规模、大容量的流媒体分发***的要求。

如图3所示，为本发明RTP分布式流媒体服务***的第二实施例的结构示意图。与上一实施例相比，本实施例给出了中心转发服务器2、边缘节点3和终端5的具体构成，边缘节点4的主要构成与边缘节点3相同，这里就不介绍了。

中心转发服务器2具体包括以下模块：源接收模块，用于接收流媒体节目源提供的流媒体形式的原始节目内容；RTP打包模块，用于按照RTP协议对所述原始节目内容进行打包，其中RTP包的扩展包头包括该RTP包中的视频数据的位置信息及标识信息；RTP流发送模块，用于将打包后的RTP流发送到网络中，供边缘节点录制和/或供终端播放。

边缘节点3可以具体包括：RTP流接收模块，用于接收网络中所述中心转发服务器转发的RTP流；RTP流分析模块，用于分析所述RTP流的扩展包头中的位置信息及标识信息；录制存储模块，用于将RTP流中需要的数据录制到本地，在录制时按照所述扩展包头对视频数据进行分段和保存。

终端5也包括与边缘节点3相同的RTP流接收模块和RTP流分析模块，还可以包括第一播放模块，用于按照所述扩展包头对RTP流中需要的视频数据进行播放，这种情况主要适用于直播。

在本实施例中，流媒体数据的传输既包括中心转发服务器2和终端5之间，也包括中心转发服务器2和边缘节点3和4之间，同时也包括边缘节点3和4互相传输，这些传输均遵循着统一的流传输机制来进行，进而完成全程全网的流媒体分发、存储和流服务。

具体到流媒体数据的分发，可以包括中心节点到边缘节点，边缘节点之间流媒体数据的分发，分发的方式既可以通过单播RTP流传输的方式，也可以通过组播RTP流的方式进行传输，这两种传输方式在运用时因为不同的特性，有具有不同的特点。组播模式用于从中心节点向各个边缘节点进行实时流媒体数据，直播节目流的分发，为各个节点的节目录制，存储进行支持，同时也可为用户提供直播服务。

如果在中心转发服务器2进行分发过程中出现了丢包情况，边缘节点3可以根据扩展包头检查是否有数据缺失问题，进而进行相应的数据重传处理，具体参见图4的实施例，边缘节点3还包括数据重传模块，用于根据所述扩展包头检查RTP流中的视频数据存在缺失时，与周围边缘节点(例如边缘节点4)通信，获取存在缺失的视频数据对应的完整视频数据。

在本实施例中，可以根据需要对边缘节点进行设计，可以在每个边缘节点中均增加数据重传模块，也可以只在一些重点的边缘节点增加数据重传模块，例如在边缘节点3加入数据重传模块，而在边缘节点4只保留上一实施例中的基本模块。发生数据缺失的边缘节点在选择作为重传源的周围边缘节点时，可以预先为边缘节点提供可选择的边缘节点列表，也可以直接指定某个边缘节点，或者由边缘节点进行周围边缘节点的搜索，再进行选择等。

如图5所示，为本发明RTP分布式流媒体服务***的第四实施例的结构示意图。与上一实施例相比，在本实施例中边缘节点还可以包括流服务模块，用于为所述终端提供视频数据服务。边缘节点将本地录制的视频数据提供给终端用户，这样就为终端5在接收直播之外，又提供了点播、回看等服务，满足了用户的多方面需求。

终端5也可以包括播放视频数据服务的第二播放模块，能够对所述边缘节点的流服务模块提供的视频数据服务按照所述扩展包头进行播放。

通过前面的几个***实施例，本发明为流媒体服务网络提供了完善的管理机制，同时也为用户提供了多方位的服务选择。

下面，本发明还给出了RTP分布式流媒体服务方法的几个实施例及流程，如图6所示，为本发明RTP分布式流媒体服务方法的第一实施例的流程示意图。该流程包括：

步骤101、中心转发服务器接收流媒体节目源提供的流媒体形式的原始节目内容；

步骤102、中心转发服务器按照RTP协议对所述原始节目内容进行打包，其中RTP包的扩展包头包括该RTP包中的视频数据的位置信息及标识信息；

步骤103、中心转发服务器将打包后的RTP流发送到网络中，供边缘节点录制和/或供终端播放；

步骤104、所述边缘节点接收网络中所述中心转发服务器转发的RTP流，并将RTP流中需要的数据录制到本地，在录制时按照所述扩展包头对视频数据进行分段和保存。

通过本发明***及基本流程，使得RTP传输能够适应在大规模、大并发的分布式流媒体***中进行各种有效的分发，存储，调度和组合，并为重传，分发提供了良好的机制，使得流媒体分发和存储成为现实，进而为流媒体业务运营商优化流媒体网络，建设高可靠性、大并发、大流量的优质网络提供了有效的机制和方法，较大的提升了用户体验。

如图7所示，为本发明RTP分布式流媒体服务方法的第二实施例的信令示意图。在本实施例中主要对数据重传进行详细说明，该信令流程包括：

1)在中心节点，流媒体节目源将原始节目内容发送到中心转发服务器。

2)中心转发服务器对原始节目内容进行RTP打包，其遵循RTP包的扩展包头的格式要求，在扩展包头包括该RTP包中的视频数据的位置信息及标识信息，然后发送到IP网络中，传送方式可以采用组播RTP流方式或者单播RTP流传输等。

3)IP网络将打包后数据发送到边缘节点B。

4)边缘节点B的分析模块对接收到的RTP流进行RTP分析，并根据RTP包头中的标识进行分段存储，并验证其数据完整性。

5)边缘节点A的分析对接收到的RTP流进行RTP分析，并根据RTP包头中的标识进行分段存储，在验证完整性时，发现缺少数据，可能是网络丢包引起的。

6)边缘节点A向周围的边缘节点(在本实施例中为边缘节点B)发送数据恢复请求，请求发送丢失的数据，因为RTP扩展头中已经包含了分段标识，RTP序号，两个节点录制的数据是一致的。

7)边缘节点B向边缘节点A返回请求的数据。

8)边缘节点A收到请求的数据，在本地录制当中将该缺失的视频数据段补充完整。

如图8所示，为本发明RTP分布式流媒体服务方法的第三实施例的信令示意图。在本实施例中主要对终端所能实现的功能进行说明，该信令流程包括：

1)在中心节点，流媒体节目源将原始节目内容发送到中心转发服务器。

2)中心转发服务器对原始节目内容进行RTP打包，其遵循RTP包的扩展包头的格式要求，在扩展包头包括该RTP包中的视频数据的位置信息及标识信息，然后发送到IP网络中，传送方式可以采用组播RTP流方式或者单播RTP流传输等。

3)IP网络将打包后数据发送到边缘节点。

4)边缘节点的分析模块对接收到的RTP流进行RTP分析，并根据RTP包头中的标识进行分段存储，并验证其数据完整性。

5)终端启动直播频道播放，并向IP网络请求相应的组播流。

6)终端侧接收到IP网络发送的组播流数据，并进行播放。

7)终端侧切换到直播的时移或者回看，并开始向提供流服务的边缘节点请求单播流。

8)边缘节点根据终端请求向终端发送相应的录制节目流。

特别说明的是，在IPTV***中，RTP负荷中包含的是TS流数据，而且一个RTP包含了多个TS包，因此可能存在一个情况，就是一个RTP包所包含的多个TS包中，有一部分是I帧的，一部分可能是B帧的。这种情况下，上述机制就不能正常工作。因此我们规定，在使用RTP包进行传输时，一个RTP包中包含的数据，只能属于一个帧，不能包含两个帧的数据。这样以来，一个帧可能会分成多个RTP包，而一个RTP中不可能含有多个帧的数据。如果一个RTP包含的数据到了帧尾，只剩下少数数据，那么该RTP包大小可以小于正常的大小值。

此外，在IPTV***中，流媒体数据不仅要发送到终端，为终端提供音视频数据流服务，也需在后台要进行录制，保存和分发，或者重新组织。那么在进行存储和分发的时候，总是需要以一段数据为单位进行组织，在这里，我们定义了一个单位-存储片段，把它作为流媒体***分发和存储的最小单位。这意味者，流媒体***的分发和存储最小只能存储和分发这样的一个单位，不能再进行更小的划分。

一个存储片段对应一个节目流中的某一时间段的全部数据，互相相邻的两个时间段，存储片段标识的差为1，也就是N，N+1。而且两段相邻的数据不能有重复，不能缺少部分流数据。

在流媒体网络中进行分发和录制时，可以在整个网络中的流媒体数据采用一致的segment_id标识，也就是说，在整个网络范围内，要保证所有节点，所有服务器，对于同一个节目的相同时间的存储片段，他们的标识都是相同的，数据也要相同。

要实现以上目的，最好在节目源头，或者节目进入IPTV流媒体网络的开始就对流媒体数据进行分片处理，打上segment_id标识，保证全网存储片段标识和数据的一致性。在进行分片处理时，可以设置一定的时间间隔，过了这个时间，就生成一个新的片段，标识的值加1。同时，为了方便处理，每个片段的都以I帧数据开始，完整帧结尾。

各个节点对存储片段进行处理时，要保证数据的完整性和一致性，不能随意更改存储片段标识，当数据不完整时，必须进行适当处理。数据的完整性可以依靠segment_pos进行判断和处理。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应当说明的是：以上实施例仅用以说明本发明的技术方案而非对其限制；尽管参照较佳实施例对本发明进行了详细的说明，所属领域的普通技术人员应当理解：依然可以对本发明的具体实施方式进行修改或者对部分技术特征进行等同替换；而不脱离本发明技术方案的精神，其均应涵盖在本发明请求保护的技术方案范围当中。

Claims (12)

1.一种RTP分布式流媒体服务***，包括：

流媒体节目源，用于提供流媒体形式的原始节目内容；

中心转发服务器，用于接收所述原始节目内容，并按照RTP协议对所述原始节目内容进行打包，其中RTP包的扩展包头包括帧类型指示、表明当前RTP包中的视频数据处于当前帧的位置的帧位置指示、表明当前RTP包中的视频数据处于当前存储片段的位置的存储片段位置指示、当前存储片段标识和当前RTP包的负荷数据相对于本存储片段的偏移地址，然后将打包后的RTP流发送到网络中，供边缘节点录制和/或供终端播放；

边缘节点，用于接收网络中所述中心转发服务器转发的RTP流，并将RTP流中需要的数据录制到本地，在录制时按照所述扩展包头对视频数据进行分段和保存；

终端，用于接收网络中所述中心转发服务器转发的RTP流，并按照所述扩展包头对RTP流中需要的视频数据进行播放。

2.根据权利要求1所述的RTP分布式流媒体服务***，其中所述中心转发服务器具体包括：

源接收模块，用于接收流媒体节目源提供的流媒体形式的原始节目内容；

RTP打包模块，用于按照RTP协议对所述原始节目内容进行打包，其中RTP包的扩展包头包括帧类型指示、表明当前RTP包中的视频数据处于当前帧的位置的帧位置指示、表明当前RTP包中的视频数据处于当前存储片段的位置的存储片段位置指示、当前存储片段标识和当前RTP包的负荷数据相对于本存储片段的偏移地址；

RTP流发送模块，用于将打包后的RTP流发送到网络中，供边缘节点录制和/或供终端播放。

3.根据权利要求1所述的RTP分布式流媒体服务***，其中所述边缘节点具体包括：

RTP流接收模块，用于接收网络中所述中心转发服务器转发的RTP流；

RTP流分析模块，用于分析所述RTP流的扩展包头中的位置信息及标识信息；

录制存储模块，用于将RTP流中需要的数据录制到本地，在录制时按照所述扩展包头对视频数据进行分段和保存。

4.根据权利要求3所述的RTP分布式流媒体服务***，其中所述终端具体包括：

RTP流接收模块，用于接收网络中所述中心转发服务器转发的RTP流；

RTP流分析模块，用于分析所述RTP流的扩展包头中的位置信息及标识信息；

第一播放模块，用于按照所述扩展包头对RTP流中需要的视频数据进行播放。

5.根据权利要求3或4所述的RTP分布式流媒体服务***，其中所述边缘节点还包括：

数据重传模块，用于根据所述扩展包头检查RTP流中的视频数据存在缺失时，与周围边缘节点通信，获取存在缺失的视频数据对应的完整视频数据。

6.根据权利要求5所述的RTP分布式流媒体服务***，其中所述边缘节点还包括：

流服务模块，用于为所述终端提供视频数据服务。

7.根据权利要求6所述的RTP分布式流媒体服务***，其中所述终端还包括：

第二播放模块，用于对所述边缘节点的流服务模块提供的视频数据服务按照所述扩展包头进行播放。

8.一种RTP分布式流媒体服务方法，包括：

中心转发服务器接收流媒体节目源提供的流媒体形式的原始节目内容，并按照RTP协议对所述原始节目内容进行打包，其中RTP包的扩展包头包括帧类型指示、表明当前RTP包中的视频数据处于当前帧的位置的帧位置指示、表明当前RTP包中的视频数据处于当前存储片段的位置的存储片段位置指示、当前存储片段标识和当前RTP包的负荷数据相对于本存储片段的偏移地址；

所述中心转发服务器将打包后的RTP流发送到网络中，供边缘节点录制和/或供终端播放；

所述边缘节点接收网络中所述中心转发服务器转发的RTP流，并将RTP流中需要的数据录制到本地，在录制时按照所述扩展包头对视频数据进行分段和保存。

9.根据权利要求8所述的RTP分布式流媒体服务方法，其中在所述边缘节点录制视频数据时，如果根据所述扩展包头检查RTP流中的视频数据存在缺失，则与周围边缘节点通信，获取存在缺失的视频数据对应的完整视频数据。

10.根据权利要求8或9所述的RTP分布式流媒体服务方法，其中在所述边缘节点将RTP流中需要的数据录制到本地后，为所述终端提供视频数据服务。

11.根据权利要求10所述的RTP分布式流媒体服务方法，其中在所述边缘节点为所述终端提供视频数据服务之后，所述终端对所述边缘节点提供的视频数据服务按照所述扩展包头进行播放。

12.根据权利要求8所述的RTP分布式流媒体服务方法，其中还包括：所述终端接收网络中所述中心转发服务器转发的RTP流，并按照所述扩展包头对RTP流中需要的视频数据进行播放。

Images