媒体流的实时递送方法及服务器

摘要

本发明公开了一种媒体流的实时递送方法及服务器，其中，方法包括：接收客户端发送的媒体段请求，其中，媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数；根据媒体段请求生成媒体段，其中，根据第一类参数确定待传送的目标媒体流，根据第二类参数确定待传送的候选媒体单元，并将待传送的候选媒体单元封装成媒体段；发送媒体段至客户端。该方法根据客户端的请求来实时生成媒体段，并返回给客户端，以实现按客户端需求分段的实时媒体流递送，从而有效降低媒体流传输延时和开销，进一步提高实时媒体流的传输性能。

权利要求

1.一种媒体流的实时递送方法，其特征在于，所述媒体流为实时产生的媒体单元的序列，其中，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，所述媒体单元由服务器产生或接收自其他装置，所述方法包括以下步骤：接收客户端发送的媒体段请求，其中，所述媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数；

根据所述媒体段请求生成媒体段，其中，根据所述第一类参数确定所述待传送的目标媒体流，根据所述第二类参数确定所述待传送的候选媒体单元，并将所述待传送的候选媒体单元封装成所述媒体段；以及发送所述媒体段至所述客户端。

2.根据权利要求1所述的媒体流的实时递送方法，其特征在于，所述根据所述媒体段请求生成媒体段，进一步包括：如果所述媒体段请求不携带所述第一类参数，则所述待传送的目标媒体流为缺省指定的媒体流；

如果所述的媒体段请求中不携带所述第二类参数，则所述候选媒体单元包括缺省指定的媒体单元，所述缺省指定的媒体单元为所述目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元，或者为所述目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元。

3.根据权利要求1所述的媒体流的实时递送方法，其特征在于，所述根据媒体段请求生成媒体段，进一步包括：如果所述媒体段请求携带至少一个所述第二类参数，其中，所述每个第二类参数对应着候选媒体单元的至少一个约束条件，则所述待传送的候选媒体单元包括所述目标媒体流中同时满足所述第二类参数对应的全部约束条件的所有媒体单元。

4.根据权利要求3所述的媒体流的实时递送方法，其特征在于，所述第二类参数包括起始序号，所述起始序号对应的约束条件为：如果所述起始序号有效，则所述候选媒体单元的序号在所述起始序号之后，或者等于所述起始序号。

5.根据权利要求3所述的媒体流的实时递送方法，其特征在于，所述第二类参数包括起始时间，所述起始时间对应的约束条件为：如果所述起始时间有效，则所述候选单元的产生时间在起始时间之后。

6.根据权利要求3所述的媒体流的实时递送方法，其特征在于，所述第二类参数包括单元个数，所述单元个数对应的约束条件为：如果所述单元个数有效，则所述的候选媒体单元的数目不超过所述单元个数；

如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则所述的候选媒体单元和最新媒体单元的序号间隔小于所述单元个数。

7.根据权利要求3所述的媒体流的实时递送方法，其特征在于，所述第二类参数包括分段时长，所述分段时长对应的约束条件为：如果所述分段时长有效，则所述的候选媒体单元中最早产生的单元和最晚产生的单元的产生时间间隔小于所述分段时长；

如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则所述的候选媒体单元和最新媒体单元的产生时间间隔小于所述分段时长。

8.根据权利要求1所述的媒体流的实时递送方法，其特征在于，所述第一类参数包括媒体流标识，以指定所述待传送的目标媒体流。

9.根据权利要求8所述的媒体流的实时递送方法，其特征在于，所述将所述待传送的候选媒体单元封装成所述媒体段，进一步包括：获取媒体流索引信息，并将所述媒体流索引信息封装到所述媒体段中，其中，所述的媒体流索引信息包含属于同一个内容的多个媒体流描述信息，所述的媒体流描述信息包括媒体流标识和媒体流比特率。

10.一种媒体流的实时递送服务器，其特征在于，所述媒体流为实时产生的媒体单元的序列，其中，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，所述媒体单元由服务器产生或接收自其他装置，所述服务器包括：客户端接口组件，用于接收客户端发送的媒体段请求并返回相应的媒体段，其中，所述媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数；

媒体段生成组件，根据所述媒体段请求生成媒体段，其中，根据所述第一类参数确定所述待传送的目标媒体流，根据所述第二类参数确定所述待传送的候选媒体单元，并将所述待传送的候选媒体单元封装成所述媒体段，并通过所述客户端接口组件发送所述媒体段至所述客户端。

11.根据权利要求10所述的媒体流的实时递送服务器，其特征在于，所述媒体段生成组件进一步用于在所述媒体段请求不携带所述第一类参数时，所述待传送的目标媒体流为缺省指定的媒体流，并在所述的媒体段请求中不携带所述第二类参数时，所述候选媒体单元包括缺省指定的媒体单元，所述缺省指定的媒体单元为所述目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元，或者为所述目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元。

12.根据权利要求10所述的媒体流的实时递送服务器，其特征在于，所述的媒体段生成组件进一步用于在所述的媒体段请求中携带至少一个所述第二类参数时，其中，所述每个第二类参数对应着候选媒体单元的至少一个约束条件，所述待传送的候选媒体单元包括所述目标媒体流中同时满足所述第二类参数对应的全部约束条件的所有媒体单元。

13.根据权利要求12所述的媒体流的实时递送服务器，其特征在于，所述第二类参数包括起始序号，所述起始序号对应的约束条件为：如果所述起始序号有效，则所述候选媒体单元的序号在所述起始序号之后，或者等于所述起始序号。

14.根据权利要求12所述的媒体流的实时递送服务器，其特征在于，所述第二类参数包括起始时间，所述起始时间对应的约束条件为：如果所述起始时间有效，则所述候选单元的产生时间在起始时间之后。

15.根据权利要求12所述的媒体流的实时递送服务器，其特征在于，所述第二类参数包括所述单元个数，所述单元个数对应的约束条件为：如果所述单元个数有效，则所述的候选媒体单元的数目不超过所述单元个数；

如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则所述的候选媒体单元和最新媒体单元的序号间隔小于所述单元个数。

16.根据权利要求12所述的媒体流的实时递送服务器，其特征在于，所述第二类参数包括分段时长，所述分段时长对应的约束条件为：如果所述分段时长有效，则所述的候选媒体单元中最早产生的单元和最晚产生的单元的产生时间间隔小于所述分段时长；

如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则所述的候选媒体单元和最新媒体单元的产生时间间隔小于所述分段时长。

17.根据权利要求10所述的媒体流的实时递送服务器，其特征在于，所述第一类参数包括媒体流标识，以指定所述待传送的目标媒体流。

18.根据权利要求17所述的媒体流的实时递送服务器，其特征在于，所述媒体段生成组件进一步用于获取媒体流索引信息，并将所述媒体流索引信息封装到所述媒体段中，其中，所述的媒体流索引信息包含属于同一个内容的多个媒体流描述信息，所述的媒体流描述信息包括媒体流标识和媒体流比特率。

19.根据权利要求10所述的媒体流的实时递送服务器，其特征在于，还包括：

至少一个实时媒体流生成组件，用于自行产生或接收来自其他装置的一个或多个实时媒体流。

20.一种计算机设备，其特征在于，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时，实现如权利要求1-9中任一所述的方法。

21.一种非临时性计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-9中任一所述的方法。

说明书

媒体流的实时递送方法及服务器

技术领域

[0001] 本发明涉及数字信息传送技术领域，特别涉及一种媒体流的实时递送方法及服务器。

背景技术

[0002] 随着互联网特别是移动互联网的快速发展，通过互联网来实时传送音频、视频、图像等多媒体数据成为许多应用的基本需求，为满足这一需求，人们提出了各种流媒体实时传输技术，目前得到广泛使用的主要包括三类：实时传送协议(RTP(Real-time Transport Protocol，实时传输协议)/RTSP(Real Time Streaming Protocol，实时流传输协议))、RTMP(Real Time Messaging Protocol，实时消息传送协议)和HTTP(HyperText Transfer Protocol，超文本传输协议)自适应性流传输HAS(HTTP Adaptive Streaming)。其中，HTTP自适应流传输又包括多种方案：苹果公司提出的HLS(HTTP Live Streaming)、微软提出的平滑流Smooth Streaming、Adobe提出的HDS(HTTP Dynamic Streaming)、MPEG组织提出的DASH(Dynamic Adaptive Streaming over HTTP，基于HTTP的动态自适应流)。

[0003] 这些HTTP自适应性流传输方案的共同特点是将媒体流切割成短时间(2s～10s)的媒体片段，并同时生成描述这些媒体片段的索引文件或清单文件(例如HLS中的m3u8播放列表和DASH中的MPD文件)，然后将其保存到各Web服务器上，客户端通过访问播放列表或清单文件，获得这些媒体片段的URL(Uniform Resource Locator，统一资源定位符)访问地址，然后可以采用标准的HTTP协议来逐个下载这些媒体片段并进行播放。这些方案的主要区别体现在媒体片段采用的封装格式和清单文件格式的不同。

[0004] 相对于RTP/RTSP和RTMP来说，HTTP自适应流传输可以充分利用现有的互联网Web缓存设施(如CDN和各种Web缓存服务器)，可以支持大规模的用户访问。同时，通过提供多种码率的媒体片段，还可以支持客户端根据网络条件和终端能力来自行选择合适码率的片段，实现码率自适应。因此，HTTP自适应流传输已成为目前互联网上实时流媒体递送的主流方式。

[0005] 但是，上述的这些HTTP自适应流传输方案均存在两个问题：

[0006] 问题1，媒体片段的时长无法适应动态变化的网络传输。目前的HAS方案均采用预分段的方式，即服务器按照预先设置的时长来生成媒体片段及其清单文件并提交给web服务器。当网络传输带宽充足且延时较小时，设置较大的片段时长意味着增加实时传送的延时；当网络传输带宽不足且延时较大时，设置较小的片段时长意味着频繁的文件请求，增加服务器的负担和网络传输开销。由于互联网上的传输带宽和传输延时是动态变化的，采用固定时长的预分段方式无法实现最优传输。

[0007] 问题2，清单文件增加了传送延时和开销。客户端需要先得到清单文件，才能获得媒体片段的URL地址。但是由于清单文件需要经过一段时间才能传输给客户端，因此，客户端得到的清单文件并不能反映当前最新的媒体片段的生成情况，此外，当清单文件遇到阻塞或者传输出错时，将阻塞用户对媒体片段的快速访问，降低实时流媒体的传送性能。

发明内容

[0008] 本发明旨在至少在一定程度上解决相关技术中的技术问题之一。

[0009] 为此，本发明的第一个目的在于提出一种媒体流的实时递送方法，该方法可以有效降低媒体流传输延时和开销，进一步提高实时媒体流的传输性能。

[0010] 本发明的第二个目的在于提出一种媒体流的实时递送服务器。

[0011] 本发明的第三个目的在于提出一种计算机设备。

[0012] 本发明的第四个目的在于提出一种非临时性计算机可读存储介质。

[0013] 本发明的第五个目的在于提出一种计算机程序产品。

[0014] 为达到上述目的，本发明第一方面实施例提出了一种媒体流的实时递送方法，所述媒体流为实时产生的媒体单元的序列，其中，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，所述方法包括以下步骤：接收客户端发送的媒体段请求，其中，所述媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数；根据所述媒体段请求生成媒体段，其中，根据所述第一类参数确定所述待传送的目标媒体流，根据所述第二类参数确定所述待传送的候选媒体单元，并将所述待传送的候选媒体单元封装成所述媒体段；发送所述媒体段至所述客户端。

[0015] 本发明实施例的媒体流的实时递送方法，根据客户端的请求来实时生成媒体段，并返回给客户端，以实现按客户端需求分段的实时媒体流递送，媒体分段的时长将自动适应网络传输带宽的变化，客户端可以通过主动请求来控制媒体分段的时长，由于每个媒体段是由客户端的请求触发产生的，不再需要清单文件，客户端也不需要请求和解析清单文件，一方面客户端可以更快速的获得最新的媒体流，减少了实时媒体流的传输延时，另一方面，也降低了清单文件带来的传输开销和处理开销，从而有效降低媒体流传输延时和开销，进一步提高实时媒体流的传输性能。

[0016] 另外，根据本发明上述实施例的媒体流的实时递送方法还可以具有以下附加的技术特征：

[0017] 进一步地，在本发明的一个实施例中，所述根据所述媒体段请求生成媒体段，进一步包括：如果所述媒体段请求不携带所述第一类参数，则所述待传送的目标媒体流为缺省指定的媒体流；如果所述的媒体段请求中不携带所述第二类参数，则所述候选媒体单元包括缺省指定的媒体单元，所述缺省指定的媒体单元为所述目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元，或者为所述目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元。

[0018] 进一步地，在本发明的一个实施例中，如果所述的媒体段请求携带至少一个所述第二类参数，其中，所述每个第二类参数对应着候选媒体单元的至少一个约束条件，则所述待传送的候选媒体单元包括所述目标媒体流中同时满足所述第二类参数对应的全部约束条件的所有媒体单元。

[0019] 进一步地，在本发明的一个实施例中，所述第二类参数包括起始序号，所述起始序号对应的约束条件为：如果所述起始序号有效，则所述候选媒体单元的序号在所述起始序号之后，或者等于所述起始序号。

[0020] 进一步地，在本发明的一个实施例中，所述第二类参数包括起始时间，所述起始时间对应的约束条件为：如果所述起始时间有效，则所述候选单元的产生时间在起始时间之后。

[0021] 进一步地，在本发明的一个实施例中，所述第二类参数包括单元个数，所述单元个数对应的约束条件为：如果所述单元个数有效，则所述的候选媒体单元的数目不超过所述单元个数；进一步，如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则所述的候选媒体单元和最新媒体单元的序号间隔小于所述单元个数。

[0022] 进一步地，在本发明的一个实施例中，所述第二类参数包括分段时长，所述分段时长对应的约束条件为：如果所述分段时长有效，则所述的候选媒体单元中最早产生的单元和最晚产生的单元的产生时间间隔小于所述分段时长；进一步，如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则所述的候选媒体单元和最新媒体单元的产生时间间隔小于所述分段时长。

[0023] 进一步地，在本发明的一个实施例中，所述第一类参数包括媒体流标识，以指定所述待传送的目标媒体流。

[0024] 进一步地，在本发明的一个实施例中，所述将所述待传送的候选媒体单元封装成所述媒体段，进一步包括：获取媒体流索引信息，并将所述媒体流索引信息封装到所述媒体段中，其中，所述的媒体流索引信息包含属于同一个内容的多个媒体流描述信息，所述的媒体流描述信息包括媒体流标识和媒体流比特率。

[0025] 为达到上述目的，本发明第二方面实施例提出了一种媒体流的实时递送服务器，所述媒体流为实时产生的媒体单元的序列，其中，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，所述服务器包括：客户端接口组件，用于接收客户端发送的媒体段请求并返回相应的媒体段，其中，所述媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数；媒体段生成组件，根据所述媒体段请求生成媒体段，其中，根据所述第一类参数确定所述待传送的目标媒体流，根据所述第二类参数确定所述待传送的候选媒体单元，并将所述待传送的候选媒体单元封装成所述媒体段，并通过所述客户端接口组件发送所述媒体段至所述客户端。

[0026] 本发明实施例的媒体流的实时递送服务器，根据客户端的请求来实时生成媒体段，并返回给客户端，以实现按客户端需求分段的实时媒体流递送，媒体分段的时长将自动适应网络传输带宽的变化，客户端可以通过主动请求来控制媒体分段的时长，由于每个媒体段是由客户端的请求触发产生的，不再需要清单文件，客户端也不需要请求和解析清单文件，一方面客户端可以更快速的获得最新的媒体流，减少了实时媒体流的传输延时，另一方面，也降低了清单文件带来的传输开销和处理开销，从而有效降低媒体流传输延时和开销，进一步提高实时媒体流的传输性能。

[0027] 另外，根据本发明上述实施例的媒体流的实时递送服务器还可以具有以下附加的技术特征：

[0028] 进一步地，在本发明的一个实施例中，所述媒体段生成组件进一步用于在所述媒体段请求不携带所述第一类参数时，所述待传送的目标媒体流为缺省指定的媒体流，并在所述的媒体段请求中不携带所述第二类参数时，所述候选媒体单元包括缺省指定的媒体单元，所述缺省指定的媒体单元为所述目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元，或者为所述目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元。

[0029] 进一步地，在本发明的一个实施例中，如果所述的媒体段请求携带至少一个所述第二类参数，其中，所述每个第二类参数对应着候选媒体单元的至少一个约束条件，则所述待传送的候选媒体单元包括所述目标媒体流中同时满足所述第二类参数对应的全部约束条件的所有媒体单元。

[0030] 进一步地，在本发明的一个实施例中，所述第二类参数包括起始序号，所述起始序号对应的约束条件为：如果所述起始序号有效，则所述候选媒体单元的序号在所述起始序号之后，或者等于所述起始序号。

[0031] 进一步地，在本发明的一个实施例中，所述第二类参数包括起始时间，所述起始时间对应的约束条件为：如果所述起始时间有效，则所述候选单元的产生时间在起始时间之后。

[0032] 进一步地，在本发明的一个实施例中，所述第二类参数包括单元个数，所述单元个数对应的约束条件为：如果所述单元个数有效，则所述的候选媒体单元的数目不超过所述单元个数；进一步，如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则所述的候选媒体单元和最新媒体单元的序号间隔小于所述单元个数。

[0033] 进一步地，在本发明的一个实施例中，所述第二类参数包括分段时长，所述分段时长对应的约束条件为：如果所述分段时长有效，则所述的候选媒体单元中最早产生的单元和最晚产生的单元的产生时间间隔小于所述分段时长；进一步，如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则所述的候选媒体单元和最新媒体单元的产生时间间隔小于所述分段时长。

[0034] 进一步地，在本发明的一个实施例中，所述第一类参数包括媒体流标识，以指定所述待传送的目标媒体流。

[0035] 进一步地，在本发明的一个实施例中，所述媒体段生成组件进一步用于获取媒体流索引信息，并将所述媒体流索引信息封装到所述媒体段中，其中，所述的媒体流索引信息包含属于同一个内容的多个媒体流描述信息，所述的媒体流描述信息包括媒体流标识和媒体流比特率。

[0036] 进一步地，在本发明的一个实施例中，还包括：至少一个实时媒体流生成组件，用于自行产生或接收来自其他装置的一个或多个实时媒体流。

[0037] 为达到上述目的，本发明第三方面实施例提出了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时，实现如上述实施例描述的媒体流的实时递送方法。

[0038] 为达到上述目的，本发明第四方面实施例提出了一种非临时性计算机可读存储介质，该程序被处理器执行时实现如上述实施例描述的媒体流的实时递送方法。

[0039] 为达到上述目的，本发明第五方面实施例提出了一种计算机程序产品，当所述计算机程序产品中的指令由处理器执行时，执行如上述实施例描述的媒体流的实时递送方法。

[0040] 本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

[0041] 本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

[0042] 图1为根据本发明一个实施例的媒体流的实时递送方法的流程图；

[0043] 图2为根据本发明一个实施例的客户端连续提交媒体段请求的实时传送过程示意图；

[0044] 图3为根据本发明一个实施例的媒体流的实时递送服务器的结构示意图；

[0045] 图4为根据本发明一个具体实施例的媒体流的实时递送服务器的结构示意图。

具体实施方式

[0046] 下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本发明，而不能理解为对本发明的限制。

[0047] 在互联网中，经常需要将各种实时产生的音频流、视频流或数据流从一个网络节点传送到另一个网络节点，这些网络节点既包括各种终端，如PC、手机、平板，也包括各种应用服务器，如视频服务器、音频服务器，将传送的这些音频流、视频流或数据流统称为媒体流。媒体流的传送过程可以用通用的客户端－服务器模型来描述：实时产生的媒体流由服务器递送给客户端。这里的服务器和客户端指的是逻辑上的功能实体，其中，服务器为发送媒体流的功能实体，客户端为接收媒体流的功能实体。服务器和客户端可存在于任何网络节点上。

[0048] 每个传送的媒体流是一个实时产生的媒体单元的序列。不同的媒体流，其对应的媒体单元可以自行选择。当媒体流是一个实时产生的字节流时，可以选取一个字节为媒体单元；当媒体流是一个经过实时采样获得的音频流或视频流时，可以选取原始的音频帧或视频帧为媒体单元；当媒体流是一个经过实时采样和编码的音频流或视频流时，可以选择编码后的音频帧、编码后的视频帧或访问单元(Access Unit)为媒体单元；当媒体流是一个经过实时采样、编码和封装的音频流或视频流时，可以选择封装后的传输包(如RTP包，PES/PS/TS包等)为媒体单元；当媒体流是一个经过实时采样、编码、封装和预分段的音频流或视频流时，可以选择一个已分割的媒体片段(如HLS协议中使用的TS格式片段、DASH协议中使用的fMP4格式片段)为媒体单元。

[0049] 每个媒体单元可以关联一个产生时间，该产生时间通常为一个时间戳。每个媒体单元还可以关联一个序号，该序号可以用来表示媒体单元产生的顺序。当序号用来表示媒体单元产生的顺序时，序号的意义需要根据具体的媒体单元来定义。当媒体单元为一个字节时，媒体单元的序号为字节序号；当媒体单元为音频帧、视频帧时，媒体单元的序号为帧序号；当媒体单元为一个传输包时，媒体单元的序号为包序号；当媒体单元为一个流片段时，媒体单元的序号为片段序号(如HLS中每个TS片段的Media Sequence)。

[0050] 对于一个媒体流来说，可以同时关联一个表示产生顺序的序号和一个产生时间，比如，当实时媒体流为一个RTP包流时，RTP头部既有包序号(Sequence Number)字段来指示RTP包的顺序，又有Timestramp字段来指示RTP中封装的媒体数据的产生时间。在此情况下，多个连续的RTP包可能对应相同的产生时间，但是其序号则是唯一的。

[0051] 本发明实施例的方法可以针对任何一种实时媒体流来实施。在下面的实施例当中，本发明实施例将分别选择RTP实时媒体流或MPEG2-TS实时媒体流来阐述本发明实施例的实施方法。对于RTP实时流来说，媒体单元为一个RTP包，选择RTP的包序号(SequenceNumber)为媒体单元的序号，RTP包的包序号为一个16位字段，最大值为65535，对于连续产生的RTP包，其序号是循环计数的，如果当前包序号为Seq，则下一个包的序号为(Seq+1)％65536，因此，序号在实现上受制于其位长，可能出现序号大小无法反映其先后顺序的情况，此时，可通过媒体单元的产生时间来判断序号是否出现循环计数，以准确判断两个媒体单元的序号的先后关系及其间隔。对于MPEG2-TS实时流来说，可以采用类似于HLS/DASH的方式，将TS流分割成固定时长比如1秒左右的TS片段，每个TS片段可包括多个媒体帧，然后将这些片段按产生顺序编上序号，作为媒体单元，每个片段中包含的第一个媒体帧的时间戳指明了该片段的产生时间。

[0052] 在传统的实时流媒体协议如RTP或RTMP中，采用的是服务器推送的方式：服务器上一旦有新的媒体单元，则主动发送给客户端。本发明实施例的方法则与各种HTTP自适应流(如HLS、平滑流，MPEG-DASH)类似，采用客户端拉取的方式，但是不同点在于，现有的各种HTTP自适应流中，客户端都是根据清单文件来请求或拉取已分割好的片段，每个片段可以通过一个URL来标识，而在本发明实施例中，媒体段不是预先分割好的，而是服务器根据客户端的请求即时生成的，客户端可以控制媒体段的内容及时长。

[0053] 下面参照附图描述根据本发明实施例提出的媒体流的实时递送方法及服务器，首先将参照附图描述根据本发明实施例提出的媒体流的实时递送方法。

[0054] 图1是本发明一个实施例的媒体流的实时递送方法的流程图。

[0055] 如图1所示，该媒体流的实时递送方法，媒体流为实时产生的媒体单元的序列，其中，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，方法包括以下步骤：

[0056] 在步骤S101中，接收客户端发送的媒体段请求，其中，媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数。

[0057] 具体而言，媒体段请求可以不携带任何第一类参数和第二类参数，可以根据进一步实施的需要来定义新的参数，例如，可以作为第一类参数的控制参数包括：媒体流标识、媒体流名称等；可以作为第二类参数的控制参数包括：起始序号、起始时间、单元个数，分段时长等。

[0058] 媒体段请求可以采用任何协议来提交，比如常见的HTTP协议、TCP协议、UDP协议等。当采用HTTP协议提交媒体段请求时，也可以采用HTTP-GET方式或者HTTP-POST方式。

[0059] 当媒体段请求中携带控制参数时，控制参数需要采用一定的方式封装成字符串或字节流，发送给服务器。例如，当采用HTTP-GET来发送媒体段请求时，控制参数可以作为字符串封装到URL中。采用HTTP-GET的媒体段请求的示例如下：

[0060] 不携带控制参数的媒体段请求：

[0061] GET“http://www.xxx-server.com/msreq”[req1]

[0062] 携带一个控制参数的媒体段请求：

[0063] GET“http://www.xxx-server.com/msreq？streamID＝601”[req2]

[0064] GET“http://www.xxx-server.com/msreq？seqBegin＝1005”[req3][0065] GET“http://www.xxx-server.com/msreq？timeBegin＝31000”[req4][0066] GET“http://www.xxx-server.com/msreq？unitCount＝8”[req5]

[0067] GET“http://www.xxx-server.com/msreq？segDuration＝1000”[req6][0068] 携带两个控制参数的媒体段请求：

[0069] GET“http://www.xxx-server.com/msreq？streamID＝602&seqBegin＝1020”[req7]

[0070] GET“http://www.xxx-server.com/msreq？streamID＝601&timeBegin＝32000”[req8]

[0071] GET“http://www.xxx-server.com/msreq？seqBegin＝1010&unitCount＝5”[req9]

[0072] GET“http://www.xxx-server.com/msreq？timeBegin＝31000&segDuration＝3000”[req10]

[0073] 携带三个控制参数的媒体段请求：

[0074] GET“http://www.xxx-server.com/msreq？streamID＝601&seqBegin＝1010&unitCount＝5”[req11]

[0075] GET“http://www.xxx-server.com/msreq？streamID＝601&timeBegin＝33000&segDuration＝3000”[req12]

[0076] 上述请求的URL中，参数名streamID、seqBegin、timeBegin、unitCount、segDuration分别代表媒体流标识、起始序号、起始时间、单元个数、分段时长。

[0077] 服务器端可以采用Web服务器来接收上述客户端的媒体段请求，并从请求的URL中提取出相应的控制参数，并对控制参数进行分类：如果是媒体流标识，则该参数为第一类参数；如果为起始序号、起始时间、单元个数、分段时长，则为第二类参数。

[0078] 在步骤S102中，根据媒体段请求生成媒体段，其中，根据第一类参数确定待传送的目标媒体流，根据第二类参数确定待传送的候选媒体单元，并将待传送的候选媒体单元封装成媒体段。

[0079] 具体而言，服务器接收到媒体段请求后，可获取媒体段请求中携带的控制参数，然后可以根据其中的第一类参数来确定待传送的目标媒体流，根据携带的第二类参数来确定待传送的候选媒体单元，最后将待传送的候选媒体单元封装成媒体段。其中，可以采用自定义的封装协议将一个或多个媒体单元封装成媒体段，例如一个简单的封装协议如下：媒体段由段头和段净荷组成，段净荷由若干个媒体单元级联而成，段头中则指示每个媒体单元的起始位置和长度。

[0080] 在步骤S103中，发送媒体段至客户端。

[0081] 具体而言，服务器可以根据客户端的媒体段请求所使用的协议来选择适当的方式将媒体段发送给客户端，例如当接收的媒体段请求采用HTTP GET方式时，可以通过HTTP GET响应消息来发送生成的媒体段：将媒体段放入到HTTP响应消息的实体主体中。

[0082] 当服务器接收到来自客户端的连续的媒体段请求时，服务器将根据客户端的请求来不断生成新的媒体段，这些新的媒体段中封装了最近产生的若干媒体单元，客户端解析这些媒体段，即可恢复出实时媒体流的各媒体单元，实现了媒体流从服务器到客户端的实时传送，这一过程如图2所示。

[0083] 由于采用了即时生成媒体段的方式，本发明实施例的方法不再需要清单文件，从而降低传输延时和节省开销。此外，客户端可以自行调整发送请求的频率来控制媒体段的时长，以更好的适应网络带宽的变化。

[0084] 应理解，步骤S101和步骤S103的设置仅为了描述的方便，而不用于限制方法的执行顺序。

[0085] 上述是对实施例1的详细阐述，下面将对实施例2进行详细说明，以下实施例中，将对服务器如何根据媒体段请求来生成媒体段做出说明。

[0086] 进一步地，在本发明的一个实施例中，根据媒体段请求生成媒体段，进一步包括：如果媒体段请求不携带第一类参数，则待传送的目标媒体流为缺省指定的媒体流；如果媒体段请求中不携带第二类参数，则候选媒体单元包括缺省指定的媒体单元，缺省指定的媒体单元为目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元，或者为目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元。

[0087] 以RTP实时流为例，媒体单元为一个RTP包，每个RTP包都携带一个包序号。假定最新产生的RTP包的包序号为1020，第一预设值为20，当服务器收到一个不携带任何参数的媒体段请求时如[req1]，服务器可从现有的实时媒体流中选择一个作为目标媒体流，则待发送的候选媒体单元包括目标媒体流中最近产生的20个RTP包(包序号从1001到1020)。

[0088] 以TS实时流为例，媒体单元为一个TS片段，每个TS片段都关联了一个产生时间，该产生时间为该TS片段中第一个媒体帧的时间戳。假定最新产生的TS片段的产生时间为33000(单位是微秒)，第二预设值为3000，当服务器收到一个不携带任何参数的媒体段请求时如[req1]，服务器可从现有的实时媒体流中选择一个作为目标媒体流，则待发送的候选媒体单元包括目标媒体流中最近3秒产生的TS片段，即产生时间Tp在范围(3000033000)内的TS片段。

[0089] 采用上述实施方式，每次用户发送的媒体段请求都会返回最近产生的若干个媒体单元。当服务器持续接受到媒体段请求后，会持续将最近产生的媒体单元递送给客户端。

[0090] 实施例3，以下实施例中，将对服务器如何根据第二类参数来确定待传送的候选媒体单元进行说明。

[0091] 进一步地，在本发明的一个实施例中，如果的媒体段请求携带至少一个第二类参数，其中，每个第二类参数对应着候选媒体单元的至少一个约束条件，则待传送的候选媒体单元包括目标媒体流中同时满足第二类参数对应的全部约束条件的所有媒体单元。

[0092] 下面将进一步给出四种第二类参数，以及每种第二类参数对应的约束条件，具体实施时可以根据需要采用其中的一种或多种，也并不限定自行定义其他的第二类参数：

[0093] 1)起始序号

[0094] 起始序号对应的约束条件为：如果起始序号有效，则候选媒体单元的序号在起始序号之后，或者等于起始序号。

[0095] 2)起始时间

[0096] 起始时间对应的约束条件为：如果起始时间有效，则候选单元的产生时间在起始时间之后。

[0097] 3)单元个数

[0098] 单元个数对应的约束条件为：如果单元个数有效，则的候选媒体单元的数目不超过单元个数；进一步，如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则的候选媒体单元和最新媒体单元的序号间隔小于单元个数。

[0099] 4)分段时长

[0100] 分段时长对应的约束条件为：如果分段时长有效，则的候选媒体单元中最早产生的单元和最晚产生的单元的产生时间间隔小于分段时长；

[0101] 上述的第二类参数有效和无效指的是参数的值是否在一个指定的范围内。以起始序号为例，该起始序号的值不能超过当前最新媒体单元的序号，另一方面，为保证实时性，起始序号的值不能是早于某个现有媒体单元的序号，在上述范围内的起始序号即为有效。如果某个第二类参数为无效，则等同于不携带这个第二类参数。当所有第二类参数均无效时，待传送的候选媒体单元为缺省指定的媒体单元。

[0102] 以RTP实时流为例，媒体单元为一个RTP包，每个RTP包都携带一个包序号。假定最新产生的RTP包的包序号为1020，服务器接收到如下媒体段请求时：

[0103] 1)GET“http://www.xxx-server.com/msreq？seqBegin＝1005”[req3][0104] 该请求只携带了一个第二类参数：起始序号，满足该起始序号对应的约束条件的RTP有16个(包序号从1005到1020)，则待发送的候选媒体单元包括这16个RTP包；

[0105] 2)GET“http://www.xxx-server.com/msreq？unitCount＝8”[req5][0106] 该请求只携带一个第二类参数：单元个数，由于没有其他第二类参数指示出媒体单元的范围，则候选媒体单元的序号和最新媒体单元的序号应小于8，即待发送的候选单元包括8个RTP包(包序号从1013到1020)；

[0107] 3)GET“http://www.xxx-server.com/msreq？seqBegin＝1010&unitCount＝5”[req9]

[0108] 该请求携带了两个第二类参数：起始序号和单元个数，候选单元需要满足两个约束条件，第一个约束条件是候选媒体单元的序号应大于等于1010，满足该约束条件的候选媒体单元共有11个(包序号从1010到1020)，第二个条件是候选媒体单元数目应不超过5。从满足第一个约束条件的候选媒体单元中任意选出5个即可，具体实现时，可自行指定一种选取规则，如选取序号排前的5个符合约束条件的个媒体单元(包序号从1010到1014)作为待发送的候选单元。

[0109] 以TS实时流为例，媒体单元为一个TS片段，每个TS片段都关联了一个产生时间，该产生时间为该TS片段中第一个媒体帧的时间戳。假定最新产生的TS片段的产生时间为33000(单位是微秒)服务器接收到如下媒体段请求时：

[0110] 1)GET“http://www.xxx-server.com/msreq？timeBegin＝31000”[req4][0111] 该请求只携带了一个第二类参数：起始时间，该起始序号对应的约束条件是TS片段的产生时间应在起始时间之后，则候选媒体单元包括产生时间Tp在范围(31000

[0112] 2)GET“http://www.xxx-server.com/msreq？segDuration＝1000”[req6][0113] 该请求只携带了一个第二类参数：分段时长。由于没有其他第二类参数指示出媒体单元的范围，因此，候选媒体单元满足的约束条件为：候选媒体单元与最新媒体单元的产生时间间隔小于1000，即候选媒体单元包括产生时间Tp范围(32000

[0114] 3)GET“http://www.xxx-server.com/msreq？timeBegin＝31000&segDuration＝3000”[req9]

[0115] 该请求携带了两个第二类参数：起始时间和分段时长。其中，起始时间对应的约束条件是TS片段的产生时间应大于31000，则候选媒体单元包括产生时间Tp在范围(31000

[0116] 该实施例中，客户端可以通过连续提交媒体段请求，并通过携带的第二类参数如起始序号或起始时间，即可获得最近产生的媒体单元，实现媒体流的实时传送，图2给出了通过连续提交带起始序号的媒体段请求来实现媒体流的实时传送过程的示意图。此外，客户端还可以通过单元个数和分段时长来控制所产生的媒体段的内容和时长。

[0117] 实施例4，在以下实施例中，将对服务器在生成媒体段时如何确定目标媒体流进行说明。

[0118] 进一步地，在本发明的一个实施例中，第一类参数包括媒体流标识，以指定待传送的目标媒体流。

[0119] 可以理解的是，第一类参数包括媒体流标识，确定待传送的目标媒体流包括：当媒体段请求中携带的第一类参数只包括媒体流标识时，目标媒体流由媒体流标识所指定。

[0120] 具体而言，当服务器上存在多个实时媒体流时，服务器可以给每个实时媒体流分配一个标识，以区分不同的实时媒体流，并指定其中的一个为缺省的目标媒体流；如果服务器上只存在一个实时媒体流时，该媒体流即为缺省的目标媒体流。

[0121] 当接收的媒体段请求中不携带任何第一类参数时(如实施例1中列举的媒体段请求req1,req3～req6,req9～req10)，将缺省的目标媒体流发送给客户端；当接收的媒体段请求携带的第一类参数中包含媒体流标识时(如实施例1中列举的媒体段请求req2,req7～req8,req11～req12)，则目标媒体流为该媒体流标识所对应的实时媒体流。

[0122] 实施例5，以下实施例中，将对多码率自适应的实时媒体流递送进行说明。

[0123] 进一步地，在本发明的一个实施例中，将待传送的候选媒体单元封装成媒体段，进一步包括：获取媒体流索引信息，并将媒体流索引信息封装到媒体段中，其中，媒体流索引信息包含属于同一个内容的多个媒体流描述信息，媒体流描述信息包括媒体流标识和媒体流比特率。

[0124] 举例而言，当服务器中存在属于同一个内容的多个实时媒体流时，可以通过不同的媒体流标识来区分这些实时流，并建立起该内容的媒体流索引信息；这个媒体流索引信息实际上包括了媒体流标识和媒体流比特率的映射关系。如表1所示，显示了同一个内容(比如一个现场演唱会直播)对应的媒体流索引信息：该内容包括了三个实时媒体流，其中媒体流1(标识为1000，码率为8Mbps)为高清码流，媒体流2(标识为1001，码率为2Mbps)为标清码流，媒体流3(标识为1002，码率为500Kbps)为移动标清流。

[0125] 表1

[0126] 媒体流标识 媒体流码率601 8000Kbps
602 2000Kbps
603 500Kbps

[0127] 当客户端请求媒体流标识为601的实时流时，服务器通过查询媒体流索引表，发现存在来自同一个内容源的媒体流2和媒体流3，此时，服务器可将上述媒体流索引信息作为一个控制消息，和其他媒体单元一起封装到媒体段中.

[0128] 客户端可根据媒体流索引信息，根据网络传输情况从属于同一个内容的多个媒体流中选择请求的目标。一般来说，由于媒体流索引信息在一段较长时间内保持不变，所以没有必要在每个媒体段中都封装该媒体流索引信息，可以将媒体流索引信息封装到间隔选定的媒体段中，或者封装给发送给客户端的前几个媒体段中。

[0129] 根据本发明实施例提出的媒体流的实时递送方法，根据客户端的请求来实时生成媒体段，并返回给客户端，以实现按客户端需求分段的实时媒体流递送，媒体分段的时长将自动适应网络传输带宽的变化，客户端可以通过主动请求来控制媒体分段的时长，当客户端与服务器之间的传输带宽充足且延时较小时，客户端可以更快速的提出请求，从而得到时长更短的媒体段，降低实时传输延时；当客户端与服务器之间的传输带宽不足且延时较大时，客户端可以延长提交请求的间隔，从而得到更长的媒体段，减少请求次数以降低传输开销；由于每个媒体段是由客户端的请求触发产生的，不再需要清单文件，客户端也不需要请求和解析清单文件，一方面客户端可以更快速的获得最新的媒体流，减少了实时媒体流的传输延时，另一方面，也降低了清单文件带来的传输开销和处理开销，从而有效降低媒体流传输延时和开销，进一步提高实时媒体流的传输性能。

[0130] 其次参照附图描述根据本发明实施例提出的媒体流的实时递送服务器。

[0131] 图3是本发明一个实施例的媒体流的实时递送服务器的结构示意图。

[0132] 如图3所示，该媒体流的实时递送服务器10包括：客户端接口组件100和媒体段生成组件200。

[0133] 其中，客户端接口组件100用于接收客户端发送的媒体段请求并返回相应的媒体段，其中，媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数。媒体段生成组件200根据媒体段请求生成媒体段，其中，根据第一类参数确定待传送的目标媒体流，根据第二类参数确定待传送的候选媒体单元，并将待传送的候选媒体单元封装成媒体段，并通过客户端接口组件100发送媒体段至客户端。本发明实施例的服务器10根据客户端的请求来实时生成媒体段，并返回给客户端，以实现按客户端需求分段的实时媒体流递送，从而有效降低媒体流传输延时和开销，进一步提高实时媒体流的传输性能。

[0134] 具体而言，客户端接口组件100用于接收客户端的媒体段请求，以及将生成的媒体段发送给客户端；媒体段请求可以携带0个、1个或多个控制参数；控制参数包括以下类别：第一类参数和第二类参数；第一类参数用于指示待传送的目标媒体流；第二类参数用于指示待传送的候选媒体单元。客户端接口组件可以采用任何指定的协议来接收媒体段请求，例如，当采用HTTP协议时，客户端接口组件可以是一个Web服务器，可以接收任何采用http协议的媒体段请求并且通过HTTP响应来返回媒体段；当采用TCP协议时，客户端接口组件是一个TCP服务器，并提供一个固定的服务端口。

[0135] 媒体段生成组件200用于根据客户端的媒体段请求来生成所需的媒体段。从客户端接口组件获取媒体段请求及其控制参数，根据第一类参数来确定待传送的目标媒体流，根据第二类参数来确定待传送的候选媒体单元，从媒体流存储单元中提取出待传送的候选媒体单元，将其封装成媒体段，然后直接交由客户端接口组件来发送。

[0136] 进一步，如图4所示，本发明实施例的服务器10还包括至少一个实时媒体流生成组件，用于自行产生或接收来自其他服务器的一个或多个实时媒体流；媒体流是一个实时产生的媒体单元的序列；每个媒体单元都关联有一个产生时间和/或一个序号，序号用来表示媒体单元产生的顺序；

[0137] 具体而言，实时媒体流生成组件可能包括媒体流生成的一个或多个处理步骤，例如，处理步骤包括但不限于：媒体信号的实时采集、编码压缩、传输封装和预分段。此外，实时媒体流生成组件还可以接收来自其他装置的实时媒体流，或者将一个已存在的媒体流文件转换成实时流。

[0138] 进一步地，在本发明的一个实施例中，媒体段生成组件进一步用于在媒体段请求不携带第一类参数时，待传送的目标媒体流为缺省指定的媒体流，并在的媒体段请求中不携带第二类参数时，候选媒体单元包括缺省指定的媒体单元，缺省指定的媒体单元为目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元，或者为目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元。

[0139] 进一步地，在本发明的一个实施例中，如果媒体段请求携带至少一个第二类参数，其中，每个第二类参数对应着候选媒体单元的至少一个约束条件，则待传送的候选媒体单元包括目标媒体流中同时满足第二类参数对应的全部约束条件的所有媒体单元。

[0140] 进一步地，在本发明的一个实施例中，第二类参数包括起始序号，起始序号对应的约束条件为：如果起始序号有效，则候选媒体单元的序号在起始序号之后，或者等于起始序号。

[0141] 进一步地，在本发明的一个实施例中，第二类参数包括起始时间，起始时间对应的约束条件为：如果起始时间有效，则候选单元的产生时间在起始时间之后。

[0142] 进一步地，在本发明的一个实施例中，第二类参数包括单元个数，单元个数对应的约束条件为：如果单元个数有效，则的候选媒体单元的数目不超过单元个数；进一步，如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则的候选媒体单元和最新媒体单元的序号间隔小于单元个数。

[0143] 进一步地，在本发明的一个实施例中，第二类参数包括分段时长，分段时长对应的约束条件为：如果分段时长有效，则的候选媒体单元中最早产生的单元和最晚产生的单元的产生时间间隔小于分段时长；进一步，如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则的候选媒体单元和最新媒体单元的产生时间间隔小于分段时长。

[0144] 进一步地，在本发明的一个实施例中，第一类参数包括媒体流标识，以指定待传送的目标媒体流。

[0145] 进一步地，在本发明的一个实施例中，媒体段生成组件进一步用于获取媒体流索引信息，并将媒体流索引信息封装到媒体段中，其中，的媒体流索引信息包含属于同一个内容的多个媒体流描述信息，的媒体流描述信息包括媒体流标识和媒体流比特率。

[0146] 需要说明的是，前述对媒体流的实时递送方法实施例的解释说明也适用于该实施例的媒体流的实时递送服务器，此处不再赘述。

[0147] 根据本发明实施例提出的媒体流的实时递送服务器，根据客户端的请求来实时生成媒体段，并返回给客户端，以实现按客户端需求分段的实时媒体流递送，媒体分段的时长将自动适应网络传输带宽的变化，客户端可以通过主动请求来控制媒体分段的时长，当客户端与服务器之间的传输带宽充足且延时较小时，客户端可以更快速的提出请求，从而得到时长更短的媒体段，降低实时传输延时；当客户端与服务器之间的传输带宽不足且延时较大时，客户端可以延长提交请求的间隔，从而得到更长的媒体段，减少请求次数以降低传输开销；由于每个媒体段是由客户端的请求触发产生的，不再需要清单文件，客户端也不需要请求和解析清单文件，一方面客户端可以更快速的获得最新的媒体流，减少了实时媒体流的传输延时，另一方面，也降低了清单文件带来的传输开销和处理开销，从而有效降低媒体流传输延时和开销，进一步提高实时媒体流的传输性能。

[0148] 为了实现上述实施例，本发明实施例还提出了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时，实现如上述实施例描述的媒体流的实时递送方法。

[0149] 为了实现上述实施例，本发明实施例还提出了一种非临时性计算机可读存储介质，该程序被处理器执行时实现如上述实施例描述的媒体流的实时递送方法。

[0150] 为了实现上述实施例，本发明实施例还提出了一种计算机程序产品，当计算机程序产品中的指令由处理器执行时，执行如上述实施例描述的媒体流的实时递送方法。

[0151] 此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

[0152] 在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

[0153] 尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。