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

Abstract

本发明公开了一种媒体流的实时推送方法及服务器，其中，方法包括：生成媒体段，其中，生成初始媒体段，并根据客户端的反馈和媒体单元的产生情况生成新的媒体段，媒体段封装有至少一个媒体单元，客户端的反馈包括媒体段中已接收数据的指示；向客户端发送生成的媒体段并接收客户端的反馈，其中，采用预设网络传输协议与客户端建立至少一个传送连接，以使用至少一个传送连接传送生成的媒体段。根据本发明实施例的推送方法，可以实现媒体流的自适应分段推送，支持多种网络传输协议，提高媒体流的传送效率和在复杂网络环境下的传送性能。

Description

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

技术领域

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

背景技术

随着互联网特别是移动互联网的快速发展，通过互联网来实时传送音频、视频、图像等多媒体数据成为许多应用的基本需求，为满足这一需求，人们提出了各种流媒体实时传送技术，根据数据传送的发起方不同，这些流媒体实时传送技术可分为两大类：一类是流拉取方式，基本原理是客户端主动向服务器请求实时数据，采用流拉取的技术方案有：苹果公司提出的HLS(HTTP Live Streaming)、微软提出的平滑流Smooth Streaming、Adobe提出的HDS(HTTP Dynamic Streaming)、MPEG组织提出的DASH(Dynamic Adaptive Streamingover HTTP)；另一类是流推送方式，基本原理是服务器主动向客户端推送实时产生的媒体流，采用流推送的技术方案有：实时传送协议(RTP(Real-time Transport Protocol，实时传输协议)/RTSP(Real Time Streaming Protocol，实时流传输协议))、RTMP(Real TimeMessaging Protocol，实时消息传送协议)和HTTP-FLV。

相对于流拉取方式来说，流推送方式不需要等待客户端的请求，可以将实时产生的媒体流数据快速发送给客户端，实现低延时，因此，在实时性要求较高的应用场合，如交互直播，视频会议等，普遍采用这种基于推送的模式。

然而，相关技术的各种推送方案存在以下问题：

1、缺乏对媒体数据的分段推送。在相关的各种推送方案中，一旦媒体数据产生，则立即送入发送缓冲区，但是，如果单个媒体单元的数据量较少，频繁的单次推送将增加网络传输开销，降低传送效率。

2、只使用单一的网络传输协议，无法适应各种复杂的网络环境。首先，由于互联网中路由器和防火墙的设置，服务器和某些客户端之间只能使用特定的传输协议，服务器需要为不同的客户端选择不同的网络传输协议；其次，当客户端所在的终端通过无线网络接入互联网，其接入链路的信号质量会随着终端的位置而变化，相应地，网络传输带宽、传输延时和丢包率也会变化，只使用一种网络传输协议无法保证业务性能，如当链路丢包率较高时，TCP传输效率非常低，甚至无法工作。

3、只使用单一的传送连接，造成累积延时。对于RTMP或HTTP-FLV来说，需要在传送前建立一个TCP连接，并在整个传送过程中使用该连接，这很容易导致累积延时，即当发生网络拥塞时，来不及发送的数据包被累积起来，阻塞了后续数据包的传送。虽然可以采用清空缓存和断开重连的方式弥补上述问题，但是这会造成了缓存中所有数据的丢失。

发明内容

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

为此，本发明的第一个目的在于提出一种媒体流的实时推送方法，该方法可以实现媒体流的自适应分段推送，支持多种网络传输协议，提高媒体流的传送效率和在复杂网络环境下的传送性能。

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

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

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

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

为达到上述目的，本发明第一方面实施例提出了一种媒体流的实时推送方法，媒体流为实时产生的媒体单元的序列，其中，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，其中，所述方法包括：生成媒体段，其中，生成初始媒体段，并根据客户端的反馈和媒体单元的产生情况生成新的媒体段，所述媒体段封装有至少一个媒体单元，所述客户端的反馈包括所述媒体段中已接收数据的指示；向所述客户端发送生成的媒体段并接收所述客户端的反馈，其中，采用预设网络传输协议与所述客户端建立至少一个传送连接，以使用所述至少一个传送连接传送生成的所述媒体段。

本发明实施例的媒体流的实时推送方法，可以通过媒体流的自适应分段，实现媒体数据的分段推送，提高媒体流的传送效率，并且可以根据客户端的反馈来自动调整媒体段的时长和内容，以适应网络的动态变化；其次，媒体段的传送可以采用任意指定的网络传输协议，并且还可以根据网络传输情况为每个客户端甚至每个媒体段选择合适的网络传输协议，以适合复杂网络环境下的传送；最后，当采用同一个网络传输协议传送不同的媒体段时，既可以共享同一个传送连接，也可以分别采用不同的传送连接，以避免网络拥塞或故障导致的累积延时。

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

进一步地，在本发明的一个实施例中，所述初始媒体段封装缺省指定的媒体单元，所述缺省指定的媒体单元为所述媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元，或者为所述媒体流中所有和所述最新媒体单元的产生时间间隔小于第二预设值的媒体单元。

进一步地，在本发明的一个实施例中，所述根据客户端的反馈和媒体单元的产生情况生成新的媒体段，进一步包括：每当一个新的媒体单元产生时，判断已有媒体单元是否满足一个预设的媒体段生成条件，其中，如果满足所述预设的媒体段生成条件，则选择部分或全部未成功发送的媒体单元封装成所述新的媒体段。

可选地，在本发明的一个实施例中，所述预设的媒体段生成条件为：最新媒体单元与已发送媒体段中的所有媒体单元的序号间隔大于或等于一个预设的序号间隔。

可选地，在本发明的一个实施例中，所述预设的媒体段生成条件为：最新媒体单元与已发送媒体段中的所有媒体单元的产生时间间隔大于或等于一个预设的时间间隔。

可选地，在本发明的一个实施例中，所述预设网络传输协议为以下协议之一：RTP、TCP、HTTP和QUIC。

其中，在本发明的一个实施例中，当所述预设网络传输协议包含多种网络传输协议时，根据所述客户端的反馈和所述媒体流的传送需求选择网络传输协议。

另外，在本发明的一个实施例中，当采用同一种网络传输协议向所述客户端发送不同的媒体段时，使用不同的传送连接，或者共用同一个传送连接。

为达到上述目的，本发明第二方面实施例提出了一种媒体流的实时推送服务器，媒体流为实时产生的媒体单元的序列，其中，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，其中，所述服务器包括：媒体段生成组件，用于生成媒体段，其中，生成初始媒体段，并根据客户端的反馈和媒体单元的产生情况生成新的媒体段，所述媒体段封装有至少一个媒体单元，所述客户端的反馈包括所述媒体段中已接收数据的指示；媒体段发送组件，用于向所述客户端发送生成的媒体段并接收所述客户端的反馈，其中，采用预设网络传输协议与所述客户端建立至少一个传送连接，以使用所述至少一个传送连接传送生成的所述媒体段。

本发明实施例的媒体流的实时推送服务器，可以通过媒体流的自适应分段，实现媒体数据的分段推送，提高媒体流的传送效率，并且可以根据客户端的反馈来自动调整媒体段的时长和内容，以适应网络的动态变化；其次，媒体段的传送可以采用任意指定的网络传输协议，并且还可以根据网络传输情况为每个客户端甚至每个媒体段选择合适的网络传输协议，以适合复杂网络环境下的传送；最后，当采用同一个网络传输协议传送不同的媒体段时，既可以共享同一个传送连接，也可以分别采用不同的传送连接，以避免网络拥塞或故障导致的累积延时。

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

进一步地，在本发明的一个实施例中，所述初始媒体段封装缺省指定的媒体单元，所述缺省指定的媒体单元为所述媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元，或者为所述媒体流中所有和所述最新媒体单元的产生时间间隔小于第二预设值的媒体单元。

进一步地，在本发明的一个实施例中，所述媒体段发送组件进一步用于每当一个新的媒体单元产生时，判断已有媒体单元是否满足一个预设的媒体段生成条件，其中，如果满足所述预设的媒体段生成条件，则选择部分或全部未成功发送的媒体单元封装成所述新的媒体段。

可选地，在本发明的一个实施例中，所述预设的媒体段生成条件为：最新媒体单元与已发送媒体段中的所有媒体单元的序号间隔大于或等于一个预设的序号间隔。

可选地，在本发明的一个实施例中，所述预设的媒体段生成条件为：最新媒体单元与已发送媒体段中的所有媒体单元的产生时间间隔大于或等于一个预设的时间间隔。

可选地，在本发明的一个实施例中，所述预设网络传输协议为以下协议之一：RTP、TCP、HTTP和QUIC。

其中，在本发明的一个实施例中，当所述预设网络传输协议包含多种网络传输协议时，根据所述客户端的反馈和所述媒体流的传送需求选择网络传输协议。

另外，在本发明的一个实施例中，当采用同一种网络传输协议向所述客户端发送不同的媒体段时，使用不同的传送连接，或者共用同一个传送连接。

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

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

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

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

附图说明

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

图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包可能对应相同的产生时间，但是其序号则是唯一的。

本发明实施例可以针对任何一种实时媒体流来实施。在下面的实施例当中，本发明实施例将选择MPEG2-TS实时媒体流来阐述本发明实施例的实施方法。对于MPEG2-TS实时流来说，可以预先采用类似于HLS/DASH的方式，将实时产生或接收的TS流分割成短时长比如1秒左右的TS片段，每个TS片段可包括多个媒体帧，然后将这些片段按产生顺序编上序号，作为媒体单元，每个片段中包含的第一个媒体帧的时间戳指明了该片段的产生时间。

在相关技术的实时流媒体协议如RTP、RTMP或HTTP-FLV中，采用的是服务器推送的方式：服务器上一旦有新的媒体单元，则主动发送给客户端，并不涉及到对媒体流的分段封装，而在各种HTTP自适应流(如HLS、平滑流，MPEG-DASH)中，则采用了预分段的方式，媒体流按照固定的时间长度来生成媒体片段并发布清单文件，然后等待客户端的拉取。与上述这些方式都不同的是，在本发明实施例中，服务器主动对媒体流进行实时分段并推送，并根据媒体段的发送情况自动调整后续媒体段的内容和时长。

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

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

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

在步骤S101中，生成媒体段，其中，生成初始媒体段，并根据客户端的反馈和媒体单元的产生情况生成新的媒体段，媒体段封装有至少一个媒体单元，客户端的反馈包括媒体段中已接收数据的指示。

具体而言，在推送过程中，服务器可以通过将小的媒体单元组合成媒体段，可以减少推送的次数，提高推送的效率，但是，媒体单元封装成媒体段的过程也会增加媒体单元的等待延时，因此，服务器先给出一个初始媒体段，来试探网络的传送延时和传送带宽，然后根据客户端的反馈来进一步调整后续的媒体段的时长和内容，以达到传送延时和传送效率的折衷。例如，如果网络传送带宽足够，可以减少媒体段中封装的媒体单元的个数，增加推送次数，以降低延时；如果网络传送带宽不足，则可以减少推送次数，并选择部分媒体单元进行推送。

另外，服务器可以通过客户端的反馈来了解当前的网络传送带宽和传送延时。例如，首先，客户端的反馈包括所述媒体段中已接收数据的指示，上述的已接收数据可以是指媒体段中已接收的字节数，也可以是媒体段中已接收的媒体单元。其次，客户端的反馈应该及时，比如客户端可以按照一个设定的间隔周期性向服务器发送反馈。最后，客户端的反馈可以是显式反馈或隐式反馈，需要说明的是，上述的显式反馈可以是指客户端的反馈独立于所使用的网络传输协议；上述的隐式反馈可以是指客户端的反馈隐含在所使用的网络传输协议中，如TCP中已有对接收数据的反馈消息。

在本发明的实施例中，为了保证推送的实时性，初始媒体段中封装的媒体单元应包括最新产生的媒体单元。另外，可以采用自定义的封装协议将一个或多个媒体单元封装成媒体段，例如，一个简单的封装协议如下：媒体段由段头和段净荷组成，段净荷由若干个媒体单元级联而成，段头中则指示每个媒体单元的起始位置和长度，方便客户端的解析。如果媒体单元中未包含其产生时间和/或序号，则还需将媒体单元对应的产生时间和/或序号也应封装在媒体段中，方便接收端的接收和解析。

在步骤S102中，向客户端发送生成的媒体段并接收客户端的反馈，其中，采用预设网络传输协议与客户端建立至少一个传送连接，以使用至少一个传送连接传送生成的媒体段。

具体而言，服务器可以采用任何网络传输协议来发送媒体段。当将媒体流推送给一个客户端时，服务器和客户端应该约定两者之间可以使用的网络传输协议，如果服务器和客户端只约定一种网络传输协议，则服务器按此网络传输协议来发送媒体段到客户端；如果服务器和客户端约定了两种或两种以上的网络传输协议，则服务器可以根据客户端的反馈来自行选择一种网络传输协议。这样，当客户端分布在不同的网络中时，可以选择最合适的网络传输协议来推送媒体段，实现在复杂网络环境下服务器到各客户端的推送。

当使用一种网络传输协议来发送媒体段时，首先要使用该网络传输协议来建立到客户端的至少一个传送连接，然后再通过该传送连接来发送媒体段。我们可以将此传送连接看成是一个逻辑上的数据管道。以TCP协议为例，为了使用该TCP协议向客户端推送媒体段，服务器和客户端建立一个TCP连接，这个TCP连接实际上绑定了服务器和客户端的IP地址以及端口号，建立连接后，服务器器可以通过该TCP连接发送媒体段数据并且接收客户端的反馈。

由于媒体流的推送是基于媒体段来进行的，本发明实施例的方法可以根据网络的传送情况为每个媒体段选定一个网络传输协议及对应的传送连接，因此，各媒体段可以选择在不同的连接上传送，不会出现单个连接时的累积延时现象。

应理解，步骤S101和步骤S102的设置仅为了描述的方便，而不用于限制方法的执行顺序，在具体实现中，步骤S101和步骤S102可以作为两个并行的执行进程或线程。

上述是对实施例1的详细阐述，下面将对实施例2进行详细说明，以下实施例中，将对服务器如何生成初始媒体段做出说明。

进一步地，在本发明的一个实施例中，初始媒体段封装缺省指定的媒体单元，缺省指定的媒体单元为媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元，或者为媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元。

在本发明的实施例中，为降低传送延时，初始媒体段一般包含最新产生的媒体单元，即将最新产生的媒体单元立刻推送出去，另一方面，初始媒体段的大小与客户端的接收缓存有关，客户端接收到初始媒体段后，将其存入接收缓冲区，因此，初始媒体段的长度不应该超过其接收缓冲区的大小，因此，在推送之前，服务器和客户端应该约定初始媒体段中包含的媒体单元个数(由第一预设值决定)或初始媒体段的时长(由第二预设值决定)。

下述实施过程以MPEG2-TS实时流为例，媒体单元为一个TS片段，每个TS片段都关联了一个序号。如图2所示，假定最新产生的TS片段的序号为21，客户端和服务器约定的第一预设值为2，则初始媒体段MS1中封装了2个媒体单元(序号为20和21)。当然，我们也可以采用第二预设值来限制初始媒体段的时长，例如，假定每个TS片段的时长为1秒，第二预设值设为3秒，则意味着初始媒体段的时长不超过3秒，即最多包括3个媒体单元。

在其他实施方式中，还可以按照其他规则来选择初始媒体段中包含的媒体单元，比如选择特定优先级的媒体单元。

实施例3，以下实施例中，将对服务器如何根据客户端的反馈和媒体单元的产生情况生成新的媒体段进行说明。

进一步地，在本发明的一个实施例中，根据客户端的反馈和媒体单元的产生情况生成新的媒体段，进一步包括：每当一个新的媒体单元产生时，判断已有媒体单元是否满足一个预设的媒体段生成条件，其中，如果满足预设的媒体段生成条件，则选择部分或全部未成功发送的媒体单元封装成新的媒体段。

在本发明的实施例中，通过客户端的反馈，可以获得现有媒体单元中哪些已经成功发送，哪些还未成功发送。每当新的媒体单元产生时，检查已有媒体单元是否满足一个预设的媒体段生成条件，如果满足，即生成新的媒体段。在具体实施中，预设的媒体段生成条件可自行定义。

可选地，在本发明的一个实施例中，预设的媒体段生成条件为：最新媒体单元与已发送媒体段中的所有媒体单元的序号间隔大于或等于一个预设的序号间隔。

可选地，在本发明的一个实施例中，预设的媒体段生成条件为：最新媒体单元与已发送媒体段中的所有媒体单元的产生时间间隔大于或等于一个预设的时间间隔。

可以理解的是，本发明实施例的方法可以给出两种媒体段生成条件：

生成条件1：最新媒体单元与已发送媒体段中的所有媒体单元的序号间隔大于或等于一个指定的序号间隔(Specified Sequence Interval,SSI)；

所述SSI可以是一个固定值，即意味着每隔固定个数的媒体单元就生成一个媒体段；所述SSI也可以根据客户端的反馈和新媒体单元的产生情况来动态调整，例如，一个简单的调整过程是：根据客户端的反馈可以确定当前网络的传输带宽，根据新媒体单元的产生情况可以获得当前媒体流的码率，如果当前网络传输带宽远大于媒体流的码率时，可以加快媒体流的发送，应该减少SSI，而当网络传输带宽远小于媒体流的码率时，则可以延长媒体段的发送过程，则应该增大SSI。

生成条件2：最新媒体单元与已发送媒体段中的所有媒体单元的产生时间间隔大于或等于一个指定的时间间隔(Specified Time Interval，STI)；

STI可以是一个固定值，即意味着每隔固定时间间隔就生成一个媒体段；STI也可以根据客户端的反馈和新媒体单元的产生情况来动态调整，例如，一个简单的调整过程是：根据客户端的反馈可以确定当前网络的传输带宽，根据新媒体单元的产生情况可以获得当前媒体流的码率，如果当前网络传输带宽远大于媒体流的码率时，可以加快媒体流的发送，应该减少STI，而当网络传输带宽远小于媒体流的码率时，则可以延长媒体段的发送过程，则应该增大STI。

以MPEG2-TS实时流为例，如图2所示，假设媒体段采用TCP协议来发送，并采用生成条件1来生成媒体段，SSI的初值等于第一预设值，该值为2，即第一个媒体段MS1包括最近产生的2个媒体单元。后续的SSI的值则可以根据客户端的反馈和新媒体单元的产生情况来确定，一种调整SSI的值的实施方法如下。

客户端在接收媒体段时，同时反馈接收成功的数据量，服务器根据客户端的反馈来计算出网络的瞬时传输带宽，一种简单的方法如下：设服务器接收某个媒体段的第K次反馈时的时间为T(k)，客户端接收成功的数据量为D(k)，则采用以下公式对网络的瞬时传输带宽进行估计：

瞬时传输带宽BW(k)＝(D(k+1)-D(k))/(T(k+1)-T(k))

然后，服务器可以根据媒体单元的产生情况来计算媒体流的瞬时码率，假定媒体流中第i个媒体单元的数据量为S(i)，第i个媒体单元的产生时间为T(i)，则采用以下公式对媒体流的瞬时码率进行估计：

媒体流的瞬时码率R(i)＝S(i)/(T(i+1)-T(i))

当一个新的媒体单元产生时，首先对SSI进行调整。服务器从瞬时带宽BW(k)、BW(k-1)、BW(k-l)可以计算出一个时间段内的网络加权平均传输带宽BW_avg，同理，也可以根据瞬时码率计算出同时间段内的媒体流加权平均码率R_avg，然后将两者进行比较：如果BW_avg远大于R_avg，则减少SSI；如果BW_avg稍大于R_avg，则保持SSI的值不变；否则增加SSI。

当确定了SSI的值后，再判断是否生成媒体段。如果最新媒体单元与已发送媒体段中的所有媒体单元的序号间隔大于或等于调整后的SSI，则生成媒体段；

最后选择媒体单元封装成媒体段，一种最简单的选择方法就是将当前所有未发送成功的媒体单元封装成一个媒体段，还可以根据媒体单元的时效性和优先级进行选择，以提高传送效率，例如，在网络传输带宽较低放弃延时较大的媒体单元或者优先级低的媒体单元。

图2展示了根据客户端的反馈SSI的变化情况以及媒体段的生成情况。可以看出，当网络传输带宽下降时，SSI值增大；当网络传输带宽增加时，SSI值减少。

从上述实施例可以看出，可以根据客户端的反馈来自动调整媒体段的生成时间、时长和内容。这种对媒体段的灵活调整，可以使得媒体流的推送更好的适应网络的动态变化。

实施例4，以下实施例中，将对服务器如何采用多种网络传输协议来传送媒体段进行说明。

可选地，在本发明的一个实施例中，预设网络传输协议为以下协议之一：RTP、TCP、HTTP和QUIC。

具体地，使用TCP来传送媒体段已经在前述实施例1中做了介绍，这里，将分别阐述一下如何使用另外几种传输协议来传送媒体段。

当使用RTP协议来传送媒体段时，RTP协议实际上是建立在UDP协议之上的，因此，客户端应该提供一个IP地址和UDP端口号，由服务器来建立一个到客户端的单向UDP连接，用于发送媒体段，另一方面，服务器可提供一个UDP端口号，用于接收来自客户端的反馈。

当使用HTTP协议来传送媒体段时，可以采用两种方式，一种是每次由服务器使用HTTP POST方法将媒体段提交给服务器的特定地址，这种方式每提交一次则需要建立一次TCP连接，另一种则是采用HTTP GET，由客户端向服务器端发起请求建立连接后，服务器返回HTTP响应，但不携带消息体内容长度，使用HTTP CHUNK模式发送每个媒体段,这种方式中多个媒体段传送共用同一个TCP连接。客户端可以采用HTTP POST方法或其他的协议，在接收媒体段数据的同时向服务器发送反馈。

当使用QUIC协议来发送媒体段时，服务器与客户端建立一个QUIC连接，QUIC连接类似于TCP连接，是一个双向可靠传送的连接，因此，服务器可以直接利用QUIC连接向客户端发送媒体段，客户端也可以直接利用QUIC连接来发送反馈。

如图3所示，当一个服务器与多个不同的客户端连接时，可以约定媒体段传送时所采用的网络传输协议以及建立连接所需的参数，比如采用UDP或TCP协议时，需要约定客户端的IP地址和端口号，采用HTTP协议时，给出客户端的推送地址URL。

实施例5，以下实施例中，将对在媒体段传送过程中自动选择网络传输协议进行说明。

其中，在本发明的一个实施例中，当预设网络传输协议包含多种网络传输协议时，根据客户端的反馈和媒体流的传送需求选择网络传输协议。

具体地，当服务器和客户端约定了两种或两种以上的网络传输协议时，服务器可以根据客户端的反馈来选择所使用的网络传输协议。一般来说，客户端和服务器之间的实际传输带宽是时变的，这是因为互联网是一个带宽共享网络，同一时刻总是存在多个连接来竞争传输带宽，另一个原因是，客户端所处的终端的网络接入方式也是多种多样的，例如：

1、客户端所处的终端通过有线光纤接入互联网；

2、客户端所处的终端通过Wifi网络接入互联网，且其位置是变动的；

3、客户端所处的终端通过3G/4G移动通信网络接入互联网，且其位置是变动的。

显然，采用不同的网络接入方式时，客户端与服务器之间的网络传输质量也是不同的。通过客户端的反馈，可以对服务器与客户端之间的网络传输质量进行估计，获取一段时间内的传输性能参数，如吞吐量、传送延时、丢包率，连接中断次数等等。

另一方面，根据媒体流的传送需求，为每种网络传输协议设定对应的传输性能参数的范围，如果实际的传输性能参数一直在此范围内，则保持该网络传输协议不变，否则，选择其他的网络传输协议。

以音视频直播业务的媒体流为例，音视频直播业务允许一定的丢包率和传送延时，但不能容忍频繁的丢包和传输中断，因此，如果服务器和客户端约定了三种网络传输协议(RTP、TCP、QUIC)，则可以按图4所述规则来选择媒体段传送所使用的网络传输协议：

起始阶段使用RTP协议，监控其丢包率，如果丢包率超过第一预设门限，则选择TCP协议，若丢包率超过第二预设门限，则选择QUIC协议；

当采用TCP协议传送时，监控其连接中断次数，如果单位时间内的连接中断次数超过第三预设门限，说明网络丢包严重，则选择QUIC协议；如果超过一段预设时间(如5分钟)未发生任何连接中断，则切换回RTP协议；

当采用QUIC协议时，监控其丢包率，若丢包率小于第二预设门限，则选择TCP协议；如果丢包率小于第一预设门限，则选择RTP协议。

在上述方式中，优先选择RTP协议，在丢包率较少的时候采用TCP协议，而丢包率严重时则采用QUIC协议。RTP协议最为简单，可降低传送和处理开销，但无法提供可靠传送；TCP协议工作在内核层，支持低误码率链路上的可靠传送；QUIC协议最为复杂，工作在用户层，但可支持高误码率链路上的可靠传送。这样，可以用最小的处理和传送开销来支持媒体流在不同网络环境下的传送质量。

实施例6，以下实施例中，将对在媒体段传送过程中如何使用多个传送连接进行说明。

另外，在本发明的一个实施例中，当采用同一种网络传输协议向客户端发送不同的媒体段时，使用不同的传送连接，或者共用同一个传送连接。

具体地，当采用同一种网络传输协议向所述客户端发送不同的媒体段时，使用不同的传送连接，或者共用同一个传送连接。

当服务器向客户端发送生成的媒体段时，首先需要采用选定的网络传输协议与客户端建立至少一个传送连接，然后使用所述建立的传送连接来传送生成的媒体段。

当网络传输协议为RTP或QUIC时，由于其使用的是UDP协议，一个UDP连接可支持多个媒体段的并行发送，并不会产生队头阻塞，因此，只需要建立一个传送连接即可，该传送连接可支持所有媒体段的传送。

当网络传输协议为TCP或HTTP时，由于其使用的是TCP协议，一个TCP连接只能支持媒体段的串行发送，因此，如果某个媒体段没有发送成功，会阻塞后续的所有媒体段，此时，可以建立多个TCP连接或HTTP连接，并根据媒体段的传送情况来决定使用哪个连接。

这种多个连接的建立方式可以是串行的，即为每个发送的媒体段单独建立一个TCP连接或HTTP连接，在媒体段发送完毕后关闭连接。为了尽可能减少传送的延时，可以在每个媒体段产生之前建立连接。但是，这种方式会导致大量连接的建立和释放，增加传送和处理开销。

另一种更好的做法是，始终并行建立和维护少数几个(如2个或3个)连接，根据媒体段的产生情况和传送情况来决定选择哪个传送连接。

以TCP协议为例，如图5所示，初始时建立两个到客户端的TCP连接，TCP连接1作为媒体段传送的主连接，而TCP连接2作为备用连接。当媒体段在TCP连接1上发送未遇到阻塞或其他故障时，将新生成的媒体段放在TCP连接1上传送。当通过客户端的反馈发现TCP连接1出现阻塞或故障时，需要重新调整发送的媒体单元时，将新生成的媒体段放到TCP连接2上传送，即将TCP连接2作为主连接，同时建立TCP连接3作为备用连接。

采用上述多连接传送方式，可以在单个连接因为阻塞或链路故障无法继续使用时，快速将新生成的媒体段切换到备用的TCP连接上传送，避免使用单个TCP连接导致的累积延时问题。

根据本发明实施例的媒体流的实时推送方法，可以通过媒体流的自适应分段，实现媒体数据的分段推送，提高媒体流的传送效率，并且可以根据客户端的反馈来自动调整媒体段的时长和内容，以适应网络的动态变化；其次，媒体段的传送可以采用任意指定的网络传输协议，并且还可以根据网络传输情况为每个客户端甚至每个媒体段选择合适的网络传输协议，以适合复杂网络环境下的传送；最后，当采用同一个网络传输协议传送不同的媒体段时，既可以共享同一个传送连接，也可以分别采用不同的传送连接，以避免网络拥塞或故障导致的累积延时。

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

图6是本发明实施例的媒体流的实时推送服务器的结构示意图。

如图6所示，该媒体流的实时推送服务器10包括：媒体段生成组件100和媒体段发送组件200。

其中，媒体流为实时产生的媒体单元的序列，其中，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号。具体地，媒体段生成组件100用于生成媒体段，其中，生成初始媒体段，并根据客户端的反馈和媒体单元的产生情况生成新的媒体段，媒体段封装有至少一个媒体单元，客户端的反馈包括媒体段中已接收数据的指示。媒体段发送组件200用于向客户端发送生成的媒体段并接收客户端的反馈，其中，采用预设网络传输协议与客户端建立至少一个传送连接，以使用至少一个传送连接传送生成的媒体段。本发明实施例的服务器10可以实现媒体流的自适应分段推送，提高媒体流的传送效率和在复杂网络环境下的传送性能。

具体而言，媒体段生成组件100实现了媒体流的自适应分段，首先，生成初始媒体段，并将初始媒体段交给媒体段发送组件200去发送，并同时从媒体段发送组件200中接收客户端的反馈。通过客户端的反馈和新的媒体段的生成情况，媒体段生成组件100决定在什么时刻生成新的媒体段以及新的媒体段中应包括哪些媒体单元，然后将生成的媒体段提交给媒体段发送组件200去发送。

媒体段发送组件200用于将生成的媒体段发送给客户端，同时接收客户端的反馈。媒体段发送组件200接收媒体段生成组件100中产生的媒体段，并将该媒体段发送给客户端，同时将客户端的反馈传递给媒体段生成组件100。为了发送一个媒体段，媒体段发送组件200采用选定的网络传输协议与客户建立至少一个传送连接，然后使用所述建立的传送连接来传送生成的媒体段。

进一步地，在本发明的一个实施例中，初始媒体段封装缺省指定的媒体单元，缺省指定的媒体单元为媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元，或者为媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元。

进一步地，在本发明的一个实施例中，媒体段发送组件200进一步用于每当一个新的媒体单元产生时，判断已有媒体单元是否满足一个预设的媒体段生成条件，其中，如果满足预设的媒体段生成条件，则选择部分或全部未成功发送的媒体单元封装成新的媒体段。

可选地，在本发明的一个实施例中，预设的媒体段生成条件为：最新媒体单元与已发送媒体段中的所有媒体单元的序号间隔大于或等于一个预设的序号间隔。

可选地，在本发明的一个实施例中，预设的媒体段生成条件为：最新媒体单元与已发送媒体段中的所有媒体单元的产生时间间隔大于或等于一个预设的时间间隔。

可选地，在本发明的一个实施例中，预设网络传输协议为以下协议之一：RTP、TCP、HTTP和QUIC。

其中，在本发明的一个实施例中，当预设网络传输协议包含多种网络传输协议时，根据客户端的反馈和媒体流的传送需求选择网络传输协议。

另外，在本发明的一个实施例中，当采用同一种网络传输协议向客户端发送不同的媒体段时，使用不同的传送连接，或者共用同一个传送连接。

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

根据本发明实施例的媒体流的实时推送服务器，可以通过媒体流的自适应分段，实现媒体数据的分段推送，提高媒体流的传送效率，并且可以根据客户端的反馈来自动调整媒体段的时长和内容，以适应网络的动态变化；其次，媒体段的传送可以采用任意指定的网络传输协议，并且还可以根据网络传输情况为每个客户端甚至每个媒体段选择合适的网络传输协议，以适合复杂网络环境下的传送；最后，当采用同一个网络传输协议传送不同的媒体段时，既可以共享同一个传送连接，也可以分别采用不同的传送连接，以避免网络拥塞或故障导致的累积延时。

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

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

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

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

在本发明中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”、“固定”等术语应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或成一体；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通或两个元件的相互作用关系，除非另有明确的限定。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。

在本发明中，除非另有明确的规定和限定，第一特征在第二特征“上”或“下”可以是第一和第二特征直接接触，或第一和第二特征通过中间媒介间接接触。而且，第一特征在第二特征“之上”、“上方”和“上面”可是第一特征在第二特征正上方或斜上方，或仅仅表示第一特征水平高度高于第二特征。第一特征在第二特征“之下”、“下方”和“下面”可以是第一特征在第二特征正下方或斜下方，或仅仅表示第一特征水平高度小于第二特征。

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

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

Claims (19)

1.一种媒体流的实时推送方法，其特征在于，媒体流为实时产生的媒体单元的序列，其中，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，其中，所述方法包括：

生成媒体段，其中，生成初始媒体段，并根据客户端的反馈和媒体单元的产生情况生成新的媒体段，所述媒体段封装有至少一个媒体单元，所述客户端的反馈包括所述媒体段中已接收数据的指示；

向所述客户端发送生成的媒体段并接收所述客户端的反馈，其中，采用预设网络传输协议与所述客户端建立至少一个传送连接，以使用所述至少一个传送连接传送生成的所述媒体段。

2.根据权利要求1所述的媒体流的实时推送方法，其特征在于，所述初始媒体段封装缺省指定的媒体单元，所述缺省指定的媒体单元为所述媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元，或者为所述媒体流中所有和所述最新媒体单元的产生时间间隔小于第二预设值的媒体单元。

3.根据权利要求1所述的媒体流的实时推送方法，其特征在于，所述根据客户端的反馈和媒体单元的产生情况生成新的媒体段，进一步包括：

每当一个新的媒体单元产生时，判断已有媒体单元是否满足一个预设的媒体段生成条件，其中，如果满足所述预设的媒体段生成条件，则选择部分或全部未成功发送的媒体单元封装成所述新的媒体段。

4.根据权利要求3所述的媒体流的实时推送方法，其特征在于，所述预设的媒体段生成条件为：最新媒体单元与已发送媒体段中的所有媒体单元的序号间隔大于或等于一个预设的序号间隔。

5.根据权利要求3所述的媒体流的实时推送方法，其特征在于，所述预设的媒体段生成条件为：最新媒体单元与已发送媒体段中的所有媒体单元的产生时间间隔大于或等于一个预设的时间间隔。

6.根据权利要求1所述的媒体流的实时推送方法，其特征在于，所述预设网络传输协议为以下协议之一：RTP、TCP、HTTP和QUIC。

7.根据权利要求1所述的媒体流的实时推送方法，其特征在于，当所述预设网络传输协议包含多种网络传输协议时，根据所述客户端的反馈和所述媒体流的传送需求选择网络传输协议。

8.根据权利要求1所述的媒体流的实时推送方法，其特征在于，当采用同一种网络传输协议向所述客户端发送不同的媒体段时，使用不同的传送连接，或者共用同一个传送连接。

9.一种媒体流的实时推送服务器，其特征在于，媒体流为实时产生的媒体单元的序列，其中，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，其中，所述服务器包括：

媒体段生成组件，用于生成媒体段，其中，生成初始媒体段，并根据客户端的反馈和媒体单元的产生情况生成新的媒体段，所述媒体段封装有至少一个媒体单元，所述客户端的反馈包括所述媒体段中已接收数据的指示；

媒体段发送组件，用于向所述客户端发送生成的媒体段并接收所述客户端的反馈，其中，采用预设网络传输协议与所述客户端建立至少一个传送连接，以使用所述至少一个传送连接传送生成的所述媒体段。

10.根据权利要求9所述的媒体流的实时推送服务器，其特征在于，所述初始媒体段封装缺省指定的媒体单元，所述缺省指定的媒体单元为所述媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元，或者为所述媒体流中所有和所述最新媒体单元的产生时间间隔小于第二预设值的媒体单元。

11.根据权利要求9所述的媒体流的实时推送服务器，其特征在于，所述媒体段发送组件进一步用于每当一个新的媒体单元产生时，判断已有媒体单元是否满足一个预设的媒体段生成条件，其中，如果满足所述预设的媒体段生成条件，则选择部分或全部未成功发送的媒体单元封装成所述新的媒体段。

12.根据权利要求11所述的媒体流的实时推送服务器，其特征在于，所述预设的媒体段生成条件为：最新媒体单元与已发送媒体段中的所有媒体单元的序号间隔大于或等于一个预设的序号间隔。

13.根据权利要求11所述的媒体流的实时推送服务器，其特征在于，所述预设的媒体段生成条件为：最新媒体单元与已发送媒体段中的所有媒体单元的产生时间间隔大于或等于一个预设的时间间隔。

14.根据权利要求9所述的媒体流的实时推送服务器，其特征在于，所述预设网络传输协议为以下协议之一：RTP、TCP、HTTP和QUIC。

15.根据权利要求9所述的媒体流的实时推送服务器，其特征在于，当所述预设网络传输协议包含多种网络传输协议时，根据所述客户端的反馈和所述媒体流的传送需求选择网络传输协议。

16.根据权利要求9所述的媒体流的实时推送服务器，其特征在于，当采用同一种网络传输协议向所述客户端发送不同的媒体段时，使用不同的传送连接，或者共用同一个传送连接。

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

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

19.一种计算机程序产品，当所述计算机程序产品中的指令由处理器执行时，执行如权利要求1-8中任一所述的方法。

Images