CN111193684A - 媒体流的实时递送方法及服务器 - Google Patents

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

Info

Publication number
CN111193684A
CN111193684A CN201811351129.1A CN201811351129A CN111193684A CN 111193684 A CN111193684 A CN 111193684A CN 201811351129 A CN201811351129 A CN 201811351129A CN 111193684 A CN111193684 A CN 111193684A
Authority
CN
China
Prior art keywords
media
unit
time
candidate
units
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.)
Granted
Application number
CN201811351129.1A
Other languages
English (en)
Other versions
CN111193684B (zh
Inventor
姜红旗
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Kaiguang Information Technology Co ltd
Original Assignee
Beijing Kaiguang Information Technology Co ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Beijing Kaiguang Information Technology Co ltd filed Critical Beijing Kaiguang Information Technology Co ltd
Priority to CN201811351129.1A priority Critical patent/CN111193684B/zh
Priority to PCT/CN2019/112324 priority patent/WO2020098455A1/zh
Publication of CN111193684A publication Critical patent/CN111193684A/zh
Application granted granted Critical
Publication of CN111193684B publication Critical patent/CN111193684B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40Support for services or applications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1074Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H04L67/1078Resource delivery mechanisms
    • H04L67/108Resource delivery mechanisms characterised by resources being split in blocks or fragments

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本发明公开了一种媒体流的实时递送方法及服务器,其中,方法包括:接收客户端发送的媒体段请求,其中,媒体段请求不携带或携带至少一个控制参数,且控制参数包括指示待传送的目标媒体流的第一类参数、指示待传送的候选媒体单元的第二类参数和单元排序方式;根据媒体段请求生成媒体段,其中,根据第一类参数确定待传送的目标媒体流,根据第二类参数确定待传送的候选媒体单元,并将待传送的候选媒体单元按单元排序方式指定的顺序排序并封装成媒体段;发送媒体段至客户端。该方法可以实现按客户端需求分段的实时媒体流递送,从而有效降低媒体流传输延时和开销,并支持对最新媒体单元和高优先级媒体单元的优先传送。

Description

媒体流的实时递送方法及服务器
技术领域
本发明涉及数字信息传送技术领域,特别涉及一种媒体流的实时递送方法及服务器。
背景技术
随着互联网特别是移动互联网的快速发展,通过互联网来实时传送音频、视频、图像等多媒体数据成为许多应用的基本需求,为满足这一需求,人们提出了各种流媒体实时传输技术,目前得到广泛使用的主要包括三类:实时传送协议(RTP(Real-time TransportProtocol,实时传输协议)/RTSP(Real Time Streaming Protocol,实时流传输协议))、RTMP(Real Time Messaging Protocol,实时消息传送协议)和HTTP(HyperText TransferProtocol,超文本传输协议)自适应性流传输HAS(HTTP Adaptive Streaming)。其中,HTTP自适应流传输又包括多种方案:苹果公司提出的HLS(HTTP Live Streaming)、微软提出的平滑流Smooth Streaming、Adobe提出的HDS(HTTP Dynamic 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/TCP协议来传送,一旦发生拥塞,则能传送到客户端的只是这些媒体片段的前半部,而包含较新媒体内容的后半部却无法及时传送。
第四,不支持对高优先级内容的优先传送。在一些应用场景中,媒体流包括了各种不同类型的媒体单元,这些媒体单元的重要性或优先级不同,比如通常音频单元比视频单元的优先级更高;另外,即使同一种类型的媒体单元,也可能因为编码,产生不同的优先级,比如视频编码中,I帧的重要性高于P帧和B帧。当网络传输条件较差导致无法传送所有媒体单元时,为了保证用户的体验,应优先传送高优先级内容,但是,对于现有的HTTP自适应流传输方案来说,由于媒体片段都是预先生成的,无法调整媒体片段的内容,因此,无法支持高优先级内容的优先传送,亟待解决。
发明内容
本发明旨在至少在一定程度上解决相关技术中的技术问题之一。
为此,本发明的第一个目的在于提出一种媒体流的实时递送方法,该方法可以有效降低媒体流传输延时和开销,并支持对最新媒体单元和高优先级媒体单元的优先传送。
本发明的第二个目的在于提出一种媒体流的实时递送服务器。
本发明的第三个目的在于提出一种计算机设备。
本发明的第四个目的在于提出一种非临时性计算机可读存储介质。
本发明的第五个目的在于提出一种计算机程序产品。
为达到上述目的,本发明一方面实施例提出了一种媒体流的实时递送方法,其特征在于,所述媒体流为实时产生的媒体单元的序列,其中,每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号,所述方法包括:接收客户端发送的媒体段请求,其中,所述媒体段请求不携带或携带至少一个控制参数,且控制参数包括指示待传送的目标媒体流的第一类参数、指示待传送的候选媒体单元的第二类参数和单元排序方式;根据所述媒体段请求生成媒体段,其中,根据所述第一类参数确定所述待传送的目标媒体流,根据所述第二类参数确定所述待传送的候选媒体单元,将所述待传送的候选媒体单元按所述单元排序方式指定的顺序排序并封装成所述媒体段;发送所述媒体段至所述客户端。
本发明实施例的媒体流的实时递送方法,根据客户端的请求来实时生成媒体段,并返回给客户端,以实现按客户端需求分段的实时媒体流递送,媒体分段的时长将自动适应网络传输带宽的变化,客户端可以通过主动请求来控制媒体分段的时长,由于每个媒体段是由客户端的请求触发产生的,不再需要清单文件,客户端也不需要请求和解析清单文件,一方面客户端可以更快速的获得最新的媒体流,减少了实时媒体流的传输延时,另一方面,也降低了清单文件带来的传输开销和处理开销,最后,客户端还可以通过请求来控制媒体段中媒体单元的产生时间及排列顺序,在网络传输条件较差时尽可能保证及时发送最新产生的媒体单元或高优先级的媒体单元,从而有效降低媒体流传输延时和开销,并支持对最新媒体单元和高优先级媒体单元的优先传送。
另外,根据本发明上述实施例的媒体流的实时递送方法还可以具有以下附加的技术特征:
进一步地,在本发明的一个实施例中,所述根据所述媒体段请求生成媒体段,进一步包括:如果所述媒体段请求不携带所述第一类参数,则所述待传送的目标媒体流为缺省指定的媒体流;如果所述媒体段请求中不携带所述第二类参数,则所述候选媒体单元包括缺省指定的媒体单元,所述缺省指定的媒体单元为所述目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元,或者为所述目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元;如果所述媒体段请求中不携带所述单元排序方式,则将所述候选媒体单元按照缺省指定的单元排序方式来封装成所述媒体段。
进一步地,在本发明的一个实施例中,所述根据媒体段请求生成媒体段,进一步包括:如果所述媒体段请求携带至少一个所述第二类参数,其中,所述每个第二类参数对应着候选媒体单元的至少一个约束条件,则所述待传送的候选媒体单元包括所述目标媒体流中同时满足所述第二类参数对应的全部约束条件的所有媒体单元。
进一步地,在本发明的一个实施例中,所述每个媒体单元关联有一个序偏,所述序偏是指所述媒体单元与最新媒体单元的序号间隔,所述第二类参数包括起始序号和/或最大序偏,其中,所述起始序号对应的约束条件为:如果所述起始序号有效,则所述候选媒体单元的序号在所述起始序号之后;所述最大序偏对应的约束条件为:如果所述最大序偏有效,则所述候选媒体单元的序偏小于或等于所述最大序偏。
进一步地,在本发明的一个实施例中,所述每个媒体单元关联有一个时偏,所述时偏是指所述媒体单元与最新媒体单元的产生时间间隔,所述第二类参数包括起始时间和/或最大时偏,其中,所述起始时间对应的约束条件为:如果所述起始时间有效,则所述候选媒体单元的产生时间在所述起始时间之后;所述最大时偏对应的约束条件为:如果所述最大时偏有效,则所述候选媒体单元的时偏小于或等于所述最大时偏。
进一步地,在本发明的一个实施例中,所述每个媒体单元关联有一个优先级,所述第二类参数包括最小优先级,所述最小优先级对应的约束条件包括:如果所述最小优先级有效,则所述候选媒体单元的优先级大于或等于最小优先级;如果所述媒体段请求携带的其他第二类参数未限定候选媒体单元的范围,则所述候选媒体单元的范围为缺省指定。
可选地,在本发明的一个实施例中,所述单元排序方式为以下基本排序方式之一:序号正向、序号反向、产生时间正向、产生时间反向。
可选地,在本发明的一个实施例中,所述每个媒体单元关联有一个优先级,所述单元排序方式为以下基本排序方式之一:序号正向、序号反向、产生时间正向、产生时间反向、高优先级优先、低优先级优先。
可选地,在本发明的一个实施例中,所述单元排序方式为多个基本排序方式的级联,所述将候选媒体单元按单元排序方式指定的顺序排序包括:将所述候选媒体单元按照第一基本排序方式排序,且将排序后位置相同的候选媒体单元按照第二基本排序方式排序,依此类推直至完成排序。
为达到上述目的,本发明另一方面实施例提出了一种媒体流的实时递送服务器,所述媒体流为实时产生的媒体单元的序列,其中,每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号,所述服务器包括:客户端接口组件,用于接收客户端发送的媒体段请求并返回相应的媒体段,其中,所述媒体段请求不携带或携带至少一个控制参数,且控制参数包括指示待传送的目标媒体流的第一类参数、指示待传送的候选媒体单元的第二类参数和单元排序方式;媒体段生成组件,根据所述媒体段请求生成媒体段,其中,根据所述第一类参数确定所述待传送的目标媒体流,根据所述第二类参数确定所述待传送的候选媒体单元,将所述待传送的候选媒体单元按单元排序方式指定的顺序排序并封装成所述媒体段,并通过所述客户端接口组件发送所述媒体段至所述客户端。
本发明实施例的媒体流的实时递送服务器,根据客户端的请求来实时生成媒体段,并返回给客户端,以实现按客户端需求分段的实时媒体流递送,媒体分段的时长将自动适应网络传输带宽的变化,客户端可以通过主动请求来控制媒体分段的时长,由于每个媒体段是由客户端的请求触发产生的,不再需要清单文件,客户端也不需要请求和解析清单文件,一方面客户端可以更快速的获得最新的媒体流,减少了实时媒体流的传输延时,另一方面,也降低了清单文件带来的传输开销和处理开销,最后,客户端还可以通过请求来控制媒体段中媒体单元的产生时间及排列顺序,在网络传输条件较差时尽可能保证及时发送最新产生的媒体单元或高优先级的媒体单元,从而有效降低媒体流传输延时和开销,并支持对最新媒体单元和高优先级媒体单元的优先传送。
另外,根据本发明上述实施例的媒体流的实时递送服务器还可以具有以下附加的技术特征:
进一步地,在本发明的一个实施例中,所述媒体段生成组件进一步用于在所述媒体段请求不携带所述第一类参数时,所述待传送的目标媒体流为缺省指定的媒体流,且在所述媒体段请求中不携带所述第二类参数时,所述候选媒体单元包括缺省指定的媒体单元,所述缺省指定的媒体单元为所述目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元,或者为所述目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元,以及在所述媒体段请求中不携带所述单元排序方式时,将所述候选媒体单元按照缺省指定的单元排序方式来封装成所述媒体段。
进一步地,在本发明的一个实施例中,所述媒体段生成组件进一步用于在所述媒体段请求携带至少一个所述第二类参数,其中,所述每个第二类参数对应着候选媒体单元的至少一个约束条件时,所述待传送的候选媒体单元包括所述目标媒体流中同时满足所述第二类参数对应的全部约束条件的所有媒体单元。
进一步地,在本发明的一个实施例中,所述每个媒体单元关联有一个序偏,所述序偏是指所述媒体单元与最新媒体单元的序号间隔,所述第二类参数包括起始序号和/或最大序偏,其中,所述起始序号对应的约束条件为:如果所述起始序号有效,则所述候选媒体单元的序号在所述起始序号之后;所述最大序偏对应的约束条件为:如果所述最大序偏有效,则所述候选媒体单元的序偏小于或等于所述最大序偏。
进一步地,在本发明的一个实施例中,所述每个媒体单元关联有一个时偏,所述时偏是指所述媒体单元与最新媒体单元的产生时间间隔,所述第二类参数包括起始时间和/或最大时偏,其中,所述起始时间对应的约束条件为:如果所述起始时间有效,则所述候选媒体单元的产生时间在所述起始时间之后;所述最大时偏对应的约束条件为:如果所述最大时偏有效,则所述候选媒体单元的时偏小于或等于所述最大时偏。
进一步地,在本发明的一个实施例中,所述每个媒体单元关联有一个优先级,所述第二类参数包括最小优先级,所述最小优先级对应的约束条件包括:如果所述最小优先级有效,则所述候选媒体单元的优先级大于或等于最小优先级;如果所述媒体段请求携带的其他第二类参数未限定候选媒体单元的范围,则所述候选媒体单元的范围为缺省指定。
可选地,在本发明的一个实施例中,所述单元排序方式为以下基本排序方式之一:序号正向、序号反向、产生时间正向、产生时间反向。
可选地,在本发明的一个实施例中,所述每个媒体单元关联有一个优先级,所述单元排序方式为以下基本排序方式之一:序号正向、序号反向、产生时间正向、产生时间反向、高优先级优先、低优先级优先。
可选地,在本发明的一个实施例中,所述单元排序方式为多个基本排序方式的级联,所述将候选媒体单元按单元排序方式指定的顺序排序包括:将所述候选媒体单元按照第一基本排序方式排序,且将排序后位置相同的候选媒体单元按照第二基本排序方式排序,依此类推直至完成排序。
为达到上述目的,本发明第三方面实施例提出了一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时,实现如上述实施例描述的媒体流的实时递送方法。
为达到上述目的,本发明第四方面实施例提出了一种非临时性计算机可读存储介质,该程序被处理器执行时实现如上述实施例描述的媒体流的实时递送方法。
为达到上述目的,本发明第五方面实施例提出了一种计算机程序产品,当所述计算机程序产品中的指令由处理器执行时,执行如上述实施例描述的媒体流的实时递送方法。
本发明附加的方面和优点将在下面的描述中部分给出,部分将从下面的描述中变得明显,或通过本发明的实践了解到。
附图说明
本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解,其中:
图1为根据本发明实施例的媒体流的实时递送方法的流程图;
图2为根据本发明一个实施例的客户端连续提交媒体段请求的实时传送过程示意图;
图3为根据本发明一个实施例的候选媒体单元排序并封装到媒体段的示意图(单元排序方式为序号反向);
图4为根据本发明另一个实施例的候选媒体单元排序并封装到媒体段的示意图(单元排序方式为时间反向);
图5为根据本发明再一个实施例的候选媒体单元排序并封装到媒体段的示意图(单元排序方式为高优先级优先+时间反向);以及
图6为根据本发明实施例的媒体流的实时递送服务器的结构示意图。
具体实施方式
下面详细描述本发明的实施例,所述实施例的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的,旨在用于解释本发明,而不能理解为对本发明的限制。
在互联网中,经常需要将各种实时产生的音频流、视频流或数据流从一个网络节点传送到另一个网络节点,这些网络节点既包括各种终端,如PC、手机、平板,也包括各种应用服务器,如视频服务器、音频服务器,将传送的这些音频流、视频流或数据流统称为媒体流。媒体流的传送过程可以用通用的客户端-服务器模型来描述:实时产生的媒体流由服务器递送给客户端。这里的服务器和客户端指的是逻辑上的功能实体,其中,服务器为发送媒体流的功能实体,客户端为接收媒体流的功能实体。服务器和客户端可存在于任何网络节点上。
每个传送的媒体流是一个实时产生的媒体单元的序列。不同的媒体流,其对应的媒体单元可以自行选择。当媒体流是一个实时产生的字节流时,可以选取一个字节为媒体单元;当媒体流是一个经过实时采样获得的音频流或视频流时,可以选取原始的音频帧或视频帧为媒体单元;当媒体流是一个经过实时采样和编码的音频流或视频流时,可以选择编码后的音频帧、编码后的视频帧或访问单元(Access Unit)为媒体单元;当媒体流是一个经过实时采样、编码和封装的音频流或视频流时,可以选择封装后的传输包(如RTP包,PES/PS/TS包等)为媒体单元;当媒体流是一个经过实时采样、编码、封装和预分段的音频流或视频流时,可以选择一个已分割的媒体片段(如HLS协议中使用的TS格式片段、DASH协议中使用的fMP4格式片段)为媒体单元。
每个媒体单元可以关联一个产生时间,该产生时间通常为一个时间戳。每个媒体单元还可以关联一个序号,该序号可以用来表示媒体单元产生的顺序。当序号用来表示媒体单元产生的顺序时,序号的意义需要根据具体的媒体单元来定义。当媒体单元为一个字节时,媒体单元的序号为字节序号;当媒体单元为音频帧、视频帧时,媒体单元的序号为帧序号;当媒体单元为一个传输包时,媒体单元的序号为包序号;当媒体单元为一个流片段时,媒体单元的序号为片段序号(如HLS中每个TS片段的Media Sequence)。
对于一个媒体流来说,可以同时关联一个表示产生顺序的序号和一个产生时间,比如,当实时媒体流为一个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实时流来说,可以采用类似于HLS/DASH的方式,将TS流分割成固定时长比如1秒左右的TS片段,每个TS片段可包括多个媒体帧,然后将这些片段按产生顺序编上序号,作为媒体单元,每个片段中包含的第一个媒体帧的时间戳指明了该片段的产生时间。
在相关技术中的实时流媒体协议如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?seqBegin=1005”[req3]
GET“http://www.xxx-server.com/msreq?timeBegin=31000”[req4]
GET“http://www.xxx-server.com/msreq?maxSeqOffset=10”[req5]
GET“http://www.xxx-server.com/msreq?maxTimeOffset=2000”[req6]
GET“http://www.xxx-server.com/msreq?minPriority=4”[req7]
GET“http://www.xxx-server.com/msreq?maxPriority=3”[req8]
GET“http://www.xxx-server.com/msreq?unitSortMode=SEQ_BACKWARD”[req9]
携带两个控制参数的媒体段请求:
GET“http://www.xxx-server.com/msreq?seqBegin=1010&maxSeqOffset=5”[req10]
GET“http://www.xxx-server.com/msreq?timeBegin=31000&maxTimeOffset=3000”[req11]
GET“http://www.xxx-server.com/msreq?seqBegin=1010&minPriority=3”[req12]
GET“http://www.xxx-server.com/msreq?timeBegin=31000&
unitSortMode=TIME_BACKWARD”[req13]
GET“http://www.xxx-server.com/msreq?timeBegin=31000&unitSortMode=HIGH_PRIORITY_FIRST”[req14]
GET“http://www.xxx-server.com/msreq?maxTimeOffset=2000&unitSortMode=HIGH_PRIORITY_FIRST+TIME_BACKWARD”[req15]
携带三个控制参数的媒体段请求:
GET“http://www.xxx-server.com/msreq?seqBegin=1010&maxSeqOffset=5&unitSortMode=TIME_BACKWARD”[req16]
GET“http://www.xxx-server.com/msreq?timeBegin=33000&maxTimeOffset=3000&unitSortMode=TIME_BACKWARD”[req17]
上述请求的URL中,参数名streamID、seqBegin、timeBegin、maxSeqOffset、maxTimeOffset、minPriority、maxPriority和unitSortMode分别代表媒体流标识、起始序号、起始时间、最大序偏、最大时偏,最小优先级、最大优先级和单元排序方式。
服务器端可以采用Web服务器来接收上述客户端的媒体段请求,并从请求的URL中提取出相应的控制参数,并对控制参数进行分类:如果是媒体流标识,则该参数为第一类参数;如果为起始序号、起始时间、最大序偏、最大时偏、最小优先级和最大优先级,则为第二类参数。
在步骤S102中,根据媒体段请求生成媒体段,其中,根据第一类参数确定待传送的目标媒体流,根据第二类参数确定待传送的候选媒体单元,并将待传送的候选媒体单元按单元排序方式指定的顺序排序并封装成媒体段。
具体而言,服务器接收到媒体段请求后,可获取媒体段请求中携带的控制参数,然后可以根据其中的第一类参数来确定待传送的目标媒体流,根据携带的第二类参数来确定待传送的候选媒体单元,最后将待传送的候选媒体单元按单元排序方式指定的顺序排序并封装成媒体段。其中,可以采用自定义的封装协议将一个或多个媒体单元封装成媒体段,例如一个简单的封装协议如下:媒体段由段头和段净荷组成,段净荷由若干个媒体单元级联而成,段头中则指示每个媒体单元的起始位置和长度。候选单元在封装成媒体端时,应保证媒体单元在媒体段中的顺序与单元排序方式指定的顺序一致。
在步骤S103中,发送媒体段至客户端。
具体而言,服务器可以根据客户端的媒体段请求所使用的协议来选择适当的方式将媒体段发送给客户端,例如当接收的媒体段请求采用HTTP GET方式时,可以通过HTTPGET响应消息来发送生成的媒体段:将媒体段放入到HTTP响应消息的实体主体中。
当服务器接收到来自客户端的连续的媒体段请求时,服务器将根据客户端的请求来不断生成新的媒体段,这些新的媒体段中封装了最近产生的若干媒体单元,客户端解析这些媒体段,即可恢复出实时媒体流的各媒体单元,实现了媒体流从服务器到客户端的实时传送,这一过程如图2所示。
由于采用了即时生成媒体段的方式,本发明实施例的方法不再需要清单文件,从而降低传输延时和节省开销。此外,客户端可以自行调整发送请求的频率来控制媒体段的时长,以更好的适应网络带宽的变化。
上述是对实施例1的详细阐述,下面将对实施例2进行详细说明,以下实施例中,将对服务器如何根据媒体段请求来生成媒体段做出说明。
进一步地,在本发明的一个实施例中,根据媒体段请求生成媒体段,进一步包括:如果媒体段请求不携带第一类参数,则待传送的目标媒体流为缺省指定的媒体流;如果媒体段请求中不携带第二类参数,则候选媒体单元包括缺省指定的媒体单元,所述缺省指定的媒体单元为所述目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元,或者为所述目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元;如果所述的媒体段请求中不携带所述单元排序方式,则将所述候选媒体单元按照缺省指定的单元排序方式来封装成媒体段。
以RTP实时流为例,媒体单元为一个RTP包,每个RTP包都携带一个包序号。假定最新产生的RTP包的包序号为1020,第一预设值为20,缺省指定的单元排序方式为序号正向,当服务器收到一个不携带任何参数的媒体段请求时如[req1],服务器可从现有的实时媒体流中选择一个作为目标媒体流,则待发送的候选媒体单元包括目标媒体流中最近产生的20个RTP包(包序号从1001到1020),然后将这20个RTP包按序号的先后顺序封装成媒体段。
以TS实时流为例,媒体单元为一个TS片段,每个TS片段都关联了一个产生时间,该产生时间为该TS片段中第一个媒体帧的时间戳。假定最新产生的TS片段的产生时间为33000(单位是微秒),第二预设值为3000,缺省指定的单元排序方式为产生时间正向,当服务器收到一个不携带任何参数的媒体段请求时如[req1],服务器可从现有的实时媒体流中选择一个作为目标媒体流,则待发送的候选媒体单元包括目标媒体流中最近3秒产生的TS片段,即产生时间Tp在范围(30000<Tp<=33000)内的TS片段,然后将这些TS片段按照产生时间的先后顺序封装成媒体段。
采用上述实施方式,每次用户发送的媒体段请求都会返回最近产生的若干个媒体单元。当服务器持续接受到媒体段请求后,会持续将最近产生的媒体单元递送给客户端。
实施例3,以下实施例中,将对服务器如何根据第二类参数来确定待传送的候选媒体单元进行说明。
进一步地,在本发明的一个实施例中,如果所述的媒体段请求携带至少一个所述第二类参数,其中,所述每个第二类参数对应着候选媒体单元的至少一个约束条件,则所述待传送的候选媒体单元包括所述目标媒体流中同时满足所述第二类参数对应的全部约束条件的所有媒体单元。
下面将进一步给出六种第二类参数,以及每种第二类参数对应的约束条件,具体实施时可以根据需要采用其中的一种或多种,也并不限定自行定义其他的第二类参数:
1)起始序号
所述起始序号对应的约束条件为:如果所述起始序号有效,则所述候选媒体单元的序号在所述起始序号之后。
2)最大序偏
一个媒体单元的序偏是指所述媒体单元与最新媒体单元的序号间隔,所述最大序偏对应的约束条件为:如果所述最大序偏有效,则所述的候选媒体单元的序偏小于或等于所述最大序偏。
3)起始时间
所述起始时间对应的约束条件为:如果所述起始时间有效,则所述候选单元的产生时间在起始时间之后。
4)最大时偏
一个媒体单元的时偏是指所述媒体单元与最新媒体单元的产生时间间隔,所述最大时偏的约束条件为:如果所述最大时偏有效,则所述的候选媒体单元的时偏小于或等于所述最大时偏;
5)最小优先级
每个媒体单元关联有一个优先级,所述最小优先级对应的约束条件为:如果所述最小优先级有效,则所述候选媒体单元的优先级大于或等于最小优先级;如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围,则所述候选媒体单元的范围为缺省指定。
6)最大优先级
每个媒体单元关联有一个优先级,所述最大优先级对应的约束条件为:如果所述最大优先级有效,则所述候选媒体单元的优先级小于或等于最大优先级;如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围,则所述候选媒体单元的范围为缺省指定。
上述的第二类参数有效和无效指的是所述参数的值是否在一个指定的范围内。以起始序号为例,该起始序号的值不能超过当前最新媒体单元的序号,另一方面,为保证实时性,起始序号的值不能是早于某个现有媒体单元的序号,在上述范围内的起始序号即为有效。如果某个第二类参数为无效,则等同于不携带这个第二类参数。当所有第二类参数均无效时,所述的候选媒体单元为所述缺省指定的媒体单元。
需要指出的是,在其他的实施方式中,可以定义新的第二类参数,但是,如果在一定的映射规则下,参数A可以映射到参数B,且参数A对应的约束条件可以转换成参数B的约束条件,则称这两个参数为等价参数。等价参数不应看作是多个第二类参数,仍应该看作是同一个参数的不同实施方式。举例来说,可以定义一个第二类参数——最小序号,最小序号对应的约束条件是:如果所述最小序号有效,则所述候选媒体单元的序号应大于或等于最小序号,所述的大于是指该序号在最小序号之后。将该最小序号与起始序号的约束条件进行对比,即可发现,若建立一个映射规则:最小序号=起始序号+1,则起始序号和最小序号对应的约束条件包含的候选媒体单元将完全一样。因此,最小序号和起始序号实际上是等价参数,应看作是同一个第二类参数的不同实施方法,而不应该看作是一个新的第二类参数。
下述实施过程以RTP实时流为例,媒体单元为一个RTP包,每个RTP包都携带一个包序号,用来指示RTP包产生的先后顺序。假定最新产生的RTP包的包序号为1020,服务器接收到如下媒体段请求时:
1)GET“http://www.xxx-server.com/msreq?seqBegin=1005”[req3]
该请求只携带了一个第二类参数:起始序号,满足该起始序号对应的约束条件的RTP有15个(包序号从1006到1020),则待发送的候选媒体单元包括这15个RTP包;
2)GET“http://www.xxx-server.com/msreq?maxSeqOffset=10”[req5]
该请求只携带一个第二类参数:最大序偏,满足该最大序偏对应的约束条件的RTP包有11个(包序号从1010到1020,其中,包序号为1010的RTP包的序偏为10,包序号为1020的RTP包的序偏为0),则待发送的候选媒体单元包括11个RTP包(包序号从1010到1020);
3)GET“http://www.xxx-server.com/msreq?seqBegin=1010&
maxSeqOffset=5”[req10]
该请求携带了两个第二类参数:起始序号和最大序偏,所述的候选单元需要满足两个约束条件,第一个约束条件是候选媒体单元的序号应大于1010,满足该约束条件的候选媒体单元共有10个(包序号从1011到1020),第二个条件是候选媒体单元的序偏不超过5,满足该约束条件的候选媒体单元共有6个RTP包(包序号从1015到1020)。因此,同时满足上述两个约束条件的候选媒体单元包括6个RTP包(包序号从1015到1020)。
下述实施过程以TS实时流为例,媒体单元为一个TS片段,每个TS片段都关联了一个产生时间,该产生时间为该TS片段中第一个媒体帧的时间戳。假定最新产生的TS片段的产生时间为33000(单位是微秒),服务器接收到如下媒体段请求时:
1)GET“http://www.xxx-server.com/msreq?timeBegin=31000”[req4]
该请求只携带了一个第二类参数:起始时间,该起始序号对应的约束条件是TS片段的产生时间应在所述起始时间之后,则候选媒体单元包括产生时间Tp在范围(31000<Tp<=33000)内的所有TS片段;
2)GET“http://www.xxx-server.com/msreq?
maxTimeOffset=2000”[req6]
该请求只携带了一个第二类参数:最大时偏。满足最大时偏的约束条件为:候选媒体单元与最新媒体单元的产生时间间隔小于或等于2000,即候选媒体单元包括产生时间Tp范围(31000<=Tp<=33000)内的所有TS片段;
3)GET“http://www.xxx-server.com/msreq?timeBegin=31000&
maxTimeOffset=3000”[req11]
该请求携带了两个第二类参数:起始时间和最大时偏。其中,起始时间对应的约束条件是TS片段的产生时间应大于31000,则候选媒体单元包括产生时间Tp在范围(31000<Tp<=33000)内的所有TS片段;最大时偏对应的约束条件是候选媒体单元与最新媒体单元的产生时间间隔小于或等于3000,满足该约束条件的候选媒体单元包括产生时间Tp在范围(30000<=Tp<=33000)内的所有TS片段,因此,最终同时满足上述两个约束条件的待发送的候选媒体单元即是产生时间Tp在范围(31000<Tp<=33000)内的所有TS片段。
下述实施过程以带优先级的RTP流为例,媒体单元为一个RTP包,每个RTP包都携带一个包序号,并且根据RTP包携带的净荷内容关联了一个优先级。每个媒体单元的优先级可以根据具体情况来定义,例如,当RTP包为一个多媒体数据流时,可以将RTP包分为三个优先级:
优先级3:RTP包中封装的是音频信息;
优先级2:RTP包中封装的是关键视频信息;
优先级1:RTP包中封装的是非关键视频信息;
假定最新产生的RTP包的包序号为1020,从包序号为1000的RTP包开始,每个RTP包关联的优先级如表1所示。其中,表1为每个RTP包关联的优先级表。
表1
包序号 产生时间 优先级 包序号 产生时间 优先级
1000 29500 3 1011 32000 2
1001 31000 1 1012 32000 3
1002 31000 2 1013 32500 1
1003 31000 2 1014 32500 2
1004 31000 3 1015 32500 2
1005 31500 1 1016 32500 3
1006 31500 2 1017 33000 1
1007 31500 2 1018 33000 2
1008 31500 3 1019 33000 2
1009 32000 1 1020 33000 3
1010 32000 2
服务器接收到如下媒体段请求时:
1)GET“http://www.xxx-server.com/msreq?minPriority=3”[req7]
该请求只携带一个第二类参数:最小优先级,由于没有其他第二类参数来限定媒体单元的范围,因此,候选媒体单元首先需要满足的约束条件是其序号在一个缺省指定的范围内。这里,设第一预设值为20,则缺省指定的序号范围是:从1001到1020的20个RTP包;同时,候选媒体单元还需满足的约束条件是其优先级大于或等于最小优先级,因此,最终同时满足上述约束条件的RTP包有5个(包序号分别为1004,1008,1012,1016和1020)。
2)GET“http://www.xxx-server.com/msreq?maxPriority=1”[req8]
该请求只携带一个第二类参数:最大优先级,由于没有其他第二类参数来限定媒体单元的范围,因此,候选媒体单元首先需要满足的约束条件是其序号在一个缺省指定的范围内。这里,设第一预设值为20,则缺省指定的序号范围是:从1001到1020的20个RTP包;同时,候选媒体单元还需满足的约束条件是其优先级小于或等于最大优先级,因此,最终同时满足上述约束条件的RTP包有5个(包序号分别为1001,1005,1009,1013和1017)。
该实施例中,客户端可以通过连续提交媒体段请求,并通过携带的第二类参数如起始序号或起始时间,即可获得最近产生的媒体单元,实现媒体流的实时传送。当客户端判断网络无法及时传送完所有媒体单元时,可以在媒体段请求中携带第二类参数——最大序偏和最大时偏,服务器将仅传送最新产生的若干媒体单元,丢弃产生较早而没有得到及时传送的媒体单元,以实现客户端对最新媒体内容的优先传送。此外,当客户端判断网络无法及时传送完所有媒体单元时,还可以在媒体段请求中携带第二类参数--最小优先级,服务器将仅传送优先级高于最小优先级的媒体单元,以实现客户端对高优先级媒体单元的优先传送。
实施例4,在以下实施例中,将对服务器在生成媒体段时如何根据单元排序方式来对候选媒体单元排序并封装成媒体段进行说明。
进一步地,在本发明的一个实施例中,所述的单元排序方式为以下基本排序方式之一:序号正向、序号反向、产生时间正向、产生时间反向。当媒体单元关联有一个优先级时,基本排序方式还包括高优先级优先和低优先级优先两种。
可以理解的是,当单元排序方式为序号正向时,候选媒体单元按照序号指示的先后顺序封装到所述媒体段中,即序号越前的媒体单元在媒体段中的位置越靠前;单元排序方式为序号反向时,序号越后的媒体单元在媒体段中的位置越靠前;单元排序方式为产生时间正向时,产生时间越早的媒体单元在媒体段中的位置越靠前;单元排序方式为产生时间反向时,产生时间越晚的媒体单元在媒体段中的位置越靠前;单元排序方式为高优先级优先时,高优先级媒体单元排在低优先级媒体单元前面;单元排序方式为低优先级优先时,低优先级媒体单元排在高优先级媒体单元前面。
对于某些媒体流来说,存在以下情况,多个序号连续的媒体单元的产生时间甚至优先级都可能相同。因此,如果只采用一种基本排序方式(如产生时间反向或高优先级优先)时,仍然存在排序位置相同的多个媒体单元,对于这些媒体单元来说,可以选择一个缺省的基本排序方式(比如序号正向)再排序。另一种实施方法时,单元排序方式可以是多个基本排序方式的级联:第一基本排序方式+第二基本排序方式+第三基本排序方式等等。此时,所述的将候选媒体单元按单元排序方式指定的顺序排序包括:首先将所述的候选媒体单元按照第一基本排序方式排序,然后将排序后位置相同的候选媒体单元按照第二基本排序方式排序,依此类推。如果按照指定的多个基本排序方式排序后,还存在位置相同的媒体单元,则将这些媒体单元按照一个缺省的基本排序方式(序号正向)排序。
下述实施过程以带优先级的RTP流为例,媒体单元为一个RTP包,每个RTP包都携带一个包序号,并且根据RTP包携带的净荷内容关联了一个优先级。每个媒体单元的优先级可以根据具体情况来定义,例如,当RTP包为一个多媒体数据流时,可以将RTP包分为三个优先级:优先级1、优先级2和优先级3。假定最新产生的RTP包的包序号为1020,从包序号为1000的RTP包开始,每个RTP包关联的优先级如表1所示。服务器接收到如下媒体段请求时:
1)GET“http://www.xxx-server.com/msreq?
unitSortMode=SEQ_BACKWARD”[req9]
该请求中不携带第一类参数和第二类参数,因此,所述的目的媒体流为缺省指定的媒体流;所述的候选媒体单元为缺省指定的媒体单元,设第一预设值为20,则缺省指定的媒体单元包括目标媒体流中最近产生的20个RTP包(包序号从1001到1020)。该请求中携带的单元排序方式为序号反向,因此,将这20个RTP包封装到媒体段时,序号越后的媒体单元在媒体段中的位置越靠前,即候选媒体单元封装到媒体段中的顺序如图3所示。
2)GET“http://www.xxx-server.com/msreq?timeBegin=31000&
unitSortMode=TIME_BACKWARD”[req13]
该请求中携带了一个第二类参数:起始时间,因此,所述的候选媒体单元需要满足的约束条件是:RTP包的产生时间在起始时间之后。满足上述约束条件的RTP包共有16个(包序号从1005到1020)。该请求中携带的单元排序方式为时间反向,因此,产生时间越晚(即最新产生)的RTP包在媒体段中的位置越靠前,另外,对于产生时间相同的RTP包,默认的缺省排序方式为序号正向,最终候选媒体单元封装到媒体段中的顺序如图4所示。
3)GET“http://www.xxx-server.com/msreq?maxTimeOffset=2000&
unitSortMode=HIGH_PRIORITY_FIRST+TIME_BACKWARD”[req15]
该请求中携带了一个第二类参数,最大时偏,因此,所述的候选媒体单元需要满足的约束条件是:RTP包的时偏应小于或等于最大时偏。由于最新媒体单元的产生时间为33000,最大时偏为2000,因此,候选媒体单元的产生时间范围应该为产生时间Tp在范围(31000<=Tp<=33000)内的所有RTP包。该请求中携带的单元排序方式为两个基本排序方式的级联:其中第一基本排序方式为高优先级优先,第二基本排序方式为时间反向,因此,首先按照高优先级优先来对候选单元进行排序,然后,对排序后位置相同的候选单元按照时间反向的方式来排序,最后,如果还有位置相同的候选单元,则按照缺省的序号正向来排序,最终候选媒体单元封装到媒体段中的顺序如图5所示。
当网络传送条件较差时,可以通过将请求中的单元排序方式设为序号反向或产生时间反向,这样,可以将最新产生的媒体单元先递送给客户端,保证对最新媒体单元的优先传送。另一方面,还可以通过将单元排序方式设为高优先级优先,将高优先级的媒体单元封装在媒体段的前面,保证客户端对高优先级的媒体单元的优先递送。
根据本发明实施例提出的媒体流的实时递送方法,根据客户端的请求来实时生成媒体段,并返回给客户端,以实现按客户端需求分段的实时媒体流递送,媒体分段的时长将自动适应网络传输带宽的变化,客户端可以通过主动请求来控制媒体分段的时长,当客户端与服务器之间的传输带宽充足且延时较小时,客户端可以更快速的提出请求,从而得到时长更短的媒体段,降低实时传输延时;当客户端与服务器之间的传输带宽不足且延时较大时,客户端可以延长提交请求的间隔,从而得到更长的媒体段,减少请求次数以降低传输开销;由于每个媒体段是由客户端的请求触发产生的,不再需要清单文件,客户端也不需要请求和解析清单文件,一方面客户端可以更快速的获得最新的媒体流,减少了实时媒体流的传输延时,另一方面,也降低了清单文件带来的传输开销和处理开销,最后,客户端还可以通过请求来控制媒体段中媒体单元的产生时间及排列顺序,在网络传输条件较差时尽可能保证及时发送最新产生的媒体单元或优先级较高的媒体单元,从而有效降低媒体流传输延时和开销,并支持对最新媒体单元和高优先级媒体单元的优先传送。
其次参照附图描述根据本发明实施例提出的媒体流的实时递送服务器。
图6是本发明实施例的媒体流的实时递送服务器的结构示意图。
如图6所示,该媒体流的实时递送服务器10包括:客户端接口组件100和媒体段生成组件200。
其中,客户端接口组件100用于接收客户端发送的媒体段请求并返回相应的媒体段,其中,媒体段请求不携带或携带至少一个控制参数,且控制参数包括指示待传送的目标媒体流的第一类参数、指示待传送的候选媒体单元的第二类参数和单元排序方式。媒体段生成组件200根据媒体段请求生成媒体段,其中,根据第一类参数确定待传送的目标媒体流,根据第二类参数确定待传送的候选媒体单元,并将待传送的候选媒体单元按单元排序方式指定的顺序排序并封装成媒体段,并通过客户端接口组件100发送媒体段至客户端。本发明实施例的服务器10可以根据客户端的请求来实时生成媒体段,并返回给客户端,以实现按客户端需求分段的实时媒体流递送,从而有效降低媒体流传输延时和开销,并支持对最新媒体单元和高优先级媒体单元的优先传送。
具体而言,客户端接口组件100用于接收客户端的媒体段请求,以及将生成的媒体段发送给客户端;媒体段请求可以携带0个、1个或多个控制参数;控制参数包括以下类别:第一类参数、第二类参数和单元排序方式;第一类参数用于指示待传送的目标媒体流;第二类参数用于指示待传送的候选媒体单元。客户端接口组件可以采用任何指定的协议来接收媒体段请求,例如,当采用HTTP协议时,客户端接口组件可以是一个Web服务器,可以接收任何采用http协议的媒体段请求并且通过HTTP响应来返回媒体段;当采用TCP协议时,客户端接口组件是一个TCP服务器,并提供一个固定的服务端口。
媒体段生成组件200用于根据客户端的媒体段请求来生成所需的媒体段。从客户端接口组件获取媒体段请求及其控制参数,根据第一类参数来确定待传送的目标媒体流,根据第二类参数来确定待传送的候选媒体单元,从媒体流存储单元中提取出待传送的候选媒体单元,将其按照单元排序方式指定的顺序封装成媒体段,然后直接交由客户端接口组件来发送。
进一步地,在本发明的一个实施例中,媒体段生成组件200进一步用于在媒体段请求不携带第一类参数时,待传送的目标媒体流为缺省指定的媒体流,且在媒体段请求中不携带第二类参数时,候选媒体单元包括缺省指定的媒体单元,缺省指定的媒体单元为目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元,或者为目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元,以及在媒体段请求中不携带单元排序方式时,将候选媒体单元按照缺省指定的单元排序方式来封装成媒体段。
进一步地,在本发明的一个实施例中,媒体段生成组件200进一步用于在媒体段请求携带至少一个第二类参数,其中,每个第二类参数对应着候选媒体单元的至少一个约束条件时,待传送的候选媒体单元包括目标媒体流中同时满足第二类参数对应的全部约束条件的所有媒体单元。
进一步地,在本发明的一个实施例中,每个媒体单元关联有一个序偏,序偏是指媒体单元与最新媒体单元的序号间隔,第二类参数包括起始序号和/或最大序偏,其中,起始序号对应的约束条件为:如果起始序号有效,则候选媒体单元的序号在起始序号之后;最大序偏对应的约束条件为:如果最大序偏有效,则候选媒体单元的序偏小于或等于最大序偏。
进一步地,在本发明的一个实施例中,每个媒体单元关联有一个时偏,时偏是指媒体单元与最新媒体单元的产生时间间隔,第二类参数包括起始时间和/或最大时偏,其中,起始时间对应的约束条件为:如果起始时间有效,则候选媒体单元的产生时间在起始时间之后;最大时偏对应的约束条件为:如果最大时偏有效,则候选媒体单元的时偏小于或等于最大时偏。
进一步地,在本发明的一个实施例中,每个媒体单元关联有一个优先级,第二类参数包括最小优先级,最小优先级对应的约束条件包括:如果最小优先级有效,则候选媒体单元的优先级大于或等于最小优先级;如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围,则候选媒体单元的范围为缺省指定。
可选地,在本发明的一个实施例中,单元排序方式为以下基本排序方式之一:序号正向、序号反向、产生时间正向、产生时间反向。
可选地,在本发明的一个实施例中,每个媒体单元关联有一个优先级,单元排序方式为以下基本排序方式之一:序号正向、序号反向、产生时间正向、产生时间反向、高优先级优先、低优先级优先。
可选地,在本发明的一个实施例中,单元排序方式为多个基本排序方式的级联,将候选媒体单元按单元排序方式指定的顺序排序包括:将候选媒体单元按照第一基本排序方式排序,且将排序后位置相同的候选媒体单元按照第二基本排序方式排序,依此类推直至完成排序。
需要说明的是,前述对媒体流的媒体流的实时递送方法实施例的解释说明也适用于该实施例的媒体流的实时递送服务器,此处不再赘述。
根据本发明实施例提出的媒体流的实时递送服务器,根据客户端的请求来实时生成媒体段,并返回给客户端,以实现按客户端需求分段的实时媒体流递送,媒体分段的时长将自动适应网络传输带宽的变化,客户端可以通过主动请求来控制媒体分段的时长,当客户端与服务器之间的传输带宽充足且延时较小时,客户端可以更快速的提出请求,从而得到时长更短的媒体段,降低实时传输延时;当客户端与服务器之间的传输带宽不足且延时较大时,客户端可以延长提交请求的间隔,从而得到更长的媒体段,减少请求次数以降低传输开销;由于每个媒体段是由客户端的请求触发产生的,不再需要清单文件,客户端也不需要请求和解析清单文件,一方面客户端可以更快速的获得最新的媒体流,减少了实时媒体流的传输延时,另一方面,也降低了清单文件带来的传输开销和处理开销,最后,客户端还可以通过请求来控制媒体段中媒体单元的产生时间及排列顺序,在网络传输条件较差时尽可能保证及时发送最新产生的媒体单元或优先级较高的媒体单元,从而有效降低媒体流传输延时和开销,并支持对最新媒体单元和高优先级媒体单元的优先传送。
为了实现上述实施例,本发明实施例还提出了一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,处理器执行程序时,实现如上述实施例描述的媒体流的实时递送方法。
为了实现上述实施例,本发明实施例还提出了一种非临时性计算机可读存储介质,该程序被处理器执行时实现如上述实施例描述的媒体流的实时递送方法。
为了实现上述实施例,本发明实施例还提出了一种计算机程序产品,当计算机程序产品中的指令由处理器执行时,执行如上述实施例描述的媒体流的实时递送方法。
此外,术语“第一”、“第二”仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中,“多个”的含义是至少两个,例如两个,三个等,除非另有明确具体的限定。
在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且,描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外,在不相互矛盾的情况下,本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
尽管上面已经示出和描述了本发明的实施例,可以理解的是,上述实施例是示例性的,不能理解为对本发明的限制,本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (21)

1.一种媒体流的实时递送方法,其特征在于,所述媒体流为实时产生的媒体单元的序列,其中,每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号,所述方法包括:
接收客户端发送的媒体段请求,其中,所述媒体段请求不携带或携带至少一个控制参数,且控制参数包括指示待传送的目标媒体流的第一类参数、指示待传送的候选媒体单元的第二类参数和单元排序方式;
根据所述媒体段请求生成媒体段,其中,根据所述第一类参数确定所述待传送的目标媒体流,根据所述第二类参数确定所述待传送的候选媒体单元,将所述待传送的候选媒体单元按所述单元排序方式指定的顺序排序并封装成所述媒体段;以及
发送所述媒体段至所述客户端。
2.根据权利要求1所述的媒体流的实时递送方法,其特征在于,所述根据所述媒体段请求生成媒体段,进一步包括:
如果所述媒体段请求不携带所述第一类参数,则所述待传送的目标媒体流为缺省指定的媒体流;
如果所述媒体段请求中不携带所述第二类参数,则所述候选媒体单元包括缺省指定的媒体单元,所述缺省指定的媒体单元为所述目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元,或者为所述目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元;
如果所述媒体段请求中不携带所述单元排序方式,则将所述候选媒体单元按照缺省指定的单元排序方式来封装成所述媒体段。
3.根据权利要求1所述的媒体流的实时递送方法,其特征在于,所述根据媒体段请求生成媒体段,进一步包括:
如果所述媒体段请求携带至少一个所述第二类参数,其中,所述每个第二类参数对应着候选媒体单元的至少一个约束条件,则所述待传送的候选媒体单元包括所述目标媒体流中同时满足所述第二类参数对应的全部约束条件的所有媒体单元。
4.根据权利要求3所述的媒体流的实时递送方法,其特征在于,所述每个媒体单元关联有一个序偏,所述序偏是指所述媒体单元与最新媒体单元的序号间隔,所述第二类参数包括起始序号和/或最大序偏,其中,
所述起始序号对应的约束条件为:如果所述起始序号有效,则所述候选媒体单元的序号在所述起始序号之后;
所述最大序偏对应的约束条件为:如果所述最大序偏有效,则所述候选媒体单元的序偏小于或等于所述最大序偏。
5.根据权利要求3所述的媒体流的实时递送方法,其特征在于,所述每个媒体单元关联有一个时偏,所述时偏是指所述媒体单元与最新媒体单元的产生时间间隔,所述第二类参数包括起始时间和/或最大时偏,其中,
所述起始时间对应的约束条件为:如果所述起始时间有效,则所述候选媒体单元的产生时间在所述起始时间之后;
所述最大时偏对应的约束条件为:如果所述最大时偏有效,则所述候选媒体单元的时偏小于或等于所述最大时偏。
6.根据权利要求3所述的媒体流的实时递送方法,其特征在于,所述每个媒体单元关联有一个优先级,所述第二类参数包括最小优先级,所述最小优先级对应的约束条件包括:
如果所述最小优先级有效,则所述候选媒体单元的优先级大于或等于最小优先级;
如果所述媒体段请求携带的其他第二类参数未限定候选媒体单元的范围,则所述候选媒体单元的范围为缺省指定。
7.根据权利要求1所述的媒体流的实时递送方法,其特征在于,所述单元排序方式为以下基本排序方式之一:序号正向、序号反向、产生时间正向、产生时间反向。
8.根据权利要求1所述的媒体流的实时递送方法,其特征在于,所述每个媒体单元关联有一个优先级,所述单元排序方式为以下基本排序方式之一:序号正向、序号反向、产生时间正向、产生时间反向、高优先级优先、低优先级优先。
9.根据权利要求7或8所述的媒体流的实时递送方法,其特征在于,所述单元排序方式为多个基本排序方式的级联,所述将候选媒体单元按单元排序方式指定的顺序排序包括:将所述候选媒体单元按照第一基本排序方式排序,且将排序后位置相同的候选媒体单元按照第二基本排序方式排序,依此类推直至完成排序。
10.一种媒体流的实时递送服务器,其特征在于,所述媒体流为实时产生的媒体单元的序列,其中,每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号,所述服务器包括:
客户端接口组件,用于接收客户端发送的媒体段请求并返回相应的媒体段,其中,所述媒体段请求不携带或携带至少一个控制参数,且控制参数包括指示待传送的目标媒体流的第一类参数、指示待传送的候选媒体单元的第二类参数和单元排序方式;
媒体段生成组件,根据所述媒体段请求生成媒体段,其中,根据所述第一类参数确定所述待传送的目标媒体流,根据所述第二类参数确定所述待传送的候选媒体单元,将所述待传送的候选媒体单元按单元排序方式指定的顺序排序并封装成所述媒体段,并通过所述客户端接口组件发送所述媒体段至所述客户端。
11.根据权利要求10所述的媒体流的实时递送服务器,其特征在于,所述媒体段生成组件进一步用于在所述媒体段请求不携带所述第一类参数时,所述待传送的目标媒体流为缺省指定的媒体流,且在所述媒体段请求中不携带所述第二类参数时,所述候选媒体单元包括缺省指定的媒体单元,所述缺省指定的媒体单元为所述目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元,或者为所述目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元,以及在所述媒体段请求中不携带所述单元排序方式时,将所述候选媒体单元按照缺省指定的单元排序方式来封装成所述媒体段。
12.根据权利要求10所述的媒体流的实时递送服务器,其特征在于,所述媒体段生成组件进一步用于在所述媒体段请求携带至少一个所述第二类参数,其中,所述每个第二类参数对应着候选媒体单元的至少一个约束条件时,所述待传送的候选媒体单元包括所述目标媒体流中同时满足所述第二类参数对应的全部约束条件的所有媒体单元。
13.根据权利要求12所述的媒体流的实时递送服务器,其特征在于,所述每个媒体单元关联有一个序偏,所述序偏是指所述媒体单元与最新媒体单元的序号间隔,所述第二类参数包括起始序号和/或最大序偏,其中,
所述起始序号对应的约束条件为:如果所述起始序号有效,则所述候选媒体单元的序号在所述起始序号之后;
所述最大序偏对应的约束条件为:如果所述最大序偏有效,则所述候选媒体单元的序偏小于或等于所述最大序偏。
14.根据权利要求12所述的媒体流的实时递送服务器,其特征在于,所述每个媒体单元关联有一个时偏,所述时偏是指所述媒体单元与最新媒体单元的产生时间间隔,所述第二类参数包括起始时间和/或最大时偏,其中,
所述起始时间对应的约束条件为:如果所述起始时间有效,则所述候选媒体单元的产生时间在所述起始时间之后;
所述最大时偏对应的约束条件为:如果所述最大时偏有效,则所述候选媒体单元的时偏小于或等于所述最大时偏。
15.根据权利要求12所述的媒体流的实时递送服务器,其特征在于,所述每个媒体单元关联有一个优先级,所述第二类参数包括最小优先级,所述最小优先级对应的约束条件包括:
如果所述最小优先级有效,则所述候选媒体单元的优先级大于或等于最小优先级;
如果所述媒体段请求携带的其他第二类参数未限定候选媒体单元的范围,则所述候选媒体单元的范围为缺省指定。
16.根据权利要求10所述的媒体流的实时递送服务器,其特征在于,所述单元排序方式为以下基本排序方式之一:序号正向、序号反向、产生时间正向、产生时间反向。
17.根据权利要求10所述的媒体流的实时递送服务器,其特征在于,所述每个媒体单元关联有一个优先级,所述单元排序方式为以下基本排序方式之一:序号正向、序号反向、产生时间正向、产生时间反向、高优先级优先、低优先级优先。
18.根据权利要求16或17所述的媒体流的实时递送服务器,其特征在于,所述单元排序方式为多个基本排序方式的级联,所述将候选媒体单元按单元排序方式指定的顺序排序包括:将所述候选媒体单元按照第一基本排序方式排序,且将排序后位置相同的候选媒体单元按照第二基本排序方式排序,依此类推直至完成排序。
19.一种计算机设备,其特征在于,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其特征在于,所述处理器执行所述程序时,实现如权利要求1-9中任一所述的方法。
20.一种非临时性计算机可读存储介质,其上存储有计算机程序,其特征在于,该程序被处理器执行时实现如权利要求1-9中任一所述的方法。
21.一种计算机程序产品,当所述计算机程序产品中的指令由处理器执行时,执行如权利要求1-9中任一所述的方法。
CN201811351129.1A 2018-11-14 2018-11-14 媒体流的实时递送方法及服务器 Active CN111193684B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201811351129.1A CN111193684B (zh) 2018-11-14 2018-11-14 媒体流的实时递送方法及服务器
PCT/CN2019/112324 WO2020098455A1 (zh) 2018-11-14 2019-10-21 媒体流的实时递送方法及服务器

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811351129.1A CN111193684B (zh) 2018-11-14 2018-11-14 媒体流的实时递送方法及服务器

Publications (2)

Publication Number Publication Date
CN111193684A true CN111193684A (zh) 2020-05-22
CN111193684B CN111193684B (zh) 2021-12-21

Family

ID=70710503

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811351129.1A Active CN111193684B (zh) 2018-11-14 2018-11-14 媒体流的实时递送方法及服务器

Country Status (2)

Country Link
CN (1) CN111193684B (zh)
WO (1) WO2020098455A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113873343A (zh) * 2020-06-30 2021-12-31 北京开广信息技术有限公司 媒体流的自适应实时递送方法及服务器
CN114173145A (zh) * 2021-12-08 2022-03-11 四川启睿克科技有限公司 一种基于hls协议动态码率低延迟直播方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102055773A (zh) * 2009-11-09 2011-05-11 华为技术有限公司 实现基于http的流媒体业务的方法、系统和网络设备
US20160134672A1 (en) * 2014-11-11 2016-05-12 Qualcomm Incorporated Delivering partially received segments of streamed media data
US20160198012A1 (en) * 2013-07-12 2016-07-07 Canon Kabushiki Kaisha Adaptive data streaming method with push messages control
CN106657143A (zh) * 2017-01-20 2017-05-10 中兴通讯股份有限公司 一种流媒体传输方法、装置、服务器及终端
CN107040505A (zh) * 2016-02-04 2017-08-11 中兴通讯股份有限公司 媒体数据传输方法及装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
BR112014003909B1 (pt) * 2011-08-29 2022-10-18 Sling Media Pvt Ltd Sistema de codificação de mídia e respectivo método implementado por computador
CN107920108A (zh) * 2016-10-11 2018-04-17 华为技术有限公司 一种媒体资源的推送方法、客户端及服务器
CN107959667B (zh) * 2016-10-18 2020-10-09 华为技术有限公司 一种媒体分片的推送方法、服务器及客户端
CN106961613A (zh) * 2017-03-30 2017-07-18 上海七牛信息技术有限公司 一种流式实时转码点播方法及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102055773A (zh) * 2009-11-09 2011-05-11 华为技术有限公司 实现基于http的流媒体业务的方法、系统和网络设备
US20160198012A1 (en) * 2013-07-12 2016-07-07 Canon Kabushiki Kaisha Adaptive data streaming method with push messages control
US20160134672A1 (en) * 2014-11-11 2016-05-12 Qualcomm Incorporated Delivering partially received segments of streamed media data
CN107040505A (zh) * 2016-02-04 2017-08-11 中兴通讯股份有限公司 媒体数据传输方法及装置
CN106657143A (zh) * 2017-01-20 2017-05-10 中兴通讯股份有限公司 一种流媒体传输方法、装置、服务器及终端

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113873343A (zh) * 2020-06-30 2021-12-31 北京开广信息技术有限公司 媒体流的自适应实时递送方法及服务器
CN113873343B (zh) * 2020-06-30 2023-02-24 北京开广信息技术有限公司 媒体流的自适应实时递送方法及服务器
CN114173145A (zh) * 2021-12-08 2022-03-11 四川启睿克科技有限公司 一种基于hls协议动态码率低延迟直播方法

Also Published As

Publication number Publication date
CN111193684B (zh) 2021-12-21
WO2020098455A1 (zh) 2020-05-22

Similar Documents

Publication Publication Date Title
US11477262B2 (en) Requesting multiple chunks from a network node on the basis of a single request message
US9979771B2 (en) Adaptive variable fidelity media distribution system and method
US10757453B2 (en) Distributed multi-datacenter video packaging system
US8717890B2 (en) Application, usage and radio link aware transport network scheduler
KR101846382B1 (ko) 전송 계층에서 요청 가속을 시그널링하기 위한 시스템들 및 방법들
US20120124179A1 (en) Traffic management in adaptive streaming protocols
EP2696552A1 (en) Method, system and network for transmitting multimedia data to a plurality of clients
US9596323B2 (en) Transport accelerator implementing client side transmission functionality
US20140095593A1 (en) Method and apparatus for transmitting data file to client
EP2944089A1 (en) Technique for operating client and server devices in a broadcast communication network
US20150271226A1 (en) Transport accelerator implementing a multiple interface architecture
US20110082943A1 (en) P2p network system and data transmitting and receiving method thereof
CN111193684B (zh) 媒体流的实时递送方法及服务器
KR20160134802A (ko) 클라이언트 단말기들과 적어도 하나의 서버 사이의 전송 경로를 따라 배열된 캐시를 동작시키기 위한 방법, 및 대응하는 캐시
CN107920072B (zh) 一种基于数据特征的多媒体共享方法及系统
CN110072128B (zh) 媒体流的实时推送方法及服务器
CN110086797B (zh) 媒体流的实时接收方法、客户端、计算机设备和存储介质
CN111193686B (zh) 媒体流的递送方法及服务器
US10609111B2 (en) Client-driven, ABR flow rate shaping
CN110881018B (zh) 媒体流的实时接收方法及客户端
CN110545492B (zh) 媒体流的实时递送方法及服务器
CN111654725B (zh) 媒体流的实时接收方法及客户端
US10893303B1 (en) Streaming chunked media segments
WO2020048268A1 (zh) 媒体流的实时递送方法、实时接收方法、服务器及客户端
TW201542013A (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