数据流控制方法与流程

本申请涉及用于将媒体数据从流传输服务器传送到一个或多个客户端的数据传输协议。更具体地，本发明提供了可以与诸如TCP/IP的现有协议结合使用的增强型数据流控制方法。根据本发明的数据流控制方法考虑了网络条件以及接收节点或客户端设备条件(例如客户端播放器的数据缓冲器)，以提高互联网协议电视(IPTV)应用的媒体数据传输的速度和质量。

背景技术：

视频业务目前占了通信网络(例如互联网或现今任何类似的无线通信网络，如LAN、WLAN等)上的超过60％的世界带宽使用。如何将这些数据注入到网络中对通过网络的整个数据流具有重要影响。对网络的不受控数据注入可能导致拥塞影响，例如缓慢的整体业务流、分组延迟、分组丢失、分组乱序、分组重传、网络设备(路由器、交换机等)泛滥/崩溃、以及不可控业务的泛滥。这些类型的事件导致网络流量变慢，并且如果使用中的交换机和路由网络设备无法处理流量需求，则有时会完全停止。此外，无管理数据注入将对依赖于实时通信的应用(例如VoIP(IP语音)、媒体事件的实况广播、实时视频会议和其他时间敏感应用)具有负面影响。

传输控制协议(TCP)是互联网协议组(IP)(即，用于互联网的网络协议集合)的核心协议之一。TCP在运行于连接到局域网(LANO、内联网或互联网)的计算机的程序之间提供可靠、有序、校错的八位字节流传输。它驻留在传输层。互联网协议电视(IPTV)是这样一种系统，通过该系统使用互联网协议组在诸如LAN或互联网的分组交换网络上传送电视服务，而不是通过传统的地面、卫星信号和有线电视格式来传送电视服务。TCP是互联网上最常用的协议。其原因是因为TCP提供了纠错。当使用TCP协议时，存在“受保障传送”。原因在于TCP中被称为“流控制”的方法。流控制确定何时需要重新发送数据，并且在先前数据分组已成功传输之前何时停止数据流。这产生效果，其原因在于如果发送数据分组，则可能发生冲突。当发生冲突时，接收客户端系统或端点可以向发送数据的服务器重新请求分组，直到整个分组完成并且与所发送的原始分组相同为止。因此，TCP是一种高级传输协议，其具有100％的数据传输成功率、内置流控制和纠错，从而在无管理网络上有效运行。对于一个或多个网络段不被IPTV服务运营商管理的所有开放网络IPTV部署来说，目前需要使用TCP。

然而，在IPTV流传输应用中采用TCP具有许多缺点，并且由于该协议的结构，可能导致网络流量问题。由于标准TCP的默认数据帧结构，因此标准TCP的数据传输的开销大。报头指的是数据信元或分组的第一部分，其包含诸如源地址和目的地地址的信息以及关于电信网络如何处理数据的指令。报头是数据传输协议中的开销的一部分。对于典型的TCP/IP传输，即大多数互联网业务，报头通常是每个分组的40个字节(20个字节的TCP和20个字节的IP报头)。如果在所传输的数据中启用了“选项”，则TCP和IP报头可以大于20个字节。互联网控制消息协议(ICMP)，即用于发送测试和控制消息的协议，具有28个字节的报头。报头造成的这种开销可能影响IPTV用户体验，尤其是当网络条件异常时，即由于繁忙业务流量造成拥塞。TCP不提供切断传输流以改善网络拥塞的能力。另外，TCP无法在不产生不必要的数据浪费的情况下管理到IPTV客户端播放器的带宽发送速率。

用户数据报协议(UDP)也是互联网协议组的核心成员之一。使用UDP，计算机应用可以向互联网协议(IP)网络上的其他主机发送消息(在这种情况下称为数据报)，而无需预先通信来建立特殊传输信道或数据路径。UDP使用具有最小协议机制的简单传输模型。它没有握手对话，并且因此将底层网络协议的任何不可靠性都暴露给用户程序。UDP提供针对数据完整性的校验和以及用于在数据报的源和目的地处寻址不同功能的端口号。然而，在UDP中没有传送保障、有序性或重复保护。

UDP适合于校错和纠错不是必需或者在传输之前已在应用处执行的目的，从而避免这种在网络接口级的处理开销。时间敏感的应用往往使用UDP，因为优选丢弃数据分组，而不是等待延迟的分组，等待延迟的分组在实时系统中并不是一个可行的选择。如果在网络接口级需要纠错设施，则驻留在主机或用于发送该数据的系统上的应用将需要使用传输控制协议(TCP)或流控制传输协议(SCTP)，其被设计用于此目的。

UDP具有优于TCP的一些独特优点，但也有缺点。例如，当传输要求将单播方法和多播方法组合时，需要UDP。多播的使用允许以固定数据速率占用可用带宽，而不面对用户增长容量问题。然而，UDP不能用于发送诸如网页、数据库信息等重要数据，并且其目前的用途主要限于流传输音频和流传输视频。UDP可以提供速度并且与TCP相比数据传输得更快，因为在UDP中没有流控制或纠错的形式。因此，使用UDP在互联网上发送的数据受到冲突的影响，并且会出现错误。因此，UDP仅被推荐用于在受管理网络(即，服务质量(QoS)由服务提供商管理的网络)上或者当数据丢失不是传输的考虑因素时流传输媒体。由于其简单和轻量级设计，当在不太可能发生分组冲突的QoS管理网络上传输数据时，UDP是一种理想的传输协议。与TCP相比，UDP提供了快速数据注入、更低的分组开销和更快的响应时间。对于IPTV，上述益处可以改善电视等的体验，尤其是快速频道切换、即时电影回放等，并且还减轻了服务器和网络设备的压力。然而，使用UDP，业务冲突和分组丢失不可避免，因为该协议没有任何内置的流控制机制。

Nagle算法(以John Nagle命名)提出了通过减少需要在网络上发送的数据分组的数量来提高TCP/IP网络的效率。在该技术中，在IP/TCP网络(RFC 896)中的拥塞控制中，描述了应用以小数据块(通常大小仅为1个字节)重复发射数据的“小分组问题”。由于TCP分组具有40个字节的报头(20个字节用于TCP，20个字节用于IPv4)，因此对于仅1个字节的有用信息，将产生41个字节的分组，这是一个巨大的开销。这种情况经常发生在Telnet会话中，其中大多数按键按压产生即刻传输的单字节数据。在缓慢的网络链路上，可能有许多这样的分组正在同时传输，这可能导致拥塞崩溃。Nagle的算法通过组合多个小的外发消息并将它们一次性发送来工作。具体地，发送方系统或应用应该对其输出保持缓冲，直到其具有值得输出的完整分组，使得可以一次性发送该输出。下面说明使用Nagle算法的现有技术。

A.对于任何TCP连接来说，最多有一个小分组未被接收机应用或设备确认。除非其被确认，否则发送机不发送任何其他小分组(具有很少数据字节的有用信息)。

B.TCP收集这些小分组，并仅当接收到该确认之后将它们作为一个整体分组发送出去。因此，随着更多确认到达，发送更多的数据分组。在WAN/MAN/LAN之一上，TCP连接的往返时间(RTT)值的范围通常为100ms至300ms。该延迟允许TCP有足够的时间在下一个确认到达之前收集小分组。

尽管使用TCP以及Nagle算法有利于使用TCP的一些类型的数据通信和传输，但是该益处并没有扩展到IPTV数据和服务，在IPTV数据和服务中，300ms的倍数的延迟对于确定好或差的用户体验来说可能至关重要。对于许多应用来说，这样的延时不可接受。

因此，需要用于通信网络上的数据分组传输的新方法或新协议，其克服了TCP和UDP的缺点，并且以最小的网络流量开销来提供速度、流控制和纠错。

技术实现要素：

在一个方面中，本发明提供一种用于通过通信网络从发送节点向接收节点发送媒体数据的数据流控制方法，所述接收节点能够播放所述媒体数据，所述方法包括：识别所述发送节点和接收节点之间的通信网络的条件；识别所述接收节点的条件；以及基于所识别的所述通信网络的条件和所识别的所述接收节点的条件来调整通过所述通信网络的媒体数据流。

在另一方面中，所述发送节点被配置为：基于来自所述接收节点的对媒体数据的请求，对所述媒体数据进行编码并将编码后的媒体数据流传输到所述接收节点，并且所述接收节点能够对所述媒体数据进行解码和回放。

在另一方面中，识别网络的条件的步骤包括：检测网络流量的水平并基于检测到的网络业务的水平来确定所述发送节点和所述接收节点之间的网络处于正常状态还是处于拥塞状态；以及

-其中，识别所述接收节点的条件的步骤包括：确定所述接收节点处的数据缓冲器处于安全水平、不安全水平还是临界水平，所述缓冲器在安全水平是80％满载或更多，在不安全水平是20％-80％满载，并且在临界水平是0％-20％满载；其中，周期性地监视所述网络条件和所述接收节点条件，并以定义的间隔在所述发送节点和所述接收节点之间传送所述网络条件和所述接收节点条件。

在另一方面中，响应于来自所述接收节点的对媒体数据的请求，本发明包括：

-以初始数据流传输速率流传输所请求的媒体数据；

-识别所述接收机节点支持的最大数据流传输速率；

-识别网络的条件；

-识别接收节点的条件；-如果网络条件被识别为正常且缓冲器的条件处于临界或不安全水平，则连续增加数据流传输的速率，直到达到所述最大速率为止，或直到缓冲器达到安全水平为止，或直到网络条件变为拥塞为止。

在另一方面中，如果在连续增加数据流传输速率的步骤期间接收节点处的缓冲器达到安全水平，则所述方法包括：将数据流传输的速率调整为等于回放期间的缓冲器的消耗速率的速率。

在另一方面中，如果在连续增加数据流传输的速率的步骤期间网络条件变为“拥塞”并在第一定义时间段内保持拥塞，则所述方法包括：

-识别接收节点处的数据缓冲器中的剩余数据的剩余回放时间；

-将数据流传输的速率降低到接近零或计算出的低流传输速率，或者完全暂停来自服务器的数据的流传输，直到网络条件变为正常或者所识别的剩余回放时间减少到15秒或更少为止。

在另一方面中，如果剩余回放时间减少到15秒或更少，则所述方法包括：

-请求所述发送节点接受在所述发送节点和所述接收节点之间的附加网络通信链路；

-确定在所述接收节点处维持实时回放所需的附加链路的总数；

-由所述发送节点建立附加链路；

-从所述发送节点在建立的所有链路上均匀地流传输媒体数据，使得如果网络条件被识别为在所述多个链路中的第一链路上拥塞，则经由下一个可用的通信链路发送媒体数据。

在另一方面中，所述方法包括：通过使用每个媒体数据帧的报头部分中的顺序标识符对无序地到达所述接收节点的媒体数据分组进行重新排序。在另一方面中，所述方法还包括：

-识别能够将所请求的媒体数据流传输到所述接收节点的一个或多个附加发送节点；

-由所述发送节点中的每一个发送节点建立到所述接收节点的附加通信链路，使得每个发送节点能够在附加链路上发送媒体数据事件。

在另一方面中，所述发送节点处的流传输应用能够根据适合于所识别的接收节点的缓冲器的缓冲器条件的比特率，对要从所述发送节点流传输的媒体数据进行自适应编码。

在另一方面中，本发明提供了一种用于通过通信网络从发送节点向接收节点发送媒体数据的数据流控制方法，所述接收节点能够播放所述媒体数据，所述方法包括：

响应于所述接收节点对媒体数据的请求，确定所述媒体数据的副本是本地存储在所述接收节点处还是存储在所述接收节点可访问的存储器设备上；其中，如果数据请求的整个文件或部分的本地副本存储在本地可用，则访问该副本并请求所述发送节点仅流传输缺少的部分。

在另一方面中，如果所请求的媒体数据的本地副本在所述接收节点处不可用，则所述方法包括以下步骤：

识别接收节点的条件，所述条件包括连接到所述节点的显示屏幕的屏幕大小、分辨率和能力；

根据所识别的所述显示屏幕支持的屏幕大小、视频分辨率和能力，选择用于流传输媒体数据的比特率；

在开始所述流传输时，使用所选择的比特率或更高比特率从所述发送节点流传输所请求的媒体数据，而不是以最低可用比特率开始所述流传输。

在另一方面中，如果网络条件被识别为拥塞，则通过仅将媒体数据分组的I帧流传输到所述接收节点而不将所述媒体数据的B帧和P帧流传输到所述接收节点，以当前流传输速率继续所述流传输，直到网络条件变为正常为止，以确保持续流传输所述媒体数据以便在接收节点处回放。

在另一方面中，当缓冲器处于安全水平时，所述方法包括：

-识别存储在数据缓冲器中的具有低视频比特率的先前流传输的段或缓冲器队列中的部分GOP；

-识别接收节点处的数据缓冲器中的剩余数据的剩余回放时间；

-如果剩余回放时间大于10秒，则识别从所述发送节点流传输媒体数据的当前速率；

-如果当前流传输的速率大于接收节点所支持的平均速率，则所述方法还包括：请求发送节点重新发送具有低视频比特率的现有帧或具有更高视频比特率的部分GOP。

在另一方面中，本发明提供了一种用于通过通信网络从发送节点向接收节点发送媒体数据的数据流控制方法，所述接收节点能够播放所述媒体数据，所述方法包括：

响应于所述接收节点对媒体数据的请求，识别多个中间数据提供者节点，每个中间数据提供者节点存储所请求的媒体数据的本地副本；

-如果被识别为所述接收节点的邻居的数据提供者节点是所识别的中间节点之一，则从该邻居数据提供者节点获得媒体数据的副本，所述邻居节点是所述接收节点的对等节点；

-如果没有数据提供者被识别为所述接收节点的邻居，则从所述发送节点流传输所请求的媒体数据。在另一方面中，本发明提供一种用于通过通信网络从发送节点向接收节点发送媒体数据的数据流控制方法，所述接收节点能够播放所述媒体数据，所述方法包括：响应于所述接收节点对媒体数据的请求，在定义的时间段以当前可用比特率从所述发送节点流传输所述媒体数据，以检测网络带宽；

-如果所述带宽能够支持比当前速率更高的视频比特率，则对网络进行比较以切换为所述更高的视频比特率以用于连续的流传输。

在另一方面中，本发明提供了一种用于通过通信网络从发送节点向接收节点发送媒体数据的数据流控制方法，所述接收节点能够播放所述媒体数据，所述方法包括：

响应于所述接收节点对媒体数据的请求，在定义的时间段以当前可用比特率从所述发送节点流传输所述媒体数据，以检测网络带宽；

-在所述流传输之前，识别要被流传输的高动态视频数据的多个画面组(GOP)并且检查每个GOP的大小和平均比特率以及网络条件；

-如果GOP的平均比特率比当前流传输的媒体的平均比特率小30％，则所述方法包括：将所述GOP识别为低动态画面GOP，并将当前流传输比特率切换为更低比特率从而以当前比特率流传输GOP；

-如果GOP的平均比特率比平均比特率大30％，则所述方法包括：将所述GOP识别为高动态画面GOP，并将当前流传输比特率切换为最高可用比特率从而以最高比特率流传输GOP。

在另一方面中，所述发送节点是IPTV流传输服务器，并且所述接收节点是包括多媒体播放器的客户端设备。在另一方面中，本发明提供了一种用于实现根据前述权利要求中任一项所述的方法的系统，包括能够经由通信网络进行通信的发送节点和接收节点，所述发送节点具有能够流传输存储在所述发送节点的存储装置中的多媒体数据的流传输模块，并且所述接收节点能够请求从所述发送节点流传输多媒体数据以在所述接收节点包括的多媒体播放器上回放。

附图说明

图1和图2分别示出了TCP和UDP的帧结构。

图3示出了描绘根据第一实施例的数据流控制方法的指数加速模式的流程图。

图4示出了描绘根据第一实施例的数据流控制方法的指数回退模式的流程图。

图5示出了描绘根据第一实施例的数据流控制方法的线性涓退(trickle off)模式的流程图。

图6示出了根据第二实施例的数据流控制方法的数据共享模式的比特率选择方法。

图7示出了根据第三实施例的数据流控制方法的高质量视频数据回放的自适应比特率选择方法。

图8示出了根据第三实施例的数据流控制方法的基于分辨率的比特率选择方法。

图9示出了描绘根据第三实施例的数据流控制方法的选择性帧丢弃的方法的流程图。

图10a和10b分别示出了描绘具有和不具有图9的选择性帧丢弃的观看体验的图表。

图11示出了描绘根据第三实施例的数据流控制方法的用于对高动态视频帧进行带宽分配的方法的流程图。

图12示出了描绘根据第三实施例的数据流控制方法的缓冲器修复模式的流程图。

图13示出了描绘第一、第二和第三实施例的模式之间的交互的流程图。

图14示出了描绘根据本发明的自适应地启用或禁用Nagle算法的方法的流程图。

图15a和15b分别示出了描绘使用和不使用图14的方法的性能测试结果的表格和曲线图。

具体实施方式

当数据沿着网络移动时，各种属性被添加到数据文件以创建帧。这一过程被称为封装。根据所使用的协议和拓扑，存在不同的封装方法。因此，数据帧的帧结构不同。图1示出了TCP帧结构，图2示出了UDP帧结构。所示帧中的有效载荷字段包含实际数据。TCP具有比UDP更复杂的帧结构。这主要是因为TCP是可靠的面向连接的协议，如背景部分中所解释的。图1所示的附加字段(当与图2所示的UDP帧相比时)是确保由TCP提供的“受保障传送”所需的字段。因此，当与UDP比较时，TCP是一个慢得多的数据传输协议，并且具有大得多的开销。如果TCP与背景部分描述的Nagle算法的使用相结合时，尤其如此。

本发明提供了一种在互联网协议组中使用的新的数据传输协议或数据流控制方法。具体地，本发明提供了用于媒体数据分组传输(优选地，通信网络上的视频数据传输)的多个流机制或模式，其克服了TCP和UDP的缺点，并在最小网络流量开销的情况下提供了速度、流控制和纠错机制。

在一个方面，本发明提供了一种对OSI模型的应用层上的数据流管理进行处理的数据流控制方法。尽管本发明涉及媒体数据，尤其涉及IPTV服务的视频数据，但是本领域技术人员将容易理解，本发明可以用于管理可以在通信网络(例如互联网)上传输的任何类型的数据和信息的流。

根据本发明第一实施例的数据流控制方法基于监视一个或多个发送节点或服务器侧条件(例如，用于发送数据的IPTV提供商服务器)以及一个或多个接收节点或客户端侧条件(用于接收数据的客户端设备，例如播放器或机顶盒)。本发明促进发送服务器和接收客户端之间的信息通信和数据交换，以便传送每一端的本地网络条件。基于从客户端设备和服务器设备两者检测到的条件，根据第一实施例的数据流控制方法能够计算和预测网络环境。

当网络条件被检测到或被通知给服务器或客户端时，根据本发明的流控制方法能够应用一种或多种数据传输模式或技术(这些模式在下文中详细解释)，以确保可以在无管理和/或波动的网络上流传输高质量视频数据。在另一方面，本发明的数据流控制方法能够通过数据共享、本地缓存和数据再循环来消耗网络中的未使用的带宽(剩余或浪费的带宽)，以进行更有效的数据传输。

在另一方面，本发明的数据流控制提供高视频质量传送并且保持在任何网络上的视频回放的流畅性。

数据流控制方法或协议结合了通过HTTP(超文本传输协议)封装的RTSP(实时流传输协议)的组合。在应用层中处理根据本发明的数据流控制方法。该方法能够实现驻留在服务器侧或客户端终端或者这两者上的一个或多个模块。配备有用于实现这样的流控制的模块的客户端和服务器节点一直共同协作，以预测网络流、调整数据流、增强视频质量、通过各种网络路由进行导航，维持常规数据传输协议(如TCP和UDP)不能提供的良好IPTV用户体验。

本申请的一些目标是在快速响应、流畅数据流和数据质量之间进行平衡。下面提供根据本发明的数据流控制方法的一些优点的概述。针对单个传输实现所有这些优点不是必要的，因为对特定传输来说一个效果可能比其他有利效果更重要。A.尽可能快地向终端用户发送媒体数据，以确保用户设备(即客户端系统)处的缓冲器保持满载并保持流畅回放。

B.先于TCP检测拥塞并立即(而不像TCP那样逐渐)回退(减少或停止发送分组)，这将有助于快速缓解拥塞。C.在建立会话之前通过使用动态多链路策略(多个网络路径和路由)来有效地使用带宽。

D.检测并区分物理网络拥塞与常规网络拥塞，并应用适当的控制模式，避免自我竞争。

E.支持基于网络条件的自适应比特率流传输。

F.通过充分利用网络信道并优先考虑高比特率视频GOP(画面组)来提供高视频体验。

G.提供缓冲器修复，使得当客户端缓冲器处于健康阶段时，数据流控制方法被配置为重新评估缓冲器上的视频比特率，并用较高的视频质量替换较低/较差质量的段。这种修复仅当网络条件允许时才安全有效地进行。

H.流控制方法被配置为通过在本地存储设备上缓存热门数据来再循环数据以防止来自服务器的重复流传输，并且还被配置为与对端共享本地缓存的数据。

I.当条件允许时切换到P2P类型的通信。这主要用于VOD和电视重播场景

J.与其他类型的服务数据流(例如VoIP)和平共存，即没有分组冲突。

根据本发明的应用层数据流控制方法包括数据流控制方法和视频质量控制方法。

根据本发明的第一实施例，基于网络条件和缓冲器条件来应用的数据流控制方法或模式是：

A.指数加速(以速率递增的方式发送数据)

B.指数回退(将数据发送速率降低至接近零)

C.线性或流畅的涓流模式(发送数据速率等于视频播放速率)

D.动态的多个链接(在多个TCP连接中发送数据)

E.考虑网络和播放器缓冲器条件的自适应流传输。根据本发明的第二实施例，用于实现数据共享以改善整体网络和流传输效率并减少网络资源的数据流控制方法是：

A.数据再循环(尽可能地保留和重用缓存的数据)

B.混合型点对点(P2P)流传输(在条件允许时以受控方式接收并与其他客户端共享数据)

根据本发明的第三实施例，视频质量流控制方法是：

A.基于质量贪婪条件的自适应比特率流传输(确保以最高优先级发送高质量视频数据)。

B.智能开始视频比特率选择(基于设备分辨率动态选择视频最佳比特率，以改善用户体验)

C.视频帧选择性丢弃或帧忽略(在网络条件改善前，通过忽略非I帧来维持视频连续性)

D.动态画面优先(对高动态视频帧的带宽分配)

E.低视频质量缓冲器修复/用较高比特率替换差的视频(如果出现正确的条件，则回到缓冲器用较高视频质量替换在先的还未播放的低质量视频(GOP))

5.1第一实施例

基于网络条件以及客户端或接收节点的缓冲器条件的数据流控制机制。

虽然TCP对视频流传输来说是够用且可靠的，但是良好的IPTV体验是指与传统数字有线电视、卫星电视和地面电视差不多的体验。期望达到良好的视频质量、快速的频道变更、即时的视频获取以及连续的流传输。为了实现这一水平，本发明提出了多个数据流控制机制，其可以与TCP、公共网络一起工作并在拥塞的网络段周围进行导航。以下机制或数据流控制模式不同于传统TCP或UDP所应用的技术，因为它们基于从发送节点流传输数据时的网络条件与播放器或客户端缓冲器的条件的协作。以前和现有的系统没有这种协作，并且依赖于报告网络中的异常。在本发明中，可以从服务器(发送节点，其不必仅是数据的唯一或原始源，还可以是存储数据文件的中间节点)、客户端或端用户接收节点/播放器、或者这两个节点(通过利用它们之间的信息交换)获得网络条件和缓冲器条件。

5.1.1指数加速(尽可能快地前推)：

图3示出了第一实施例的指数加速数据流控制机制。以下说明该机制的优选步骤：

3a.将初始发送速率init_rate设置为1.6xVOD(视频点播)文件的“实时回放”比特率(表示为rt_bitrate)。

3b.将最大推送速率max_rate设置为0.625x(1/1.6x)从播放器报告的下行链路带宽。

3c.如果max_rate小于init_rate，则流控制方法将max_rate设置为init_rate。

3d.尝试以init_rate前推媒体数据。如果网络正常(无拥塞)，则尝试以速度1.6x当前速度(即1.6*init_rate，其等于1.6*1.6*rt_bitrate)进行推送。

3e.以指数方式继续提高推送速度，直到播放器侧的高速缓存缓冲器为80％、达到max_rate、或网络变得拥塞为止。

上述步骤3a-3e阐述了指数加速数据流控制模式的主要特征。以下步骤说明了基于附加的异常缓冲器条件和网络条件而采用的机制，并且阐述了通过与第一实施例的其他数据流控制机制交互来实现在指数加速模式之后的有效数据流的过程。3f.如果缓存水平大于95％，则立即进入指数回退过程(这将在下面的5.1.2中说明)。

3g.否则，如果高速缓存缓冲器大于80％，则进入线性涓流模式(参见下面的5.1.3)，从而以1x rt_bitrate前推媒体数据。

3h.如果达到max_rate，则保持该速率，直到高速缓存缓冲器为80％或网络变得拥塞为止。3i.当网络变得拥塞时，如果高速缓存缓冲器达到临界水平，则数据流控制方法前进到动态多链路处理(参见5.1.4)。否则，推送(流传输)速度可以降低到当前速度的0.625x(1/1.6x)。如果普遍存在网络拥塞，则推送速度可以降低到当前速度的0.625x(1/1.6x)，但不小于1x rt_bitrate。当在播放器侧(即客户端设备)上进行缓冲时，可以发起多路径/并发多路由处理(参见5.1.5项)。

3j.当网络从拥塞中恢复时，数据流控制机制试图以最近的推送速度发送，然后前进到重复上述步骤3e-3j。

3k.在流控制方法从指数回退返回(参见5.1.2)之后，可以重复上述步骤3d-3j。

5.1.2指数回退

第一实施例的流控制方法的该回退机制可以在检测到与预设回退标准相匹配的网络或播放器缓冲器的拥塞/条件时触发。缓解IPTV分组数据传输的拥塞的最佳解决方案是使用一个或多个不同的路径进行回退或导航，以避免加重(contribute)现有的网络拥塞和业务。当检测到拥塞时，触发根据本发明的数据流控制方法的指数回退模式或机制(也称为友好回退模式)。该模式将暂停所有其他流控制模式，并将数据发送速率降至接近零或“0.05x rt_birate”，以为其他应用产生带宽。图4中示出了第一实施例的指数回退数据流控制机制。以下说明该机制的优选步骤：

4a.在回放会话期间，具有流传输应用或模块的服务器或系统将尝试根据第5.1.1项所述的“指数加速”机制来前推媒体数据。

4b.在回放会话期间，客户端设备或播放器将周期性地向流传输应用报告其缓存/缓冲的媒体数据大小和“实时回放”持续时间，即在缓冲器中剩余的播放时间量。根据所使用的RTP/RTCP(实时控制协议)计算，每隔2至5秒发送一次更新。服务器或流传输应用可以记录此信息供以后使用。4c.如果通过指数加速机制在网络路径中检测到连续的网络拥塞，则流传输服务器将在一段时间(例如，等于步骤4b中播放器报告的时间(实时回放)的1/3)内停止向TCP层发送数据。提供以下步骤以示出该机制与本申请的其他机制和数据流控制模式组合的工作。

4d.在步骤c的延迟时间到期之后，流传输应用或模块将尝试按照指数加速机制(上面的5.1.1)记录的最近推送速度来推送数据，以补偿早先在步骤4c中的延迟损失。

4e.如果步骤d由于网络吞吐量、拥塞而失败，或者如果播放器未在正常时间轴内接收到所有分组，则流传输应用将停止发送，并基于从播放器报告的新的“实时回放”重新编译新的计算。该过程将持续以产生或释放网络带宽，直到“实时回放”小于15秒(或定义的临界水平)或者如果网络条件变得正常，即在预测或预期时间内以及预期的QoS水平上没有拥塞并且传输发生。4f.如果由于我们的回退过程，在播放器中留下的高速缓存数据小于15秒(临界水平)，则可以应用5.1.4中阐述的“动态多链路”机制，从而以快速有效的方式来补偿早期的延迟/丢失。4g.如果网络恢复到正常条件，则可以退出指数回退模式，并且可以恢复指数加速模式5.1.1。

5.1.3线性涓流模式

当播放器侧或客户端终端上的高速缓存缓冲器处于安全水平(缓冲器的80％或更多)时，触发或应用根据第一实施例的数据流控制方法的线性或流畅涓流模式。服务器节点处的IPTV流传输模块或应用将在安全水平进入线性涓流模式。在该机制中，流传输应用将以1x rt_bitrate的速度发送媒体数据，该速度等于当使用来自缓冲器的数据时播放器侧的高速缓存缓冲器的消耗速度。这确保缓冲器可以保持在安全水平(即80％)以确保流畅的视频数据回放。

图5中示出了描绘线性涓流模式的流程图。在该图中，数据流最初被示为处于5a的指数加速模式。在步骤5b，确定数据高速缓存水平是否大于95％，如是，则在步骤5c中发起指数回退模式(参见5.1.2)。如果在步骤5d确定高速缓存水平为80％，则在5f发起线性涓流模式。步骤5d的该确定也可以在步骤5e的检查网络条件之后进行，如图5所示。

5.1.4动态多链路机制

传统和现有的数据传输被建立为一个TCP链路上的位于一个客户端和一个服务器之间的单播会话。当客户端和服务器之间的这条路径被阻塞或拥塞时，常规技术将开始缓冲数据或完全放弃。此外，即使经由多个TCP链路从多个源获取数据，也会遇到以下问题：

A.在一个数据无序到达并且必须被丢弃的情况下进行分组重新排序。此效果由于所使用的TCP链接的总数而成倍地增加，问题变得更糟。B.分组被延迟并且在多个源之间以错误的顺序排序

C.在播放器侧重装配之后，数据可能不连续。

D.防止数据传输的重复并重组经由多个源获取的分组。

在第一实施例的数据流控制方法中使用动态多链路(DML)作为连接管理机制用于基于网络条件和客户环境中的条件来建立和维护服务器侧系统与客户端播放器或系统之间的多个连接。DML机制动态地建立服务器和客户端之间的多个TCP连接，以实现更高的网络吞吐量。同时，该机制还利用这些多个网络路径来帮助缓解拥塞，并允许播放器在不中断的情况下持续保持视频会话。当迫切需要数据以防止IPTV的视频缓冲效果时，这是有用的。该DML机制基于客户端侧和服务器之间的信息交换和协作工作，使得当迫切需要数据时，模块(其可以是专用DML模块或与其他设备集成)能够计算所需的总连接，并请求服务器侧接受新的连接。服务器侧根据其他因素和网络条件确定其将使用多少连接。

在流传输会话期间，服务器中的流传输应用将尝试以平均方式(即均匀地)在所有可用TCP链路上发送数据。当一个数据段由于网络拥塞而不能在一个链路上发送时，服务器将尝试下一个可用链路。这种非选择性发送策略将增加服务器和客户端之间的整体吞吐量。当我们需要与其他交叉业务竞争带宽资源以保持流畅回放时，它也可以用作紧急缓冲救援武器。

这种动态发送策略将增加服务器和客户端之间的整体吞吐量。经由多个链路到达客户端侧的媒体分组通常被打乱并且无序地到达。因此，在客户端处需要进行重新排序，优选地，这可以基于位于RTP报头中的顺序号。优选地，客户端配备有模块或应用，该模块或应用用于对从不同链路无序到达的RTP分组进行重新排序并且给无序分组赋予优先级，以确保缓冲器被整齐地布置用于所接收的数据的连续回放。必须在IPTV服务提供商和监管部门的管理和支配下应用多个路径或链路的使用，使得其对于现今的网络而言是公平和友好的策略，尤其是在许多媒体服务提供商和其他类型的数据传输在相同的信道上竞争带宽的情况下。第一实施例的DML机制的公平使用可以产生许多益处，例如：

1.与客户端/接收机设备建立多个链路，以测量到流传输视频数据的单个服务器的可能备用网络路径。在正常条件下(即在正常业务条件的情况下)使用一个主TCP链路(即主链路)。如果网络吞吐量在流传输会话期间降低，则DML机制被配置为通过在会话开始时已建立的其他TCP链路(从链路)发送业务。因此，在基于网络和客户端条件进行数据传输之前，建立了多个链路，并且当业务沿着网络信道改变时，以动态方式使用这些链路。

2.如果在使用多个数据链路的情况下数据流条件继续恶化，这表示以下之一：A、网络拥塞由其他业务引起，或者B、网络拥塞由物理网络路径引起。播放器/客户端侧将无法确定原因是A还是B，并且即使确定了，也将无法对该情况做出反应。因此，通过使用DML机制，客户端可以与服务器协作以试图使用DML来实现更好的吞吐量。如果数据流条件没有表现出改善，则可以假定发生了条件B，并且数据流方法可以选择切换到用于处理异常条件的不同机制或模式。例如，流控制可以应用如第5.1.5项所述的自适应流传输策略。第一实施例的DML机制允许充分利用带宽资源，并且还公平地处理其他网络流量。

3.在预定条件下动态地调整DML机制的使用或不使用。例如，在上述条件“A”的情况下，本发明的数据流控制方法的可能反应是使用更多的链路，即，使用DML机制，以实现额外的TCP资源以快速填充IPTV播放器缓冲器并退出网络拥挤，因为通过不加入现有业务可以缓解拥塞。

这种机制基于客户端和服务器二者之间的协作。在优选模型中，基于网络和客户端条件，客户端负责建立新的链路，之后，服务器可以在一些或所有可用TCP链路上发送媒体数据。

以上讨论涉及一个服务器和一个客户端之间的链路。以下描述与能够流传输所需视频数据文件的一个以上服务器一起使用的动态多链路机制的另一方面。当一个或多个用户(向客户端播放器或设备，例如，连接到显示设备(即电视屏幕)的机顶盒)请求视频数据流时，这些请求被路由到最健康的流传输服务器，即最适合传输所请求的文件的多个服务器。基于诸如服务器负载和访问这些数据的便利性等条件来评估服务器健康。一旦视频从服务器的流传输应用开始流传输，DML机制就被用于建立客户端到特定数量的流传输服务器的所有可能的路由路径。当满足某些条件时，根据本发明的数据流控制方法基于上述DML机制来应用多个并发路由机制。这些条件的示例如下：

1.当即使已应用DML策略后播放器还遭受缓冲并且仍然不能获得更多数据时，预测该问题是路由拥塞问题，并且本发明的数据流控制方法将在改变流控制模式前检查可以更有效地向播放器发送的数据的其他源。a.播放器(客户端)将基于可使用的多个可用服务器的信息来建立到备选的建议流传输服务器的另一连接。该信息可以在索引文件或数据结构中可用，并且包括基于每个服务器的地理位置、可用性和可用容量的信息。b.如果播放器可以从这个备选服务器获得流畅回放，则不需要识别其他服务器。

c.否则，播放器将尝试识别另外的流传输服务器，并且将继续向保存相同数据的所有识别的流传输服务器请求并发数据传输。

d.播放器将继续监视来自所有活动源的数据有效性，并且如果一个特定源不按要求执行，则它将停止来自该服务器的连接，并请求其他并发流传输服务器改变数据流模式。

e.当到达播放器的所有路径上的网络都无效时，则在所有路由上使用动态链接机制以确保缓冲器达到适用于上面5.1.3中说明的流畅涓流模式的水平。

2.当数据达到40％缓冲水平并且具有高视频质量时，本发明的流控制方法可以应用混合型服务器到客户端和客户端到客户端数据传输方法。在涉及数据共享技术的第二实施例中对此进行更详细的说明。将选择具有更快响应时间和更好网络路径的数据提供者(服务器或其他客户端设备)作为数据分发的路由。

利用本发明的数据流控制机制的DML机制的多个并发路由机制为本发明的流控制方法提供了经由多个业务路由进行导航以及基于检测到的网络和客户端缓冲器条件来动态避免拥塞段的能力。

5.1.5自适应流传输

自适应比特率流传输是在计算机网络上流传输多媒体所使用的技术。它通过实时检测用户的带宽和CPU能力并相应地调整视频流的质量来工作。它需要使用能够以多个比特率对单个源视频进行编码的编码器。播放器客户端根据可用资源在流传输的不同编码之间切换。因此，可以为IPTV应用获得极少的缓冲、快速启动时间以及高端连接和低端连接二者的良好体验。自适应流传输如今用于HLS或DASH视频流传输服务。这些标准渐进式下载和切换流是基于网络流实时决定的。然而，现有的自适应流传输技术不考虑客户端播放器能力、缓冲器条件或在客户端处回放的视频质量。

本发明的数据流控制方法提出了一种自适应流传输机制，其基于网络条件同时还考虑最高视频传送来切换视频流。这通过服务器侧和客户端之间的协作以接收与客户端侧(播放器)条件相关的信息(例如缓冲水平、回放剩余时间和当前发送速度)来实现。这实现了更好的“流切换”决定。因此，通过考虑网络条件以及缓冲器条件，根据本发明的第一实施例的自适应流传输可以传送高视频质量输出。

5.2.第二实施例

根据本申请第二实施例的数据流控制方法涉及用于数据共享、本地数据高速缓存和重用该数据以减少网络开销的模式和机制。以下对其进行详细说明：

5.2.1数据再循环模式

用户有时向一个或多个服务器多次请求相同的媒体数据。例如，用户向流服务器请求他们喜欢的歌曲或他们经常观看很多次的喜欢的视频。这种行为导致不必要的带宽使用，并影响整个互联网生态系统。一些专家预测，这种不必要的重复消耗占每天消耗的带宽的30％。当一个家庭或全家购买新发行的电影但不能花时间一起观看时，也会出现同样的情况。这导致多个观看和流传输同一电影，并且消耗不必要的带宽和其他网络资源。

第二实施例中的本发明的数据流控制机制通过基于客户端设备中的预设存储空间在客户端/本地设备处自动缓存近期观看的热门内容来克服这一点。可以基于它们的热门分数来缓存或从存储设备中移除内容。通过这样做，热门观看内容驻留在设备上，并且即使设备未连接到互联网也可以重看。这防止不必要的重传以节省总能量。

第二实施例的流控制方法的数据再循环机制可用于视频点播(VOD)或电视重放。为了实现这种模式，例如，在RAM缓冲器大小为20Megs且本地存储预留为2GB(HDD)的客户端处实现数据缓存策略模块。数据再循环机制包括规则和策略，以指定传送到客户端设备的数据将被编写索引、组织和记录以供将来使用。

图6示出了描绘具有数据再循环使得在从服务器拉取数据之前查阅本地高速缓存的数据流控制机制的流程图。在开始回放会话之前，本发明的数据流控制方法首先检查本地RAM和HDD存储器处的内容。如果本地有副本，则立即播放。在一些实例中，可能仅在本地缓存了部分热门内容。在这种情况下，数据再循环机制还被配置为在回放时请求流传输服务器开始流传输视频文件的任何缺失部分。将以相同的比特率水平请求数据的接续部分，并且在最前面的几个画面组GOP之后，针对会话的其余部分恢复流传输。该方法允许仅在必要时有效地利用带宽，并且可以实现即时回放，这也提高了用户体验。

5.2.2混合型P2P流传输

服务器或客户端设备之间的点对点通信(通常称为P2P)并非一个新概念，并且已经在互联网上的许多应用中广泛使用。然而，P2P策略不适用于IPTV应用的高质量视频流传输。本发明的数据流控制方法提出了一种“混合型P2P”流传输机制，其作为客户端到服务器以及客户端到客户端P2P的组合基础来工作。在不影响流畅视频回放的情况下，当网络与其他对等端安全地共享数据时，确定使用这些P2P方法中的一种。

第二实施例的混合型P2P机制首先包括正常地向流传输服务器请求数据。一旦播放器缓冲器处于安全水平，混合型P2P机制就考虑从最近的相邻客户端设备(对等端)获取数据，而不是向服务器请求数据。为了与自适应流传输策略共存并提供最佳质量(见5.1.5)，在P2P系统中交换高视频比特率。当缓冲器健康时，通常触发这种混合型P2P流传输模式，并且当缓冲器小于15％时，数据流控制方法退出混合型P2P模式。

就视频质量而言，如今的IPTV用户所期待的要远高于标准清晰度(SD)(480个像素)。如今制作的大多数内容是高清晰度(HD)(720、1080个像素)质量，并且需要一批新的流传输要求。这些要求包括更高的服务器规格、多个处理内核、更大的带宽骨干和网络设备的广泛I/O性能。还要求使用SD和其他ISP的现有服务提供商更多地投资于网络升级。服务器主机运营和传送成本也随着高质量视频对更多数据使用的需求而增加。本发明的数据流控制方法的混合型P2P机制处理这些问题。

数据流控制的混合型P2P机制是一种数据共享概念，其涉及向服务器向客户端发送数据、客户端向其他客户端共享数据以及客户端向许多客户端共享数据的组合。这可以被视为层次树结构，其中服务器A是数据的原始源，其将数据提供给客户端A，然后客户端A将该数据提供给客户端节点B、C、D等。因此，叶节点X的源可以是流传输服务器或者具有相同数据并且能够将该数据提供给叶节点X的另一个叶节点。

在正常网络条件下利用混合型P2P将最终以最高视频比特率达到峰值流传输。当网络资源和速度良好并且在预定义时间时且如果条件保持良好，第二实施例的数据流控制机制将播放器切换到混合型P2P。参与P2P的客户端设备将需要被配置为使得它们可以充当“数据提供者”或“数据消费者”或两者，并且该信息可以存储在后台系统中，当另一个客户端请求数据提供者的设备中同样可用的数据文件时被访问。当客户端设备最初将电影流传输到设备时，电影信息和数据块被记录到中央数据库中，用于未来分发引导。如果另一客户端参与混合型P2P模式并请求特定内容，则数据库中的信息将该客户端引导到具有该内容且被许可为“数据提供者”的那些对等端。如果发现新客户端的请求不匹配，则播放器将自动退出混合型P2P，并基于本发明的上述实施例中所述的本发明的其他数据共享模式来恢复数据流。

在混合型P2P网络机制中，一个客户端设备可以与网络内的一个或多个客户端共享缓存的数据，反之亦然。通过使用混合型P2P，服务器端可以节省高达90％的带宽和I/O资源。在P2P网络中，被注册为数据提供者的客户端设备越多，服务器侧所需的负载越小。这允许IPTV服务运营商显著降低服务器主机运营成本。

5.3第三实施例

本发明的数据流控制方法的第三实施例包括用于视频质量控制的模式和机制，以确保向IPTV终端用户提供最高质量的视频数据。这些机制说明如下：

5.3.1高质量视频的自适应比特率流传输

这是从与第一实施例相关的第5.1.5项所述的自适应比特率流传输导出的。第三实施例中的自适应流传输基于视频质量贪婪策略。自适应流传输是一种在计算机网络上流传输多媒体的技术，通过实时检测用户的带宽和CPU能力并相应地调整视频流的质量来工作。这种机制需要使用能够以多个比特率对单个源视频进行编码的编码器。播放器客户端能够根据可用资源在流传输不同编码之间切换。这导致极少的缓冲、快速启动时间和高端和低端连接二者的良好体验。图7中示出了用于实现高质量视频数据的自适应数据流传输的优选机制，下文对其进行说明：以下常数值基于可用视频流的数量来定义。假设我们有streamNr视频流，提供以下控制参数：

QualityGreedyThreshSec 12 streamNr*2

QualityGreedyDurSec streamNr*2.5

NoLimitUpThreshSec 12 streamNr*8

NoLimitUpThreshSec表示服务器可以在没有任何限制的情况下切换到较高的比特率水平质量。

QualityGreedyDurSec表示保持质量贪婪切换策略的时长。此策略将保持或切换到较高的比特率水平质量。

QualityGreedyThreshSec定义何时开始质量贪婪切换策略。

利用这些定义，以下结合图7来描述自适应切换处理：

7a.在回放期间，如果播放器侧的缓存时间小于12秒，那么服务器将切换到最低比特率。

7b.否则，如果缓存时间小于QualityGreedyThreshSec，那么我们需要检查附加条件。如果当前发送操作由于网络问题而被阻止，并且如果服务器发送速度大于1.6x rt_bitrate，则服务器将保持其当前比特率水平，并且令

5.1.1中的“指数加速模式”来控制速度调节。但是如果服务器发送速度不超过1.6x rt_bitrate，则服务器将切换到较低的比特率水平质量。

7c.当缓存时间小于QualityGreedyThreshSec且发送操作未被阻止时，如果服务器发送速度大于1.0x rt_bitrate，服务器将切换到较高的比特率质量水平。如果服务器发送速度不大于1.0x rt_bitrate，则保持当前视频质量。

7d.如果当缓存时间大于QualityGreedyThreshSec并小于NoLimitUpThreshSec时，服务器发送操作由于网络问题而被阻止，则自适应流传输机制保持当前视频质量。如果发送操作未被阻止，则将其切换到较高的比特率水平质量。

7e.当缓存时间大于NoLimitUpThreshSec时，服务器将切换到较高的比特率水平质量，直到最高水平为止。

7f.每当未达到最高比特率质量水平时，将最大发送速度设置为1.6x rt_bitrate。当网络未来再次变好/正常时，这将限制低质量视频的时隙。

5.3.2高质量视频数据的起始比特率选择

提出起始比特率选择机制，作为本发明的数据流控制机制的一部分。在回放之前，检查本地存储器或缓存。如果本地有副本，则不请求流传输服务器，替代地，播放器立即播放本地数据(类似于5.2.1的数据再循环)。当所有本地数据都已被消耗时，根据本发明第三实施例的比特率选择机制提出了以与本地文件相同的比特率进行流传输的方法。播放器侧向服务器请求适当的文件并开始播放。初始比特率不必是最低视频比特率。存在确定应以什么比特率播放的许多因素。在该实施例中，其取决于回放设备屏幕的分辨率。理想情况下，如果是一个大屏幕电视，则最低视频比特率不合适，并且可能具有非常差的视频质量。因此，在本发明的数据流控制方法的比特率选择机制中，存在要在快速启动和视频质量之间做出的平衡。

图8中可以看出根据第三实施例的用于实现起始比特率选择机制的优选方法。现在，存在许多不同类型的设备和能够显示流传输视频的屏幕尺寸。每个设备唯一地支持不同的视频分辨率，并且发送不正确的分辨率大小可能导致不可观看的视频或相关联硬件的崩溃。因此，在向服务器请求视频之前需要识别分辨率。在本发明中，这可以通过在播放器软件中实现播放器类型ID来实现。当播放器请求视频文件时，数据流控制方法被配置为检查设备类型ID并确定要发送哪个视频文件，而不是始终以最低视频比特率开始发送。起始比特率选择机制可以提供显著的结果。例如，当在大屏幕电视上播放电影时，较低的视频比特率通常会表现出许多瑕疵。因此，当播放器类型被识别为电视时，数据流控制装置一开始就可以以第二高或第三高水平的比特率而不是最低比特率来开始发送。

5.3.3选择性帧丢弃模式

在直播IPTV流传输会话期间，互联网连接有时可能下降到最低视频比特率以下，并且所应用的所有视频流传输机制和模式可能无法处理拥塞。这种情况很少见，但可能导致缓冲器被清空，并且视频回放可能中断。有时，几kbps的数据造成了流畅回放和视频缓冲之间的区别。当这种情况发生时，数据流控制装置要从接受视频缓冲效果或提供其他选项以保持流畅回放中做出选择。

图9中示出了本发明的选择性帧丢弃模式。该机制是一个“不”流传输视频GOP内的非I帧(也称为B/P帧)的动态过程。这将产生视频跳跃效果，但其同时允许在所需带宽的仅20％可用时持续地进行流传输。这可能是带宽不足期间的一种可接受的效果形式。音频不变差或中断，这在大多数情况下对于用户是可以接受的。例如，可以通过设置两个丢弃水平来确保流畅回放：A.丢弃一个GOP(画面组)中的50％的B/P帧，B.丢弃一个GOP(画面组)中的100％的B/P帧。这将暂时减少30％-80％的所需带宽，并且节省下的带宽用于将剩余的视频帧和音频发送到播放器。在该时间窗期间，视频可能呈现出一定的跳跃效果，并且可能保持这种方式直到网络可以从严重的暂时拥塞恢复为止。如果上述任何模式都失败了，则将该帧丢弃方法用作最终尝试，并且可以确保连续流传输不被中断。这确保流控制机制仍然可以提供质量连续的视频数据，并且可以短时间在100kbps的互联网管道上流传输200kbps的视频文件以保持流畅回放。图10a是当应用选择性帧丢弃机制时IPTV终端用户观看体验的指示，图10b是在没有这种机制的情况下的观看体验的指示。如图所示，图10b中的缓冲效果不可避免。

5.3.4高动态画面优先策略

视频编码可以具有用于增强视频质量的不同模式和滤波器。根据本发明的数据流控制方法提供了用于处理高动态图像帧以增强观看体验、提供最高观看质量和有效管理网络资源的机制或策略。在H.264编解码器中，VBR(可变比特率)编码是可以产生良好的视频质量输出的模式。该编码对那些快速动态移动场景生成较大的GOP并对较少动态的场景生成较小的GOP，并且生成大的GOP(画面组)，反之亦然。每当流控制方法处理大GOP时，其消耗更多的网络资源，这将产生网络尖峰或抖动。如果不考虑这一因素，则“快速动态画面”场景可能欺骗数据流协议，其被用于错误地从当前视频质量切换到下一个较低的质量水平。这是因为大GOP可能错误地警告数据流控制的自适应流传输机制(在5.3.1中列出)以切换到较低的比特率。这种错误触发显著地影响了观看体验。为了避免这种错误警报，本发明在第三实施例中提出了一种数据流控制机制，其实现下面描述的、被称为“高动态画面优先”或高动态画面优选考虑策略的策略，以在有限的网络条件下获得更好的观看体验。

图11中示出了高动态画面优先机制。在视频会话开始时，数据流控制方法利用大约第一分钟来测量和检测网络带宽。如果确定带宽足以维持最高视频比特率，则停止递增式比特率切换，并且流控制直接跳转到最高级。选择性GOP也是增强本发明的数据流控制机制的视频观看体验的重要因素。检查每个GOP并考虑它们的大小。如果GOP大小远大于视频比特率，则这转换为高动态事件。低网络环境下的这些大GOP可能导致缓冲，并且低编码比特率暴露实体动画(pixilation)下的大GOP也导致差的视频质量。

在发送一个GOP中的运动画面的第一分组之前，通过数据流控制机制来计算GOP大小。如果该GOP中的平均比特率比当前影片剪辑的平均比特率小30％，则该GOP被标记为“低动态画面GOP”。如果一个GOP中的平均比特率比当前影片剪辑的平均比特率大30％，则该GOP被标记为“快速动态画面GOP”。

数据流控制机制通过检查是否正在流传输最高视频比特率来继续监视网络吞吐量。如果流传输的阶段不处于最高比特率，则认为网络条件较差，并且数据流控制方法将不能始终使用较高比特率来发送数据。这种状况会显著影响回放视频质量，因为带宽的轻微变化会错误地告诉播放器去请求较低的比特率。为了克服这个问题，识别本地缓冲器的条件以及正在发送的GOP的类型。如果缓冲器处于安全阈值，并且如果发送GOP被标记为“低动态画面GOP”，则数据流控制方法切换到较低的比特率，以产生用于“快速动态画面GOP”的附加带宽。因此，数据流控制机制针对那些静态或低动态画面GOP时钟控制下降(clock down)到较低的比特率，以预留在较高比特率用于较高GOP的带宽。由此，保持了恒定的视频质量以及流畅的流传输效果。

高动态画面优先策略允许数据流控制方法在拥塞时间窗期间继续发送较高比特率，以始终为那些高动态画面GOP分配更多带宽。

5.3.5缓冲器增强和修复

动态自适应流传输(5.3.1中)和选择帧丢弃(5.3.1)用于保持流畅的流传输，以对抗互联网带宽波动和不稳定性。然而，这些机制有时可能导致负面影响，例如，随着网络条件产生的可见视频变差或实时帧跳变。这些负面影响被认为是不可避免的，目前的技术不能解决它们。本发明的数据流方法提出了一种缓冲器修复或增强机制，用于监视网络条件和缓冲器填充率，然后预测有多少时间和速度可用于允许流控制方法用高质量GOP替换缓冲器中的较低质量GOP。

这种缓冲器修复机制提高了视频回放质量。随着流传输的进行，网络波动并且及视频质量也波动。在自适应比特率流传输中，缓冲器被分段成多个段，所述多个段由形成连续回放时间轴的各个视频比特率组成。一些视频段具有低比特率，这对观看体验具有负面影响。为了解决这个问题，当缓冲器达到安全水平，即80％满载时，应用数据流控制的缓冲器修复机制。在该模式期间，流控制方法被配置为检查缓冲器中具有低视频比特率且仍然排队等待播放的先前流传输的段。然后，缓冲器修复机制被配置为在转到回放前请求用较高视频比特率替换这些段。这确保缓冲器的第一部分始终具有最高视频比特率并以最高视频质量进行回放。

图12中示出了缓冲器修复或增强机制，并且详细说明如下：

12a.在回放会话期间，流控制机制确保播放器保持一个GOP队列，所述GOP队列存储将被发送到视频解码器的所有GOP数据。

12b.播放器周期性地监视GOP队列。如果该队列的时间跨度小于10秒，则不采取任何操作。否则，播放器将检查队列中是否存在仅有一部分B/P帧的任何GOP(部分GOP)。如果没有要在10秒内发送到解码器的部分GOP，则该机制被配置为检查当前服务器发送速度。如果服务器发送速度小于或等于1.0x rt_bitrate，则不采取任何操作。否则，如果发送速度大于1.0x re_bitrate，则流控制机制请求服务器以相同质量重新发送具有所有帧的该GOP。12c.在接收到由服务器重新发送的具有所有帧的GOP之后，播放器然后将使用该GOP来替换GOP队列中的部分GOP。12d.如果队列中没有部分GOP，并且如果队列时间跨度小于15秒，则不采取任何动作。

12e.否则，在该队列中识别最低质量GOP，并将其与当前接收GOP质量进行比较。如果最低质量GOP高于当前数据，则不采取动作。否则，如果服务器当前发送速度大于1.0x rt_bitrate，则播放器将请求服务器以高一级的质量重新发送该GOP。

12f.在接收到由服务器重新发送的高一级的质量的该GOP之后，数据流机制使用该GOP来替换GOP队列中的旧GOP。

5.4第四实施例

以下机制提供了可应用于现有TCP数据传输以提供根据本发明第四实施例的增强型数据流控制方法的流控制技术。

5.4.1动态Nagle算法

在背景技术部分2中解释的Nagle算法对IPTV服务具有默认(200+ms时间延迟)的负面影响，尤其是当用户发起例如频道改变、内容查询、计费等交互式服务时。因此，本发明提出了一种基于动作和请求的类型来动态地启用/禁用Nagle算法以确保可以实现最佳效果的方法。理想情况下，当检测到用户设备和服务器之间的命令交换时，第四实施例的流控制方法禁用Nagle算法。这消除了TCP传输层上至少200ms的延迟。这样做可以减少将被注入到网络中的分组的数目，并且还可以改善用户交互体验。

图13中示出了用于应用如上所述的动态Nagle算法应用的优选过程。图14a中示出了当Nagle算法处于启用、禁用和自适应状态时所进行的测试的细节，图14b中示出了每个上述状态的不同的分组发送速率。在LAN环境中进行这些测试。

5.4.2修改的Linux控制

以下Linux控制可以应用于现有的TCP以提供根据本发明的增强型数据流控制。

A.net.ipv4.tcp_window_scaling＝1

此参数允许TCP在接收机和发送机上使用大的窗口尺寸。这将提高总吞吐量。

B.net.ipv4.tcp_timestamps＝1

此参数允许TCP在其报头中使用时间戳选项。这将有助于TCP估计RTT值(往返时间)

C.net.ipv4.tcp_sack＝1

此参数允许TCP接收机发送选择性确认以报告多个分组丢失，而不是针对每个确认仅报告一个分组。这将有助于发送机更快地重传丢失的分组。

D.net.ipv4.tcp_congestion_control＝cubic

此参数仅对内核2.6.13或以后的版本有效。它允许用户改变拥塞控制算法以获得特殊应用的更好性能。

E.net.core.rmem_max/net.core.wmem_max

这些参数控制发送机和接收机通告的窗口大小。它们将通过限制网络中的实时数据来影响TCP吞吐量。可以根据提供的不同网络环境来放大该窗口大小。

F.新内核

从Linux 2.6.17版本起，cwnd可以高达4MB。这将提高高速网络上的TCP吞吐量。

5.5本发明的数据流控制技术的交互

图13中示出了构成所提出的本发明的第一、第二和第三实施例的数据流控制协议或方法的上述模式、策略、方法和机制的交互。

尽管描述了一些实施例，但是这些实施例仅以示例方式提出，而不是为了限制本发明的范围。事实上，本文中描述的新设备、方法和产品可以以各种形式来体现；此外，可以在不脱离本发明的精神和范围的情况下，对本文描述的方法和系统的形式进行各种省略、替换和改变。所附权利要求及其等同物旨在涵盖落入实施例的范围内的这些形式或修改。