CN111193686B - 媒体流的递送方法及服务器 - Google Patents
媒体流的递送方法及服务器 Download PDFInfo
- Publication number
- CN111193686B CN111193686B CN201811353208.6A CN201811353208A CN111193686B CN 111193686 B CN111193686 B CN 111193686B CN 201811353208 A CN201811353208 A CN 201811353208A CN 111193686 B CN111193686 B CN 111193686B
- Authority
- CN
- China
- Prior art keywords
- media
- stream
- time
- type
- sequence number
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/75—Media network packet handling
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
本发明公开了一种媒体流的递送方法及服务器,其中,方法包括:接收客户端发送的媒体段请求,其中,媒体段请求不携带或携带至少一个控制参数,且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数;根据媒体段请求生成媒体段,其中,根据第一类参数确定待传送的目标媒体流,确定目标媒体流的流传送类型,根据流传送类型和第二类参数确定待传送的候选媒体单元,并将待传送的候选媒体单元封装成媒体段;发送媒体段至客户端。该方法可以实现按客户端需求分段的媒体流递送,有效降低媒体流的传输延时和开销,并为媒体流的直播、点播和时移提供统一的递送接口,简化服务器和客户端的实现。
Description
技术领域
本发明涉及数字信息传送技术领域,特别涉及一种媒体流的递送方法及服务器。
背景技术
随着互联网特别是移动互联网的快速发展,通过互联网来实时或非实时传送音频、视频、图像等多媒体数据成为许多应用的基本需求,为满足这一需求,人们提出了各种流媒体传输技术,目前得到广泛使用的实时流媒体传输技术主要包括三类:实时传送协议(RTP(Real-time Transport Protocol,实时传输协议)/RTSP(Real Time StreamingProtocol,实时流传输协议))、RTMP(Real Time Messaging Protocol,实时消息传送协议)和HTTP(HyperText Transfer Protocol,超文本传输协议)自适应性流传输HAS(HTTPAdaptive Streaming)。其中,HTTP自适应流传输又包括多种方案:苹果公司提出的HLS(HTTP Live Streaming)、微软提出的平滑流Smooth Streaming、Adobe提出的HDS(HTTPDynamic Streaming)、MPEG组织提出的DASH(Dynamic Adaptive Streaming over HTTP,基于HTTP的动态自适应流)。
相关技术中的HTTP自适应性流传输方案的共同特点是将媒体流切割成短时间(2s~10s)的媒体片段,并同时生成描述这些媒体片段的索引文件或清单文件(例如HLS中的m3u8播放列表和DASH中的MPD文件),然后将其保存到各Web服务器上,客户端通过访问播放列表或清单文件,获得这些媒体片段的URL(Uniform Resource Locator,统一资源定位符)访问地址,然后可以采用标准的HTTP协议来逐个下载这些媒体片段并进行播放。简言之,上述方案的主要区别体现在媒体片段采用的封装格式和清单文件格式的不同。
相对于RTP/RTSP和RTMP来说,HTTP自适应流传输可以充分利用现有的互联网Web缓存设施(如CDN和各种Web缓存服务器),可以支持大规模的用户访问。同时,通过提供多种码率的媒体片段,还可以支持客户端根据网络条件和终端能力来自行选择合适码率的片段,实现码率自适应。因此,HTTP自适应流传输已成为目前互联网上实时流媒体递送的主流方式。
但是,相关技术中的HTTP自适应流传输方案均存在以下问题:
第一,媒体片段的时长无法适应动态变化的网络传输。目前的HAS方案均采用预分段的方式,即服务器按照预先设置的时长来生成媒体片段及其清单文件并提交给web服务器。当网络传输带宽充足且延时较小时,设置较大的片段时长意味着增加实时传送的延时;当网络传输带宽不足且延时较大时,设置较小的片段时长意味着频繁的文件请求,增加服务器的负担和网络传输开销。由于互联网上的传输带宽和传输延时是动态变化的,采用固定时长的预分段方式无法实现最优传输。
第二,清单文件增加了传送延时和开销。客户端需要先得到清单文件,才能获得媒体片段的URL地址。但是由于清单文件需要经过一段时间才能传输给客户端,因此,客户端得到的清单文件并不能反映当前最新的媒体片段的生成情况,此外,当清单文件遇到阻塞或者传输出错时,将阻塞用户对媒体片段的快速访问,降低实时流媒体的传送性能。
第三,不适合长时媒体流的非实时传送。以视频点播应用来说,HTTP自适应流传输需要将一个长时间的视频文件预先分割成大量的短视频片段并为该视频生成特定格式的清单文件,这带来额外的处理开销、存储开销和传输开销。
第四,无法为直播、时移和点播提供统一的递送接口。以视频直播为例,在视频直播的过程中,用户希望通过时移看到错过的播放内容,在视频直播结束后,用户希望回看,即从直播切换到点播。但是,现有HTTP自适应流传输中,为减少直播中频繁更新清单文件带来的开销,清单文件只指示最近产生的若干媒体片段,如果用户需要时移或点播,则需要另外为该用户生成新的清单文件或提供辅助的控制信息,这增加了服务器和客户端实现的复杂性和网络的传输开销。
发明内容
本发明旨在至少在一定程度上解决相关技术中的技术问题之一。
为此,本发明的第一个目的在于提出一种媒体流的递送方法,该方法可以有效降低媒体流的传输延时和开销,并为媒体流的直播、点播和时移播放提供统一的递送接口,简化服务器和客户端的实现。
本发明的第二个目的在于提出一种媒体流的递送服务器。
本发明的第三个目的在于提出一种计算机设备。
本发明的第四个目的在于提出一种非临时性计算机可读存储介质。
本发明的第五个目的在于提出一种计算机程序产品。
为达到上述目的,本发明一方面实施例提出了一种媒体流的递送方法,所述媒体流为媒体单元的序列,其中,每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号,所述方法包括:接收客户端发送的媒体段请求,其中,所述媒体段请求不携带或携带至少一个控制参数,且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数;根据所述媒体段请求生成媒体段,其中,根据所述第一类参数确定所述待传送的目标媒体流,确定所述目标媒体流的流传送类型,根据所述流传送类型和所述第二类参数确定所述待传送的候选媒体单元,将所述待传送的候选媒体单元封装成所述媒体段,所述流传送类型为实时传送或非实时传送;发送所述媒体段至所述客户端。
本发明实施例的媒体流的递送方法,根据客户端的请求来生成媒体段,并返回给客户端,以实现按客户端需求分段的媒体流递送,媒体分段的时长将自动适应网络传输带宽的变化,客户端可以通过主动请求来***体分段的时长,由于每个媒体段是由客户端的请求触发产生的,不再需要清单文件,客户端也不需要请求和解析清单文件,一方面客户端可以更快速的获得最新的媒体流,减少了实时媒体流的传输延时,另一方面,也降低了清单文件带来的传输开销和处理开销,最后,客户端还可以通过请求来***体段中所封装的媒体单元的范围,为媒体流的直播、点播和时移播放提供统一的递送接口,简化服务器和客户端的实现。
另外,根据本发明上述实施例的媒体流的递送方法还可以具有以下附加的技术特征:
其中,在本发明的一个实施例中,所述确定目标媒体流的流传送类型的方法为缺省指定。
进一步地,在本发明的一个实施例中,所述第一类参数包括媒体文件标识,当所述待传送的目标媒体流由所述媒体文件标识来指示时,所述目标媒体流的流传送类型缺省指定为非实时传送。
进一步地,在本发明的一个实施例中,所述确定目标媒体流的流传送类型,包括:如果所述目标媒体流不再产生新的媒体单元的持续时间超过预设时间值,则所述目标媒体流的流传送类型为非实时传送,否则,所述目标媒体流的流传送类型为实时传送。
进一步地,在本发明的一个实施例中,所述根据所述媒体段请求生成媒体段,进一步包括:如果所述媒体段请求不携带所述第一类参数,则所述待传送的目标媒体流为缺省指定的媒体流;如果所述媒体段请求中不携带所述第二类参数,则所述候选媒体单元包括根据流传送类型缺省指定的媒体单元。
进一步地,在本发明的一个实施例中,所述根据流传送类型缺省指定的媒体单元,包括:如果所述流传送类型为实时传送,则所述缺省指定的媒体单元为所述目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元,或者为所述目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元;如果所述流传送类型为非实时传送,则所述缺省指定的媒体单元为所述目标媒体流中所有和流起始单元的序号间隔小于第三预设值的媒体单元,或者为所述目标媒体流中所有和流起始单元的产生时间间隔小于第四预设值的媒体单元;其中,所述流起始单元为媒体流中最早产生的媒体单元。
进一步地,在本发明的一个实施例中,所述根据媒体段请求生成媒体段进一步包括:如果所述媒体段请求携带至少一个所述第二类参数,其中,所述每个第二类参数在指定流传送类型下对应着候选媒体单元的至少一个约束条件,则所述待传送的候选媒体单元包括所述目标媒体流中同时满足所述第二类参数在所述流传送类型下对应的全部约束条件的所有媒体单元。
进一步地,在本发明的一个实施例中,所述第二类参数包括起始序号,其中,所述起始序号在流传送类型为实时传送时,对应的约束条件为:如果所述起始序号有效,则所述候选媒体单元的序号在所述起始序号之后;所述起始序号在流传送类型为非实时传送时,对应的约束条件为:如果所述起始序号有效,则所述候选媒体单元的序号在所述起始序号之后,且和所述起始序号的间隔小于一个第一预设间隔值。
进一步地,在本发明的一个实施例中,所述第二类参数包括序号范围,所述序号范围包括至少一个序号区间,所述序号区间指示了序号的最小值和最大值,所述序号范围在任意流传送类型下对应的约束条件为:如果序号范围有效,则所述候选媒体单元的序号在所述序号范围包括的序号区间内。
进一步地,在本发明的一个实施例中,所述第二类参数包括起始时间,其中,所述起始时间在所述流传送类型为实时传送时,对应的约束条件为:如果所述起始时间有效,则所述候选媒体单元的产生时间在所述起始时间之后;所述起始时间在所述流传送类型为非实时传送时,对应的约束条件为:如果所述起始时间有效,则所述候选媒体单元的产生时间在所述起始时间之后,且和所述起始时间的间隔小于一个第二预设间隔值。
进一步地,在本发明的一个实施例中,所述第二类参数包括产生时间范围,所述产生时间范围包括至少一个产生时间区间,所述产生时间区间指示了产生时间的最小值和最大值,所述产生时间范围在任意流传送类型下对应的约束条件为:如果所述产生时间范围有效,则所述候选媒体单元的产生时间在所述产生时间范围内。
进一步地,在本发明的一个实施例中,所述每个媒体单元关联有一个序移,所述序移是指媒体单元与流起始单元的序号间隔,所述流起始单元是指媒体流中最早产生的媒体单元,所述第二类参数包括序移范围,所述序移范围包括至少一个序移区间,所述序移区间指示了序移的最小值和最大值,所述序移范围在任意流传送类型下对应的约束条件为:如果所述序移范围有效,则所述候选媒体单元的序移在所述序移范围内。
进一步地,在本发明的一个实施例中,所述每个媒体单元关联有一个时移,所述时移是指媒体单元与流起始单元的产生时间间隔,所述的所述流起始单元是指媒体流中最早产生的媒体单元,所述第二类参数包括时移范围,所述时移范围包括至少一个时移区间,所述时移区间指示了时移的最小值和最大值,所述时移范围在任意流传送类型下对应的约束条件为:如果所述时移范围有效,则所述候选媒体单元的时移在所述时移范围内。
为达到上述目的,本发明另一方面实施例提出了一种媒体流的递送服务器,所述媒体流为媒体单元的序列,其中,每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号,所述服务器包括:客户端接口组件,用于接收客户端发送的媒体段请求并返回相应的媒体段,其中,所述媒体段请求不携带或携带至少一个控制参数,且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数;媒体段生成组件,根据所述媒体段请求生成媒体段,其中,根据所述第一类参数确定所述待传送的目标媒体流,确定所述目标媒体流的流传送类型,根据所述流传送类型和所述第二类参数确定所述待传送的候选媒体单元,将所述待传送的候选媒体单元封装成所述媒体段,并通过所述客户端接口组件发送所述媒体段至所述客户端,所述流传送类型为实时传送或非实时传送。
本发明实施例的媒体流的递送服务器,根据客户端的请求来生成媒体段,并返回给客户端,以实现按客户端需求分段的媒体流递送,媒体分段的时长将自动适应网络传输带宽的变化,客户端可以通过主动请求来***体分段的时长,由于每个媒体段是由客户端的请求触发产生的,不再需要清单文件,客户端也不需要请求和解析清单文件,一方面客户端可以更快速的获得最新的媒体流,减少了实时媒体流的传输延时,另一方面,也降低了清单文件带来的传输开销和处理开销,最后,客户端还可以通过请求来***体段中所封装的媒体单元的范围,为媒体流的直播、点播和时移播放提供统一的递送接口,简化服务器和客户端的实现。
另外,根据本发明上述实施例的媒体流的递送服务器还可以具有以下附加的技术特征:
其中,在本发明的一个实施例中,所述确定目标媒体流的流传送类型的方法为缺省指定。
进一步地,在本发明的一个实施例中,所述第一类参数包括媒体文件标识,当所述待传送的目标媒体流由所述媒体文件标识来指示时,所述目标媒体流的流传送类型缺省指定为非实时传送。
进一步地,在本发明的一个实施例中,所述媒体段生成组件进一步用于在所述目标媒体流不再产生新的媒体单元的持续时间超过预设时间值时,所述目标媒体流的流传送类型为非实时传送,否则,所述目标媒体流的流传送类型为实时传送。
进一步地,在本发明的一个实施例中,所述媒体段生成组件进一步用于在所述媒体段请求不携带所述第一类参数时,所述待传送的目标媒体流为缺省指定的媒体流,且在所述媒体段请求中不携带所述第二类参数时,所述候选媒体单元包括根据流传送类型缺省指定的媒体单元。
进一步地,在本发明的一个实施例中,所述媒体段生成组件进一步用于在所述流传送类型为实时传送时,所述缺省指定的媒体单元为所述目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元,或者为所述目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元,且在所述流传送类型为非实时传送时,所述缺省指定的媒体单元为所述目标媒体流中所有和流起始单元的序号间隔小于第三预设值的媒体单元,或者为所述目标媒体流中所有和流起始单元的产生时间间隔小于第四预设值的媒体单元,其中,所述流起始单元为媒体流中最早产生的媒体单元。
进一步地,在本发明的一个实施例中,所述媒体段生成组件进一步用于在所述媒体段请求携带至少一个所述第二类参数,其中,所述每个第二类参数在指定流传送类型下对应着候选媒体单元的至少一个约束条件时,所述待传送的候选媒体单元包括所述目标媒体流中同时满足所述第二类参数在所述流传送类型下对应的全部约束条件的所有媒体单元。
进一步地,在本发明的一个实施例中,所述第二类参数包括起始序号,其中,所述起始序号在流传送类型为实时传送时,对应的约束条件为:如果所述起始序号有效,则所述候选媒体单元的序号在所述起始序号之后;所述起始序号在流传送类型为非实时传送时,对应的约束条件为:如果所述起始序号有效,则所述候选媒体单元的序号在所述起始序号之后,且和所述起始序号的间隔小于一个第一预设间隔值。
进一步地,在本发明的一个实施例中,所述第二类参数包括序号范围,所述序号范围包括至少一个序号区间,所述序号区间指示了序号的最小值和最大值,所述序号范围在任意流传送类型下对应的约束条件为:如果序号范围有效,则所述候选媒体单元的序号在所述序号范围包括的序号区间内。
进一步地,在本发明的一个实施例中,所述第二类参数包括起始时间,其中,所述起始时间在所述流传送类型为实时传送时,对应的约束条件为:如果所述起始时间有效,则所述候选媒体单元的产生时间在所述起始时间之后;所述起始时间在所述流传送类型为非实时传送时,对应的约束条件为:如果所述起始时间有效,则所述候选媒体单元的产生时间在所述起始时间之后,且和所述起始时间的间隔小于一个第二预设间隔值。
进一步地,在本发明的一个实施例中,所述第二类参数包括产生时间范围,所述产生时间范围包括至少一个产生时间区间,所述产生时间区间指示了产生时间的最小值和最大值,所述产生时间范围在任意流传送类型下对应的约束条件为:如果所述产生时间范围有效,则所述候选媒体单元的产生时间在所述产生时间范围内。
进一步地,在本发明的一个实施例中,所述每个媒体单元关联有一个序移,所述序移是指媒体单元与流起始单元的序号间隔,所述流起始单元是指媒体流中最早产生的媒体单元,所述第二类参数包括序移范围,所述序移范围包括至少一个序移区间,所述序移区间指示了序移的最小值和最大值,所述序移范围在任意流传送类型下对应的约束条件为:如果所述序移范围有效,则所述候选媒体单元的序移在所述序移范围内。
进一步地,在本发明的一个实施例中,所述每个媒体单元关联有一个时移,所述时移是指媒体单元与流起始单元的产生时间间隔,所述的所述流起始单元是指媒体流中最早产生的媒体单元,所述第二类参数包括时移范围,所述时移范围包括至少一个时移区间,所述时移区间指示了时移的最小值和最大值,所述时移范围在任意流传送类型下对应的约束条件为:如果所述时移范围有效,则所述候选媒体单元的时移在所述时移范围内。
为达到上述目的,本发明第三方面实施例提出了一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时,实现如上述实施例描述的媒体流的递送方法。
为达到上述目的,本发明第四方面实施例提出了一种非临时性计算机可读存储介质,该程序被处理器执行时实现如上述实施例描述的媒体流的递送方法。
为达到上述目的,本发明第五方面实施例提出了一种计算机程序产品,当所述计算机程序产品中的指令由处理器执行时,执行如上述实施例描述的媒体流的递送方法。
本发明附加的方面和优点将在下面的描述中部分给出,部分将从下面的描述中变得明显,或通过本发明的实践了解到。
附图说明
本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解,其中:
图1为根据本发明实施例的媒体流的递送方法的流程图;
图2为根据本发明一个实施例的客户端连续提交媒体段请求的实时传送过程示意图(应用于直播);
图3为根据本发明领一个实施例的客户端连续提交媒体段请求的实时传送过程示意图(应用于直播和时移播放);
图4为根据本发明再一个实施例的客户端连续提交媒体段请求的非实时传送过程示意图(应用于点播和回看);以及
图5为根据本发明一个实施例的媒体流的实时递送服务器的结构示意图。
具体实施方式
下面详细描述本发明的实施例,所述实施例的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的,旨在用于解释本发明,而不能理解为对本发明的限制。
在互联网中,经常需要将各种实时产生的音频流、视频流或数据流从一个网络节点传送到另一个网络节点,这些网络节点既包括各种终端,如PC、手机、平板,也包括各种应用服务器,如视频服务器、音频服务器,将传送的这些音频流、视频流或数据流统称为媒体流。媒体流的传送过程可以用通用的客户端-服务器模型来描述:媒体流由服务器递送给客户端。这里的服务器和客户端指的是逻辑上的功能实体,其中,服务器为发送媒体流的功能实体,客户端为接收媒体流的功能实体。服务器和客户端可存在于任何网络节点上。
每个传送的媒体流是一个媒体单元的序列。不同的媒体流,其对应的媒体单元可以自行选择。当媒体流是一个实时产生的字节流时,可以选取一个字节为媒体单元;当媒体流是一个经过实时采样获得的音频流或视频流时,可以选取原始的音频帧或视频帧为媒体单元;当媒体流是一个经过实时采样和编码的音频流或视频流时,可以选择编码后的音频帧、编码后的视频帧或访问单元(Access Unit)为媒体单元;当媒体流是一个经过实时采样、编码和封装的音频流或视频流时,可以选择封装后的传输包(如RTP包,PES/PS/TS包等)为媒体单元;当媒体流是一个经过实时采样、编码、封装和预分段的音频流或视频流时,可以选择一个已分割的媒体片段(如HLS协议中使用的TS格式片段、DASH协议中使用的fMP4格式片段)为媒体单元。
每个媒体单元可以关联一个产生时间,该产生时间通常为一个时间戳。每个媒体单元还可以关联一个序号,该序号可以用来表示媒体单元产生的顺序。当序号用来表示媒体单元产生的顺序时,序号的意义需要根据具体的媒体单元来定义。当媒体单元为一个字节时,媒体单元的序号为字节序号;当媒体单元为音频帧、视频帧时,媒体单元的序号为帧序号;当媒体单元为一个传输包时,媒体单元的序号为包序号;当媒体单元为一个流片段时,媒体单元的序号为片段序号(如HLS中每个TS片段的MediaSequence)。
对于一个媒体流来说,可以同时关联一个表示产生顺序的序号和一个产生时间,比如,当媒体流为一个RTP包流时,RTP头部既有包序号(Sequence Number)字段来指示RTP包的顺序,又有Timestramp字段来指示RTP中封装的媒体数据的产生时间。在此情况下,多个连续的RTP包可能对应相同的产生时间,但是其序号则是唯一的。
根据媒体单元的产生和传送的时间关系,媒体流的传送可分为两种传送类型:实时传送和非实时传送。如果媒体流中的媒体单元是在传送过程中实时产生的,则该媒体流的流传送类型为实时传送,如果媒体流是在传送前已经产生完毕,例如一个媒体文件,则该媒体流的流传送类型为非实时传送。实时传送和非实时传送是可以相互转换的,比如一个直播的媒体流在播放结束后保存起来用于回看或点播,则该媒体流从实时传送转为非实时传送。
本发明实施例的方法可以针对任何一种媒体流来实施。在下面的实施例当中,本发明实施例将分别选择RTP媒体流或MPEG2-TS媒体流来阐述本发明实施例的实施方法。
对于RTP媒体流来说,媒体单元为一个RTP包,选择RTP的包序号(SequenceNumber)为媒体单元的序号,RTP包的包序号为一个16位字段,最大值为65535,对于连续产生的RTP包,其序号是循环计数的,如果当前包序号为Seq,则下一个包的序号为(Seq+1)%65536,因此,序号在实现上受制于其位长,可能出现序号大小无法反映其先后顺序的情况,此时,可通过媒体单元的产生时间来判断序号是否出现循环计数,以准确判断两个媒体单元的序号的先后关系及其间隔。
对于MPEG2-TS媒体流来说,TS包中封装了PES包,选择PES包作为媒体单元,每个PES包的包头中的时间戳PTS作为媒体单元的产生时间。对于不同的媒体流,时间戳PTS的单位也不一致,比如视频流中PTS的时间单位一般为1/90000秒,音频流中PTS的时间单位则与采样率有关,为简化起见,在本实施例说明中,PTS的单位统一设为毫秒。
在传统的实时流媒体协议如RTP或RTMP中,采用的是服务器推送的方式:服务器上一旦有新的媒体单元,则主动发送给客户端。本发明实施例的方法则与各种HTTP自适应流(如HLS、平滑流,MPEG-DASH)类似,采用客户端拉取的方式,但是不同点在于,现有的各种HTTP自适应流中,客户端都是根据清单文件来请求或拉取已分割好的片段,每个片段可以通过一个URL来标识,而在本发明实施例中,媒体段不是预先分割好的,而是服务器根据客户端的请求实时生成的,客户端可以***体段的内容及时长。
下面参照附图描述根据本发明实施例提出的媒体流的递送方法及服务器,首先将参照附图描述根据本发明实施例提出的媒体流的递送方法。
图1是本发明一个实施例的媒体流的递送方法的流程图。
如图1所示,该媒体流的递送方法,媒体流为媒体单元的序列,其中,每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号,方法包括:
在步骤S101中,接收客户端发送的媒体段请求,其中,媒体段请求不携带或携带至少一个控制参数,且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数。
具体而言,媒体段请求可以不携带任何第一类参数和第二类参数,可以根据进一步实施的需要来定义新的参数,例如,可以作为第一类参数的控制参数包括:媒体流标识、媒体流名称、媒体文件标识、媒体文件名等;可以作为第二类参数的控制参数包括:起始序号、起始时间、序号范围、产生时间范围、序移范围、时移范围等。
媒体段请求可以采用任何协议来提交,比如常见的HTTP协议、TCP协议、UDP协议等。当采用HTTP协议提交媒体段请求时,也可以采用HTTP-GET方式或者HTTP-POST方式。
当媒体段请求中携带控制参数时,控制参数需要采用一定的方式封装成字符串或字节流,发送给服务器。例如,当采用HTTP-GET来发送媒体段请求时,控制参数可以作为字符串封装到URL中。采用HTTP-GET的媒体段请求的示例如下:
不携带控制参数的媒体段请求:
GET“http://www.xxx-server.com/msreq”[req1]
携带一个控制参数的媒体段请求:
GET“http://www.xxx-server.com/msreq?streamID=601”[req2]
GET“http://www.xxx-server.com/msreq?fileID=5100”[req3]
GET“http://www.xxx-server.com/msreq?fileName=hello.ts”[req4]
GET“http://www.xxx-server.com/msreq?seqBegin=1005”[req5]
GET“http://www.xxx-server.com/msreq?timeBegin=31000”[req6]
GET“http://www.xxx-server.com/msreq?seqRange=1010-1015”[req7]
GET“http://www.xxx-server.com/msreq?timeRange=31000-32000”[req8]
GET“http://www.xxx-server.com/msreq?SeqShiftRange=0-10”[req9]
GET“http://www.xxx-server.com/msreq?timeShiftRange=0-1000”[req10]
携带两个控制参数的媒体段请求:
GET“http://www.xxx-server.com/msreq?streamID=601&seqBegin=1010”[req11]
GET“http://www.xxx-server.com/msreq?fileName=hello.ts&timeBegin=31000”[req12]
GET“http://www.xxx-server.com/msreq?streamID=601&seqShiftRange=0-20”[req13]
GET“http://www.xxx-server.com/msreq?fileName=hello.ts&timeShiftRange=0-3000”[req14]
上述请求的URL中,参数名streamID、fileID、fileName、seqBegin、timeBegin、seqRange、timeRange、seqShiftRange、timeShiftRange分别代表媒体流标识、媒体文件标识、媒体文件名、起始序号、起始时间、序号范围、产生时间范围、序移范围、时移范围。
服务器端可以采用Web服务器来接收上述客户端的媒体段请求,并从请求的URL中提取出相应的控制参数,并对控制参数进行分类:如果是媒体流标识、媒体文件标识、媒体文件名,则该参数为第一类参数;如果为起始序号、起始时间、序号范围、产生时间范围、序移范围、时移范围,则为第二类参数。
在步骤S102中,根据媒体段请求生成媒体段,其中,根据第一类参数确定待传送的目标媒体流,确定目标媒体流的流传送类型是实时传送还是非实时传送,根据流传送类型和第二类参数确定待传送的候选媒体单元,并将待传送的候选媒体单元封装成媒体段。
具体而言,服务器接收到媒体段请求后,可获取媒体段请求中携带的控制参数,然后可以根据其中的第一类参数来确定待传送的目标媒体流,确定目标媒体流的流传送类型是实时类型还是非实时类型,根据流传送类型和携带的第二类参数来确定待传送的候选媒体单元,最后将待传送的候选媒体单元封装成媒体段。其中,可以采用自定义的封装协议将一个或多个媒体单元封装成媒体段,例如,一个简单的封装协议如下:媒体段由段头和段净荷组成,段净荷由若干个媒体单元级联而成,段头中则指示每个媒体单元的起始位置和长度。对于MPEG2-TS流来说,媒体单元为一个PES包,由于每个PES包都对应着整数个TS包,因此,除了采用上述简单封装协议外,还可以直接对MPEG2-TS流进行切割来生成媒体段,将候选媒体单元所对应的PES包以及必要的控制信息封装成一个TS片段作为媒体段。
在步骤S103中,发送媒体段至客户端。
具体而言,服务器可以根据客户端的媒体段请求所使用的协议来选择适当的方式将媒体段发送给客户端,例如当接收的媒体段请求采用HTTP GET方式时,可以通过HTTPGET响应消息来发送生成的媒体段:将媒体段放入到HTTP响应消息的实体主体中。
对于实时传送来说,当服务器接收到来自客户端的连续的媒体段请求时,服务器将根据客户端的请求来不断生成新的媒体段,这些新的媒体段中封装了最近产生的若干媒体单元,客户端解析这些媒体段,即可恢复出媒体流的各媒体单元,实现了媒体流从服务器到客户端的直播,这一过程如图2所示。
在上述实时传送过程中,客户端还可以任意请求以往的某个时间段上的媒体流,服务器则将指定时间段上的媒体单元封装为媒体段发送给客户端,实现媒体流的时移播放,且可以通过请求在时移播放和直播间自由切换,这一过程如图3所示。
对于非实时传送来说,当服务器接收到来自客户端的媒体段请求时,服务器将根据客户端的请求来生成新的媒体段,这些新的媒体段中封装了客户端指定范围的若干媒体单元,客户端通过解析这些媒体段,即可恢复出媒体流的各媒体单元,实现了媒体流从服务器到客户端的点播或回看,这一过程如图4所示。
由于采用了即时生成媒体段的方式,本发明实施例的方法不再需要清单文件,从而降低传输延时和节省开销。此外,客户端可以自行调整发送请求的频率来***体段的时长,以更好的适应网络带宽的变化。另一方面,根据客户端的请求,服务器可以将指定范围内的媒体单元封装为媒体段,为媒体流的直播、点播和时移播放提供了统一的递送接口,简化服务器和客户端的实现。
上述是对实施例1的详细阐述,下面将对实施例2进行详细说明,以下实施例中,将对服务器如何根据目标媒体流来确定流传送类型做出说明。
进一步地,在本发明的一个实施例中,所述的确定目标媒体流的流传送类型的方法为缺省指定。服务器上可以同时存在多个待发送的媒体流,客户端可以通过第一类参数,如媒体流标识、媒体文件标识或媒体文件名来指示出目标媒体流,其中,媒体文件名可以看作一种特殊的媒体文件标识。这些目标媒体流的流传送类型可以由服务器缺省指定,比如当请求的媒体流为文件时(如req3和req4),由于其不再生成新的媒体单元,其缺省传送方式即为非实时传送。
对于一个正处于直播过程中的媒体流来说,其媒体单元仍然在不断产生,因此,此时该媒体流的流传送类型为实时传送,但是,当直播过程已结束时,此时仍然访问该媒体流的用户,其目的是回看或点播,此时,服务器应该将媒体流的流传送类型确定为非实时传送。
服务器判断直播过程是否结束的方法可以有两种,一种是媒体源主动通知服务器,另一种则是服务器可以对目标媒体流不再产生新的媒体单元的持续时间进行计时,当该持续时间超过一定设定值,比如1分钟,即认为目标媒体流已停止更新,该媒体流的流传送方式改为非实时方式。这样,当客户端通过相同的接口(如req2)在不同的时间来访问媒体流时,可平滑地在直播和点播之间切换。
实施例3,以下实施例中,将对服务器如何根据媒体段请求来生成媒体段做出说明。
进一步地,在本发明的一个实施例中,根据媒体段请求生成媒体段,进一步包括:如果媒体段请求不携带第一类参数,则待传送的目标媒体流为缺省指定的媒体流;如果媒体段请求中不携带第二类参数,则候选媒体单元包括根据流传送类型缺省指定的媒体单元。
进一步,所述的根据流传送类型缺省指定的媒体单元包括:
如果流传送类型为实时传送,则所述缺省指定的媒体单元为所述目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元,或者为所述目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元;
如果流传送类型为非实时传送,则所述缺省指定的媒体单元为所述目标媒体流中所有和流起始单元的序号间隔小于第三预设值的媒体单元,或者为所述目标媒体流中所有和流起始单元的产生时间间隔小于第四预设值的媒体单元;所述的流起始单元是指媒体流中最早产生的媒体单元。
媒体流的实时传送以RTP实时流为例来阐述,媒体单元为一个RTP包,每个RTP包都携带一个包序号。假定最新产生的RTP包的包序号为1020,第一预设值为20,当服务器收到一个不携带任何参数的媒体段请求时如[如req1],服务器可从现有的RTP媒体流中选择一个作为目标媒体流,并确定该目标媒体流的流传送类型为实时传送,由于该请求不携带第二类参数,则待发送的候选媒体单元包括目标媒体流中最近产生的20个RTP包(包序号从1001到1020),然后服务器将这20个RTP包封装成媒体段。
媒体流的非实时传送以MPEG2-TS流为例,媒体单元为一个PES包,每个PES包都关联了一个PTS时间戳,该时间戳即为媒体单元的产生时间。假定TS流中的第一个PES包即流起始单元的PTS时间戳为30000,第四预设值为3000毫秒,则当服务器收到一个不携带第二类参数的媒体段请求时如[req3或req4],服务器根据第一类参数中来确定目标媒体流,由于目标媒体流为媒体文件,因此,其流传送方式缺省指定为非实时传送,此时,由于请求中不携带第二类参数,待发送的候选媒体单元包括目标媒体流中从流起始单元开始的3000毫秒内产生的所有PES包,即时间戳PTS在范围(30000<=PTS<=33000)内的PES包,然后将这些PES包封装成媒体段。
采用上述实施方式,对于实时传送来说,服务器每次接收到用户发送的媒体段请求都会返回最近产生的若干个媒体单元。当服务器持续接受到媒体段请求后,会持续将最近产生的媒体单元递送给客户端。而对于非实时传送来说,服务器接收到用户发送的不携带任何控制参数的媒体段请求时,会将该媒体流的最初产生的若干个媒体单元返回给客户端,客户端可以根据接收的媒体单元信息,通过调整控制参数来请求后续的媒体单元。
实施例4,以下实施例中,将对服务器如何根据第二类参数来确定待传送的候选媒体单元进行说明。
进一步地,在本发明的一个实施例中,如果所述的媒体段请求携带至少一个所述第二类参数,其中,所述每个第二类参数在指定流传送类型下对应着候选媒体单元的至少一个约束条件,则所述待传送的候选媒体单元包括所述目标媒体流中同时满足所述第二类参数在所述流传送类型下对应的全部约束条件的所有媒体单元。
下面将进一步给出六种第二类参数,以及每种第二类参数在指定流传送类型下对应的约束条件,具体实施时可以根据需要采用其中的一种或多种,也并不限定自行定义其他的第二类参数:
1)起始序号
所述起始序号在流传送类型为实时传送时对应的约束条件为:如果所述起始序号有效,则所述候选媒体单元的序号在所述起始序号之后;
所述起始序号在流传送类型为非实时传送时对应的约束条件为:如果所述起始序号有效,则所述候选媒体单元的序号在所述起始序号之后,且和所述起始序号的间隔小于一个第一预设间隔值。
2)序号范围
所述序号范围包括至少一个序号区间,所述序号区间指示了序号的最小值和最大值,所述序号范围在任意流传送类型下对应的约束条件为:如果序号范围有效,则所述候选媒体单元的序号在所述序号范围包括的序号区间内。
3)起始时间
所述起始时间在流传送类型为实时传送时对应的约束条件为:如果所述起始时间有效,则所述候选单元的产生时间在起始时间之后;
所述起始时间在流传送类型为非实时传送时对应的约束条件为:如果所述起始时间有效,则所述候选媒体单元的产生时间在所述起始时间之后,且和所述起始时间的间隔小于一个第二预设间隔值。
4)产生时间范围
所述产生时间范围包括至少一个产生时间区间,所述产生时间区间指示了产生时间的最小值和最大值,所述产生时间范围在任意流传送类型下对应的约束条件为:如果所述产生时间范围有效,则所述候选媒体单元的产生时间在所述产生时间范围内。
5)序移范围
所述序移是指媒体单元与流起始单元的序号间隔,所述的流起始单元是指媒体流中最早产生的媒体单元。所述序移范围包括至少一个序移区间,所述序移区间指示了序移的最小值和最大值,所述序移范围在任意流传送类型下对应的约束条件为:如果所述序移范围有效,则所述候选媒体单元的序移在所述序移范围内。
6)时移范围
所述时移是指媒体单元与流起始单元的产生时间间隔,所述的流起始单元是指媒体流中最早产生的媒体单元,所述第二类参数包括时移范围,所述时移范围包括至少一个时移区间,所述时移区间指示了时移的最小值和最大值,所述时移范围在任意流传送类型下对应的约束条件为:如果所述时移范围有效,则所述候选媒体单元的时移在所述时移范围内。
上述的第二类参数有效和无效指的是所述参数的值是否在一个指定的范围内。以起始序号为例,对于实时传送来说,该起始序号的值不能超过当前最新媒体单元的序号,另一方面,为保证实时性,起始序号的值不能早于某个现有媒体单元的序号,在上述范围内的起始序号即为有效;对于非实时传送来说,该起始序号的值不能超过最后一个媒体单元的序号。如果某个第二类参数为无效,则等同于不携带这个第二类参数。当所有第二类参数均无效时,所述的候选媒体单元为所述缺省指定的媒体单元。
进一步需要指出的是,所有指示范围的控制参数(如序号范围、产生时间范围、序移范围、时移范围)可以包括一个或多个区间,其中每个区间的表示方法可以在实施时自行定义。一种区间的表示方式是直接指示出其最大值max和最小值min,另一种区间的表示方法是采用最小值min和区间长度len,其中,最大值max可间接指示出来:max=min+len-1。当采用字符串方式来表示范围时,一种实施方法是:各区间可用逗号’,’隔开,最小值和最大值可用短破折号’-’隔开,最小值和区间长度可用冒号’:’隔开,此外,如果最小值和最大值相同,则可以省略最大值或区间长度,因此,以序号范围为例,下述两种表示方式对应同一个序号范围,均包括17个媒体单元:
A)1200-1205,1208,1211-1220
B)1200:6,1208:1,1211:10
对于指示范围的控制参数来说,还可以在具体的最小值或最大值后面添加一个特定的字母如X来表示不包括此最小值或最大值。比如产生时间Tp的范围是31000X-32000,指示的产生时间范围是31000<Tp<=32000。
进一步需要指出的是,在其他的实施方式中,可以定义新的第二类参数,但是,如果在一定的映射规则下,参数A可以映射到参数B,且参数A对应的约束条件可以转换成参数B的约束条件,则称这两个参数为等价参数。等价参数不应看作是多个第二类参数,仍应该看作是同一个参数的不同实施方式。举例来说,可以定义一个第二类参数——最小序号,最小序号对应的约束条件是:如果所述最小序号有效,则所述候选媒体单元的序号应大于或等于最小序号,所述的大于是指该序号在最小序号之后。将该最小序号与起始序号的约束条件进行对比,即可发现,若建立一个映射规则:最小序号=起始序号+1,则起始序号和最小序号对应的约束条件包含的候选媒体单元将完全一样。因此,最小序号和起始序号实际上是等价参数,应看作是同一个第二类参数的不同实施方法,而不应该看作是一个新的第二类参数。
实时传送以RTP实时流为例,媒体单元为一个RTP包,每个RTP包都携带一个包序号。假定第一个产生的RTP包的包序号为1000,最新产生的RTP包的包序号为1020,服务器接收到如下媒体段请求时:
1)GET“http://www.xxx-server.com/msreq?seqBegin=1005”[req5]
该请求只携带了一个第二类参数:起始序号,满足该起始序号对应的约束条件的RTP有15个(包序号从1006到1020),则待发送的候选媒体单元包括这16个RTP包;客户端通过连续提交待有起始序号的请求,服务器可将最近产生的媒体单元返回给客户端,实现媒体流的直播。
2)GET“http://www.xxx-server.com/msreq?seqRange=1010-1015”[req7]
该请求只携带一个第二类参数:序号范围,该序号范围只包括一个序号区间,该序号区间的最小值为1010,最大值为1015,则待发送的候选媒体单元包括所有序号在此范围的媒体单元,即从1010到1015共六个RTP包。通过提交带有序号范围的请求,客户端可以任意指定范围的媒体单元片段,实现时移操作。
3)GET“http://www.xxx-server.com/msreq?seqShiftRange=0-10”[req9]
该请求携带了一个第二类参数:序移范围,所述的待发送的候选媒体单元的序移范围是0到10。由于序移是媒体单元与流起始单元的序号间隔,而流起始单元的序号为1000,因此,上述序移范围指示出候选媒体单元的序号范围是1000到1010,共包括11个RTP包。通过提交带有序移范围的请求,客户端可以获取任意指定范围的媒体单元片段,实现媒体流的时移播放。
非实时传送以MPEG2-TS实时流为例,媒体单元为一个PES包,每个PES包都关联了一个PTS时间戳,该时间戳即为媒体单元的产生时间。假定TS流中的第一个PES包即流起始单元的PTS时间戳为30000,当服务器接收到如下媒体段请求时:
1)GET“http://www.xxx-server.com/msreq?timeBegin=31000”[req6]
该请求只携带了一个第二类参数:起始时间,该起始时间在非实时传送对应的约束条件:如果所述起始时间有效,则所述候选媒体单元的产生时间在所述起始时间之后,且和所述起始时间的间隔小于一个预设值。这里,预设值假定为5000,即候选媒体单元包括时间戳PTS在范围(31000<PTS<=36000)内的所有PES包。通过提交带有起始时间的请求,客户端可以获得从起始时间开始的固定时长的媒体段,实现点播和时移播放。
2)GET“http://www.xxx-server.com/msreq?timeRange=31000-32000”[req8]
该请求只携带了一个第二类参数:产生时间范围。该产生时间范围只包括一个时间区间,其最大值为32000,最小值为31000,因此,所述的候选媒体单元应包括所有时间戳PTS在范围(31000<=Tp<=32000)内的所有PES包;通过提交带有产生时间范围的请求,客户端可以请求任意位置的媒体段,实现点播和时移播放。
3)GET“http://www.xxx-server.com/msreq?timeShiftRange=0-1000”[req13]
该请求携带了一个第二类参数:时移范围。其中,所述的待发送的候选媒体单元的时移范围是0到1000。由于时移是媒体单元与流起始单元的时间间隔,而流起始单元的产生时间即PTS为30000,因此,上述时移范围指示出候选媒体单元包括PTS时间戳在范围(30000<=PTS<=31000)内的所有PES包。通过提交带有时移范围的请求,客户端可以请求任意位置的媒体段,实现点播和时移播放。
根据本发明实施例提出的媒体流的递送方法,根据客户端的请求来实时生成媒体段,并返回给客户端,以实现按客户端需求分段的媒体流递送,媒体分段的时长将自动适应网络传输带宽的变化,客户端可以通过主动请求来***体分段的时长,当客户端与服务器之间的传输带宽充足且延时较小时,客户端可以更快速的提出请求,从而得到时长更短的媒体段,降低实时传输延时;当客户端与服务器之间的传输带宽不足且延时较大时,客户端可以延长提交请求的间隔,从而得到更长的媒体段,减少请求次数以降低传输开销;由于每个媒体段是由客户端的请求触发产生的,不再需要清单文件,客户端也不需要请求和解析清单文件,一方面客户端可以更快速的获得最新的媒体流,减少了实时媒体流的传输延时,另一方面,也降低了清单文件带来的传输开销和处理开销,最后,客户端还可以通过请求来***体段中所封装的媒体单元的范围,为媒体流的直播、点播和时移播放提供统一的递送接口,简化服务器和客户端的实现。
其次参照附图描述根据本发明实施例提出的媒体流的实时递送服务器。
图5是本发明一个实施例的媒体流的实时递送服务器的结构示意图。
如图5所示,该媒体流的实时递送服务器10包括:客户端接口组件100和媒体段生成组件200。
其中,客户端接口组件100用于接收客户端发送的媒体段请求并返回相应的媒体段,其中,媒体段请求不携带或携带至少一个控制参数,且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数。媒体段生成组件200根据媒体段请求生成媒体段,其中,根据第一类参数确定待传送的目标媒体流,确定目标媒体流的流传送类型是实时传送还是非实时传送,根据流传送类型和第二类参数确定待传送的候选媒体单元,并将待传送的候选媒体单元封装成媒体段,并通过客户端接口组件100发送媒体段至客户端。本发明实施例的服务器10根据客户端的请求来实时生成媒体段,并返回给客户端,以实现按客户端需求分段的实时媒体流递送,从而有效降低媒体流传输延时和开销,并为直播、点播和时移播放提供统一的递送方法,简化服务器和客户端的实现。
具体而言,客户端接口组件100用于接收客户端的媒体段请求,以及将生成的媒体段发送给客户端;媒体段请求可以携带0个、1个或多个控制参数;控制参数包括以下类别:第一类参数和第二类参数;第一类参数用于指示待传送的目标媒体流;第二类参数用于指示待传送的候选媒体单元。客户端接口组件可以采用任何指定的协议来接收媒体段请求,例如,当采用HTTP协议时,客户端接口组件可以是一个Web服务器,可以接收任何采用http协议的媒体段请求并且通过HTTP响应来返回媒体段;当采用TCP协议时,客户端接口组件是一个TCP服务器,并提供一个固定的服务端口。
媒体段生成组件200用于根据客户端的媒体段请求来生成所需的媒体段。从客户端接口组件获取媒体段请求及其控制参数,根据第一类参数来确定待传送的目标媒体流,确定目标媒体流的流传送类型为实时传送还是非实时传送,根据流传送类型和第二类参数来确定待传送的候选媒体单元,从媒体流存储单元中提取出待传送的候选媒体单元,将其封装成媒体段,然后直接交由客户端接口组件来发送。
其中,在本发明的一个实施例中,确定目标媒体流的流传送类型的方法为缺省指定。
进一步地,在本发明的一个实施例中,第一类参数包括媒体文件标识,当待传送的目标媒体流由媒体文件标识来指示时,目标媒体流的流传送类型缺省指定为非实时传送。
进一步地,在本发明的一个实施例中,媒体段生成组件200进一步用于在目标媒体流不再产生新的媒体单元的持续时间超过预设时间值时,目标媒体流的流传送类型为非实时传送,否则,目标媒体流的流传送类型为实时传送。
进一步地,在本发明的一个实施例中,媒体段生成组件200进一步用于在媒体段请求不携带第一类参数时,待传送的目标媒体流为缺省指定的媒体流,且在媒体段请求中不携带第二类参数时,候选媒体单元包括根据流传送类型缺省指定的媒体单元。
进一步地,在本发明的一个实施例中,媒体段生成组件300进一步用于在流传送类型为实时传送时,缺省指定的媒体单元为目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元,或者为目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元,且在流传送类型为非实时传送时,缺省指定的媒体单元为目标媒体流中所有和流起始单元的序号间隔小于第三预设值的媒体单元,或者为目标媒体流中所有和流起始单元的产生时间间隔小于第四预设值的媒体单元,其中,流起始单元为媒体流中最早产生的媒体单元。
进一步地,在本发明的一个实施例中,媒体段生成组件300进一步用于在媒体段请求携带至少一个第二类参数,其中,每个第二类参数在指定流传送类型下对应着候选媒体单元的至少一个约束条件时,待传送的候选媒体单元包括目标媒体流中同时满足第二类参数在流传送类型下对应的全部约束条件的所有媒体单元。
进一步地,在本发明的一个实施例中,第二类参数包括起始序号,其中,起始序号在流传送类型为实时传送时,对应的约束条件为:如果起始序号有效,则候选媒体单元的序号在起始序号之后;起始序号在流传送类型为非实时传送时,对应的约束条件为:如果起始序号有效,则候选媒体单元的序号在起始序号之后,且和起始序号的间隔小于一个第一预设间隔值。
进一步地,在本发明的一个实施例中,第二类参数包括序号范围,序号范围包括至少一个序号区间,序号区间指示了序号的最小值和最大值,序号范围在任意流传送类型下对应的约束条件为:如果序号范围有效,则候选媒体单元的序号在序号范围包括的序号区间内。
进一步地,在本发明的一个实施例中,第二类参数包括起始时间,其中,起始时间在流传送类型为实时传送时,对应的约束条件为:如果起始时间有效,则候选媒体单元的产生时间在起始时间之后;起始时间在流传送类型为非实时传送时,对应的约束条件为:如果起始时间有效,则候选媒体单元的产生时间在起始时间之后,且和起始时间的间隔小于一个第二预设间隔值。
进一步地,在本发明的一个实施例中,第二类参数包括产生时间范围,产生时间范围包括至少一个产生时间区间,产生时间区间指示了产生时间的最小值和最大值,产生时间范围在任意流传送类型下对应的约束条件为:如果产生时间范围有效,则候选媒体单元的产生时间在产生时间范围内。
进一步地,在本发明的一个实施例中,每个媒体单元关联有一个序移,序移是指媒体单元与流起始单元的序号间隔,流起始单元是指媒体流中最早产生的媒体单元,第二类参数包括序移范围,序移范围包括至少一个序移区间,序移区间指示了序移的最小值和最大值,序移范围在任意流传送类型下对应的约束条件为:如果序移范围有效,则候选媒体单元的序移在序移范围内。
进一步地,在本发明的一个实施例中,每个媒体单元关联有一个时移,时移是指媒体单元与流起始单元的产生时间间隔,的流起始单元是指媒体流中最早产生的媒体单元,第二类参数包括时移范围,时移范围包括至少一个时移区间,时移区间指示了时移的最小值和最大值,时移范围在任意流传送类型下对应的约束条件为:如果时移范围有效,则候选媒体单元的时移在时移范围内。
根据本发明实施例提出的媒体流的递送服务器,根据客户端的请求来实时生成媒体段,并返回给客户端,以实现按客户端需求分段的媒体流递送,媒体分段的时长将自动适应网络传输带宽的变化,客户端可以通过主动请求来***体分段的时长,当客户端与服务器之间的传输带宽充足且延时较小时,客户端可以更快速的提出请求,从而得到时长更短的媒体段,降低实时传输延时;当客户端与服务器之间的传输带宽不足且延时较大时,客户端可以延长提交请求的间隔,从而得到更长的媒体段,减少请求次数以降低传输开销;由于每个媒体段是由客户端的请求触发产生的,不再需要清单文件,客户端也不需要请求和解析清单文件,一方面客户端可以更快速的获得最新的媒体流,减少了实时媒体流的传输延时,另一方面,也降低了清单文件带来的传输开销和处理开销,最后,客户端还可以通过请求来***体段中所封装的媒体单元的范围,为媒体流的直播、点播和时移播放提供统一的递送接口,简化服务器和客户端的实现。
为了实现上述实施例,本发明实施例还提出了一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,处理器执行程序时,实现如上述实施例描述的媒体流的递送方法。
为了实现上述实施例,本发明实施例还提出了一种非临时性计算机可读存储介质,该程序被处理器执行时实现如上述实施例描述的媒体流的递送方法。
为了实现上述实施例,本发明实施例还提出了一种计算机程序产品,当计算机程序产品中的指令由处理器执行时,执行如上述实施例描述的媒体流的递送方法。
此外,术语“第一”、“第二”仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中,“多个”的含义是至少两个,例如两个,三个等,除非另有明确具体的限定。
在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且,描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外,在不相互矛盾的情况下,本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
尽管上面已经示出和描述了本发明的实施例,可以理解的是,上述实施例是示例性的,不能理解为对本发明的限制,本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。
Claims (28)
1.一种媒体流的递送方法,其特征在于,所述媒体流为媒体单元的序列,其中,每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号,所述方法包括:
接收客户端发送的媒体段请求,其中,所述媒体段请求不携带或携带至少一个控制参数,且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数;
根据所述媒体段请求生成媒体段,其中,根据所述第一类参数确定所述待传送的目标媒体流,确定所述目标媒体流的流传送类型,根据所述流传送类型和所述第二类参数确定所述待传送的候选媒体单元,将所述待传送的候选媒体单元封装成所述媒体段,所述流传送类型为实时传送或非实时传送;以及
发送所述媒体段至所述客户端。
2.根据权利要求1所述的媒体流的递送方法,其特征在于,所述确定目标媒体流的流传送类型的方法为缺省指定。
3.根据权利要求2所述的媒体流的递送方法,其特征在于,所述第一类参数包括媒体文件标识,当所述待传送的目标媒体流由所述媒体文件标识来指示时,所述目标媒体流的流传送类型缺省指定为非实时传送。
4.根据权利要求1所述的媒体流的递送方法,其特征在于,所述确定目标媒体流的流传送类型,包括:
如果所述目标媒体流不再产生新的媒体单元的持续时间超过预设时间值,则所述目标媒体流的流传送类型为非实时传送,否则,所述目标媒体流的流传送类型为实时传送。
5.根据权利要求1所述的媒体流的递送方法,其特征在于,所述根据所述媒体段请求生成媒体段,进一步包括:
如果所述媒体段请求不携带所述第一类参数,则所述待传送的目标媒体流为缺省指定的媒体流;
如果所述媒体段请求中不携带所述第二类参数,则所述候选媒体单元包括根据流传送类型缺省指定的媒体单元。
6.根据权利要求5所述的媒体流的递送方法,其特征在于,所述根据流传送类型缺省指定的媒体单元,包括:
如果所述流传送类型为实时传送,则所述缺省指定的媒体单元为所述目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元,或者为所述目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元;
如果所述流传送类型为非实时传送,则所述缺省指定的媒体单元为所述目标媒体流中所有和流起始单元的序号间隔小于第三预设值的媒体单元,或者为所述目标媒体流中所有和流起始单元的产生时间间隔小于第四预设值的媒体单元;其中,所述流起始单元为媒体流中最早产生的媒体单元。
7.根据权利要求1所述的媒体流的递送方法,其特征在于,所述根据媒体段请求生成媒体段进一步包括:
如果所述媒体段请求携带至少一个所述第二类参数,其中,所述每个第二类参数在指定流传送类型下对应着候选媒体单元的至少一个约束条件,则所述待传送的候选媒体单元包括所述目标媒体流中同时满足所述第二类参数在所述流传送类型下对应的全部约束条件的所有媒体单元。
8.根据权利要求7所述的媒体流的递送方法,其特征在于,所述第二类参数包括起始序号,其中,
所述起始序号在流传送类型为实时传送时,对应的约束条件为:如果所述起始序号有效,则所述候选媒体单元的序号在所述起始序号之后;
所述起始序号在流传送类型为非实时传送时,对应的约束条件为:如果所述起始序号有效,则所述候选媒体单元的序号在所述起始序号之后,且和所述起始序号的间隔小于一个第一预设间隔值。
9.根据权利要求7所述的媒体流的递送方法,其特征在于,所述第二类参数包括序号范围,所述序号范围包括至少一个序号区间,所述序号区间指示了序号的最小值和最大值,所述序号范围在任意流传送类型下对应的约束条件为:
如果序号范围有效,则所述候选媒体单元的序号在所述序号范围包括的序号区间内。
10.根据权利要求7所述的媒体流的递送方法,其特征在于,所述第二类参数包括起始时间,其中,
所述起始时间在所述流传送类型为实时传送时,对应的约束条件为:如果所述起始时间有效,则所述候选媒体单元的产生时间在所述起始时间之后;
所述起始时间在所述流传送类型为非实时传送时,对应的约束条件为:如果所述起始时间有效,则所述候选媒体单元的产生时间在所述起始时间之后,且和所述起始时间的间隔小于一个第二预设间隔值。
11.根据权利要求7所述的媒体流的递送方法,其特征在于,所述第二类参数包括产生时间范围,所述产生时间范围包括至少一个产生时间区间,所述产生时间区间指示了产生时间的最小值和最大值,所述产生时间范围在任意流传送类型下对应的约束条件为:
如果所述产生时间范围有效,则所述候选媒体单元的产生时间在所述产生时间范围内。
12.根据权利要求7所述的媒体流的递送方法,其特征在于,所述每个媒体单元关联有一个序移,所述序移是指媒体单元与流起始单元的序号间隔,所述流起始单元是指媒体流中最早产生的媒体单元,所述第二类参数包括序移范围,所述序移范围包括至少一个序移区间,所述序移区间指示了序移的最小值和最大值,所述序移范围在任意流传送类型下对应的约束条件为:
如果所述序移范围有效,则所述候选媒体单元的序移在所述序移范围内。
13.根据权利要求7所述的媒体流的递送方法,其特征在于,所述每个媒体单元关联有一个时移,所述时移是指媒体单元与流起始单元的产生时间间隔,所述的所述流起始单元是指媒体流中最早产生的媒体单元,所述第二类参数包括时移范围,所述时移范围包括至少一个时移区间,所述时移区间指示了时移的最小值和最大值,所述时移范围在任意流传送类型下对应的约束条件为:
如果所述时移范围有效,则所述候选媒体单元的时移在所述时移范围内。
14.一种媒体流的递送服务器,其特征在于,所述媒体流为媒体单元的序列,其中,每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号,所述服务器包括:
客户端接口组件,用于接收客户端发送的媒体段请求并返回相应的媒体段,其中,所述媒体段请求不携带或携带至少一个控制参数,且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数;
媒体段生成组件,根据所述媒体段请求生成媒体段,其中,根据所述第一类参数确定所述待传送的目标媒体流,确定所述目标媒体流的流传送类型,根据所述流传送类型和所述第二类参数确定所述待传送的候选媒体单元,将所述待传送的候选媒体单元封装成所述媒体段,并通过所述客户端接口组件发送所述媒体段至所述客户端,所述流传送类型为实时传送或非实时传送。
15.根据权利要求14所述的媒体流的递送服务器,其特征在于,所述确定目标媒体流的流传送类型的方法为缺省指定。
16.根据权利要求15所述的媒体流的递送服务器,其特征在于,所述第一类参数包括媒体文件标识,当所述待传送的目标媒体流由所述媒体文件标识来指示时,所述目标媒体流的流传送类型缺省指定为非实时传送。
17.根据权利要求14所述的媒体流的递送服务器,其特征在于,所述媒体段生成组件进一步用于在所述目标媒体流不再产生新的媒体单元的持续时间超过预设时间值时,所述目标媒体流的流传送类型为非实时传送,否则,所述目标媒体流的流传送类型为实时传送。
18.根据权利要求14所述的媒体流的递送服务器,其特征在于,所述媒体段生成组件进一步用于在所述媒体段请求不携带所述第一类参数时,所述待传送的目标媒体流为缺省指定的媒体流,且在所述媒体段请求中不携带所述第二类参数时,所述候选媒体单元包括根据流传送类型缺省指定的媒体单元。
19.根据权利要求18所述的媒体流的递送服务器,其特征在于,所述媒体段生成组件进一步用于在所述流传送类型为实时传送时,所述缺省指定的媒体单元为所述目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元,或者为所述目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元,且在所述流传送类型为非实时传送时,所述缺省指定的媒体单元为所述目标媒体流中所有和流起始单元的序号间隔小于第三预设值的媒体单元,或者为所述目标媒体流中所有和流起始单元的产生时间间隔小于第四预设值的媒体单元,其中,所述流起始单元为媒体流中最早产生的媒体单元。
20.根据权利要求14所述的媒体流的递送服务器,其特征在于,所述媒体段生成组件进一步用于在所述媒体段请求携带至少一个所述第二类参数,其中,所述每个第二类参数在指定流传送类型下对应着候选媒体单元的至少一个约束条件时,所述待传送的候选媒体单元包括所述目标媒体流中同时满足所述第二类参数在所述流传送类型下对应的全部约束条件的所有媒体单元。
21.根据权利要求20所述的媒体流的递送服务器,其特征在于,所述第二类参数包括起始序号,其中,所述起始序号在流传送类型为实时传送时,对应的约束条件为:如果所述起始序号有效,则所述候选媒体单元的序号在所述起始序号之后;所述起始序号在流传送类型为非实时传送时,对应的约束条件为:如果所述起始序号有效,则所述候选媒体单元的序号在所述起始序号之后,且和所述起始序号的间隔小于一个第一预设间隔值。
22.根据权利要求20所述的媒体流的递送服务器,其特征在于,所述第二类参数包括序号范围,所述序号范围包括至少一个序号区间,所述序号区间指示了序号的最小值和最大值,所述序号范围在任意流传送类型下对应的约束条件为:
如果序号范围有效,则所述候选媒体单元的序号在所述序号范围包括的序号区间内。
23.根据权利要求20所述的媒体流的递送服务器,其特征在于,所述第二类参数包括起始时间,其中,
所述起始时间在所述流传送类型为实时传送时,对应的约束条件为:如果所述起始时间有效,则所述候选媒体单元的产生时间在所述起始时间之后;
所述起始时间在所述流传送类型为非实时传送时,对应的约束条件为:如果所述起始时间有效,则所述候选媒体单元的产生时间在所述起始时间之后,且和所述起始时间的间隔小于一个第二预设间隔值。
24.根据权利要求20所述的媒体流的递送服务器,其特征在于,所述第二类参数包括产生时间范围,所述产生时间范围包括至少一个产生时间区间,所述产生时间区间指示了产生时间的最小值和最大值,所述产生时间范围在任意流传送类型下对应的约束条件为:
如果所述产生时间范围有效,则所述候选媒体单元的产生时间在所述产生时间范围内。
25.根据权利要求20所述的媒体流的递送服务器,其特征在于,所述每个媒体单元关联有一个序移,所述序移是指媒体单元与流起始单元的序号间隔,所述流起始单元是指媒体流中最早产生的媒体单元,所述第二类参数包括序移范围,所述序移范围包括至少一个序移区间,所述序移区间指示了序移的最小值和最大值,所述序移范围在任意流传送类型下对应的约束条件为:
如果所述序移范围有效,则所述候选媒体单元的序移在所述序移范围内。
26.根据权利要求20所述的媒体流的递送服务器,其特征在于,所述每个媒体单元关联有一个时移,所述时移是指媒体单元与流起始单元的产生时间间隔,所述的所述流起始单元是指媒体流中最早产生的媒体单元,所述第二类参数包括时移范围,所述时移范围包括至少一个时移区间,所述时移区间指示了时移的最小值和最大值,所述时移范围在任意流传送类型下对应的约束条件为:
如果所述时移范围有效,则所述候选媒体单元的时移在所述时移范围内。
27.一种计算机设备,其特征在于,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其特征在于,所述处理器执行所述程序时,实现如权利要求1-13中任一所述的方法。
28.一种非临时性计算机可读存储介质,其上存储有计算机程序,其特征在于,该程序被处理器执行时实现如权利要求1-13中任一所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811353208.6A CN111193686B (zh) | 2018-11-14 | 2018-11-14 | 媒体流的递送方法及服务器 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811353208.6A CN111193686B (zh) | 2018-11-14 | 2018-11-14 | 媒体流的递送方法及服务器 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111193686A CN111193686A (zh) | 2020-05-22 |
CN111193686B true CN111193686B (zh) | 2021-12-21 |
Family
ID=70710536
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201811353208.6A Active CN111193686B (zh) | 2018-11-14 | 2018-11-14 | 媒体流的递送方法及服务器 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111193686B (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113873343B (zh) * | 2020-06-30 | 2023-02-24 | 北京开广信息技术有限公司 | 媒体流的自适应实时递送方法及服务器 |
CN113596580A (zh) * | 2021-07-28 | 2021-11-02 | 伟乐视讯科技股份有限公司 | 基于srt协议的流媒体数据处理方法、装置及电子设备 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102577272A (zh) * | 2009-10-06 | 2012-07-11 | 微软公司 | 低等待时间的可高速缓存的媒体流式传输 |
CN104937583A (zh) * | 2013-01-18 | 2015-09-23 | 华为技术有限公司 | 一种对媒体内容进行自适应的方法和装置 |
WO2016119735A1 (en) * | 2015-01-30 | 2016-08-04 | Mediatek Inc. | Method and device for adaptive video content delivery using http |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2016536914A (ja) * | 2013-09-13 | 2016-11-24 | ホアウェイ・テクノロジーズ・カンパニー・リミテッド | ストリーミングメディア送信方法及びシステム、ユーザ機器及びサーバ |
-
2018
- 2018-11-14 CN CN201811353208.6A patent/CN111193686B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102577272A (zh) * | 2009-10-06 | 2012-07-11 | 微软公司 | 低等待时间的可高速缓存的媒体流式传输 |
CN104937583A (zh) * | 2013-01-18 | 2015-09-23 | 华为技术有限公司 | 一种对媒体内容进行自适应的方法和装置 |
WO2016119735A1 (en) * | 2015-01-30 | 2016-08-04 | Mediatek Inc. | Method and device for adaptive video content delivery using http |
Also Published As
Publication number | Publication date |
---|---|
CN111193686A (zh) | 2020-05-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6685989B2 (ja) | シグナリング又はブロック生成を用いた拡張ブロック−要求ストリーミングシステム | |
US11477262B2 (en) | Requesting multiple chunks from a network node on the basis of a single request message | |
US10659502B2 (en) | Multicast streaming | |
EP3496365B1 (en) | System and method for optimized delivery of live adaptive bitrate (abr) media | |
EP3090523B1 (en) | Content delivery | |
US10735823B2 (en) | System and method for optimized delivery of live ABR media | |
US20140032777A1 (en) | Method, apparatus, and system for transmitting and processing media content | |
US20170127147A1 (en) | Multicast streaming | |
CN108370281B (zh) | 流式传输内容的多播传送的数据速率适配 | |
EP2391953A1 (en) | Application, usage&radio link aware transport network scheduler | |
EP3391652B1 (en) | Controlling retrieval in adaptive streaming | |
TWI616097B (zh) | 串流裝置及方法、串流服務系統及記錄介質 | |
CN107920072B (zh) | 一种基于数据特征的多媒体共享方法及*** | |
CN111193686B (zh) | 媒体流的递送方法及服务器 | |
CN110086797B (zh) | 媒体流的实时接收方法、客户端、计算机设备和存储介质 | |
CN110072128B (zh) | 媒体流的实时推送方法及服务器 | |
CN111193684B (zh) | 媒体流的实时递送方法及服务器 | |
CN110881018B (zh) | 媒体流的实时接收方法及客户端 | |
Pereira et al. | Dynamic adaptive streaming over http and progressive download: Comparative considerations | |
CN110545492B (zh) | 媒体流的实时递送方法及服务器 | |
CN111654725B (zh) | 媒体流的实时接收方法及客户端 | |
KR102237900B1 (ko) | 클라이언트 단말에 의해 멀티미디어 콘텐츠의 콘텐츠 부분을 검색하기 위한 방법 | |
WO2020048268A1 (zh) | 媒体流的实时递送方法、实时接收方法、服务器及客户端 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |