CN110881018B - 媒体流的实时接收方法及客户端 - Google Patents

媒体流的实时接收方法及客户端 Download PDF

Info

Publication number
CN110881018B
CN110881018B CN201811033268.XA CN201811033268A CN110881018B CN 110881018 B CN110881018 B CN 110881018B CN 201811033268 A CN201811033268 A CN 201811033268A CN 110881018 B CN110881018 B CN 110881018B
Authority
CN
China
Prior art keywords
media
time
media stream
server
media segment
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
Application number
CN201811033268.XA
Other languages
English (en)
Other versions
CN110881018A (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 CN201811033268.XA priority Critical patent/CN110881018B/zh
Priority to PCT/CN2019/098871 priority patent/WO2020048268A1/zh
Publication of CN110881018A publication Critical patent/CN110881018A/zh
Application granted granted Critical
Publication of CN110881018B publication Critical patent/CN110881018B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/75—Media network packet handling
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols

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 TransportProtocol，实时传输协议)/RTSP(Real Time Streaming Protocol，实时流传输协议))、RTMP(Real Time Messaging Protocol，实时消息传送协议)和HTTP(HyperText TransferProtocol，超文本传输协议)自适应性流传输HAS(HTTPAdaptive 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自适应流传输方案均存在两个问题：
问题1，媒体片段的时长无法适应动态变化的网络传输。目前的HAS方案均采用预分段的方式，即服务器按照预先设置的时长来生成媒体片段及其清单文件并提交给web服务器。当网络传输带宽充足且延时较小时，设置较大的片段时长意味着增加实时传送的延时；当网络传输带宽不足且延时较大时，设置较小的片段时长意味着频繁的文件请求，增加服务器的负担和网络传输开销。由于互联网上的传输带宽和传输延时是动态变化的，采用固定时长的预分段方式无法实现最优传输。
问题2，清单文件增加了传送延时和开销。客户端需要先得到清单文件，才能获得媒体片段的URL地址。但是由于清单文件需要经过一段时间才能传输给客户端，因此，客户端得到的清单文件并不能反映当前最新的媒体片段的生成情况，此外，当清单文件遇到阻塞或者传输出错时，将阻塞用户对媒体片段的快速访问，降低实时流媒体的传送性能。
发明内容
本发明旨在至少在一定程度上解决相关技术中的技术问题之一。
为此，本发明的第一个目的在于提出一种媒体流的实时接收方法，该方法可以有效减少传输延时和开销，进一步提高实时媒体流的传输性能。
本发明的第二个目的在于提出一种媒体流的实时接收客户端。
本发明的第三个目的在于提出一种计算机设备。
本发明的第四个目的在于提出一种非临时性计算机可读存储介质。
本发明的第五个目的在于提出一种计算机程序产品。
为达到上述目的，本发明第一方面实施例提出了一种媒体流的实时接收方法，所述的媒体流为实时产生的媒体单元的序列，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，所述方法包括：发送媒体段请求至服务器，所述媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数；接收所述服务器反馈的媒体段，其中，所述媒体段由所述服务器根据所述媒体段请求生成，并封装有指定所述目标媒体流的候选媒体单元；解析所述媒体段，其中，根据所述媒体段中解析出媒体单元，并生成所述媒体单元的接收报告；根据所述媒体单元的接收报告生成新媒体段请求，其中，确定所述新媒体段请求携带的控制参数。
本发明实施例的媒体流的实时接收方法，通过持续向服务器发送媒体段请求，服务器根据接收的媒体段请求来生成媒体段并返回给客户端，并通过请求中携带的参数及发送请求的间隔来控制媒体段的内容及时长，按需生成的媒体段可以更好适应动态的网络传输环境，由于每个媒体段是由客户端的请求触发产生的，不再需要清单文件，也不需要请求和解析清单文件，一方面可以更快速的获得最新的媒体流，减少了实时媒体流的传输延时，另一方面，也降低了清单文件带来的传输开销和处理开销，从而有效减少传输延时和开销，进一步提高实时媒体流的传输性能。
另外，根据本发明上述实施例的媒体流的实时接收方法还可以具有以下附加的技术特征：
进一步地，在本发明的一个实施例中，所述发送媒体段请求至服务器，进一步包括：如果未收到所述服务器发送的任何媒体单元，则向所述服务器发送初始媒体段请求；如果根据所述接收报告生成所述新媒体段请求，则向所述服务器发送所述新媒体段请求。
进一步地，在本发明的一个实施例中，所述第二类参数包括起始序号、单元个数、起始时间和分段时长中的一项或多项。
进一步地，在本发明的一个实施例中，所述接收报告包含当前接收成功的媒体单元的序号，其中，如果所述新媒体段请求携带的第二类参数包括起始序号，则所述起始序号的值为所述当前接收成功的最新媒体单元的下一个单元的序号值。
进一步地，在本发明的一个实施例中，所述接收报告包含当前接收成功的媒体单元的产生时间，其中，如果所述新媒体段请求携带的第二类参数包括起始时间，则所述起始时间的值为所述当前接收成功的最新媒体单元的产生时间。
进一步地，在本发明的一个实施例中，在接收所述服务器反馈的媒体段之前，还包括：在发送所述媒体段请求后，检测所述媒体段的反馈时间；如果所述反馈时间超过预设时间，则终止接收当前媒体段，且解析的媒体段为未完全接收的媒体段。
进一步地，在本发明的一个实施例中，还包括：接收所述服务器发送的媒体流索引信息，其中，所述的媒体流索引信息包含属于同一个内容的多个媒体流描述信息，所述的媒体流描述信息包括媒体流标识和媒体流比特率。
进一步地，在本发明的一个实施例中，所述根据所述媒体单元的接收报告生成新媒体段请求，进一步包括：在所述新媒体段请求携带的第一类参数包括所述媒体流标识时，则根据当前传输速率和所述媒体流索引信息确定所述媒体流标识，并根据所述媒体段的接收时间得到所述当前传输速率。
进一步地，在本发明的一个实施例中，所述接收所述服务器发送的媒体流索引信息，进一步包括：根据接收的媒体段解析得到所述媒体流索引信息，其中，所述的媒体流索引信息由所述服务器封装到所述媒体段中。
为达到上述目的，本发明第二方面实施例提出了一种媒体流的实时接收客户端，所述的媒体流为实时产生的媒体单元的序列，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，所述客户端包括：服务器接口组件，用于发送媒体段请求至服务器，所述媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数，并接收所述服务器反馈的媒体段，其中，所述媒体段由所述服务器根据所述媒体段请求生成，并封装有指定所述目标媒体流的候选媒体单元；媒体段解析组件，用于解析所述媒体段，其中，根据所述媒体段中解析出媒体单元，并生成所述媒体单元的接收报告；媒体流传输控制组件，用于根据所述媒体单元的接收报告生成新媒体段请求，其中，确定所述新媒体段请求携带的控制参数。
本发明实施例的媒体流的实时接收客户端，通过持续向服务器发送媒体段请求，服务器根据接收的媒体段请求来生成媒体段并返回给客户端，并通过请求中携带的参数及发送请求的间隔来控制媒体段的内容及时长，按需生成的媒体段可以更好适应动态的网络传输环境，由于每个媒体段是由客户端的请求触发产生的，不再需要清单文件，也不需要请求和解析清单文件，一方面可以更快速的获得最新的媒体流，减少了实时媒体流的传输延时，另一方面，也降低了清单文件带来的传输开销和处理开销，从而有效减少传输延时和开销，进一步提高实时媒体流的传输性能。
另外，根据本发明上述实施例的媒体流的实时接收客户端还可以具有以下附加的技术特征：
进一步地，在本发明的一个实施例中，所述媒体流传输控制组件进一步用于在未收到所述服务器发送的任何媒体单元时，向所述服务器发送初始媒体段请求，并在根据所述接收报告生成所述新媒体段请求时，向所述服务器发送所述新媒体段请求。
进一步地，在本发明的一个实施例中，所述第二类参数包括起始序号、单元个数、起始时间和分段时长中的一项或多项。
进一步地，在本发明的一个实施例中，所述接收报告包含当前接收成功的媒体单元的序号，其中，如果所述新媒体段请求携带的第二类参数包括起始序号，则所述起始序号的值为所述当前接收成功的最新媒体单元的下一个单元的序号值。
进一步地，在本发明的一个实施例中，所述接收报告包含当前接收成功的媒体单元的产生时间，其中，如果所述新媒体段请求携带的第二类参数包括起始时间，则所述起始时间的值为所述当前接收成功的最新媒体单元的产生时间。
进一步地，在本发明的一个实施例中，在接收所述服务器反馈的媒体段之前，还包括：检测模块，用于在发送所述媒体段请求后，检测所述媒体段的反馈时间，并在所述反馈时间超过预设时间时，终止接收当前媒体段，且解析的媒体段为未完全接收的媒体段。
进一步地，在本发明的一个实施例中，所述媒体流传输控制组件进一步用于接收所述服务器发送的媒体流索引信息，其中，所述的媒体流索引信息包含属于同一个内容的多个媒体流描述信息，所述的媒体流描述信息包括媒体流标识和媒体流比特率。
进一步地，在本发明的一个实施例中，所述媒体流传输控制组件进一步用于在所述新媒体段请求携带的第一类参数包括所述媒体流标识时，则根据当前传输速率和所述媒体流索引信息确定所述媒体流标识，并根据所述媒体段的接收时间得到所述当前传输速率。
进一步地，在本发明的一个实施例中，所述媒体流传输控制组件进一步用于根据接收的媒体段解析得到所述媒体流索引信息，其中，所述的媒体流索引信息由所述服务器封装到所述媒体段中。
进一步地，在本发明的一个实施例中，还包括：媒体回放组件，用于实时回放接收的媒体单元。
为达到上述目的，本发明第三方面实施例提出了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时，实现如上述实施例描述的媒体流的实时接收方法。
为达到上述目的，本发明第四方面实施例提出了一种非临时性计算机可读存储介质，该程序被处理器执行时实现如上述实施例描述的媒体流的实时接收方法。
为达到上述目的，本发明第五方面实施例提出了一种计算机程序产品，当所述计算机程序产品中的指令由处理器执行时，执行如上述实施例描述的媒体流的实时接收方法。
本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。
附图说明
本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
图1为根据本发明一个实施例的媒体流的实时接收方法的流程图；
图2为根据本发明一个实施例的客户端连续提交携带起始序号的媒体段请求的实时传送过程示意图；
图3为根据本发明一个实施例的媒体流的实时接收客户端的结构示意图；
图4为根据本发明一个具体实施例的媒体流的实时接收客户端的结构示意图。
具体实施方式
下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本发明，而不能理解为对本发明的限制。
在互联网中，经常需要将各种实时产生的音频流、视频流或数据流从一个网络节点传送到另一个网络节点，这些网络节点既包括各种终端，如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？unitCount＝8”[req5]
GET“http://www.xxx-server.com/msreq？segDuration＝1000”[req6]
携带两个控制参数的媒体段请求：
GET“http://www.xxx-server.com/msreq？streamID＝602&seqBegin＝1020”[req7]
GET“http://www.xxx-server.com/msreq？streamID＝601&timeBegin＝32000”[req8]
GET“http://www.xxx-server.com/msreq？seqBegin＝1010&unitCount＝5”[req9]
GET“http://www.xxx-server.com/msreq？timeBegin＝31000&segDuration＝3000”[req10]
携带三个控制参数的媒体段请求：
GET“http://www.xxx-server.com/msreq？streamID＝601&seqBegin＝1010&unitCount＝5”[req11]
GET“http://www.xxx-server.com/msreq？streamID＝601&timeBegin＝33000&segDuration＝3000”[req12]
上述请求的URL中，参数名streamID、seqBegin、timeBegin、unitCount、segDuration分别代表媒体流标识、起始序号、起始时间、单元个数、分段时长。
在步骤S102中，接收服务器反馈的媒体段，其中，媒体段由服务器根据媒体段请求生成，并封装有指定目标媒体流的候选媒体单元。
具体而言，客户端可以使用和发送媒体段请求相同的协议来接收服务器返回的媒体段，比如当客户端采用HTTP GET来发送媒体段请求时，即可通过HTTP GET响应消息来接收媒体段。
在步骤S103中，解析媒体段，其中，根据媒体段中解析出媒体单元，并生成媒体单元的接收报告。
具体而言，解析接收的媒体段，包括：从接收的媒体段中解析出媒体单元，生成媒体单元接收报告；媒体段的解析是媒体段封装的逆过程，因此，首先要确定服务器端所采用的封装协议，这可以由服务器端和客户端在传送媒体流之前约定。例如，服务器采用以下自定义封装协议：媒体段有段头和段净荷组成，段净荷由若干个媒体单元级联而成，段头中则指示每个媒体单元的起始位置和长度。此时，对于客户端来说，可以首先通过段头来获得各媒体单元的起始位置和长度，然后从段净荷中解析出各媒体单元。当媒体单元为RTP包时，可以从每个RTP包的包头中，即可得到每个媒体单元的序号和产生时间，根据接收成功的RTP包的序号和产生时间，即可生成媒体单元接收报告。
在步骤S104中，根据媒体单元的接收报告生成新媒体段请求，其中，确定新媒体段请求携带的控制参数。
具体而言，根据媒体单元接收报告生成新的媒体段请求，包括，确定媒体段请求携带的控制参数。客户端可以通过媒体单元接收报告得到当前实时媒体流的接收进度，为了实现实时媒体流的持续接收，客户端生成新的媒体段请求。通过调整新的媒体端请求中携带的控制参数，客户端对下次接收的媒体段的内容进行控制，以保证媒体流的接收效率。
应理解，步骤S101和步骤S104的设置仅为了描述的方便，而不用于限制方法的执行顺序。
以下实施例中，将对客户端如何发送媒体段进行说明。
进一步地，在本发明的一个实施例中，发送媒体段请求至服务器，进一步包括：如果未收到服务器发送的任何媒体单元，则向服务器发送初始媒体段请求；如果根据接收报告生成新媒体段请求，则向服务器发送新媒体段请求。
可以理解的是，当客户端未收到任何媒体单元时，向服务器发送初始媒体段请求；当客户端根据媒体单元接收报告生成新的媒体段请求后，向服务器发送新生成的媒体段请求，其中，初始媒体段请求不携带任何第二类参数，或者包含以下第二类参数之一：起始序号、单元个数、起始时间、分段时长。
具体而言，当客户端未收到任何媒体单元时，向服务器发送初始媒体段请求；当客户端根据媒体单元接收报告生成新的媒体段请求后，立即或在指定的时间向服务器发送新生成的媒体段请求。
以RTP实时流接收为例。初始时，客户端没有收到任何媒体单元，客户端可以立即发送一个初始媒体段请求。初始媒体段请求可以不携带任何第二类参数(如前述列举的req1和req2)，此时，服务器可将实时媒体流最近产生的固定个数(如3个)RTP包封装为媒体段返回客户端，或者将实时媒体流在最近固定时间(例如2秒)内产生的RTP包封装为媒体段返回给客户端。当客户端接收到服务器返回的第一个媒体段时，客户端通过解析媒体段，获得媒体单元接收报告，从中可了解当前已经接收了哪些媒体单元，然后在新生成的媒体段请求，包括，设置新的媒体段请求中的控制参数，以保证下次请求的媒体单元是客户端所需要的。为了控制下次媒体段的时长，客户端可以立即或者通过延时一段时间向服务器发送新生成的媒体段请求。
可选择地，初始媒体段请求可包括一个第二类控制参数：起始序号。起始序号则可以指示客户端期望接收从哪个序号开始的媒体单元。起始序号用来指示客户端期望从哪个序号开始的媒体单元；起始序号的值可以任意指定，比如0。对于服务器来说，起始序号可能是有效的，即该起始序号是最近产生的媒体单元的序号，但当起始序号无效时，服务器会自动选择缺省指定的媒体单元封装为媒体段。
可选择地，初始媒体段请求可包括一个第二类控制参数：单元个数。单元个数用来指示客户端期望接收多少个最近产生的媒体单元，例如10个。
可选择地，初始媒体段请求可包括一个第二类控制参数：起始时间。起始时间用来指示客户端期望从哪个时间点开始的媒体单元；起始时间的值可以任意指定，比如0。对于服务器来说，起始时间可能是有效的，即起始时间举例最新媒体单元的产生时间在一个指定范围内，也可能是无效的。当起始时间是无效时，服务器会自动选择缺省指定的媒体单元封装为媒体段。
可选择地，初始媒体段请求可包括一个第二类控制参数：分段时长。分段时长用来指示客户端期望接收最近多长时间内产生的媒体单元。
一般来说，通过发送初始媒体段请求给服务器，无论是否携带第二类控制参数，客户端可以得到实时媒体流的最新媒体单元，从而了解当前实时媒体流的发送进度，为生成新的媒体段请求提供条件。
此外，当客户端未收到任何媒体单元时，还可以根据与服务器的直接交互来了解实时媒体流的产生情况，比如直接获得实时媒体流的最新媒体单元的序号，这样，可以设置初始媒体段请求中的第二类参数。
以下实施例中，将对客户端如何根据媒体单元接收报告来生成媒体段请求进行说明。
进一步地，在本发明的一个实施例中，接收报告包含当前接收成功的媒体单元的序号，其中，如果新媒体段请求携带的第二类参数包括起始序号，则起始序号的值为当前接收成功的最新媒体单元的下一个单元的序号值。
可以理解的是，媒体单元接收报告指示了当前接收成功的媒体单元的序号；根据媒体单元接收报告生成新的媒体段请求包括：新媒体段请求携带的第二类参数包括起始序号；起始序号的值为当前接收成功的最新媒体单元的下一个单元的序号值，通常来讲，下一个单元的序号值就是在原单元序号值加1，如果序号是循环计数的，则要判断结果是否超过其上限，如果超过，则下一个单元的序号值应重新计数。
具体而言，客户端的媒体单元接收报告由客户端在解析服务器返回的媒体段后产生，用来描述客户端上媒体单元的接收情况，可作为生成新的媒体段请求的参考。以RTP实时流接收为例，每个媒体单元为一个RTP包，媒体单元的序号即为RTP包的序号。一个媒体段可以封装多个RTP包。当客户端从接收的媒体段中解析出RTP包时，通过RTP包头，即可得到该RTP包的包序号。假设一个媒体段中封装了包序号从20到22的3个RTP包，则当客户端完全成功接收这个媒体段时，通过解析媒体段，可以获得一个媒体单元接收报告，该报告即是由成功接收的RTP包序号构成的一个列表：{20，21，22}，此时，客户端生成新的媒体段请求时，可以携带一个第二类参数：起始序号。通过单元接收报告，可知最新媒体单元的序号为22，那么下一个媒体单元的序号应为23，则新媒体段请求中携带的起始序号的值为23。图2给出了客户端连续提交起始序号的传输过程。
以下实施例中，将对客户端如何根据媒体单元接收报告来生成媒体段请求进行说明。
进一步地，在本发明的一个实施例中，接收报告包含当前接收成功的媒体单元的产生时间，其中，如果新媒体段请求携带的第二类参数包括起始时间，则起始时间的值为当前接收成功的最新媒体单元的产生时间。
具体而言，以TS实时流接收为例，每个媒体单元为一个TS片段，一个TS片段封装了固定时间段如1秒左右的多个媒体帧，每个片段中包含的第一个媒体帧的时间戳指明了该片段的产生时间。当一个媒体段封装多个TS片段时，可在该媒体段的头部封装所有TS片段的序号及产生时间。
当客户端接收到返回的媒体段时，可从中解析出多个TS片段，并通过媒体段头，得到每个TS片段的序号及产生时间。假设一个媒体段中封装了包序号从101到103的3个TS片段，则当客户端完全成功接收这个媒体段时，通过解析媒体段，可以获得一个媒体单元接收报告，该报告即是由成功接收的TS片段的序号及其产生时间构成的一个列表：{(101，15000)，(102，20000)，(103，25000)}，此时，客户端生成新的媒体段请求时，可以携带一个第二类参数：起始时间。起始时间的取值即为当前成功接收的最新媒体单元的起始时间。当服务器接收到此请求时，服务器生成媒体段时封装的媒体单元的产生时间必须在此起始时间之后。这样，通过连续提交携带起始时间的媒体段请求，客户端可获得最新产生的未成功接收的媒体单元。
以下实施例中，将对客户端接收媒体段的过程进行说明。
进一步地，在本发明的一个实施例中，在接收服务器反馈的媒体段之前，还包括：在发送媒体段请求后，检测媒体段的反馈时间；如果反馈时间超过预设时间，则终止接收当前媒体段，且解析的媒体段为未完全接收的媒体段。
可以理解的是，接收服务器返回的媒体段必须在一个设定的接收时间之前完成，如果到达该接收时间而未完成，则终止当前媒体段的接收；解析接收的媒体段包括对未完全接收的媒体段的解析。
具体而言，当客户端向服务器发送了媒体段请求后，转入了对服务器返回的媒体段请求的接收。如果服务器和客户端之间的网络传输条件很好，媒体段是能够正常的发送给客户端的。但是，如果服务器和客户端之间的网络传输条件不稳定时，例如发生了链路故障或拥塞等，可能导致媒体段出现错误或丢失。
当媒体段采用TCP或HTTP等面向连接的传输协议时，一旦发生错误，则会启动重传，这种重传可能持续较长时间，从而无法保证实时媒体流传送的实时特性。因此，客户端在发送完媒体段请求后，可以启动一个定时，给媒体段的接收设定一个最迟的接收时间，如果到达此接收时间仍未接收完所请求的媒体段，则应终止当前媒体段的接收，比如自动终止TCP或HTTP连接，并对已接收的部分媒体段进行解析，生成媒体单元接收报告，并重新提交媒体段请求，这样，可以防止由于某个媒体段的接收故障影响后续的实时流接收。
以下实施例中，将对实时媒体流接收时的码率自适应进行说明。
进一步地，在本发明的一个实施例中，还包括：接收服务器发送的媒体流索引信息，其中，媒体流索引信息包含属于同一个内容的多个媒体流描述信息，媒体流描述信息包括媒体流标识和媒体流比特率。
可以理解的是，客户端从服务器获得媒体流索引信息，媒体流索引信息包含了属于同一个内容的若干个媒体流描述信息；媒体流描述信息包括：媒体流标识和媒体流比特率。
其中，在本发明的一个实施例中，根据媒体单元的接收报告生成新媒体段请求，进一步包括：在新媒体段请求携带的第一类参数包括媒体流标识时，则根据当前传输速率和媒体流索引信息确定媒体流标识，并根据媒体段的接收时间得到当前传输速率。
可以理解的是，根据媒体单元接收报告生成新的媒体段请求包括：新的媒体段请求携带的第一类参数包括媒体流标识；媒体流标识可以通过媒体流的当前传输速率及媒体流索引信息来决定；媒体流的当前传输速率可根据媒体段的接收时间来估计。
进一步地，在本发明的一个实施例中，接收服务器发送的媒体流索引信息，进一步包括：根据接收的媒体段解析得到媒体流索引信息，其中，媒体流索引信息由服务器封装到媒体段中。
可以理解的是，客户端从服务器获得媒体流索引信息的方法：客户端从接收的媒体段中解析出媒体流索引信息，媒体流索引信息由服务器封装到发送给客户端的媒体段中。
具体而言，当服务器中存在属于同一个内容的多个实时媒体流时，可以通过不同的媒体流标识来区分这些实时流，并建立起该内容的媒体流索引信息；这个媒体流索引信息实际上包括了媒体流标识和媒体流比特率的映射关系。图中显示了同一个内容(比如一个现场演唱会直播)对应的媒体流索引信息：该内容包括了三个实时媒体流，其中媒体流1(标识为1000，码率为8Mbps)为高清码流，媒体流2(标识为1001，码率为2Mbps)为标清码流，媒体流3(标识为1002，码率为500Kbps)为移动标清流，如表1所示。
表1
媒体流标识 媒体流码率
601 8000Kbps
602 2000Kbps
603 500Kbps
客户端可以通过各种方法从服务器获得指定内容的媒体流索引信息。其中一种方法是：将客户端请求任一个媒体流时，服务器将该媒体流所对应的媒体流索引信息封装到媒体段中返回给客户端，客户端从接收的媒体段中解析出媒体流索引信息。举例来说，当客户端请求媒体流标识为601的实时媒体流，服务器发现媒体流601和其他两个码率的实时媒体流602和603都对应同一个内容，即将该媒体流索引信息{(601,8000)，(602，2000)，(603，500)}封装到媒体段的段头，返回给客户端。客户端解析媒体段的段头，即可获得该索引信息。客户端还可通过其他方法来获得媒体流索引信息，比如直接向服务器发送请求来获取等等。
当客户端发现所请求的内容存在多个码率的实时媒体流时，可以根据当前的媒体流传输速率来自动选择特定码率的实时媒体流，避免出现大量的丢包和延时，以提高客户端的接收性能。为了获得当前的媒体流传输速率，客户端可以记录每个媒体段的接收时间。媒体段的接收时间，是指接收媒体段的全部或部分数据所经过的时间。通过媒体段的接收时间可以估算出当前的媒体流传输速率，一种简单的估算方法是：
媒体流传输速率＝接收数据量/接收时长；
一旦获得了当前的媒体流传输速率，客户端可以从媒体流索引中选择一个码率与该传输速率接近的媒体流，并将其对应的媒体流标识作为新的媒体段请求中携带的第一类参数。例如，当客户端请求媒体流601时，通过接收的媒体段来测算，其实际的媒体流传输速率为3000Kbps，显然，当前的媒体流传输速率远低于媒体流601的实际码率8000Kbps，但高于媒体流602的实际码率2000Kbps，因此，客户端生成新的媒体段请求时，应该将携带的媒体流标识更改为602，以达到较好的传输性能。
当发生媒体流标识的更改时，还可以根据当前码流的接收情况(如接收到的最新媒体单元的序号和产生时间)来确定新的媒体段请求所携带的第二类参数。为了实现完全的平滑切换，属于同一个内容的多个实时媒体流应该是同步产生的，即拥有相同序号或产生时间的媒体单元对应着相同的内容片段(如同一个图像或一段语音等)。
根据本发明实施例提出的媒体流的实时接收方法，通过持续向服务器发送媒体段请求，服务器根据接收的媒体段请求来生成媒体段并返回给客户端，并通过请求中携带的参数及发送请求的间隔来控制媒体段的内容及时长，按需生成的媒体段可以更好适应动态的网络传输环境，客户端可以通过主动请求来控制媒体分段的时长：当客户端与服务器之间的传输带宽充足且延时较小时，客户端可以更快速的提出请求，从而得到时长更短的媒体段，降低实时传输延时；当客户端与服务器之间的传输带宽不足且延时较大时，客户端可以延长提交请求的间隔，从而得到更长的媒体段，减少请求次数以降低传输开销；由于每个媒体段是由客户端的请求触发产生的，不再需要清单文件，也不需要请求和解析清单文件，一方面可以更快速的获得最新的媒体流，减少了实时媒体流的传输延时，另一方面，也降低了清单文件带来的传输开销和处理开销，从而有效减少传输延时和开销，进一步提高实时媒体流的传输性能。
其次参照附图描述根据本发明实施例提出的媒体流的实时接收客户端。
图3是本发明一个实施例的媒体流的实时接收客户端的结构示意图。
如图3所示，该媒体流的实时接收客户端10包括：服务器接口组件100、媒体段解析组件200和媒体流传输控制组件300。
其中，服务器接口组件100用于发送媒体段请求至服务器，媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数，并接收服务器反馈的媒体段，其中，媒体段由服务器根据媒体段请求生成，并封装有指定目标媒体流的候选媒体单元。媒体段解析组件200用于解析媒体段，其中，根据媒体段中解析出媒体单元，并生成媒体单元的接收报告。媒体流传输控制组件300用于根据媒体单元的接收报告生成新媒体段请求，其中，确定新媒体段请求携带的控制参数。本发明实施例的客户端10通过持续向服务器发送媒体段请求，服务器根据接收的媒体段请求来生成媒体段并返回给客户端，并通过请求中携带的参数及发送请求的间隔来控制媒体段的内容及时长，从而有效减少传输延时和开销，进一步提高实时媒体流的传输性能。
在本发明的一个实施例中，服务器接口组件可以使用HTTP协议来发送媒体段请求并接收返回的媒体段。
对于客户端来讲，服务器接口组件100可以采用任何网络传输协议来发送媒体段请求及接收服务器返回的媒体段，如UDP协议，TCP协议和HTTP协议等。当服务器接口组件采用HTTP协议来提交媒体段请求并接收服务器返回的媒体段时，该服务器接口组件包含了HTTP客户端的功能：媒体段请求的参数可以封装为字符串作为HTTP GET的URL的一部分，而服务器生成的媒体段可封装到HTTP GET的响应消息中返回给客户端。
以下实施例中，将对媒体流传输控制组件中生成媒体段请求的方法进行说明。媒体段请求的生成可划分为两个阶段：
阶段1：当媒体流传输控制组件300未收到任何媒体单元接收报告时，生成初始媒体段请求；初始媒体段请求不携带任何第二类参数，或者包含以下第二类参数之一：起始序号、单元个数、起始时间、分段时长；上述第二类参数的值可缺省指定。通过发送初始媒体段请求，客户端可以接收到服务器返回的第一个媒体段，媒体段解析组件200则会产生媒体单元接收报告，发送给媒体流传输控制组件300。
阶段2：当媒体流传输控制组件300接收到媒体单元接收报告时，将根据媒体单元接收报告的内容来生成新的媒体段请求。
当接收的媒体单元接收报告指示了当前接收成功的媒体单元的序号时，生成的媒体段请求中携带的第二类参数包括起始序号；起始序号的值为当前接收成功的最新媒体单元的下一个单元的序号值；
当接收的媒体单元接收报告指示了当前接收成功的媒体单元的产生时间时，生成的媒体段请求中携带的第二类参数包括起始时间；起始时间的值为当前接收成功的最新媒体单元的产生时间。
以下实施例中，将对媒体流传输控制组件中支持码率自适应的媒体段请求的生成方法进行说明。
当同一个内容包括多个不同码率的实时媒体流时，媒体流传输控制组件300还可以支持码率自适应。媒体流传输控制组件300需要首先获得该内容的媒体流索引信息，媒体流索引信息包含了属于同一个内容的若干个媒体流描述信息；媒体流描述信息包括：媒体流标识和媒体流比特率。获取媒体流索引信息的方法可以由客户端主动请求，也可以由服务器主动发送给客户端。
在获得媒体流索引信息后，媒体流传输控制组件300在生成媒体段请求时，可以调整其携带的第一类参数：媒体流标识。媒体流传输控制组件300将根据当前媒体流的当前传输速率和媒体流索引信息来选择媒体流标识，保证所选择的媒体流的比特率与当前传输速率相匹配，以提高传输的可靠性并减少传输延时。媒体流的当前传输速率可根据媒体段的接收时间来估计，比如监测若干个时间段内(比如1秒)接收的数据量。
以下实施例中，将对一种用于客户端接收实时媒体流的方法进行说明。
在一些应用场景中，实时媒体流可以一边接收一边播放，为了支持上述功能，可以在现有的组件基础上引入一个媒体回放组件，由媒体回放组件来实时回放接收的媒体单元，如图4所示：
在具体实现过程中，媒体回放组件的功能可以包含多个处理步骤。以媒体单元为RTP包为例，为了完成RTP包的播放，媒体回放组件首先需要从RTP包中解封装，从RTP净荷中恢复媒体帧，如果该媒体帧采用了压缩，则需要对其进行解压缩，并对解压缩后得到的原始码流进行播放。
进一步地，在本发明的一个实施例中，媒体流传输控制组件300进一步用于在未收到服务器发送的任何媒体单元时，向服务器发送初始媒体段请求，并在根据接收报告生成新媒体段请求时，向服务器发送新媒体段请求。
进一步地，在本发明的一个实施例中，第二类参数包括起始序号、单元个数、起始时间和分段时长中的一项或多项。
进一步地，在本发明的一个实施例中，接收报告包含当前接收成功的媒体单元的序号，其中，如果新媒体段请求携带的第二类参数包括起始序号，则起始序号的值为当前接收成功的最新媒体单元的下一个单元的序号值。
进一步地，在本发明的一个实施例中，接收报告包含当前接收成功的媒体单元的产生时间，其中，如果新媒体段请求携带的第二类参数包括起始时间，则起始时间的值为当前接收成功的最新媒体单元的产生时间。
进一步地，在本发明的一个实施例中，在接收服务器反馈的媒体段之前，本发明实施例的客户端10还包括：检测模块。其中，检测模块用于在发送媒体段请求后，检测媒体段的反馈时间，并在反馈时间超过预设时间时，终止接收当前媒体段，且解析的媒体段为未完全接收的媒体段。
进一步地，在本发明的一个实施例中，媒体流传输控制组件300进一步用于接收服务器发送的媒体流索引信息，其中，媒体流索引信息包含属于同一个内容的多个媒体流描述信息，媒体流描述信息包括媒体流标识和媒体流比特率。
进一步地，在本发明的一个实施例中，媒体流传输控制组件300进一步用于在新媒体段请求携带的第一类参数包括媒体流标识时，则根据当前传输速率和媒体流索引信息确定媒体流标识，并根据媒体段的接收时间得到当前传输速率。
进一步地，在本发明的一个实施例中，媒体流传输控制组件300进一步用于根据接收的媒体段解析得到媒体流索引信息，其中，媒体流索引信息由服务器封装到媒体段中。
需要说明的是，前述对媒体流的实时接收方法实施例的解释说明也适用于该实施例的媒体流的实时接收客户端，此处不再赘述。
根据本发明实施例提出的媒体流的实时接收客户端，通过持续向服务器发送媒体段请求，服务器根据接收的媒体段请求来生成媒体段并返回给客户端，并通过请求中携带的参数及发送请求的间隔来控制媒体段的内容及时长，按需生成的媒体段可以更好适应动态的网络传输环境，客户端可以通过主动请求来控制媒体分段的时长：当客户端与服务器之间的传输带宽充足且延时较小时，客户端可以更快速的提出请求，从而得到时长更短的媒体段，降低实时传输延时；当客户端与服务器之间的传输带宽不足且延时较大时，客户端可以延长提交请求的间隔，从而得到更长的媒体段，减少请求次数以降低传输开销；由于每个媒体段是由客户端的请求触发产生的，不再需要清单文件，也不需要请求和解析清单文件，一方面可以更快速的获得最新的媒体流，减少了实时媒体流的传输延时，另一方面，也降低了清单文件带来的传输开销和处理开销，从而有效减少传输延时和开销，进一步提高实时媒体流的传输性能。
为了实现上述实施例，本发明实施例还提出了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时，实现如上述实施例描述的媒体流的实时接收方法。
为了实现上述实施例，本发明实施例还提出了一种非临时性计算机可读存储介质，该程序被处理器执行时实现如上述实施例描述的媒体流的实时接收方法。
为了实现上述实施例，本发明实施例还提出了一种计算机程序产品，当计算机程序产品中的指令由处理器执行时，执行如上述实施例描述的媒体流的实时接收方法。
此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。
在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (20)

1.一种媒体流的实时接收方法，其特征在于，所述的媒体流为实时产生的媒体单元的序列，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，所述方法包括：
发送媒体段请求至服务器，所述媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数；
接收所述服务器反馈的媒体段，其中，所述媒体段由所述服务器根据所述媒体段请求生成，并封装有指定所述目标媒体流的候选媒体单元；
解析所述媒体段，其中，根据所述媒体段中解析出媒体单元，并生成所述媒体单元的接收报告；以及
根据所述媒体单元的接收报告生成新媒体段请求，其中，确定所述新媒体段请求携带的控制参数。
2.根据权利要求1所述的媒体流的实时接收方法，其特征在于，所述发送媒体段请求至服务器，进一步包括：
如果未收到所述服务器发送的任何媒体单元，则向所述服务器发送初始媒体段请求；
如果根据所述接收报告生成所述新媒体段请求，则向所述服务器发送所述新媒体段请求。
3.根据权利要求1所述的媒体流的实时接收方法，其特征在于，所述第二类参数包括起始序号、单元个数、起始时间和分段时长中的一项或多项。
4.根据权利要求3所述的媒体流的实时接收方法，其特征在于，所述接收报告包含当前接收成功的媒体单元的序号，其中，
如果所述新媒体段请求携带的第二类参数包括起始序号，则所述起始序号的值为所述当前接收成功的最新媒体单元的下一个单元的序号值。
5.根据权利要求3所述的媒体流的实时接收方法，其特征在于，所述接收报告包含当前接收成功的媒体单元的产生时间，其中，
如果所述新媒体段请求携带的第二类参数包括起始时间，则所述起始时间的值为所述当前接收成功的最新媒体单元的产生时间。
6.根据权利要求1所述的媒体流的实时接收方法，其特征在于，在接收所述服务器反馈的媒体段之前，还包括：
在发送所述媒体段请求后，检测所述媒体段的反馈时间；
如果所述反馈时间超过预设时间，则终止接收当前媒体段，且解析的媒体段为未完全接收的媒体段。
7.根据权利要求1所述的媒体流的实时接收方法，其特征在于，还包括：
接收所述服务器发送的媒体流索引信息，其中，所述的媒体流索引信息包含属于同一个内容的多个媒体流描述信息，所述的媒体流描述信息包括媒体流标识和媒体流比特率。
8.根据权利要求7所述的媒体流的实时接收方法，其特征在于，所述根据所述媒体单元的接收报告生成新媒体段请求，进一步包括：
在所述新媒体段请求携带的第一类参数包括所述媒体流标识时，则根据当前传输速率和所述媒体流索引信息确定所述媒体流标识，并根据所述媒体段的接收时间得到所述当前传输速率。
9.根据权利要求7或8所述的媒体流的实时接收方法，其特征在于，所述接收所述服务器发送的媒体流索引信息，进一步包括：
根据接收的媒体段解析得到所述媒体流索引信息，其中，所述的媒体流索引信息由所述服务器封装到所述媒体段中。
10.一种媒体流的实时接收客户端，其特征在于，所述的媒体流为实时产生的媒体单元的序列，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，所述客户端包括：
服务器接口组件，用于发送媒体段请求至服务器，所述媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数，并接收所述服务器反馈的媒体段，其中，所述媒体段由所述服务器根据所述媒体段请求生成，并封装有指定所述目标媒体流的候选媒体单元；
媒体段解析组件，用于解析所述媒体段，其中，根据所述媒体段中解析出媒体单元，并生成所述媒体单元的接收报告；以及
媒体流传输控制组件，用于根据所述媒体单元的接收报告生成新媒体段请求，其中，确定所述新媒体段请求携带的控制参数。
11.根据权利要求10所述的媒体流的实时接收客户端，其特征在于，所述媒体流传输控制组件进一步用于在未收到所述服务器发送的任何媒体单元时，向所述服务器发送初始媒体段请求，并在根据所述接收报告生成所述新媒体段请求时，向所述服务器发送所述新媒体段请求。
12.根据权利要求10所述的媒体流的实时接收客户端，其特征在于，所述第二类参数包括起始序号、单元个数、起始时间和分段时长中的一项或多项。
13.根据权利要求12所述的媒体流的实时接收客户端，其特征在于，所述接收报告包含当前接收成功的媒体单元的序号，其中，
如果所述新媒体段请求携带的第二类参数包括起始序号，则所述起始序号的值为所述当前接收成功的最新媒体单元的下一个单元的序号值。
14.根据权利要求12所述的媒体流的实时接收客户端，其特征在于，所述接收报告包含当前接收成功的媒体单元的产生时间，其中，
如果所述新媒体段请求携带的第二类参数包括起始时间，则所述起始时间的值为所述当前接收成功的最新媒体单元的产生时间。
15.根据权利要求10所述的媒体流的实时接收客户端，其特征在于，在接收所述服务器反馈的媒体段之前，还包括：
检测模块，用于在发送所述媒体段请求后，检测所述媒体段的反馈时间，并在所述反馈时间超过预设时间时，终止接收当前媒体段，且解析的媒体段为未完全接收的媒体段。
16.根据权利要求10所述的媒体流的实时接收客户端，其特征在于，所述媒体流传输控制组件进一步用于接收所述服务器发送的媒体流索引信息，其中，所述的媒体流索引信息包含属于同一个内容的多个媒体流描述信息，所述的媒体流描述信息包括媒体流标识和媒体流比特率。
17.根据权利要求16所述的媒体流的实时接收客户端，其特征在于，所述媒体流传输控制组件进一步用于在所述新媒体段请求携带的第一类参数包括所述媒体流标识时，则根据当前传输速率和所述媒体流索引信息确定所述媒体流标识，并根据所述媒体段的接收时间得到所述当前传输速率。
18.根据权利要求16或17所述的媒体流的实时接收客户端，其特征在于，所述媒体流传输控制组件进一步用于根据接收的媒体段解析得到所述媒体流索引信息，其中，所述的媒体流索引信息由所述服务器封装到所述媒体段中。
19.一种计算机设备，其特征在于，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时，实现如权利要求1-9中任一所述的方法。
20.一种非临时性计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-9中任一所述的方法。
CN201811033268.XA 2018-09-05 2018-09-05 媒体流的实时接收方法及客户端 Active CN110881018B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201811033268.XA CN110881018B (zh) 2018-09-05 2018-09-05 媒体流的实时接收方法及客户端
PCT/CN2019/098871 WO2020048268A1 (zh) 2018-09-05 2019-08-01 媒体流的实时递送方法、实时接收方法、服务器及客户端

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811033268.XA CN110881018B (zh) 2018-09-05 2018-09-05 媒体流的实时接收方法及客户端

Publications (2)

Publication Number Publication Date
CN110881018A CN110881018A (zh) 2020-03-13
CN110881018B true CN110881018B (zh) 2020-11-03

Family

ID=69726974

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811033268.XA Active CN110881018B (zh) 2018-09-05 2018-09-05 媒体流的实时接收方法及客户端

Country Status (1)

Country Link
CN (1) CN110881018B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111601152A (zh) * 2020-05-11 2020-08-28 青岛海信传媒网络技术有限公司 一种直播处理方法及显示设备
CN113873343B (zh) * 2020-06-30 2023-02-24 北京开广信息技术有限公司 媒体流的自适应实时递送方法及服务器

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101969551A (zh) * 2010-09-26 2011-02-09 中兴通讯股份有限公司 一种交互式网络电视系统中的码流分片方法和系统
CN104967872A (zh) * 2015-06-08 2015-10-07 青岛海信移动通信技术股份有限公司 基于动态自适应码率传输协议hls流媒体的直播方法和服务器
CN105306969A (zh) * 2015-09-02 2016-02-03 越亮传奇科技股份有限公司 一种流媒体自适应处理系统及方法
CN105828096A (zh) * 2016-05-19 2016-08-03 网宿科技股份有限公司 媒体流文件的处理方法和装置
CN106537924A (zh) * 2014-07-16 2017-03-22 爱播股份有限公司 用于串流服务的客户端以及服务器的操作方法
CN107925669A (zh) * 2016-01-28 2018-04-17 联发科技股份有限公司 使用速率步调和mpd分段的流应用的方法及系统

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011056139A1 (en) * 2009-11-06 2011-05-12 Telefonaktiebolaget L M Ericsson (Publ). File format for synchronized media
US9756369B2 (en) * 2013-06-19 2017-09-05 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for streaming media data segments of different lengths wherein the segment of different length comprising data not belonging to the actual segment and beginning with key frames or containing key frames only

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101969551A (zh) * 2010-09-26 2011-02-09 中兴通讯股份有限公司 一种交互式网络电视系统中的码流分片方法和系统
CN106537924A (zh) * 2014-07-16 2017-03-22 爱播股份有限公司 用于串流服务的客户端以及服务器的操作方法
CN104967872A (zh) * 2015-06-08 2015-10-07 青岛海信移动通信技术股份有限公司 基于动态自适应码率传输协议hls流媒体的直播方法和服务器
CN105306969A (zh) * 2015-09-02 2016-02-03 越亮传奇科技股份有限公司 一种流媒体自适应处理系统及方法
CN107925669A (zh) * 2016-01-28 2018-04-17 联发科技股份有限公司 使用速率步调和mpd分段的流应用的方法及系统
CN105828096A (zh) * 2016-05-19 2016-08-03 网宿科技股份有限公司 媒体流文件的处理方法和装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
基于时间特性的流媒体缓存;马杰，樊建平;《计算机工程》;20060323;第32卷(第1期);全文 *

Also Published As

Publication number Publication date
CN110881018A (zh) 2020-03-13

Similar Documents

Publication Publication Date Title
US10911506B2 (en) Methods for quality-aware adaptive streaming over hypertext transfer protocol and reporting quality of experience
KR101942208B1 (ko) Dlna http 스트리밍 클라이언트들을 위한 서버측 적응형 비트 레이트 제어
US20140095593A1 (en) Method and apparatus for transmitting data file to client
US11057445B2 (en) Method for adapting the downloading behavior of a client terminal configured, to receive multimedia content, and corresponding terminal
RU2598805C2 (ru) Способ для динамической адаптации частоты следования битов при приеме и соответствующий приемник
WO2011100901A2 (zh) 媒体内容的传输处理方法、装置与系统
TW201540031A (zh) 實現客戶端側的傳送功能的傳輸加速器
WO2012161652A1 (en) Methods for transmitting and receiving a digital signal, transmitter and receiver
CN110086797B (zh) 媒体流的实时接收方法、客户端、计算机设备和存储介质
CN110881018B (zh) 媒体流的实时接收方法及客户端
US20120263063A1 (en) Client Entity, Network Entity and Data Replacement Entity
CN110072128B (zh) 媒体流的实时推送方法及服务器
CN111669665B (zh) 媒体流的实时推送方法及服务器
CN111193686B (zh) 媒体流的递送方法及服务器
WO2020098455A1 (zh) 媒体流的实时递送方法及服务器
CN111654725B (zh) 媒体流的实时接收方法及客户端
CN110545492B (zh) 媒体流的实时递送方法及服务器
KR102237900B1 (ko) 클라이언트 단말에 의해 멀티미디어 콘텐츠의 콘텐츠 부분을 검색하기 위한 방법
WO2020048268A1 (zh) 媒体流的实时递送方法、实时接收方法、服务器及客户端
GB2588930A (en) Multimedia system & method

Legal Events

Date Code Title Description
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