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

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

Info

Publication number
CN110086797A
CN110086797A CN201910324831.7A CN201910324831A CN110086797A CN 110086797 A CN110086797 A CN 110086797A CN 201910324831 A CN201910324831 A CN 201910324831A CN 110086797 A CN110086797 A CN 110086797A
Authority
CN
China
Prior art keywords
media
push
server
media segment
parameter
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
CN201910324831.7A
Other languages
English (en)
Other versions
CN110086797B (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 CN201910324831.7A priority Critical patent/CN110086797B/zh
Publication of CN110086797A publication Critical patent/CN110086797A/zh
Priority to PCT/CN2020/083038 priority patent/WO2020216035A1/zh
Application granted granted Critical
Publication of CN110086797B publication Critical patent/CN110086797B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • 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
    • H04L65/764—Media network packet handling at the destination 
    • 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/50—Network services
    • H04L67/55—Push-based network services

Landscapes

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

Abstract

本发明公开了一种媒体流的实时接收方法及客户端，其中，方法包括：发送第一媒体段请求至服务器，第一媒体段请求携带一个启动推送命令，启动推送命令用于请求服务器启动一个推送任务，启动推送命令不携带或携带至少一个命令参数，命令参数包括：指示待传送的目标媒体流的第一类参数、指示待传送的候选媒体单元特征的第二类参数和分段策略；接收并解析服务器返回的媒体段，从媒体段中解析出媒体单元和/或推送任务标识，其中，服务器根据命令参数生成媒体段，在启动推送命令不携带命令参数时，服务器根据缺省指定生成媒体段。该方法实现媒体流的按需分段推送，简化了服务器端的推送过程，提高了媒体流的传送效率和对大规模自适应推送的支持。

Description

媒体流的实时接收方法及客户端
技术领域
本发明涉及数字信息传送技术领域，特别涉及一种媒体流的实时接收方法及客户端。
背景技术
随着互联网特别是移动互联网的快速发展，通过互联网来实时传送音频、视频、图像等多媒体数据成为许多应用的基本需求，为满足这一需求，人们提出了各种流媒体实时传送技术，根据数据传送的发起方不同，这些流媒体实时传送技术可分为两大类：一类是流拉取方式，基本原理是客户端主动向服务器请求实时数据，采用流拉取方式的技术方案有：苹果公司提出的HLS(HTTP Live Streaming)、微软提出的平滑流Smooth Streaming、Adobe提出的HDS(HTTP Dynamic Streaming)、MPEG组织提出的DASH(Dynamic AdaptiveStreaming over HTTP)；另一类是流推送方式，基本原理是服务器主动向客户端推送实时产生的媒体流，采用流推送方式的技术方案有：实时传送协议(RTP(Real-time TransportProtocol，实时传输协议)/RTSP(Real Time Streaming Protocol，实时流传输协议))、实时消息传送协议(Real Time Messaging Protocol，RTMP)和HTTP-FLV协议。
相对于流拉取方式来说，流推送方式不需要等待客户端的请求，可以将实时产生的媒体流数据快速发送给客户端，实现低延时，因此，在实时性要求较高的应用场合，如带有交互的视频直播、视频监控等，普遍采用这种基于推送的模式。但是，现有的各种流推送方案存在以下问题：
问题1，缺乏对媒体数据的分段推送。在现有各种流推送方案中，一旦媒体数据产生，则立即送入发送缓冲区，但是，如果单个媒体单元的数据量较少，频繁的单次推送将增加网络传输开销，降低传送效率。
问题2，推送控制完全由服务器完成，难以支持大规模自适应推送。在现有各种流推送方案中，推送过程完全由服务器控制，客户端只是被动接收推送的数据。服务器需要为每个客户端维护一个推送进程，用于对媒体流到每个客户端的传输情况进行实时监控，并处理客户端的各种需求变化和互联网上的各种连接异常，如网络拥塞、丢包、连接中断等。由于单个推送进程的处理开销较大，服务器难以支持大规模的自适应媒体流推送。
发明内容
本发明旨在至少在一定程度上解决相关技术中的技术问题之一。
为此，本发明的第一个目的在于提出一种媒体流的实时接收方法，该方法能够实现媒体流的按需分段推送，简化服务器端的推送过程，提高媒体流的传送效率和对大规模自适应推送的支持。
本发明的第二个目的在于提出一种媒体流的实时接收客户端。
本发明的第三个目的在于提出一种计算机设备。
本发明的第四个目的在于提出一种非临时性计算机可读存储介质。
本发明的第五个目的在于提出一种计算机程序产品。
为达到上述目的，本发明第一方面实施例提出了一种媒体流的实时接收方法，所述媒体流为实时产生的媒体单元的序列，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，所述方法包括：
发送第一媒体段请求至服务器，所述第一媒体段请求携带一个启动推送命令，所述启动推送命令用于请求所述服务器启动一个推送任务，所述启动推送命令不携带或携带至少一个命令参数，所述命令参数包括：指示待传送的目标媒体流的第一类参数、指示待传送的候选媒体单元特征的第二类参数和分段策略；
接收并解析所述服务器返回的媒体段，从所述媒体段中解析出媒体单元和/或推送任务标识，其中，在所述启动推送命令携带至少一个所述命令参数时，所述服务器根据所述命令参数生成所述媒体段，在所述启动推送命令不携带所述命令参数时，所述服务器根据缺省指定生成所述媒体段。
本发明实施例的媒体流的实时接收方法，客户端通过向服务器发送媒体段请求来启动推送任务，服务器按照客户端指定的分段策略来对媒体流进行分段和推送，使得服务器可以将小的媒体单元聚合成媒体段，减少推送的次数，提高媒体流的传送效率；其次，简化了服务器端的推送过程，服务器端只需按照客户端指定的策略来生成媒体段并发送给客户端，不再需要复杂的自适应算法来应对传输过程中的各种问题，降低了服务器端需要维护的状态和处理开销，有利于支持大规模的自适应媒体流推送；最后，每个客户端可以根据媒体流的传输情况来随时调整服务器端的推送过程，使得推送过程更快的适应网络条件和客户端需求的变化。
另外，根据本发明上述实施例的媒体流的实时接收方法还可以具有以下附加的技术特征：
在本发明的一个实施例中，所述第二类参数包括起始序号、起始时间和优先级范围中的一项或多项。
在本发明的一个实施例中，所述分段策略为下述策略之一：等序号间隔推送、等时间间隔推送、单元集推送；
当分段策略为等序号间隔推送时，所述分段策略携带以下参数：指定序号间隔；当分段策略为等时间间隔推送时，所述分段策略携带以下参数：指定时间间隔；当分段策略为单元集推送时，所述分段策略携带以下参数：指定单元集个数。
在本发明的一个实施例中，所述方法还包括：
从所述服务器获取所述推送任务的持续时间，并在所述服务器终止所述推送任务前向所述服务器发送第二媒体段请求，所述第二媒体段请求携带了一个继续推送命令，所述继续推送命令用于请求所述服务器延长所述推送任务的持续时间，所述继续推送命令携带的命令参数包括所述推送任务标识。
在本发明的一个实施例中，所述方法还包括：
当不再接收所述媒体段时，向所述服务器发送第三媒体段请求，所述第三媒体段请求携带了一个终止推送命令，所述终止推送命令用于请求所述服务器终止所述推送任务，所述终止推送命令携带的命令参数包括所述推送任务标识。
在本发明的一个实施例中，所述方法还包括：
根据所述媒体段的接收情况对所述推送任务进行调整，其中，向所述服务器发送第四媒体段请求，所述第四媒体段请求携带了一个重启推送命令，所述重启推送命令不携带或携带所述推送任务标识，所述重启推送命令还携带如下至少一个命令参数：指示待传送的目标媒体流的第一类参数、指示待传送的候选媒体单元特征的第二类参数和分段策略。
在本发明的一个实施例中，所述方法还包括：
根据所述媒体段的接收情况判断所述媒体段中是否存在未成功接收的媒体单元，向所述服务器发送第五媒体段请求，所述第五媒体段请求携带了一个媒体段拉取命令，所述媒体段拉取命令用于对所述未成功接收的媒体单元进行拉取，所述媒体段拉取命令不携带或携带下述命令参数中的一项或多项：指示待传送的目标媒体流的第一类参数和指示待拉取的候选媒体单元特征的第二类参数。
为达到上述目的，本发明第二方面实施例提出了一种媒体流的实时接收客户端，所述媒体流为实时产生的媒体单元的序列，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，所述客户端包括：
媒体流传输控制组件，用于根据客户端需求和媒体段的接收情况生成第一媒体段请求，并将生成的所述第一媒体段请求提交给服务器接口组件，所述第一媒体段请求携带至少一个命令，所述命令包括：启动推送命令，所述启动推送命令用于请求所述服务器启动一个推送任务，所述启动推送命令不携带或携带至少一个命令参数，所述命令参数包括：指示待传送的目标媒体流的第一类参数、指示待传送的候选媒体单元特征的第二类参数和分段策略。
服务器接口组件，用于发送所述第一媒体段请求至所述服务器，并接收和解析所述服务器返回的媒体段，从所述媒体段中解析出媒体单元和/或推送任务标识，并将所述推送任务标识及所述媒体段的接收情况提交给媒体流传输控制组件，其中，在所述启动推送命令携带至少一个所述命令参数时，所述服务器根据所述命令参数生成所述媒体段，在所述启动推送命令不携带所述命令参数时，所述服务器根据缺省指定生成所述媒体段。
本发明实施例的媒体流的实时接收客户端，通过向服务器发送媒体段请求来启动推送任务，服务器按照客户端指定的分段策略来对媒体流进行分段和推送，从而，服务器可以将小的媒体单元聚合成媒体段，减少推送的次数，提高媒体流的传送效率；其次，简化了服务器端的推送过程，服务器端只需按照客户端指定的策略来生成媒体段并发送给客户端，不再需要复杂的自适应算法来应对传输过程中的各种问题，降低了服务器端需要维护的状态和处理开销，有利于支持大规模的自适应媒体流推送；最后，每个客户端可以根据媒体流的传输情况来随时调整服务器端的推送过程，使得推送过程更快的适应网络条件和客户端需求的变化。
另外，根据本发明上述实施例的媒体流的实时接收客户端还可以具有以下附加的技术特征：
在本发明的一个实施例中，所述第二类参数包括起始序号、起始时间和优先级范围中的一项或多项。
在本发明的一个实施例中，所述分段策略为下述策略之一：等序号间隔推送、等时间间隔推送、单元集推送；
当分段策略为等序号间隔推送时，所述分段策略携带以下参数：指定序号间隔；当分段策略为等时间间隔推送时，所述分段策略携带以下参数：指定时间间隔；当分段策略为单元集推送时，所述分段策略携带以下参数：指定单元集个数。
在本发明的一个实施例中，所述服务器接口组件，还用于：
从所述服务器获取所述推送任务的持续时间，并在所述服务器终止所述推送任务前向所述服务器发送第二媒体段请求，所述第二媒体段请求携带了一个继续推送命令，所述继续推送命令用于请求所述服务器延长所述推送任务的持续时间，所述继续推送命令携带的命令参数包括所述推送任务标识。
在本发明的一个实施例中，所述服务器接口组件，还用于：
当不再接收所述媒体段时，向所述服务器发送第三媒体段请求，所述第三媒体段请求携带了一个终止推送命令，所述终止推送命令用于请求所述服务器终止所述推送任务，所述终止推送命令携带的命令参数包括所述推送任务标识。
在本发明的一个实施例中，所述媒体流传输控制组件，还用于：
根据所述媒体段的接收情况对所述推送任务进行调整，生成第四媒体段请求，并将所述第四媒体段请求提交给所述服务器接口组件，所述第四媒体段请求携带了一个重启推送命令，所述重启推送命令携带所述推送任务标识，所述重启推送命令不携带或携带如下至少一个命令参数：指示待传送的目标媒体流的第一类参数、指示待传送的候选媒体单元特征的第二类参数和分段策略。
所述服务器接口组件，还用于：
向所述服务器发送所述第四媒体段请求。
在本发明的一个实施例中，所述媒体流传输控制组件，还用于：
根据所述媒体段的接收情况判断所述媒体段中是否存在未成功接收的媒体单元，根据所述未成功接收的媒体单元生成第五媒体段请求，并将所述第五媒体段请求提交给所述服务器接口组件，其中，所述第五媒体段请求携带了一个媒体段拉取命令，所述媒体段拉取命令用于对所述未成功接收的媒体单元进行拉取，所述媒体段拉取命令不携带或携带下述命令参数中的一项或多项：指示待传送的目标媒体流的第一类参数和指示待拉取的候选媒体单元特征的第二类参数；
所述服务器接口组件，还用于：
向所述服务器发送所述第五媒体段请求。
进一步地，在本发明的一个实施例中，还包括：媒体回放组件，用于实时回放解析出的所述媒体单元。
为达到上述目的，本发明第三方面实施例提出了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时，实现如上述实施例描述的媒体流的实时接收方法。
为达到上述目的，本发明第四方面实施例提出了一种非临时性计算机可读存储介质，该程序被处理器执行时实现如上述实施例描述的媒体流的实时接收方法。
为达到上述目的，本发明第五方面实施例提出了一种计算机程序产品，当所述计算机程序产品中的指令由处理器执行时，执行如上述实施例描述的媒体流的实时接收方法。
本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。
附图说明
本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
图1为根据本发明一个实施例的媒体流的实时接收方法的流程图；
图2为根据本发明一个实施例的客户端实时接收媒体流过程示意图；
图3为根据本发明一个实施例的分段策略为等时间间隔推送的推送过程的示意图；
图4为根据本发明一个实施例的分段策略为单元集推送的推送过程的示意图；
图5为根据本发明一个实施例的客户端发送继续推送命令来延长推送任务的过程示意图；
图6为根据本发明一个实施例的客户端快速终止推送任务的过程示意图；
图7为根据本发明一个实施例的根据重启推送命令调整分段策略的过程示意图；
图8为根据本发明一个实施例的客户端主动请求切换目标媒体流的过程示意图；
图9为根据本发明一个实施例的媒体流的实时接收客户端的结构示意图；
图10为根据本发明一个具体实施例的媒体流的实时接收客户端的结构示意图。
具体实施方式
下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本发明，而不能理解为对本发明的限制。
在互联网中，经常需要将各种实时产生的音频流、视频流或数据流从一个网络节点传送到另一个网络节点，这些网络节点既包括各种终端，如PC、手机、平板，也包括各种应用服务器，如视频服务器、音频服务器，将传送的这些音频流、视频流或数据流统称为媒体流。媒体流的传送过程可以用通用的客户端－服务器模型来描述：实时产生的媒体流由服务器递送给客户端。这里的服务器和客户端指的是逻辑上的功能实体，其中，服务器为发送媒体流的功能实体，客户端为接收媒体流的功能实体。服务器和客户端可存在于任何网络节点上。
每个传送的媒体流是一个实时产生的媒体单元的序列。不同的媒体流，其对应的媒体单元可以自行选择。当媒体流是一个实时产生的字节流时，可以选取一个字节为媒体单元；当媒体流是一个经过实时采样获得的音频流或视频流时，可以选取原始的音频帧或视频帧为媒体单元；当媒体流是一个经过实时采样和编码的音频流或视频流时，可以选择编码后的音频帧、编码后的视频帧或访问单元(Access Unit)为媒体单元；当媒体流是一个经过实时采样、编码和封装的音频流或视频流时，可以选择封装后的传输包(如RTP包，PES/PS/TS包等)为媒体单元；当媒体流是一个经过实时采样、编码、封装和预分段的音频流或视频流时，可以选择一个已分割的媒体片段(如HLS协议中使用的TS格式片段、DASH协议中使用的fMP4格式片段)为媒体单元。
每个媒体单元可以关联一个产生时间，该产生时间通常为一个时间戳。每个媒体单元还可以关联一个序号，该序号可以用来表示媒体单元产生的顺序。当序号用来表示媒体单元产生的顺序时，序号的意义需要根据具体的媒体单元来定义。当媒体单元为一个字节时，媒体单元的序号为字节序号；当媒体单元为音频帧、视频帧时，媒体单元的序号为帧序号；当媒体单元为一个传输包时，媒体单元的序号为包序号；当媒体单元为一个流片段时，媒体单元的序号为片段序号(如HLS中每个TS片段的Media Sequence)。
对于一个媒体流来说，可以给媒体单元同时关联一个表示产生顺序的序号和一个产生时间，例如，当实时媒体流为一个RTP包流时，RTP头部既有包序号(Sequence Number)字段来指示RTP包的顺序，又有Time-stamp字段来指示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-FLV中，采用的是服务器主动推送的方式：服务器上一旦有新的媒体单元，则主动发送给客户端，并不涉及到对媒体流的分段封装，而在各种HTTP自适应流(如HLS、平滑流，MPEG-DASH)中，则采用了预分段的方式，媒体流按照固定的时间长度来生成媒体片段并发布清单文件，然后等待客户端的拉取。与上述这些方式都不同的是，在本发明实施例中，客户端向服务器发送请求，服务器按照客户端请求中的分段策略对媒体流进行实时分段并推送，客户端可以随时调整媒体流的分段策略。
下面参照附图描述根据本发明实施例提出的媒体流的实时接收方法及客户端，首先将参照附图描述根据本发明实施例提出的媒体流的实时接收方法。
图1是本发明一个实施例的媒体流的实时接收方法的流程图。
如图1所示，该媒体流的实时接收方法，媒体流为实时产生的媒体单元的序列，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，方法包括以下步骤：
在步骤S101中，发送第一媒体段请求至服务器，第一媒体段请求携带一个启动推送命令，用于请求服务器启动一个推送任务，启动推送命令不携带或携带至少一个命令参数，命令参数包括：指示待传送的目标媒体流的第一类参数、指示待传送的候选媒体单元特征的第二类参数和分段策略。
具体而言，客户端可以采用任何网络传输协议来提交媒体段请求，比如常见的超文本传输协议(HyperText Transfer Protocol，HTTP)、传输控制协议(TransmissionControl Protocol，TCP)、用户数据报协议(User Datagram Protocol，UDP)、QUIC(QuickUDP Internet Connection)协议等。服务器可以预留指定的协议端口来监听并接收客户端发送的媒体段请求，比如使用80端口来接收基于HTTP协议发送的媒体段请求。当客户端采用HTTP协议提交媒体段请求时，可以采用HTTP-GET方法或者HTTP-POST方法向服务器提交媒体段请求。
客户端向服务器发送的媒体段请求中携带了命令，比如，客户端向服务器发送的第一媒体段请求中携带了一个启动推送命令。命令可以有多种，其中包括一种：启动推送命令，可以根据进一步实施的需要定义新的命令。每个命令可不携带或携带命令参数，命令不同，所携带的命令参数也不同。当命令为启动推送命令时，可以携带的命令参数包括：指示待传送的目标媒体流的第一类参数、指示待传送的候选媒体单元特征的第二类参数和分段策略。当然，启示推送命令也可以不携带任何命令参数，由服务器根据缺省指定来生成媒体段，具体地，目标媒体流为缺省指定的，初始媒体段是通过缺省指定的媒体单元封装得到的，分段策略也是缺省指定的。在具体的实施例中，可以作为第一类参数的命令参数包括：媒体流标识、媒体流名称，可以作为第二类参数的命令参数包括：起始序号、起始时间、优先级范围，可采用的分段策略为以下策略之一：等序号间隔推送、等时间间隔推送、单元集推送。当然，还可以根据进一步实施的需要为启动推送命令定义新的命令参数。
客户端需要采用一定的封装方法，将命令及其对应的命令参数封装成字节流或字符串流，发送给服务器。例如，当采用HTTP-GET来发送媒体段请求时，如果媒体段请求只携带一个命令，则可将命令及其携带的命令参数封装成一个字符串，再将该字符串封装到URL中进行传输。
采用HTTP-GET的媒体段请求的示例如下：
GET“http://www.xxx-server.com/msreq？cmd＝PushStart”
GET“http://www.xxx-server.com/msreq？cmd＝PushStart&streamID＝601”
GET“http://www.xxx-server.com/msreq？cmd＝PushStart&seqBegin＝1008”
GET“http://www.xxx-server.com/msreq？cmd＝PushStart&timeBegin＝31000”
GET“http://www.xxx-server.com/msreq？cmd＝PushStart&priorityRange＝1-2”
GET“http://www.xxx-server.com/msreq？cmd＝PushStart&streamID＝602&seqBegin＝2010”
GET“http://www.xxx-server.com/msreq？cmd＝PushStart&segStrategy＝(ESI:3)”
GET“http://www.xxx-server.com/msreq？cmd＝PushStart&streamID＝601&timeBegin＝32000&segStrategy＝(ETI:2000)”
上述URL中，参数名cmd、streamID、seqBegin、timeBegin、priorityRange、segStrategy分别代表命令类型、媒体流标识、起始序号、起始时间、优先级范围、分段策略，一个命令的所有命令参数应该紧跟在其命令类型后面。“cmd＝PushStart”指示该媒体段请求携带了一个启动推送命令，该命令用于指示服务器开启一个推送任务。
在步骤S102中，接收并解析服务器返回的媒体段，从媒体段中解析出媒体单元和/或推送任务标识，其中，在启动推送命令携带至少一个命令参数时，服务器根据命令参数生成媒体段，在启动推送命令不携带命令参数时，服务器根据缺省指定生成媒体段。
具体而言，每个启动推送命令都是针对当前服务器上的一个媒体流。如果启动推送命令携带第一类参数，如媒体流名称或媒体流标识，可直接利用该第一类参数来确定目标媒体流。如果命令参数不包括任何第一类参数，那么，服务器将指定一个缺省的媒体流作为待传送的目标媒体流。例如，服务器可以根据向客户端推送的历史媒体流，确定与历史媒体流的类型相同的一个媒体流作为待传送的目标媒体流。
图2给出了一个客户端实时接收媒体流的过程示意图，当服务器接收到客户端发送的启动推送命令后，会首先生成一个媒体段MS1，然后根据客户端请求中的分段策略来持续生成新的媒体段MS2、MS3、……，并将生成的媒体段推送给客户端，其中，在返回的第一个媒体段MS1中封装了推送任务标识PTID＝101。
当客户端采用一种网络传输协议来发送媒体段请求时，会与服务器建立相应的网络连接，客户端可以直接使用该网络连接来接收服务器返回的媒体段。举例来说，当客户端用HTTP GET来发送媒体段请求时，即可通过HTTP GET响应消息来接收媒体段，无论是发送和接收，使用的是同一个TCP连接。
媒体段的解析是媒体段封装的逆过程，因此，首先要确定服务器端所采用的封装协议，这可以由服务器端和客户端在传送媒体段之前约定。例如，服务器采用以下自定义封装协议：媒体段有段头和段净荷组成，段净荷由若干个媒体单元级联而成，段头中则指示每个媒体单元的起始位置和长度。此时，对于客户端来说，可以首先通过段头来获得各媒体单元的起始位置和长度，然后从段净荷中解析出各媒体单元。当媒体单元为RTP包时，可以从每个RTP包的包头中，即可得到每个媒体单元的序号和产生时间。在某些情况中，服务器可以将推送任务标识封装在媒体段中，比如，封装到媒体段的段头中，此时，可以通过解析媒体段的段头，得到推送任务标识。
进一步地，在本发明的一个实施例中，客户端从接收的媒体段中解析出媒体单元后，可以实时回放接收的媒体单元。
应理解，步骤S101到步骤S102的设置仅为了描述的方便，而不用于限制方法的执行顺序，在具体实现中，上述步骤可以作为独立的处理过程来执行。
以下实施例中，将对启动推送命令携带的第二类参数进行说明。
进一步地，在本发明的一个实施例中，所述第二类参数包括起始序号、起始时间和优先级范围中的一项或多项。这些第二类参数是用来指示待发送的候选媒体单元应满足的特征要求，当存在多个第二类参数时，则待发送候选媒体单元应该满足每个第二类参数的特征要求。在本发明中，给出了三种可选的第二类参数，各参数对应的特征要求如下：
1)起始序号：当起始序号有效时，候选媒体单元的序号在起始序号之后；
2)起始时间：当起始时间有效时，候选媒体单元的产生时间在起始时间之后；
3)优先级范围：候选媒体单元的优先级在该优先级范围内。
上述的第二类参数的有效和无效是指参数的值是否在一个指定的范围内。以起始序号为例，该起始序号的值不能超过当前最新媒体单元的序号，另一方面，为保证实时性，起始序号的值不能是早于某个现有媒体单元的序号，在上述范围内的起始序号即为有效。如果某个第二类参数为无效，则等同于不携带这个第二类参数。当所有第二类参数均无效时，待传送的候选媒体单元为缺省指定的媒体单元。所述缺省指定的媒体单元可以为媒体流中所有和最新媒体单元的序号间隔小于某个预设值的媒体单元，或者为媒体流中所有和最新媒体单元的产生时间间隔小于某个预设值的媒体单元。
在上述第二类参数中，有些参数，例如起始序号和起始时间，只影响首个推送媒体段的生成，这是因为：只要首个推送媒体段中的候选媒体单元的序号或产生时间符合要求，之后产生的媒体段封装的是新产生的媒体单元，这些媒体单元的序号和产生时间也必然符合要求。而另一些第二类参数，例如优先级范围，则影响所有推送媒体段的生成。
在具体实施时，还可以定义其他的第二类参数，如首个推送媒体段的时长、首个推送媒体段的最大序偏、首个推送媒体段的最大时偏等等。从上述实施例可以看出，客户端通过媒体段请求中携带的第二类参数可以控制服务器推送特定特征的媒体单元，这使得服务器端的推送过程可以更好的适应客户端的需求。
以下实施例中，将对启动推送命令中携带的分段策略进行说明。
进一步地，在本发明的一个实施例中，启动推送命令中的分段策略可从下述三种分段策略中选择其一：等序号间隔推送(ESI，Equal Sequence Interval)、等时间间隔推送(ETI，Equal Time Interval)、单元集推送(MUS，Media Unit Set)。客户端使用分段策略来指示服务器按照何种方法来对媒体流进行分段，生成新的媒体段并推送给客户端。
可选择地，分段策略为等序号间隔推送，分段策略携带参数：指定序号间隔。当服务器接收到客户端的启动推送命令后，将在生成首个媒体段后，按照指定序号间隔来生成推送的媒体段。附图2中给出了一个分段策略为等序号间隔的推送过程的示意图，其中，启动推送命令中携带了一个参数：segStrategy＝ESI：3，该参数指示分段策略为等序号间隔推送(ESI)，指定序号间隔为3，服务器生成首个媒体段MS1后，按照指定序号间隔3来生成后续的媒体段，如MS2、MS3、MS4等等。
可选择地，分段策略为等时间间隔推送，分段策略携带参数：指定时间间隔。当服务器接收到客户端的启动推送命令后，将在生成首个媒体段后，按照指定时间间隔来生成推送的媒体段。附图3中给出了一个分段策略为等时间间隔的推送过程的示意图，其中，启动推送命令中携带了一个参数：segStrategy＝ETI：2000，该参数指示分段策略为等时间间隔推送(ETI)，指定时间间隔为2000毫秒，服务器生成首个媒体段MS1后，每隔2000毫秒，生成一个媒体段。
可选择地，分段策略为单元集推送，分段策略携带参数：指定单元集个数。在一些媒体流中，若干个序号连续的媒体单元组成了一个单元集，当服务器接收到客户端的启动推送命令后，将在生成首个媒体段后，对新产生的单元集进行计数，当新产生的单元集的个数等于指定单元集个数时，生成新的媒体段。
具体而言，在许多媒体流中，当若干个序号连续的媒体单元具有共同的特征时，这些媒体单元之间可能存在依赖关系，如果只传送其中的一个媒体单元是没有意义的，最好能将其作为一个整体来传送。例如，当媒体流为一个视频RTP包流时，一个图像帧可能封装成多个RTP包，这些RTP包的时间戳都是相同的，但是其序号是不同的，此时，这些时间戳相同的RTP包即构成了一个单元集。另一个例子，当选择视频帧作为媒体单元时，连续的若干个视频帧构成了一个图像集(Group of Pictures，GOP)，每个图像集构成了一个可独立解码的集合，那么也可将该GOP看成是一个单元集。
附图4给出了一个分段策略为单元集推送的推送过程的示意图，其中，启动推送命令中携带了一个参数：segStrategy＝MUS：2，该参数指示分段策略为单元集推送(MUS)，指定单元集个数为2。在本例中，将产生时间相同的所有媒体单元看作一个单元集，例如，时间t1产生的两个媒体单元U22和U23构成了一个单元集，其中，U23为单元集的最后一个单元；时间t2时刻产生的一个媒体单元U24也构成了一个单元集，其中，U24是单元集的最后一个单元。当U24产生时，待发送的媒体单元集已经达到了指定单元集个数的要求，此时，将此两个单元集的3个媒体单元封装成一个新的媒体段发送给客户端。
从上述实施例来看，客户端可以通过指定分段策略及其携带的参数，控制服务器端生成和推送媒体段的过程，更好的满足客户端的需要和适应不同的网络条件。
以下实施例中，将对客户端如何保持服务器端的推送过程进行说明。
进一步地，在本发明的一个实施例中，还包括：从服务器获取推送任务的持续时间，并在服务器终止推送任务前向服务器发送第二媒体段请求，第二媒体段请求携带了一个继续推送命令，继续推送命令用于请求服务器延长推送任务的持续时间，继续推送命令携带的命令参数包括推送任务标识。
具体而言，服务器在收到启动推送命令后会启动一个推送任务，为了避免推送任务一直占用服务器资源，会给每个推送任务设定一个截止时间，所述截止时间是当前***时间再加一个预设的推送持续时间。所述预设的推送持续时间可以是一个固定的时长(比如60s或120s)，在该推送持续时间内，客户端不需要再重复提交请求，服务器主动将媒体段推送给客户端，当时间到达截止时间时，终止该推送任务。客户端可以通过发送继续推送命令，使得服务器重设截止时间，延长推送任务的持续时间，具体实施方式可以有以下两种：
1)服务器接收到启动推送命令后，将预设的推送持续时间封装到媒体段中，发送给客户端，客户端从接收的媒体段中解析出预设的推送持续时间，并自行推测出推送任务还将持续多长时间，并在截止时间之前发送继续推送命令；
2)服务器将剩余的推送时长封装到每个媒体段中，发送给客户端，客户端根据该剩余的推送时长来决定，是否要向服务器发送继续推送命令。一旦服务器收到继续推送命令，则更新其截止时间。
图5给出了一个客户端发送继续推送命令来延长推送任务的过程示意图。客户端可以通过定期提交继续推送命令，向服务器证明自己仍然处在正常接收状态，以此来保持服务器端的推送任务。如果客户端不再提交继续推送命令，则服务器会在设置的截止时间到达时自动终止推送任务。
以下实施例中，将对客户端如何主动终止推送任务进行说明。
进一步地，在本发明的一个实施例中，还包括：当不再接收媒体段时，向服务器发送第三媒体段请求，第三媒体段请求携带了一个终止推送命令，终止推送命令用于请求服务器终止推送任务，终止推送命令携带的命令参数包括推送任务标识。比如，服务器接收到终止推送命令后，立即终止与推送任务标识对应的推送任务。
具体而言，该实施例给出了客户端主动终止推送任务的一种方法。客户端可以在需要的时候，向服务器发送终止推送命令来终止传送任务。这样，可以保证服务器快速终止不需要的推送任务。图6给出了客户端快速终止推送任务的过程示意图。
以下实施例中，将对客户端如何调整推送任务进行说明。
进一步地，在本发明的一个实施例中，根据媒体段的接收情况对推送任务进行调整，其中，向服务器发送第四媒体段请求，第四媒体段请求携带了一个重启推送命令，重启推送命令携带推送任务标识，重启推送命令还可以不携带或携带如下至少一个命令参数：指示待传送的目标媒体流的第一类参数、指示待传送的候选媒体单元特征的第二类参数和分段策略。
具体而言，客户端在接收推送的媒体段进行时，可以对接收过程进行监控，判断当前网络的传输条件，比如传输带宽和传输延时，然后，通过发送重启推送命令，对当前的推送过程进行调整，这包括：
1)调整候选媒体单元的特征要求
客户端可以通过媒体段的接收，判断当前网络的传输带宽，如果传输带宽小于媒体流的码率，则可以调整候选媒体单元的优先级范围，使得重启的推送任务只发送高优先级的媒体单元。
重启推送命令可携带明确的第二类参数对候选媒体单元的特征要求进行修改。当重启推送命令只携带任务标识，而不携带任何其他命令参数时，服务器端将认为推送任务的目标媒体流和分段策略仍保持不变，而原有的第二类参数失效，此时，服务器将缺省指定的候选单元封装成初始媒体段，并根据原有分段策略生成新的媒体段。
2)调整分段策略
客户端还可以根据自身的延时需求及可靠性要求来调整分段策略，例如，当客户端需要更小的传送延时时，可以缩短媒体段产生的序号间隔或时间间隔；当客户端需要更高的可靠性时，可以增加媒体段产生的序号间隔或时间间隔。
图7给出了一个服务器根据重启推送命令来调整分段策略的示意图。在一个实施例中，客户端向服务器发送启动推送命令“cmd＝PushStart”，启动推送命令中携带了参数“segStrategy＝ESI：3”，即分段策略为等序号间隔，指定序号间隔为3，服务器首先返回初始媒体段MS1，其中指明推送任务标识PTID为101，然后根据分段策略开启新的媒体段的生成过程。当客户端接收完媒体段MS3时，发现网络传送带宽足够，此时为了减少传送延时，客户端向服务器发送重启推送命令“cmd＝PushRestart”，携带了该任务标识“PTID＝101”，起始序号“seqBegin＝27”和分段策略“segStrategy＝ESI：2”，服务器收到该重启推送命令后，首先终止该推送任务对应的现有媒体段生成过程和发送过程，然后，生成初始媒体段MS4，再根据新的分段策略开启新的媒体段生成过程，生成后续新的媒体段。
3)切换目标媒体流
客户端可以根据媒体段的接收情况，判断当前网络的传输带宽，如果当前网络传输带宽无法支持当前的目标媒体流的码率，那么客户端可以请求服务器推送一个属于该内容的低码率媒体流。
显然，服务器需要告知客户端当前哪些媒体流属于同一个内容。在具体实施时，服务器可采用多种方法来将此信息通告给客户端。
进一步的，在本发明的一个实施例中，所述媒体段还封装了媒体流索引信息，所述的媒体流索引信息包含属于同一个内容的多个媒体流描述信息，所述的媒体流描述信息包括媒体流标识和媒体流比特率。
举例而言，当服务器中存在属于同一个内容的多个实时媒体流时，可以通过不同的媒体流标识来区分这些实时媒体流，并建立起该内容的媒体流索引信息；这个媒体流索引信息实际上包括了媒体流标识和媒体流比特率的映射关系。如表1所示，显示了同一个内容(比如一个现场演唱会直播)对应的媒体流索引信息：该内容包括了三个实时媒体流，其中媒体流1(标识为1000，码率为8Mbps)为高清码流，媒体流2(标识为1001，码率为2Mbps)为标清码流，媒体流3(标识为1002，码率为500Kbps)为移动标清流。
表1
媒体流标识 媒体流码率
601 8000Kbps
602 2000Kbps
603 500Kbps
当客户端请求推送媒体流标识为601的实时流时，服务器通过查询媒体流索引表，发现存在来自同一个内容源的媒体流2和媒体流3，此时，服务器可将上述媒体流索引信息作为一个控制消息，和其他媒体单元一起封装到媒体段中。
客户端可根据媒体流索引信息，根据网络传输情况选择请求推送的目标媒体流。一般来说，由于媒体流索引信息在一段较长时间内保持不变，所以没有必要在每个媒体段中都封装该媒体流索引信息，可以将媒体流索引信息封装到间隔选定的媒体段中，或者封装到发送给客户端的前几个媒体段中。
图8给出了一个客户端主动请求切换目标媒体流的示意图。在一个实施例中，客户端向服务器发送启动推送命令“cmd＝PushStart”，命令中携带了媒体流标识“SID＝601”和分段策略参数“segStrategy＝ESI：3”，服务器开启对8Mbps媒体流StreamA的推送：首先返回初始媒体段MS1，其中封装了推送任务标识PTID为101和如表2所示的媒体流索引信息，然后根据分段策略开启媒体段生成过程，依次生成媒体段MS2，MS3。当客户端接收到MS3时，发现实际传送带宽只有5Mbps，无法支持当前的媒体流码率8Mbps，因此，客户端向服务器发送重启推送命令“cmd＝PushRestart”，携带了该推送任务标识“PTID＝101”，媒体流标识“SID＝602”和分段策略“segStrategy＝ESI：3”，服务器收到该重启推送命令后，首先终止该推送任务对应的现有8Mpbs媒体流StreamA的媒体段生成过程和发送过程，然后，开始推送2Mbps的媒体流StreamB，生成初始媒体段MS4，再根据新的分段策略开启新的媒体段生成过程，生成后续新的媒体段。
为简化起见，图8中虽然StreamA和StreamB的码率不同，但同一时间产生的媒体段的序号保持一致。当然，StreamA和StreamB的序号也可以不一致，客户端可通过在启动推送命令中携带第二类参数(如起始时间)来保证在时间切换的准确性，从而保证不同码率的码流的平滑切换。
从上述实施例可以看出，客户端可以通过重启推送命令对推送任务进行实时调整，使得推送过程可以快速适应客户端的需求和网络传输条件的变化。由于所有的自适应推送控制由客户端完成，而服务器端不需要复杂的处理过程，因此，本方法可以支持服务器端大规模的自适应推送。
以下实施例中，将对客户端如何同时使用推送和拉取两种传送方式进行说明。
进一步的，在本发明的一个实施例中，客户端根据媒体段的接收情况判断媒体段中是否存在未成功接收的媒体单元，然后向所述服务器发送第五媒体段请求，第五媒体段请求携带了一个媒体段拉取命令，用于对未成功接收的媒体单元进行拉取，媒体段拉取命令不携带或携带下述命令参数中的一项或多项：指示待传送的目标媒体流的第一类参数和指示待拉取的候选媒体单元特征的第二类参数。
具体而言，当客户端请求服务器按照指定的分段策略进行推送时，媒体段并不一定能够成功的推送给客户端，尤其是当传送链路出现差错或中断而媒体段传送使用了不可靠的网络传输协议(如UDP)时，此时，媒体段中的部分或全部媒体单元将出现丢失，那么，客户端可以针对这部分未成功接收的媒体单元，单独发送一个媒体段拉取命令，并在媒体段拉取命令中携带的第二类参数中指明待拉取的媒体单元的特征。在具体实施时，可以使用的第二类参数包括：序号范围、产生时间范围、优先级范围等等。这里还可以考虑以下两种情况：
1)选择待拉取的媒体单元。可以对每个媒体单元设置一个预期接收的时间，那么，如果未成功接收的媒体单元的预期接收时间在当前***时间之前，则没有必要进行拉取；
2)可以根据网络的条件，切换拉取的目标媒体流对象。例如，如果当前网络传输的带宽不够，可以选择拉取同一个内容的低码率媒体流。
从上述实施例可以看出，客户端通过结合推送和拉取两种方式，可以在保证延时性能的基础上提高整体传送的可靠性，提高媒体流的传送性能。
根据本发明实施例提出的媒体流的实时接收方法，客户端通过向服务器发送媒体段请求来启动推送任务，服务器按照客户端指定的分段策略来对媒体流进行分段和推送，使得服务器可以将小的媒体单元聚合成媒体段，减少推送的次数，提高媒体流的传送效率；其次，简化了服务器端的推送过程，服务器端只需按照客户端指定的策略来生成媒体段并发送给客户端，不再需要复杂的自适应算法来应对传输过程中的各种问题，降低了服务器端需要维护的状态和处理开销，有利于支持大规模的自适应媒体流推送；最后，每个客户端可以根据媒体流的传输情况来随时调整服务器端的推送过程，使得推送过程更快的适应网络条件和客户端需求的变化。
其次参照附图描述根据本发明实施例提出的媒体流的实时接收客户端。
图9是本发明一个实施例的媒体流的实时接收客户端的结构示意图，其中，媒体流为实时产生的媒体单元的序列，其中，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号。
如图9所示，该媒体流的实时接收客户端10包括：媒体流传输控制组件100和服务器接口组件200。
其中，媒体流传输控制组件100用于根据客户端需求和媒体段的接收情况生成第一媒体段请求，并将生成的第一媒体段请求提交给服务器接口组件，第一媒体段请求携带至少一个命令，命令包括：启动推送命令，启动推送命令用于请求服务器启动一个推送任务，启动推送命令不携带或携带至少一个命令参数，命令参数包括：指示待传送的目标媒体流的第一类参数、指示待传送的候选媒体单元特征的第二类参数和分段策略。
服务器接口组件200用于发送第一媒体段请求至服务器，并接收和解析服务器返回的媒体段，从媒体段中解析出媒体单元和/或推送任务标识，并将推送任务标识及媒体段的接收情况提交给媒体流传输控制组件100，其中，在启动推送命令携带至少一个命令参数时，服务器根据命令参数生成媒体段，在启动推送命令不携带命令参数时，服务器根据缺省指定生成媒体段。
本发明实施例的客户端10通过向服务器发送媒体段请求来启动推送任务并控制服务器端媒体流的分段过程，实现媒体流的按需分段推送，简化了服务器端的推送过程，提高了媒体流的传送效率和对大规模自适应推送的支持。
在本发明的一个实施例中，服务器接口组件200可以使用HTTP协议来发送媒体段请求并接收返回的媒体段。
对于客户端来讲，服务器接口组件200可以采用任何网络传输协议来发送媒体段请求及接收服务器返回的媒体段，如UDP协议，TCP协议和HTTP协议等。当服务器接口组件采用HTTP协议来提交媒体段请求并接收服务器返回的媒体段时，该服务器接口组件200包含了HTTP客户端的功能：媒体段请求的参数可以封装为字符串作为HTTP GET的URL的一部分，而服务器生成的媒体段可封装到HTTP GET的响应消息中返回给客户端。
以下实施例中，将对一种用于客户端接收实时媒体流的方式进行说明。
在一些应用场景中，实时媒体流可以一边接收一边播放，为了支持上述功能，可以在现有的组件基础上引入一个媒体回放组件，由媒体回放组件来实时回放解析出的媒体单元，如图10所示，媒体流的实时接收客户端10还包括：媒体回放组件300。
在具体实现过程中，媒体回放组件300的功能可以包含多个处理步骤。以媒体单元为RTP包为例，为了完成RTP包的播放，媒体回放组件300首先需要从RTP包中解封装，从RTP净荷中恢复媒体帧，如果该媒体帧采用了压缩，则需要对其进行解压缩，并对解压缩后得到的原始码流进行播放。
进一步地，在本发明的一个实施例中，第二类参数包括起始序号、起始时间和优先级范围中的一项或多项。
在本发明的一个实施例中，所述分段策略为下述策略之一：等序号间隔推送、等时间间隔推送、单元集推送；
当分段策略为等序号间隔推送时，所述分段策略携带以下参数：指定序号间隔；当分段策略为等时间间隔推送时，所述分段策略携带以下参数：指定时间间隔；当分段策略为单元集推送时，所述分段策略携带以下参数：指定单元集个数。
在本发明的一个实施例中，所述服务器接口组件，还用于：
从所述服务器获取所述推送任务的持续时间，并在所述服务器终止所述推送任务前向所述服务器发送第二媒体段请求，所述第二媒体段请求携带了一个继续推送命令，所述继续推送命令用于请求所述服务器延长所述推送任务的持续时间，所述继续推送命令携带的命令参数包括所述推送任务标识。
在本发明的一个实施例中，所述服务器接口组件，还用于：
当不再接收所述媒体段时，向所述服务器发送第三媒体段请求，所述第三媒体段请求携带了一个终止推送命令，所述终止推送命令用于请求所述服务器终止所述推送任务，所述终止推送命令携带的命令参数包括所述推送任务标识。
在本发明的一个实施例中，所述媒体流传输控制组件，还用于：
根据所述媒体段的接收情况对所述推送任务进行调整，生成第四媒体段请求，并将所述第四媒体段请求提交给所述服务器接口组件，所述第四媒体段请求携带了一个重启推送命令，所述重启推送命令携带所述推送任务标识，所述重启推送命令不携带或携带如下至少一个命令参数：指示待传送的目标媒体流的第一类参数、指示待传送的候选媒体单元特征的第二类参数和分段策略。
所述服务器接口组件，还用于：
向所述服务器发送所述第四媒体段请求。
在本发明的一个实施例中，所述媒体流传输控制组件，还用于：
根据所述媒体段的接收情况判断所述媒体段中是否存在未成功接收的媒体单元，根据未成功接收的媒体单元生成第五媒体段请求，并将所述第五媒体段请求提交给所述服务器接口组件，其中，所述第五媒体段请求携带了一个媒体段拉取命令，所述媒体段拉取命令用于对所述未成功接收的媒体单元进行拉取，所述媒体段拉取命令不携带或携带下述命令参数中的一项或多项：指示待传送的目标媒体流的第一类参数和指示待拉取的候选媒体单元特征的第二类参数；
所述服务器接口组件，还用于：
向所述服务器发送所述第五媒体段请求。
需要说明的是，前述对媒体流的实时接收方法实施例的解释说明也适用于该实施例的媒体流的实时接收客户端，此处不再赘述。
根据本发明实施例提出的媒体流的实时接收客户端，通过向服务器发送媒体段请求来启动推送任务，服务器按照客户端指定的分段策略来对媒体流进行分段和推送，从而，服务器可以将小的媒体单元聚合成媒体段，减少推送的次数，提高媒体流的传送效率；其次，简化了服务器端的推送过程，服务器端只需按照客户端指定的策略来生成媒体段并发送给客户端，不再需要复杂的自适应算法来应对传输过程中的各种问题，降低了服务器端需要维护的状态和处理开销，有利于支持大规模的自适应媒体流推送；最后，每个客户端可以根据媒体流的传输情况来随时调整服务器端的推送过程，使得推送过程更快的适应网络条件和客户端需求的变化。
为了实现上述实施例，本发明实施例还提出了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时，实现如上述实施例描述的媒体流的实时接收方法。
为了实现上述实施例，本发明实施例还提出了一种非临时性计算机可读存储介质，该程序被处理器执行时实现如上述实施例描述的媒体流的实时接收方法。
为了实现上述实施例，本发明实施例还提出了一种计算机程序产品，当计算机程序产品中的指令由处理器执行时，执行如上述实施例描述的媒体流的实时接收方法。
此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。
在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (17)

1.一种媒体流的实时接收方法，其特征在于，所述媒体流为实时产生的媒体单元的序列，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，所述方法包括：
发送第一媒体段请求至服务器，所述第一媒体段请求携带一个启动推送命令，所述启动推送命令用于请求所述服务器启动一个推送任务，所述启动推送命令不携带或携带至少一个命令参数，所述命令参数包括：指示待传送的目标媒体流的第一类参数、指示待传送的候选媒体单元特征的第二类参数和分段策略；
接收并解析所述服务器返回的媒体段，从所述媒体段中解析出媒体单元和/或推送任务标识，其中，在所述启动推送命令携带至少一个所述命令参数时，所述服务器根据所述命令参数生成所述媒体段，在所述启动推送命令不携带所述命令参数时，所述服务器根据缺省指定生成所述媒体段。
2.根据权利要求1所述的媒体流的实时接收方法，其特征在于，所述第二类参数包括起始序号、起始时间和优先级范围中的一项或多项。
3.根据权利要求1所述的媒体流的实时接收方法，其特征在于，所述分段策略为下述策略之一：等序号间隔推送、等时间间隔推送、单元集推送；
当分段策略为等序号间隔推送时，所述分段策略携带以下参数：指定序号间隔；当分段策略为等时间间隔推送时，所述分段策略携带以下参数：指定时间间隔；当分段策略为单元集推送时，所述分段策略携带以下参数：指定单元集个数。
4.根据权利要求1所述的媒体流的实时接收方法，其特征在于，还包括：
从所述服务器获取所述推送任务的持续时间，并在所述服务器终止所述推送任务前向所述服务器发送第二媒体段请求，所述第二媒体段请求携带了一个继续推送命令，所述继续推送命令用于请求所述服务器延长所述推送任务的持续时间，所述继续推送命令携带的命令参数包括所述推送任务标识。
5.根据权利要求1所述的媒体流的实时接收方法，其特征在于，还包括：
当不再接收所述媒体段时，向所述服务器发送第三媒体段请求，所述第三媒体段请求携带了一个终止推送命令，所述终止推送命令用于请求所述服务器终止所述推送任务，所述终止推送命令携带的命令参数包括所述推送任务标识。
6.根据权利要求1所述的媒体流的实时接收方法，其特征在于，还包括：
根据所述媒体段的接收情况对所述推送任务进行调整，其中，向所述服务器发送第四媒体段请求，所述第四媒体段请求携带了一个重启推送命令，所述重启推送命令携带所述推送任务标识，所述重启推送命令不携带或携带如下至少一个命令参数：指示待传送的目标媒体流的第一类参数、指示待传送的候选媒体单元特征的第二类参数和分段策略。
7.根据权利要求1所述的媒体流的实时接收方法，其特征在于，还包括：
根据所述媒体段的接收情况判断所述媒体段中是否存在未成功接收的媒体单元，向所述服务器发送第五媒体段请求，所述第五媒体段请求携带了一个媒体段拉取命令，所述媒体段拉取命令用于对所述未成功接收的媒体单元进行拉取，所述媒体段拉取命令不携带或携带下述命令参数中的一项或多项：指示待传送的目标媒体流的第一类参数和指示待拉取的候选媒体单元特征的第二类参数。
8.一种媒体流的实时接收客户端，其特征在于，所述媒体流为实时产生的媒体单元的序列，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，所述客户端包括：
媒体流传输控制组件，用于根据客户端需求和媒体段的接收情况生成第一媒体段请求，并将生成的所述第一媒体段请求提交给服务器接口组件，所述第一媒体段请求携带至少一个命令，所述命令包括：启动推送命令，所述启动推送命令用于请求所述服务器启动一个推送任务，所述启动推送命令不携带或携带至少一个命令参数，所述命令参数包括：指示待传送的目标媒体流的第一类参数、指示待传送的候选媒体单元特征的第二类参数和分段策略。
服务器接口组件，用于发送所述第一媒体段请求至所述服务器，并接收和解析所述服务器返回的媒体段，从所述媒体段中解析出媒体单元和/或推送任务标识，并将所述推送任务标识及所述媒体段的接收情况提交给媒体流传输控制组件，其中，在所述启动推送命令携带至少一个所述命令参数时，所述服务器根据所述命令参数生成所述媒体段，在所述启动推送命令不携带所述命令参数时，所述服务器根据缺省指定生成所述媒体段。
9.根据权利要求8所述的媒体流的实时接收客户端，其特征在于，所述第二类参数包括起始序号、起始时间和优先级范围中的一项或多项。
10.根据权利要求8所述的媒体流的实时接收客户端，其特征在于，所述分段策略为下述策略之一：等序号间隔推送、等时间间隔推送、单元集推送；
当分段策略为等序号间隔推送时，所述分段策略携带以下参数：指定序号间隔；当分段策略为等时间间隔推送时，所述分段策略携带以下参数：指定时间间隔；当分段策略为单元集推送时，所述分段策略携带以下参数：指定单元集个数。
11.根据权利要求8所述的媒体流的实时接收客户端，其特征在于，所述服务器接口组件，还用于：
从所述服务器获取所述推送任务的持续时间，并在所述服务器终止所述推送任务前向所述服务器发送第二媒体段请求，所述第二媒体段请求携带了一个继续推送命令，所述继续推送命令用于请求所述服务器延长所述推送任务的持续时间，所述继续推送命令携带的命令参数包括所述推送任务标识。
12.根据权利要求8所述的媒体流的实时接收客户端，其特征在于，所述服务器接口组件，还用于：
当不再接收所述媒体段时，向所述服务器发送第三媒体段请求，所述第三媒体段请求携带了一个终止推送命令，所述终止推送命令用于请求所述服务器终止所述推送任务，所述终止推送命令携带的命令参数包括所述推送任务标识。
13.根据权利要求8所述的媒体流的实时接收客户端，其特征在于，所述媒体流传输控制组件，还用于：
根据所述媒体段的接收情况对所述推送任务进行调整，生成第四媒体段请求，并将所述第四媒体段请求提交给所述服务器接口组件，所述第四媒体段请求携带了一个重启推送命令，所述重启推送命令携带所述推送任务标识，所述重启推送命令不携带或携带如下至少一个命令参数：指示待传送的目标媒体流的第一类参数、指示待传送的候选媒体单元特征的第二类参数和分段策略。
所述服务器接口组件，还用于：
向所述服务器发送所述第四媒体段请求。
14.根据权利要求8所述的媒体流的实时接收客户端，其特征在于，所述媒体流传输控制组件，还用于：
根据所述媒体段的接收情况判断所述媒体段中是否存在未成功接收的媒体单元，根据所述未成功接收的媒体单元生成第五媒体段请求，并将所述第五媒体段请求提交给所述服务器接口组件，其中，所述第五媒体段请求携带了一个媒体段拉取命令，所述媒体段拉取命令用于对所述未成功接收的媒体单元进行拉取，所述媒体段拉取命令不携带或携带下述命令参数中的一项或多项：指示待传送的目标媒体流的第一类参数和指示待拉取的候选媒体单元特征的第二类参数；
所述服务器接口组件，还用于：
向所述服务器发送所述第五媒体段请求。
15.根据权利要求8所述的媒体流的实时接收客户端，其特征在于，还包括：
媒体回放组件，用于实时回放解析出的所述媒体单元。
16.一种计算机设备，其特征在于，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时，实现如权利要求1-7中任一项所述的媒体流的实时接收方法。
17.一种非临时性计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-7中任一项所述的媒体流的实时接收方法。
CN201910324831.7A 2019-04-22 2019-04-22 媒体流的实时接收方法、客户端、计算机设备和存储介质 Active CN110086797B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201910324831.7A CN110086797B (zh) 2019-04-22 2019-04-22 媒体流的实时接收方法、客户端、计算机设备和存储介质
PCT/CN2020/083038 WO2020216035A1 (zh) 2019-04-22 2020-04-02 媒体流的实时推送方法、实时接收方法、服务器及客户端

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910324831.7A CN110086797B (zh) 2019-04-22 2019-04-22 媒体流的实时接收方法、客户端、计算机设备和存储介质

Publications (2)

Publication Number Publication Date
CN110086797A true CN110086797A (zh) 2019-08-02
CN110086797B CN110086797B (zh) 2021-05-28

Family

ID=67416027

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910324831.7A Active CN110086797B (zh) 2019-04-22 2019-04-22 媒体流的实时接收方法、客户端、计算机设备和存储介质

Country Status (1)

Country Link
CN (1) CN110086797B (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111245709A (zh) * 2020-02-10 2020-06-05 北京字节跳动网络技术有限公司 一种消息推送方法、装置、电子设备及存储介质
CN111414208A (zh) * 2020-03-13 2020-07-14 百度在线网络技术（北京）有限公司 应用程序的启动方法、装置及设备
WO2020216035A1 (zh) * 2019-04-22 2020-10-29 北京开广信息技术有限公司 媒体流的实时推送方法、实时接收方法、服务器及客户端

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101674323A (zh) * 2008-09-10 2010-03-17 华为技术有限公司 业务推送协商方法及装置、推送业务***
US20170085602A1 (en) * 2015-09-23 2017-03-23 Adobe Systems Incorporated Power efficient multimedia content streaming based on a server push
CN106604077A (zh) * 2015-10-14 2017-04-26 中兴通讯股份有限公司 自适应流媒体传输方法及装置
CN107920108A (zh) * 2016-10-11 2018-04-17 华为技术有限公司 一种媒体资源的推送方法、客户端及服务器
CN108605154A (zh) * 2016-02-03 2018-09-28 联发科技股份有限公司 一种消息交互的方法和客户端设备

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101674323A (zh) * 2008-09-10 2010-03-17 华为技术有限公司 业务推送协商方法及装置、推送业务***
US20170085602A1 (en) * 2015-09-23 2017-03-23 Adobe Systems Incorporated Power efficient multimedia content streaming based on a server push
CN106604077A (zh) * 2015-10-14 2017-04-26 中兴通讯股份有限公司 自适应流媒体传输方法及装置
CN108605154A (zh) * 2016-02-03 2018-09-28 联发科技股份有限公司 一种消息交互的方法和客户端设备
CN107920108A (zh) * 2016-10-11 2018-04-17 华为技术有限公司 一种媒体资源的推送方法、客户端及服务器

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020216035A1 (zh) * 2019-04-22 2020-10-29 北京开广信息技术有限公司 媒体流的实时推送方法、实时接收方法、服务器及客户端
CN111245709A (zh) * 2020-02-10 2020-06-05 北京字节跳动网络技术有限公司 一种消息推送方法、装置、电子设备及存储介质
CN111414208A (zh) * 2020-03-13 2020-07-14 百度在线网络技术（北京）有限公司 应用程序的启动方法、装置及设备
CN111414208B (zh) * 2020-03-13 2023-08-01 百度在线网络技术（北京）有限公司 应用程序的启动方法、装置及设备

Also Published As

Publication number Publication date
CN110086797B (zh) 2021-05-28

Similar Documents

Publication Publication Date Title
JP6632682B2 (ja) メディアデータの提供装置、提供方法、制御装置、制御方法、及び、プログラム
CN102232298B (zh) 媒体内容的传输处理方法、装置与***
CN110086797A (zh) 媒体流的实时接收方法及客户端
US10516712B2 (en) Streaming media data transmission method, client and server
JP6472892B2 (ja) 異種ネットワーク伝送における動的時間窓およびキャッシュメカニズム
CN105376613B (zh) 一种快速频道切换方法、服务器及iptv***
JP2016531466A5 (zh)
CN112511871B (zh) 用于分段器流动性的打包器
CN107454000B (zh) 网络数据传输装置及方法
CN110072128A (zh) 媒体流的实时推送方法及服务器
KR20130138638A (ko) 비트 에러율을 이용한 효과적인 멀티미디어 전송 방법
JP2022036307A (ja) クライアント、サーバ、受信方法及び送信方法
KR20130090824A (ko) 이종망 네트워크에서 부호화된 미디어 데이터를 전송하는 시스템에 랜덤 액세스를 지원하는 엠엠티 애셋의 구조, 생성 방법 및 생성 장치
GB2517060A (en) Adaptive data streaming method with push messages control
KR20190018142A (ko) Mmt 전송 패킷의 설정 방법 및 전송 방법
CN113285947B (zh) 一种hls直播和组播直播接续的方法和装置
US20230224548A1 (en) Streaming Assistance System and Computer-Implemented Method
WO2020098455A1 (zh) 媒体流的实时递送方法及服务器
CN111193686B (zh) 媒体流的递送方法及服务器
KR102595338B1 (ko) 저지연 스트리밍 캐싱 방법 및 이를 수행하는 엣지 서버
KR20130040144A (ko) 엠엠티 시스템에서의 패킷 전송 장치 및 방법, 및 패킷 수신 장치 및 방법
CN110545492B (zh) 媒体流的实时递送方法及服务器
WO2020216035A1 (zh) 媒体流的实时推送方法、实时接收方法、服务器及客户端
KR20130040151A (ko) 콤포지션 정보 및 전송 특성 정보가 연동된 미디어 데이터를 이종 ip 네트워크를 통하여 전송하는 방법
CN106936808B (zh) Http流媒体传输方法及装置

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
CB03 Change of inventor or designer information
CB03 Change of inventor or designer information

Inventor after: Jiang Hongqi

Inventor after: Jiang Hongyan

Inventor after: Shen Suhui

Inventor before: Jiang Hongqi

Inventor before: Xin Zhentao

Inventor before: Jiang Hongyan

Inventor before: Shen Suhui