CN106464601A - 信道捆绑 - Google Patents

Abstract

公开了一种用于信道捆绑的系统和方法。该系统和方法使得能够使用多个网络接口跨多个连接传输数据。此外，该系统和方法被配置为处理缓慢或有问题的连接，并且被配置为动态地修改一个或多个媒体数据流的比特率。

Description

信道捆绑

相关申请的交叉引用

本申请要求第61/972,130号美国临时申请的权益，该申请通过参考全文并入本文中。

技术领域

本说明书涉及牵涉到客户端与服务器之间的通信的应用，由此客户端具有多个网络接口，并且可以使用这些接口的任意组合来与服务器通信。此外，本说明书涉及牵涉到可变比特率流媒体的广播应用。

背景技术

信道捆绑是一种计算机联网布置，其中客户端计算机上的两个或更多个网络接口被组合起来，以便增加吞吐量和/或冗余度。例如，信道捆绑可以用于使用802.11网络接口或以太网网络接口二者来传送数据，这样会比单独地使用802.11网络接口或单独地使用以太网网络接口传送数据时更快。

发明内容

公开了用于信道捆绑的方法和系统。

在一个方面，公开了一种被配置成经由多个网络接口进行通信的设备。该设备包括：多个网络接口；存储器，被配置成存储一个或多个数据流的至少一部分；以及与多个网络接口和存储器通信的至少一个处理器。该处理器被配置成：对于多个网络接口中的每一个，建立与远程装置的相应网络连接；将一个或多个数据流分包为多个包；使用多个网络连接将多个包发送到远程装置；和评估一个网络连接在发送包时相对于剩余的网络连接中的一个或多个连接的性能。可以使用多种准则来评估网络连接。准则的示例包括但不限于：本文进一步讨论的ACK检查和RTT检查。在这点上，当评估一个网络连接相对于另一个网络连接的性能时，可以针对不同连接使用相同准则。或者，当评估一个网络连接相对于另一网络连接的性能时，可以针对不同连接使用不同准则(例如，一个连接的RTT可以用于评估另一连接的ACK检查)。

在另一方面，公开了一种用于经由多个网络接口进行通信的方法。该方法包括：为多个网络接口中的每一个建立与远程装置的相应网络连接；将一个或多个数据流分包为多个包；使用多个网络连接将多个包发送到远程装置；以及评估一个网络连接在发送包时相对于剩余的网络连接中的一个或多个连接的性能。

在又一方面中，公开了一种被配置成经由多个网络接口进行通信的设备。该设备包括：多个网络接口；存储器，被配置成存储一个或多个数据流的至少一部分；以及与多个网络接口和存储器通信的至少一个处理器。该处理器被配置成：对于多个网络接口中的每一个，建立与远程装置的相应网络连接；将一个或多个数据流分包为多个包；使用多个网络连接将多个包发送到远程装置；评估一个网络连接在发送包时的性能；以及响应于评估一个网络连接的性能，以测试模式操作该一个网络连接。

在另一方面，公开了一种经由多个网络接口进行通信的方法。该方法包括：为多个网络接口中的每一个建立与远程装置的相应网络连接；将一个或多个数据流分包为多个包；使用多个网络连接将多个包发送到远程装置；评估一个网络连接在发送包时的性能；以及响应于评估一个网络连接的性能，以测试模式操作该一个网络连接。

在另一方面，公开了一种被配置成经由多个网络接口进行通信的设备。该设备包括：多个网络接口；存储器，被配置成存储一个或多个数据流的至少一部分；以及与多个网络接口和存储器通信的至少一个处理器。该处理器被配置成：接收将一个或多个数据流发送到远程装置的指示；响应于接收到发送一个或多个数据流的指示：为多个网络接口中的每一个建立与远程装置的相应网络连接；将一个或多个数据流分包为多个包；以及使用多个网络连接将多个包发送到远程装置，由此，包被分配给一个网络连接所使用的速率由所述一个网络连接先前发送的包被确认为已经被接收时所使用的速率来确定。

在另一方面，公开了一种用于经由多个网络接口进行通信的方法。该方法包括：接收向远程装置发送一个或多个数据流的指示；响应于接收到发送一个或多个数据流的指示：为多个网络接口中的每一个建立与远程装置的相应网络连接；将一个或多个数据流分包为多个包；以及使用多个网络连接将多个包发送到远程装置，由此，包被分配给一个网络连接所使用的速率由所述一个网络连接先前发送的包被确认为已经被接收所采用的速率来确定。

在另一方面，公开了一种被配置成确定是否指示比特率改变的设备。该设备包括：网络接口，被配置成从远程装置接收一个或多个包的流；缓冲器，被配置成存储从所述一个或多个包的流导出的视频帧；和与网络接口和缓冲器通信的至少一个处理器。该处理器被配置成：基于一个或多个包的流，导出视频帧；将视频帧存储在缓冲器中；分析该缓冲器的充满度；响应于该分析，确定是否指示比特率改变；以及响应于确定指示所述比特率改变，向远程装置发送对比特率改变的指示。

在另一方面，公开了一种用于确定是否指示比特率改变的方法。该方法包括：基于一个或多个包的流，导出视频帧；将视频帧存储在缓冲器中；分析该缓冲器的充满度；响应于该分析，确定是否指示比特率改变；以及响应于确定指示所述比特率改变，向远程装置发送对比特率改变的指示。

在研究了以下附图和详细描述之后，其他系统、方法和特征对于本领域技术人员将是或将变得显而易见。所有这样的附加系统、方法和特征都旨在包括在本说明书内、在本公开的范围内，并且由所附权利要求保护。

附图说明

参考以下附图和描述可以更好地理解本技术。参考以下附图做出了非限制性和非穷举性的描述。附图中的部件不一定按比例绘制，而是着重于说明原理。在附图中，除非另有说明，否则相同的附图标记可以在不同的附图中指代相似的部件。

图1提供了信道捆绑系统的总体软件架构的框图。

图2示出了重点集中在可以在客户端装置中使用的各种不同类型的网络接口的框图。

图3示出了信道捆绑系统的架构的更高级别的视图。

图4示出了图3的架构的框图，其中客户端装置使用信道捆绑向服务器发送包。

图5示出了图3的架构的框图，其中服务器使用信道捆绑向客户端装置发送包。

图6示出了图3的架构的框图，其中客户端装置和服务器均使用信道捆绑来彼此发送和接收包。

图7示出了如先前在图4-6中所说明的用于数据传输的连接线程所用的一些高级设施的框图。

图8示出了如先前在图4-6中所说明的连接管理部件(CMC)的一些设施的框图。

图9示出了当在传递会话期间传递数据时由连接线程执行的确认检查的流程图。

图10示出了当在传递会话期间传递数据时由连接线程执行的往返时间(RTT)检查的流程图。

图11示出了用于分析连接线程在测试模式下的性能的流程图。

图12示出了用于通过分析跨多个连接提供的时间数据来确定客户端装置与服务器之间的时钟偏差的流程图。

图13示出了用于网络接口优先级排序的一些标准和技术的框图。

图14示出了客户端装置的框图，该客户端装置执行媒体的编码和/或解码，并利用多个网络接口来传输经编码的媒体。

图15示出了广播消费者的流程图。广播消费者可以分析传送会话和/或其自己的内部数据的多个方面，以确定是否调整编码媒体的比特率。

图16示出了广播消费者分析其视频缓冲器的健康状况以便确定是否调整比特率的流程图的一个示例。

图17示出了生产者基于来自CMC的关于网络连接状态的通知潜在地做出带外比特率递减的流程图。

图18示出了用于处理不健康的媒体缓冲器以便使媒体缓冲器回到健康状态的一些技术的框图。

图19示出了用于同步音频和视频回放以及用于视频回放的并发的两个流程图。

图20示出了客户端装置或服务器中的一个或两个的通用框图。

具体实施方式

本文所描述的原理可以以许多不同的形式体现。然而，可能不需要所有描绘的部件，并且一些实施方式可以包括额外的、不同的或更少的部件。在不脱离本文提出的权利要求的精神或范围的情况下，可以改变部件的布置和类型。另外，可以提供不同的或更少的部件。

存在第一装置试图将大量数据快速传递到第二装置的实例。在大多数情况下，第一装置仅使用单个网络连接来将数据传递到第二装置。该单个网络连接可以代表对于联网(networking)应用而言是足够的大型网络管道，但事实并不一定是这样的。例如，取决于联网应用的要求，单个移动宽带网络连接可能不够用。为了支持联网应用的多种需求，可以使用信道捆绑以便增加网络管道的大小。

在一个实施例中，描述了提供线程安全框架的架构，该线程安全框架可以用于同时利用客户端装置上的多个网络接口来可靠地向和/或从运行相同框架的服务器传递数据以处理数据。就这一点而言，客户端装置上的多个网络接口使得能够更快地并以更可靠的方式在任一方向(或两个方向)上传递数据。与仅使用单个网络装置相比，使用多个网络装置还可以实现在接收端上对数据的近实时处理。

该架构包括客户端/服务器模型，并且客户端装置可以包括多个网络接口。在一个实施例中，该多个网络接口可以全部是相同类型的(例如，移动宽带、Wi-Fi、以太网、卫星等中的一种)，或者可以包括网络接口类型的任何组合(例如，移动宽带、Wi-Fi、以太网、卫星等的任何组合)。在该多个网络接口中可以存在每种网络接口类型的多个实例。在更具体的实施例中，这多个网络接口可以包括总共五个移动宽带装置，并且因此所有网络接口是相同类型的。在另一个具体实施例中，该多个网络接口可以包括一个以太网装置、一个Wi-Fi装置、一个卫星装置和七个移动宽带装置。此外，在适当的情况下，网络接口不限于特定的网络提供商。在更具体的实施例中，该多个网络接口可以包括四个移动宽带装置，其中第一和第二装置与运营商#1相关联，第三装置与运营商#2相关联，第四装置与运营商#3相关联。

客户端系统通过为每个网络接口建立与服务器的单个网络连接来利用多个网络接口。每个网络连接可以被认为是一个信道，数据可以通过该信道在任一方向上流动，并且这些信道被组合的方式被称为信道捆绑。

服务器可以包括单个服务器系统或被配置为联合工作(诸如基于云的服务器布置)的多个服务器系统。在一个实施例中，服务器可以包括单个网络接口(例如被配置为经由因特网进行通信的网络接口)。在替代实施例中，服务器可以包括多个网络接口(诸如被配置为经由因特网进行通信的一个网络接口和被配置为经由除了因特网之外的网络进行通信的第二网络接口)。

在一个方面，捆绑用于使用至少一个信道来发送一个或多个数据流。流可以在任一方向上发送，并且可以同时发送多个流。与使用聚合网络连接的各种其它联网技术完全不同，在一个实施例中，捆绑为每个连接设置信道捆绑以发送数据流的不同部分，从而使吞吐量最大化。在这点上，接收设备被配置为按最初排列顺序重建特定流。如下面更详细讨论的，使用软件技术来实现信道捆绑，包括以下操作中的任何一个、任何组合或全部：在网络连接之间平衡数据递送；动态地分析连接(例如，动态地分析经由连接的传输的至少一个方面，以便处理缓慢和/或不可靠的连接)；和最终确保完整的流递送。由于网络接口通过被添加到系统和/或通过建立到网络(例如，因特网)的连接而动态地变得对客户端装置可用，在一个实施例中，可以为每个网络接口建立网络连接，其中每个网络连接被添加到可以几乎立即被用于传送数据流的网络连接的池中。另外，当网络接口变得不可用时，例如因为网络接口不再能够访问因特网或被认为太慢或不可靠，在一个实施例中，假设在池中存在至少一个网络连接，则相关联的网络连接可以被从网络连接的池中动态地移除，而不会中断数据流。在替代实施例中，被认为太慢或不可靠的网络接口可改为使其相关联的网络连接置于测试模式中，并且在处于测试模式中时对该网络接口进行评估之后，该网络接口可被重新引入到用于传送数据流的网络连接的池，如下文更详细地描述。

在替代实施例中，少于全部的可用网络连接可被放置到用于传送数据流的网络连接的池中。例如，基于各种标准(诸如成本、先前性能等)，某些网络连接(例如卫星网络连接)可能最初未被放置在可用于传送数据的网络连接的池中。稍后，基于可用于传送数据的网络连接的池中的其他网络连接的不佳性能，可以响应于某些条件将这些特定网络连接中的一个或多个放置到网络连接的池中。在另一个替换实施例中，最初在可用于传送数据的网络连接的池中的网络连接可以在传送会话期间从池中移除。例如，网络连接可以被置于针对差的性能的测试模式，并且可以基于测试模式中的网络连接的性能而被重新引入到池中，如下所述。作为另一示例，最初在可用于传送数据的网络连接的池中的网络连接(例如卫星连接)可以基于其他网络连接的性能而被从网络连接的池中移除(例如，在卫星网络连接的情况下，其他低成本网络连接可能足以完成工作(诸如具有足够的吞吐量)，因此允许去除更高成本的卫星网络连接)。因此，向池中添加可用网络连接和/或从池中移除可用网络连接可以基于其他网络连接和/或可以基于可用网络连接的性能。

捆绑可以与包括定制解决方案的一个或多个应用(被称为捆绑应用)结合起来使用。如下面更详细讨论的，捆绑应用的示例包括但不限于以下应用：广播(例如，电视广播或无线电广播)；视频会议；和文件传输。在一个实施例中，捆绑可以被配置为遵循特定API准则的库(library)。这样，捆绑应用就可以访问该库，从而从通过捆绑实现的带宽增加中受益。

如下面更详细讨论的，捆绑可以在生产者/消费者模型的背景下使用。生产者被提供以捆绑应用，并且提供要捆绑的一个或多个数据流，该捆绑负责将数据发送到接收侧。消费者也被提供以捆绑应用，并且为其自身的处理而操纵由捆绑重新组装过的流。在此背景下，生产者可以生成数据流(诸如构成文件、视频流或音频流等的数据流)。此外，消费者可以利用重新组装过的数据流(例如，将数据流写入文件、播放视频、播放音频等)。在生产者/消费者模型中，捆绑应用可以包括定制消费者和定制生产者，该定制消费者和定制生产者被放置在连接的适当侧以用于生成和操纵特定数据流。

图1提供了信道捆绑系统的总体软件架构的框图100。客户端装置102包括与捆绑相关联的软件，称为捆绑支持，其可以是库的形式。此外，客户端装置102可以包括一个或多个捆绑应用，其在被执行时各自可以利用生产者和/或消费者。在客户端装置上运行的捆绑支持首先为每个客户端网络接口与服务器(104)建立网络连接。然后，当在客户端上执行捆绑应用时，其可以将其生产者或其消费者或这两者与捆绑支持关联起来。在服务器上可以进行等效处理。也就是说，如果在客户端上运行的捆绑应用使得生产者与捆绑支持相关联，则在服务器上运行的捆绑应用使得相应的消费者与捆绑支持相关联。此外，如果在客户端上运行的捆绑应用使消费者与捆绑支持相关联，则在服务器上运行的捆绑应用使相应的生产者与捆绑支持相关联。对于在客户端和服务器二者上运行的相同捆绑应用，这两种情况可以同时发生。也就是说，捆绑应用可以在客户端上同时使用消费者和生产者两者，并且相同的捆绑应用可以在服务器上使用相应的生产者和相应的消费者。

无论是在客户端上还是在服务器上运行，生产者都向捆绑支持提供数据流。该数据流将根据捆绑应用而不相同-一些捆绑应用可以递送构成单个文件的一个数据流，而其他捆绑应用可以递送实时生成的多个编码音频和/或视频流。不管将被递送到捆绑支持的数据的类型如何，生产者都负责在将数据递送到捆绑支持之前将其分解成多个包，称为将数据分包。一旦数据被递送到捆绑支持，捆绑支持利用多个网络连接将这些包递送到接收侧。这些网络连接中的一些或全部可以被捆绑支持同时使用。生产者不需要一次性地将数据递送到捆绑支持。例如，在数据是实时生成的情况下，生产者在数据变得可用时对数据进行捆绑支持，此时，捆绑支持将数据分包，并使数据可用于网络连接以便通过捆绑发送到接收侧。

生产者以使得可以在接收侧重构原始序列的方式对数据进行分包。如前所述，可以使用多个网络连接来发送已分包的数据，并且因为包的发送被分摊在不同的网络连接上，所以各个包可以以与它们最初被生产者分包成的顺序相比被打乱的顺序到达。支持分包数据的正确重构的一种方式是在每个包中为索引留出一些空间，索引值最初从零开始并且对于每个后续包递增。另外，为了支持多个数据流，可以在每个包中为用于将一种类型的数据与另一种数据区分开的指示符留出空间。例如，针对广播捆绑应用，使用这样的指示符来将用于编码视频的包与用于编码音频的包区分开。在接收侧，包索引和数据类型指示符的组合提供的信息足以重构出与生产者生成的数据一样的原始分包数据。作为说明性示例，如果发送相同数据类型的两个包，一个包具有包索引#1以及一个包具有包索引#2，并且每个包在不同的网络连接上发送，则接收侧可能在接收到具有索引#1的包之前接收到具有索引#2的包。然而，由于每个包中存在索引，捆绑支持将以正确的顺序将包正确地递送给消费者。

在接收侧，无论在客户端还是服务器上，捆绑支持经由多个网络连接来接收分包数据。然后，由发送侧的生产者提供的分包数据必须被捆绑支持重新组装，并且当流的多个部分以分包形式可用时，消费者将这些部分解包。消费者然后为了自己的目的利用数据。例如，用于文件传送的消费者可以将流写入文件。在另一示例中，与广播相关联的消费者可以将被编码的媒体(例如，被编码的视频和/或音频)解码，然后将其播放。从捆绑支持的角度来看，数据的内容是不相干的–由消费者负责解释数据和使用数据。

值得注意的是，网络接口可以包括提供联网能力(例如，以太网、Wi-Fi、移动宽带、卫星等)的实际物理装置。在更一般的形式中，网络接口是实际物理设备的抽象概念，并且提供了可以从物理装置发送和接收数据的标准方式。省略了本领域技术人员已知的物理装置的内部工作。在这方面，例如，移动宽带网络接口仅仅是描述与物理移动宽带装置相关联的网络接口抽象概念的简短形式。

图2示出了重点集中在可以在客户端装置中使用的各种不同类型的网络接口的框图200。图2中描述的第一类型的网络接口是复合装置网络接口202。这种类型的网络接口通常可以与诸如智能电话这样的另一个完备的计算装置(复合设备242)一起使用。这样的设备可以在处理器206上执行操作系统并具有一个或多个其自己的网络接口。在图2中，与该网络接口相关联的复合设备被示为具有嵌入式移动宽带装置208，但这只是它可能具有的各种可能的网络接口之一。此外，为了在客户端装置上的复合装置网络接口与实际复合装置之间进行通信，还提供了通信接口204。这样的通信接口通常是USB、蓝牙或其他选项的形式。最后，嵌入式移动宽带装置与蜂窝网络216无线通信。虽然图2仅示出一个复合装置242，但是可以想到一个或多个复合装置，例如一个或多个智能电话。

图2还示出了移动宽带网络接口210，其可以经由通信接口212与物理移动宽带装置230通信，通信接口212通常可以采用USB、PCI等的形式。移动宽带装置通常具有其自己的处理器214，该处理器214通常用于运行一些固件。移动宽带装置与蜂窝网络216无线通信。

图2还示出了Wi-Fi网络接口218，其可以经由通信接口220与物理Wi-Fi装置246通信，通信接口220通常采取USB、PCI等的形式。Wi-Fi装置通常可以包括其自己的处理器222，处理器222通常用于运行一些固件。Wi-Fi装置与无线网络224无线通信。

图2还示出了卫星网络接口226，其可以经由通常采用USB、PCI等形式的通信接口228与物理卫星装置248通信。卫星装置通常可以具有其自己的处理器230，处理器230通常用于运行某个固件。卫星装置可以包括多个不同的硬件部件，例如卫星天线。卫星装置与一个或多个卫星232无线通信。

图2还示出了以太网网络接口234，其可以经由通信接口236与物理以太网装置250通信，通信接口236通常采用USB、PCI等的形式。以太网装置通常将具有其自己的处理器238，处理器238通常用于运行某个固件。以太网装置经由电缆与路由器240通信。

图3示出了信道捆绑系统的架构的更高级别的视图300。如先前在图1中所示，客户端装置102包括处理器304、存储器306和多个网络接口312。处理器304被配置为执行存储在存储器306中的软件。存储器306包括被配置为使用捆绑来发送和/或接收数据流的软件。尽管存储器306被示为单个存储器装置，但是一个或多个存储器装置可以用作存储器306。在一个实施例中，可以使用捆绑逻辑308和捆绑应用逻辑310来配置软件，捆绑逻辑308可以包括库。如上所述，捆绑应用可以访问捆绑库以便定制数据流的发送/接收。例如，捆绑应用逻辑310可以针对广播应用、文件传送应用、视频会议应用等。

客户端装置102还包括网络接口312。如图3所示，网络接口312被划分为不同类型的网络接口，包括移动宽带314、Wi-Fi 316、以太网318和卫星220。图3中所示的网络接口312的类型仅仅是为了说明的目的。除了图3中所示的网络接口类型以外或替代这些网络接口类型，可以使用其他网络接口类型。另外，可以存在零个或多个在特定客户端装置102中使用的特定类型的网络接口。例如，可以有一个以太网网络接口318、一个Wi-Fi网络接口316、七个移动宽带网络接口314和零个卫星网络接口320。

网络接口312可以经由诸如因特网的一个或多个网络322进行通信，如图3所示。捆绑逻辑308将为每个网络接口312建立与服务器330的网络连接。

与客户端装置102类似，如图1中先前所示，服务器104包括服务器处理器332、存储器334和服务器网络接口340。存储器334包括捆绑逻辑336和捆绑应用逻辑338。在一个实施例中，服务器的捆绑逻辑和捆绑应用逻辑可以与驻留在客户端上的捆绑逻辑和捆绑应用逻辑相同。在可替代实施例中，服务器的捆绑逻辑和捆绑应用程序逻辑可以不同于驻留在客户机上的捆绑逻辑和捆绑应用程序逻辑。特别是，虽然服务器的捆绑逻辑和捆绑应用逻辑组件可能与客户端装置的捆绑逻辑和捆绑应用逻辑组件很多共同之处，但是它们之间可能存在一些差异。通过使用客户端装置102上的捆绑逻辑308与服务器104上的捆绑逻辑336结合起来建立的网络连接，客户端的捆绑应用逻辑310或服务器的捆绑应用逻辑338或两者可以用于提供将经由该网络连接传递到接收侧的一个或多个数据流。

如上所述，在生产者/消费者模型的背景中，在客户端装置或服务器或两者上，捆绑应用可以提供生产者、消费者或生产者和消费者。在这点上，一个或多个数据流可以从客户端装置发送到服务器，从服务器发送到客户端装置，或者在客户端装置与服务器之间双向发送。图4-图6分别示出了从客户端装置到服务器、从服务器到客户端装置以及在客户端装置与服务器之间双向的包的不同流。

图4至图6进一步分析了捆绑逻辑和捆绑应用逻辑。图4示出了图3的架构的框图400，其中客户端装置使用信道捆绑向服务器发送包。图5示出了图3的架构的框图500，其中服务器使用信道捆绑向客户端装置发送包。最后，图6示出了图3的架构的框图600，其中客户端装置和服务器都使用信道捆绑来彼此发送和接收包。在这些图的每一个中，引入了连接管理器组件(CMC)412的形式的新概念。此组件是在图3中介绍的客户端装置的捆绑逻辑308的一部分，并且它负责为客户端装置的网络接口中的一个、一些或全部建立与服务器104的网络连接。这些网络接口在图4-图6中被标注为网络接口#1 426、网络接口#2 428和网络接口#N 440，意味着客户端装置可以具有1到N个网络接口。在为特定网络接口建立与服务器的网络连接之前，CMC可以检查以查看该网络接口是否存在任何网络连接，但是通常尝试经由网络接口连接到服务器就足够了。如果不存在网络连接，则连接到服务器的尝试将失败。

在一个实施例中，每个网络连接在逻辑上独立于由CMC建立的任何其他网络连接，并且为了管理特定的网络连接，CMC可以为其建立专用软件线程，称为连接线程。在图4-图6中，将客户端装置102上的每个网络接口的不同连接线程指定为连接线程#1 420、连接线程#2 422和连接线程#N424。另外，一旦服务器接收到来自特定客户端装置侧网络接口的连接时，服务器上的CMC 460也可以建立其自己的用于管理该特定连接的专用连接线程。在图4-图6中，服务器侧连接线程被标记为连接线程#1 454，连接线程#2 456和连接线程#N458。因此，可能存在客户端装置上的连接线程到服务器上的连接线程的一对一映射。

设置网络连接的一种方式是通过使用网络套接字。网络套接字是跨网络的进程间通信流的端点，并且在客户端装置和服务器的背景中，一个套接字将与客户端装置上的网络接口相关联，并且伴随的套接字将与服务器上的服务器网络接口340相关联。当最初形成连接时，可以创建套接字，同时使一个连接线程与所创建的套接字关联起来。例如，当客户端装置最初形成连接时，可以为客户端装置创建套接字以及相关联的连接线程。响应于新连接的到来，服务器可以在其一侧分配新套接字，并且还建立与其套接字相关联的连接线程。

可以经由若干协议中的一个来路由通信。例如，存在用于在因特网上传输数据的两个主要通信协议，传输控制协议(TCP)和用户数据报协议(UDP)。TCP是许多联网应用程序的一个选项，因为它提供了一些重要的特征，如连接、可靠性和错误检查。这些特征伴随着开销的发生，潜在地引起性能成本，然而，结果是，TCP可能不是对于实时或接近实时的联网应用(例如流媒体应用)的优选选项。相反，UDP是相当小的，并且通常是流媒体应用的优选选择。然而，UDP不保证数据递送。例如，如果客户端装置使用UDP向服务器发送包，则包可能被服务器接收也可能不被接收。此外，客户端装置没有办法确定服务器是否使用UDP接收到包。也就是说，UDP本身不提供用于确定这一点的手段。一些网络应用可以处理一定量的数据丢失，在捆绑应用的情况下，这取决于捆绑应用。然而，由于存在要求所有发送的数据都要被递送到接收侧的捆绑应用，如果使用UDP，则在UDP之上可能需要一定水平的可靠性以使捆绑正常工作。不是在UDP之上创建这样的层，而是使用UDT作为一个选择(基于UDP的数据传送协议)，其位于UDP之上。UDT在UDP之上添加了许多特征，例如可靠和有保证的数据递送，它还提供了一些附加特征，例如对活动网络连接的性能监视。

在这点上，每个连接可以与客户端装置上的网络接口相关联。此外，客户端装置上的多个连接可以与连接组相关联。连接组可以被认为是一个或多个网络连接的捆绑，其中该组中的每个网络连接用于在相同的目标上操作。这与独立的网络连接相反，独立的网络连接可以用于完全独立的目标。用于特定捆绑会话的连接组可以被通知给客户端装置和服务器，使得连接组可以作为一个整体使用，以便经由用于特定捆绑会话的不同连接来传送数据。例如，连接组可以包括第一连接(与客户端装置上的第一网络接口相关联)、第二连接(与客户端装置上的第二网络接口相关联)和第三连接(与客户端装置上的第三网络接口相关联)。在客户端装置侧，可以经由用于特定捆绑会话的连接组内的不同连接中的任意连接来发送数据。在服务器侧，服务器可以识别出数据是通过连接之一(无论是第一、第二或第三连接)发送的，确定该连接是特定捆绑会话的连接组的一部分，就此将经由该连接接收的数据与特定捆绑会话关联起来。

在建立连接组之后，可以发起经由该连接组的数据传送。在一个实施例中，建立连接组的装置与发起数据传送的装置可以是同一个装置。例如，客户端装置可以建立连接组，然后可以经由该连接组发起数据传送。在又一个实施例中，建立连接组的装置可以不同于发起数据传送的装置。

在一个实施例中，如果是单个方向，数据流的方向完全独立于数据传送被发起的方式。例如，对于仅将数据从客户端装置发送到服务器的广播捆绑应用，数据传送可以由客户端装置发起。但是，它可以改为由服务器发起。图4中示出了这种类型的数据传送流。作为另一示例，对于从服务器向客户端装置发送文件的文件传送捆绑应用，数据传送可以由服务器或客户端发起。这种数据传送流在图5中示出。作为另一示例，对于从客户端和服务器二者发送和接收媒体的视频会议应用，数据传送可以由客户端装置或服务器发起。这种数据传送流在图6中示出。

为了进一步详细说明数据传送的发起，例如，可以使用客户端装置上的用户界面来输入命令以发起数据传送。当捆绑应用准备好开始传送时，该传送可以由客户端装置的用户界面上的动作发起，捆绑应用可以描述要传送的数据类型，并且通过使用该描述，客户端装置上的CMC 412可以与服务器上的CMC 460交互，请求该数据类型的处理程序。更具体地，不同的数据类型可以包括广播数据类型、获取文件数据类型等。这些不同的数据类型具有相关联的处理程序，例如用于文件传送的处理程序，用于广播的处理程序等。

发起数据传送的捆绑应用的组件称为发起方，而处理发起请求的捆绑应用的组件称为接收方。在一个实施例(诸如其中所有发起请求由客户端装置处理的实施例)中，发起方总是在客户端装置上运行，并且接收方总是在服务器上运行。

如果存在合适的接收方，则进行进一步协商，以便基于捆绑应用的要求在连接的两端建立适当的生产者/消费者组合(或多个组合)。在这方面，如果对于特定捆绑应用数据仅在单个方向上流动，则在连接的一侧上具有单个消费者并且在连接的另一侧上具有单个生产者就足够了。或者，如果数据流是双向的，则两个生产者/消费者组合可能是足够的。例如，如图4和图5中所描述的，捆绑应用仅需要在一个方向上传送数据。在这种情况下，捆绑应用在发送侧提供生产者，并且捆绑应用还在接收侧提供消费者。图4和图5的主要区别在于，在图4中，发送侧是客户端装置，接收侧是服务器，而在图5中，发送侧是服务器，而接收侧是客户端。在另一个示例中，如图6所示，捆绑应用需要同时在两个方向上传送数据(例如，从时序的角度来看，在一个方向上传送的数据与在相反方向上的数据传送至少部分是同时发生的)。在这种情况下，捆绑应用在客户端装置上提供生产者和消费者，并且还在服务器上提供生产者和消费者。

更具体地，在双向数据传送中，如图6所示，可以存在附加步骤，该附加步骤在客户端装置和服务器上为每个网络连接创建第二辅助连接线程。在数据传送仅在单个方向上流动的情况下，连接线程对于连接的维护和数据的传送而言可能是足够的，如图4和图5所示。然而，在双向数据传送的情况下，使用单个软件线程来发送和接收数据可能是不方便的且不是最理想的。而是，在连接的两侧上，CMC可以为每个网络连接创建附加线程，以便更容易地处理发送和接收数据。这些辅助连接线程在图6中被示为用于客户端装置的辅助连接线程#1 602、辅助连接线程#2 604和辅助连接线程#2606，以及用于服务器的辅助连接线程#1608、辅助连接线程#2 610和辅助连接线程#N 612。重要的是要注意，每个网络连接使用一个或两个软件线程对捆绑应用是完全透明的。捆绑应用仅需要提供发起方、接收方和一个或多个生产者和消费者，并且只要捆绑应用满足其要求，信道捆绑工作的内部细节与其无关。一旦已经建立了适当的生产者/消费者组合，就可以开始数据传送。生产者负责生成用于传输的数据406。当数据变得对生产者可用时，生产者可以将数据提供给捆绑。如下面和以上更详细讨论的，生产者可以将数据分解成有序的包(即，它可以对数据408进行分包)，并使这些包可用于CMC，然后CMC可以将这些包置于发送队列416中。在一个实施例中，发送队列是至少两个可能的队列414中的一个，而另一个队列是重发队列418，这将在下面讨论。在替换实施例中，可以使用单个发送队列，其中重发的包可以被放置在发送队列的顶部。CMC可以确保将这些数据包线程安全平衡地递送到各个连接线程，这些线程认领(claim)不同的包以便将它们发送给消费者。最初，与活动连接相关联的每个连接线程可以承担先前放置在发送队列中的预定数目的包的所有权，并开始传送各自拥有的包。在一个实施例中，包的预定数目对于每个连接线程可以是相同的(例如，20个包)，如下面更详细地讨论的。当连接线程认领来自发送队列的一个包的所有权时，这个包可以被从发送队列中删除，以确保没有其他连接线程尝试获取它的所有权。

各种连接线程可以尝试同时访问驻留在发送队列中的数据。与使用单个网络接口来发送其数据的标准网络应用不同，绑定的一个目标可以是用多个连接来发送数据流的多个片段，使跨多个连接发送的数据几乎没有重叠，从而使吞吐量最大化。使用多线程来处理和递送数据包需要线程之间的协作和对同步的需要。如前所述，可以认为发送队列是准备好要发送到接收侧的包的阵列。如果两个连接线程想要大致同时检索下一个可用的包，并且两个连接线程都得到同一个包N，则捆绑增大吞吐量的优点会在某种程度上被丢失。相反，例如，要求是连接线程#1得到包N，而连接线程#2得到包N+1。

有多种线程同步技术可以用于实现这一点，其中许多技术涉及对锁的使用。一些类型的锁定机制在一个线程具有锁的同时防止其他线程前进。也就是说，当连接线程#1具有锁并正在从发送队列中检索下一个可用包时，如果连接线程#2想要同时得到包，则它必须等到连接线程#1完成。根据连接线程#2必须等待的时间，在相关联的连接线程上可能发生从用户代码到OS内核的转换，这引起其自身的时间成本。这种锁定机制可以为捆绑工作，但是以降低性能为代价。

或者，捆绑逻辑可以使用快速原语基元来确保每个连接线程对发送队列的访问是线程安全的且是高性能的。原语操作以处理器指令级产生非常低级的锁，并且在两个线程同时试图访问同一存储器的罕见情况下，硬件将确保仅一个线程可以这样做，而第二个线程将必须等待一个微小的时间量，然后才能执行该指令。

如下面更详细讨论的，CMC还可以监视数据递送以便评价网络连接(例如，检测坏的/差的网络连接)并相应地调整包递送(例如，在替代连接上重新发送数据包)。

在接收侧，相关联的连接线程可以使数据可用于CMC。通过将包按顺序放置462在由消费者提供的一个或多个接收包缓冲器450中，CMC又可以使该数据可用于捆绑应用的消费者。接收包缓冲器可以是预定大小的循环缓冲器，或者它可以是动态调整大小的。消费者然后负责将存储在接收包缓冲器中的数据解包448，然后使用解包的数据446。一旦它使用了特定的包资源，它就可以负责将该包资源返回CMC进一步使用。

与当生产者将数据分包时各个包最初被排序的情况相比，各个包可以不按顺序递送。在这方面，消费者可以对这一点负责。例如，对于文件传送捆绑应用，消费者可以在尝试写入文件之前等待连续排序的包被递送，因为文件的每个部分可以被认为是同等重要的。其他捆绑应用可能具有较不严格的要求。例如，广播捆绑应用可以不必等待丢失的包，例如，而是选择跳过一些丢失的包，却不会显著影响媒体的回放。

当数据传输正在进行时，负责发送数据的连接线程可能首先检测到其相关联的网络连接的丢失，并且如果已经建立了附加的连接，则连接的丢失可以由其它网络连接中的一个网络连接报告给接收侧，使接收侧能够更及时地对故障情况做出反应。如果所有连接都丢失，传送可能会被中止。

如下面所讨论的，如果一个连接相对于其他连接变得太慢，或者已经确定该连接一般性能较差，则该连接可以从连接组中除去，并且稍后被带回到测试模式中恢复，如以下讨论的，直到情况可能被改正为止。在一个实施例中，当连接处于测试模式时，它不发送由生产者生成的任何数据。在替代实施例中，如果连接相对于其他连接变得太慢，或者已经被确定为通常性能较差，则可以为当前空闲的网络接口建立另一连接。例如，响应于确定使用移动宽带网络接口的连接没有正确地执行，可以建立使用当前空闲的卫星网络接口的新连接并将其添加到连接组。在更具体的实施例中，在纠正了性能差的连接的情况之前，使用卫星网络接口的连接可以一直被使用。

前面提到，在一个实施例中，有两个队列414，发送队列416和重发队列418。在一个实施例中，队列414可以包括循环缓冲器。如先前所讨论的，由生产者提供的经分包的数据最初被放置在发送队列中，其随后由不同的连接线程来认领。如下面更详细地讨论的，如果特定的网络连接变得不可靠或缓慢，则将它已经认领的包发送到接收侧仍然是重要的。在这种情况下，连接线程可将其包添加到重发队列中，从而允许一个或多个其他连接线程发送这些包，而认领它们的原始连接线程也继续尝试成功地发送包。重发队列中的包比发送队列中的包具有更高的优先级。也就是说，如果在两个队列中都有要发送的包，则连接线程将在认领发送队列中的任何包之前，认领在重发队列中的包。重发队列和使用其他网络连接重发先前已经被认领的包提高了可靠性。之前，已经提到信道捆绑改善了吞吐量，并且改善的吞吐量可能是关键的好处，但是多个网络连接的存在还允许改善可靠性，这在仅使用单个网络连接的联网技术中是不可能的。虽然在其他连接上重新发送包在技术上导致吞吐量的降低，但是最终结果可能是存储在这些包中的数据被更快地递送到接收侧，因此也可以认为它也可以提高吞吐量。

当数据传送正在进行时，软件的状态可以被描述为处于传送会话中。在一个实施例中，当数据传送完成时，传送会话被认为已完成，但是另一传送会话可以在将来的某一点再次开始，以便处理新的数据传送请求。

图7示出了由如先前在图4-图6中所示的连接线程用于数据传输的一些高级设施的框图700。如图7所示，连接线程420可以包括传输分析学702。传输分析学702可以对由连接线程420发送的数据的传输的至少一个方面进行分析。传输分析学的示例包括但不限于ACK检查704和RTT检查706，下面进一步详细讨论。此外，连接线程420包括传输模式708，诸如正常模式710和测试模式712，下面将进一步详细讨论。

图8示出了如先前在图4-图6中所示的连接管理组件(CMC)的一些设施的框图800。如图8所示，客户端装置的CMC 412或服务器的CMC 460可以具有某些共同的特征，但是它们之间还存在足够的差别，以保证它们是两种不同类型的CMC，一种意图用于客户端装置，一种用于意图用于服务器。CMC包括各种连接阶段802，诸如正常连接阶段804、测试连接阶段806和预先测试连接阶段808，这些阶段中的每一个将在下面更详细地讨论。最后，CMC可以包括额外的分析学816，诸如下面进一步详细讨论的时钟偏差818。

在仅涉及单个网络连接的标准联网应用中，如果到因特网的连接较慢，则网络应用不得不接受慢速连接。此外，如果由于某些原因连接失败，则网络应用作为一个整体实际上也被停止。

相反，捆绑可以分析传输的至少一个方面(诸如连接的一个或多个方面)，并且基于该分析，可以修改系统的至少一部分的操作。修改可以包括修改连接(例如，将连接置于测试模式，使连接离线，将连接置于正常模式以传输数据等)。可替换的，或者另外，修改可以包括改变网络接口的操作。例如，客户端装置可以命令网络接口断开连接。更具体地，对于移动宽带接口，客户端装置可以命令移动宽带接口结束与蜂窝塔的通信。作为另一示例，客户端装置可以命令移动宽带接口改变其模式(例如，从3G变成4G)。作为又一示例，客户端装置可以命令当前空闲的另一网络接口建立与服务器的连接(例如，使用作为备份的卫星网络接口)。

在一个实施例中，分析包括对多个网络连接的一个或多个方面的动态分析。在替代实施例中，动态分析包括相对于(或依赖于)第二网络连接(其使用第二网络接口)动态地分析第一网络连接(其使用第一网络接口)。在更具体的替代实施例中，动态分析包括相对于(或依赖于)第二网络连接的相同方面动态地分析第一网络连接。动态分析可以包括对由生产者生成并由消费者消费的数据的至少一部分的传输的动态分析。在更具体的实施例中，动态分析包括分析连接的至少一部分的延迟。特定连接的延迟分析可以独立于、依赖于或部分依赖于和部分独立于不同连接的延迟分析。

在又一更具体的实施例中，动态分析包括对在一个连接上发送的包的往返时间(RTT)检查，可以将该往返时间与关联于一个、一些或所有其他连接上发送的包的RTT进行比较。RTT通常被定义为将包发送到接收端以及获得该包的递送的收据所花费的时间量。因此，向接收端发送包所花费的时间量可以被估计为RTT/2，即使在一个方向上比在另一个方向上发送数据可能花费更长的时间。RTT是如何对在客户端装置与服务器之间传输的包的传输时间进行检查的一个示例，并且能想到其他度量。

在另一个实施例中，动态分析包括与连接组中的任何其它连接部分地或完全独立地对一个连接进行动态分析。在更具体的实施例中，动态分析包括对经由一个连接传输的包的确认(ACK)检查，该分析可以独立于其它连接中的一个、一些或全部来分析。

在又一个实施例中，动态分析包括既部分地或完全地独立于捆绑中的任何其它连接又依赖于捆绑中的一个、一些或所有其他连接地动态分析一个连接。在更具体的实施例中，动态分析包括RTT检查(其可以利用与连接组中的其他网络连接相关联的RTT值)和ACK检查(在一个方面，其可以包括部分或完全独立于一个、一些或所有其他连接地对包的确认进行分析)。在另一个具体实施例中，动态分析包括独立于(和取决于)经由另一个连接的传输来分析相同方面。例如，在一个方面，ACK检查的分析可以独立于针对其他连接的ACK检查，在另一方面，可以取决于对其他连接的ACK检查。在这点上，相同方面，ACK检查可以是独立和依赖分析的基础。

动态分析可以处理缓慢和/或不可靠的连接。例如，在移动宽带的情况下，特定的网络接口可能经历暂时较差的信号强度。在一些区域中，运营商可以仅支持处于非常低的速率的数据传输。为了解决这种情况，捆绑可以使用各种技术，例如动态分析，以减少不良执行的网络连接的影响。

如上所述，网络连接的分析的一个方面是ACK检查。当连接线程在传送会话期间处于发送包的过程中时，在执行定义(implementation-defined)数量个包对于接收侧未完成之后，连接线程可以检查以确定这些包中的任何一个是否已经被连接的另一端接收。确认可以作为传输过程的一部分发送。例如，如果UDT用作通信层，则UDT提供的特征之一是确认，使得在连接的接收侧处理了一定数量的包之后，接收侧发送特殊确认包给发送器，该特殊确认指示已经由接收器成功接收的有序包的数量。

如果到连接线程已经达到等待确认的未解决包的执行定义限制的时候一个或多个包已经被确认，则应用进一步的分析学(例如RTT检查)可能是恰当的，但是如果它通过这些分析学，连接线程可以从发送队列取得更多包的所有权，直到它再次达到执行定义数量个等待确认的未解决包。

如果到连接线程进行检查以查看是否有任何未解决包已被接收器确认的时候还没有一个未解决包被接收，则连接线程可以等待一定量的时间，并且在该时间期间，它不可以发送任何新的数据包。也就是说，它不会从发送队列取得任何额外的包的所有权。该时间量可以是可变的时间量，如下所述。

如果在该时间段结束时，所发送的包中的一个或多个已经被接收端确认，则应用进一步的分析学(例如，RTT检查)可能是恰当的，但是如果它通过这些分析学，连接线程可以从发送队列取得更多包的所有权，直到它再次达到执行定义数量个等待确认的未解决包。

相反，如果在该时间段结束时，没有所发送的包被接收端确认，则认为该连接已经进入缓慢和/或不可靠的阶段。虽然UDT保证数据递送，假设连接仍然可用，但是如果连接变得缓慢和/或不可靠，则未解决的包被递送到接收端可能需要一段时间。缺少确认还可能指示连接不再可用，这指示包可能永远不会被递送，这取决于连接何时失去其可行性。例如，接收端可能已经成功地接收到包，但是在相关联的确认被发送端接收到之前，连接可能变坏，并且作为结果，确认包可能永远不会被接收到。不管情况如何，重要的是以及时的方式将包递送到接收端。

如果网络连接被认为已经进入缓慢和/或不可靠阶段，则连接线程可以释放其对未确认的包的“所有权”。在释放所有权之后，CMC可以将未被确认的包添加到重发队列。其他连接线程在准备好发送数据时将意识到在重发队列中有数据包可用，并且将相对于发送队列中的包优先发送来自重发队列的包。与当前处于发送队列的前端的包相比，重发队列中的包通常具有较低的数字序列号，因此，重要的是尽快发送它们。类似于用于认领发送队列中的包的所有权的线程同步技术，其他连接线程可以取得重发队列中的包的所有权以便于传输。同时，已经进入缓慢和/或不可靠阶段的原始连接线程可以继续尝试发送包。因此，接收端的CMC就可能被通知具有相同序列号的多个包通过多个连接到达。这样，CMC可能需要丢弃冗余的包。

在它的确认检查出现失败之后，连接线程在它先前发送的所有包已经被确认之前一直不可以尝试从发送或重发队列取得任何新包的所有权。在连接线程在技术上释放其对包的所有权并且使包被添加到重发队列的同时，原始包仍然已经被发送，并且可能不能依赖正利用的通信层来取消对这些包的传输。这样，连接线程将继续使用确认检查，直至它确定所有包已经被确认。如果最终原始包被确认，则连接线程可以继续从发送队列(或重发队列)取得包的所有权。如果相反，连接线程依然未能完成进一步的确认检查，则将认为该连接线程不再可行，并且可以终止相关联的连接。使用相关联的网络接口的连接可以在稍后的时间点再次被提出。建立新的网络连接可能足以纠正导致缺乏确认的任何问题。一旦建立了新连接，就可以将其添加到连接组，然后加入传送会话。

如前所述，如果到连接线程进行检查以查看是否有任何未解决的包已经被接收器确认的时候未解决的包一个也没有被接收，则连接线程可以等待一定量的时间，并且在该时间段期间，不发送任何新的包。在一个实施例中，该时间段可以被动态地计算；例如在每次需要等待时动态地计算该时间段。动态计算可以使用一个算法，该算法考虑并且基于传送会话中的所有其他连接(例如，主动传送由生产者生成的数据的连接)的平均RTT。另外，如果在该时间段期满之前接收到确认，则等待将被中断，并且连接线程可以如前所述地那样继续工作。

例如，包“XXX”可以被生产者递送到CMC并且放置在发送队列上。然后连接线程#2可以认领包“XXX”的所有权并将其发送到接收侧。在没有及时地接收到对包“XXX”的确认的情况下，连接线程#2可以释放包“XXX”的所有权，然后将包“XXX”置于重发队列中。然后另一连接线程(例如连接线程#4)可从重发队列认领包“XXX”的所有权且将其发送到接收侧。最初由连接线程#2发送的包“XXX”可能已经丢失，或者其可能被传输得过度缓慢。在后一种情况下，包“XXX”将被发送两次。在这点上，接收侧的CMC可以丢弃冗余的包“XXX”。将这一方面进一步扩展，从重发队列认领包“XXX”的所有权的连接线程#4，也可能没有完成其确认检查。在这种情况下，它将包重新添加到重发队列中，然后另一个连接线程可以认领该包的所有权。然而，连接线程#2和#4均可以不从发送或重发队列认领任何包的所有权，直至连接线程#2和#4的包“XXX”的副本已经被接收侧确认为止。

ACK检查技术允许每个连接线程自我调节自身。也就是说，它确保特定连接线程仅获取其相关联的网络连接在给定时间段内可以成功发送的数量的包的所有权。因为连接线程将在任何给定时间只认领最多不超过执行定义(implementaion-defined)的数量的包的所有权，如果一个网络连接比另一网络连接慢，则与慢网络连接相关联的连接线程不会像与较快网络连接相关联的连接线程一样频繁地取得新的包的所有权。较快的网络连接只是将比较慢的网络连接更快地从接收侧接收到确认，从而允许较快的网络连接更频繁地获取新包的所有权并发送它们。这样，每个网络连接的吞吐量可以被隐式地最大化，而不必提前进行训练会话以查看特定网络连接能够具有什么种类的吞吐量。这又使得传送会话能够在由捆绑应用启动时立即开始，因为在传送由生产者生成的数据之前不需要训练会话。

在一个实施方式中，每个连接线程最初可以被分配到相同的预定数量的包，例如20个包。在这点上，每个连接线程可以被限制为一次取得20个包的所有权，包括在开始传送会话时立即取得。因此，在传送会话启动时，不需要训练会话。相反，每个连接线程可以取得不超过20个包的所有权。此后，特定连接线程可以取得所有权的额外的包的数量取决于当前拥有的20个包中的任何包是否已经被确认。例如，如果20个包中没有一个已被确认，则特定连接线程不可以获取任何额外的包的所有权。如果特定连接线程拥有的20个包中的一个或多个被确认，则特定连接线程可以获取高达20个包限值的额外包的所有权。监视与特定连接线程相关联的未确认包的数量的该过程可以在整个传送会话中继续。

图9示出了当连接线程在传送会话期间传送数据时的确认检查的流程图900。在902，连接线程从发送队列和/或重发队列获得新包的所有权。在904，其发送新包。在906，确定是否已经针对所发送的包中的一个或多个接收到ACK。如果不是，则在908，它等待以查看在动态确定的时间限值内(如前所述，可以基于传送会话中的其他连接的RTT值来计算)是否接收到ACK。如果在时间限制内未接收到，则在910，将任何剩余的未确认包添加到重发队列。在912，ACK失败计数器递增1，其中ACK失败计数器用于连续跟踪连接线程没有完成ACK检查的次数。在914，确定ACK失败计数器是否已经超过阈值。如果是，则在916，确定连接不可行，并且在918，使连接离线。稍后，用于相同网络接口的网络连接可以重新建立起来，并且一旦其加入连接组和传送会话，则在920处，连接可以根据特定条件进入测试模式。如果相反，在914，ACK失败计数器没有超过阈值，则移动到922，在该点设置模式以指示连接线程不应该(从发送或重发队列)认领任何新包的所有权。从那里，其循环回到已经讨论的在906处的ACK接收的检查。如果，在906处已经接收到确认，或者在908处在时间限值内接收到确认，则移动到924，在该点，ACK失败计数器被重置为零。在926，确定连接线程是否处于无新包模式。如果不是，则流程图循环回到902。如果是，则在928，确定是否已经为所有释放的包(例如，在910处添加到重发队列的包)接收到确认。如果否，则流程图循环回到906。如果是，则流程图返回到902。

除了(或者代替)ACK检查，可以执行RTT检查。

当在传送会话中时，即使正在发送数据的连接从接收端接收到常规确认，将包递送到在这个特定连接上的接收端可能要花费相当长的时间，特别是与在传送会话中在其他连接上递送包所需的时间量有关。例如，如果在传送会话中有四个连接，并且连接#1-#3各自具有100mSec或更小的平均RTT值，这意味着平均来说需要50毫秒或更少时间来将包递送到连接#1-#3上的接收端。但是，连接#4需要稍长的时间来递送数据，并且具有的平均RTT值为500mSec。这意味着连接#4要花费大约250毫秒来将包发送到接收端。如前所述，一旦连接线程从发送队列(或重发队列)取得包的所有权，则没有其他连接线程会尝试发送该包。尽管连接#4将有所进展，虽然是以比连接#1-#3慢的速度有所进展，连接#4递送数据所花费的时间量可能对一些捆绑应用，特别是涉及媒体的近实时流传输的捆绑应用具有显著且有害的影响。

为了过滤掉慢的连接，可以在确认检查成功之后审查连接的RTT。在接收到确认检查之后审查RTT，因为通常，如果确认检查失败，则没有理由进行RTT检查，因为显然似乎没有任何已发送的包被接收。在一个实施例中，可以基于可变阈值比较RTT值。可变阈值可以基于传送会话中的一个、一些或所有其他连接的RTT值，诸如比基于传送会话中所有其它连接的平均RTT的计算值大很多的值。在这点上，在一个实施例中，对一个连接的评估可以至少部分地基于对一个、一些或所有剩余连接的评估。在替代实施例中，可以基于预定阈值而独立于不同连接的RTT值地评估RTT值。在另一个替代实施例中，可以基于可变阈值和非可变阈值来评估RTT值。例如，如果RTT值高于执行定义的阈值(例如，250mSec)，并且RTT值充分大于基于传送会话中的一些或所有其他连接的平均RTT计算出的值，则可以为该特定连接递增慢RTT计数器。

如果慢RTT情况继续发生，则在慢RTT计数器达到执行定义的阈值之后，连接线程已经发送的所有未确认的包可以被添加到重发队列。例如，执行定义的阈值可以包括“5”，意味着在任何未确认的包被添加到重发队列之前，慢RTT计数器需要被重复递增五次。这避免了连接线程由于暂时缓慢的连接而过早地将未确认的包添加到重发队列的可能性。如果达到该阈值，类似于ACK检查中的缺少确认的情况，则连接线程将不会从发送队列(或重发队列)取得任何新包的所有权，直至其先前发送的所有包已经被确认。如果慢RTT情况继续重复发生，则在计数达到不同的执行定义的阈值(不同的执行定义的阈值必须大于早先的执行定义的阈值)之后，连接可以被标记为慢，并且关联的连接可以被终止。在等待预定量的时间之后，该连接可以被重新利用。当被重新利用时，该连接可以被添加到连接组，然后加入传送会话，但是可以将该连接置于与正常模式不同的状态，例如置于测试模式，如下面将讨论的。

图10示出了用于在传送会话期间传送数据时由连接线程执行的往返时间(RTT)检查的流程图1000。流程图1000的多个部分类似于流程图900。在902，连接线程从发送队列和/或重发队列获得新包的所有权。在904，其发送新包。在906，确定是否已经针对所发送的包中的一个或多个接收到ACK。如果不是，则其执行如图9中所描述的ACK检查。如果在906处接收到ACK(或者在如图9中的908所描述的时间段内接收到ACK)，则移动到1002，在该点处，访问用于网络连接的RTT值。在1004，确定RTT是否大于规定的RTT限值。如果是，则在1006，确定RTT是否充分大于针对传送会话中的其他连接的平均RTT。如果是，则在1010，将用于该连接线程的RTT失败计数器递增1。然后，在1010，确定RTT失败计数器是否大于阈值#1。如果是，在910，如对于ACK检查所做的一样，任何剩余的未确认包被添加到重发队列-然而，与ACK检查相反，如果到达这一点，至少一个未解决包先前已经被确认因为它已经通过了ACK检查。在1014，确定RTT失败计数器是否大于阈值#2(阈值#2大于阈值#1)。如果是，则在916，该连接被确定为不可行，并且在918，使该连接离线。稍后，可以重新建立用于相同网络接口的网络连接，并且一旦该网络连接加入连接组和传送会话，则在920处，连接可以根据特定条件进入测试模式。如果相反，在1014，RTT失败计数器没有超过阈值#2，在912，与ACK检查一样，在这一点上，设置一个模式以指示该连接线程不应该(从发送或重发队列)认领任何新包的所有权。在912之后，其循环回到906。

如果相反，在1012，阈值#1未被超过，则移动到926，如先前在图9中所描述的，并且以与针对图9所描述的相同的方式从那里继续下去。

如果相反，1004或1006评估为否，则在1008，RTT失败计数器被重置为0。然后，如已经描述的，移动到926。

在传送会话中使用的网络连接可以处于几种模式中的一种，例如正常模式和测试模式。正常模式描述了当网络连接被用于在传送会话期间传送由生产者生成的分包数据时的网络连接的状态。

测试模式是一种特殊状态，网络连接在处于传送会话时可以基于对该连接的先前分析(例如如果该连接已被确定为执行不良)将其置于测试模式。可以基于上述不同类型的分析的结果，例如基于RTT检查和/或ACK检查，进入测试模式。更具体地，可以以两种不同的方式之一进入测试模式：(1)由于RTT检查，相关联的网络接口的最后一个连接被终止；和(2)用于相关联的网络接口的最后两个连接由于ACK检查而被终止。可以使用其他准则来确定是否应当使用测试模式。

当网络连接在传送会话期间处于测试模式时，其关联的连接线程将不会从发送或重发队列取得任何包的所有权。相反，连接可以向接收侧重复发送不包含任何实际数据的特殊测试模式包。除了这种改变之外，ACK检查和RTT检查可以以与上述相同的方式操作。

如果测试模式下的连接继续没有完成ACK检查或RTT检查，该连接将再次终止，并在稍后被重新利用。终止与重新利用连接的动作之间的时间量可以是预定的，或者可以根据相关网络接口的先前连接是否处于测试模式而变化。例如，随着用于特定网络接口的网络连接被重复地置于测试模式(并且随后由于ACK检查和/或RTT检查而不能脱离测试模式)的次数增加，先前的连接被终止的时间点与建立新连接的时间点之间的时间量可以增加到执行定义的时间限值。

在测试模式下，如果网络连接在发送了执行定义数量的测试模式包之后成功地通过ACK检查和RTT检查，则连接将退出测试模式，进入正常模式，并立即开始从发送和/或重发队列取得包的所有权。

在这方面，测试模式的意图可以是双重的。首先，测试模式可以防止执行不良的连接发送由生产者生成的任何数据，因为这可能对捆绑应用具有有害的影响。如上所述，执行不良的网络连接所意味的是该连接的性能相对于传送会话中另一连接(或其他连接)的性能而言，和/或可以是相对于预定标准的性能而言。关于将一个连接与其他连接进行比较，如果大多数连接较慢(因此具有高RTT值)，则慢连接可能不被认为是执行不良，因为它与其他网络连接相比执行状况类似。但是，不论传送会话中的其他连接进行得如何，失败的确认检查可能总是会导致相同的结果。

第二，如果任何导致连接执行不良的条件在将来得到纠正，则测试模式可以检测到这一点并允许该连接以正常模式重新加入传送会话作为连接组的生产性成员。

图11示出了用于分析连接线程在测试模式下的性能的流程图1100。图11建立在图9和图10中分别描述的ACK检查和RTT检查的基础上，并且因此，为了简洁省略了某些细节。在传送会话期间，网络连接被置于测试模式，并且在1102，发送测试模式包。在发送包时，ACK检查和RTT检查如前所述进行。当发送测试模式包时，如果在任何点，由于在1106的ACK或RTT检查而失败，则在1108连接将被终止。然后，在1110，将计数器递增1，该计数器保持跟踪在处于测试模式时在传送会话期间关联的网络接口的网络连接被终止的次数。然后，在1112，基于针对1110描述的计数器的值来确定为重新建立用于该网络接口的网络连接要等待多长时间。在1114等待该时间量，然后在1116，用于此网络接口的网络连接被重新建立，并且循环回到1102。如果相反，在1106，能够成功地发送执行定义数量的测试模式包(成功地意味着所有包被接收侧确认)而没有ACK或RTT检查失败，网络连接被置于正常模式。此外，在进入正常模式之前，将以上针对1110描述的计数器重置为零。

如上所述，CMC可以向捆绑应用逻辑提供一个或多个服务。在一个实施例中，这些服务可以与捆绑结合起来使用以改善结果，并向捆绑应用提供有用的反馈信息。在替代实施例中，这些服务可以与任何捆绑应用分开使用并且独立于任何捆绑应用。这种服务的示例先前在图8中描述。

一种服务包括确定客户端装置和服务器之间的时钟偏差。在一个实施例中，时钟偏差确定可以用于捆绑应用，因为在某些情况下，理解客户端与服务器之间的时钟偏差可能对捆绑应用有帮助。时钟偏差是在每个相应系统上设置的本地时钟时间之间的时间差。例如，如果客户端上的时间是12:00:00PM，并且服务器上的时间是12:00:01PM，则时钟偏差约为1秒。

时钟偏差可以以多种方式计算。一种方法是使用Cristian算法的变型。Cristian算法是可以用于仅使用由每个系统提供的时间数据以及与两个系统之间的网络连接有关的信息来确定两个不同系统之间的时钟偏差的方法。通过在两个系统之间建立的网络连接，第一系统在包中将其当前时间T 1发送给第二系统，第二系统在接收包的那一时间点也获得其当前时间T 2。第二系统还及时地在该时间点确定网络连接的RTT。由于如前所述，可以估计大约需要RTT/2在任一方向上发送包，所以时钟偏差可以计算为：时钟偏差＝T2-T1-RTT/2。另外，通常最好多次经历该过程，并基于多个T1/T2/RTT组合(或者选择具有最低RTT值的组合)来计算平均值。

在一个实施例中，代替简单地对于单个网络连接使用Cristian算法，在信道捆绑的环境中，该算法可以跨越多个不同的连接使用(例如对于在传送会话中的不同连接中的至少两个连接、多于两个连接、或所有连接)。在这点上，每个客户端系统向服务器发送多个时间包，并且在服务器跨不同连接累积了执行定义数量的时间包之后，服务器可以对全部连接应用Cristian算法。

例如，客户端装置可以经由两个连接：连接1和连接2与服务器通信。客户端装置可以经由每个连接偶尔发送具有当前时间T1的包，T1是在发送包时的时间；当服务器接收到该包时，服务器可以记录(note)其当前时间T2和用于相关联的网络连接的当前RTT值，该RTT值可以不断变化。在服务器在不同的连接上累积了一定数量的这些包之后，服务器可以使用Cristian算法来计算平均值。通过对多个连接(与单个网络连接相反)进行这种确定，期望的是将提高该技术的精度。

一旦服务器已经计算了时钟偏差，则服务器可以可选地通知客户端装置所计算的时钟偏差值。如上所述，捆绑应用可能希望知道时钟偏差。或者，时钟偏差可以与任何捆绑应用独立且无关地来确定。

图12示出了用于通过分析跨多个连接提供的时间数据来确定客户端装置与服务器之间的时钟偏差的流程图1200。该流程图是从服务器的角度来看的。在1202，由客户端装置通过至少两个不同连接发送的时间包被接收。在每个包被接收的时间点，如前所述，从包中提取T1，并记录T2和RTT。在1204，确定接收的包的数量是否大于阈值。如果不是，则循环回到1202，并且服务器继续通过网络连接从客户端接收时间包。如果大于阈值，则在1206，基于从不同连接接收的包以及相关联的T2和RTT值来确定客户端装置与服务器之间的时钟偏差。在1208，可选地向客户端装置通知所确定的时钟偏差。

如前面在图8中所描述的，CMC还提供能够利用一个或多个连接阶段的捆绑应用(或者用于独立的使用)，该连接阶段为：正常连接阶段；测试连接阶段；和预先测试连接阶段。正常连接阶段对应于网络连接在传送会话期间以正常模式或测试模式操作时所处的阶段。相比之下，测试连接阶段和预先测试连接阶段可以被捆绑应用用于在生成器生成实际数据之前的训练阶段。当处于这两个阶段中的任一阶段时，网络连接可以根据捆绑应用的要求在任一方向上发送假数据一段时间。在该时间段期间，跟踪网络连接的各个方面。当时间段完成时，可以分析数据，并且捆绑应用可以出于自己的目的利用该分析。作为一般规则，如果所有网络连接在测试连接阶段或预先测试连接阶段中操作以便提前了解传送会话作为整体将执行得如何，则可能是最有利的。可以在分析之后提供的数据类型的示例可以包括但不限于以下各项中的任何一个、任何组合或全部：最小的、最大的、平均的和中间的RTT；最小的、最大的、平均的和中间的吞吐量；和测试模式使用的频率。通过提供额外的分析学，例如精确确定每个包从发送器传送到接收器所花费的时间，而将预先测试连接阶段建立在测试连接阶段的基础上。重要的是要注意，捆绑应用不需要使用测试连接阶段或预先测试连接阶段，以便成功运行。在这点上，捆绑应用可以可选地使用测试连接阶段或预先测试连接阶段。

如前所述，由于信道捆绑的工作方式，训练阶段不是必需的。然而，捆绑应用在某些情况下仍然可以选择使用测试连接阶段或预先测试连接阶段，这取决于这些情况的要求。例如，广播捆绑应用可以通过能够在实际广播之前确定什么可以用作其生成的编码媒体的合理的最大比特率而受益于训练会话。没有训练会话，广播捆绑应用可能需要是保守的，并且总是以相对低的比特率开始，而较低的比特率意味着至少最初的质量可能比与较高比特率相关联的质量差。

到目前为止，已经将信道捆绑描述为等同地处理所有网络连接的方法。通过使用ACK检查和/或RTT检查，与不同网络连接相关联的连接线程对包到不同网络连接的分发进行公平的管理。比其他连接速度更快、更可靠的网络连接将默认取得更多包的所有权，而速度较慢和可靠性较低的连接默认会取得较少数据包的所有权。然而，在一个实施例中，使某些网络连接优先于其他网络连接是有利的。在这样的实施例中，信道捆绑不一定等同地对待所有网络连接。

如图13的框图1300中所描述的，存在各种准则1304可以被CMC用来使与某些网络接口相关联的网络连接比与其他网络接口相关联的网络连接优先。这些准则可以包括但不限于以下：成本1306；数据限值1308；位置1310；和一天当中的时刻1312。此外，基于优先级排序准则，CMC可以使用各种技术1314来在实践中实现这种优先级排序。这样的技术可以包括但不限于以下：禁用接口1316和加权1318。对于准则和技术将在下面更详细地讨论。

成本优先级排序准则通常涉及使用客户端装置上的特定网络接口发送和/或接收数据可能花费多少。例如，使用网络接口#1传输MB值的数据(MB worth of data)可能比使用网络接口#2传输MB值的数据更加昂贵。存在多种方式来确定与不同网络接口相关联的货币成本。在一个实施例中，客户端装置可以维护用于不同网络接口的预配置值。在另一个实施例中，服务器可以在客户端装置为该网络接口建立与服务器的网络连接的时间点处提供与网络接口相关联的值。

数据限值标准与可能与特定网络接口相关联的潜在数据限值有关。例如，客户端装置中的移动宽带网络接口#1可以与运营商#1相关联。通常，移动宽带运营商不提供具有无限数据的数据计划-大多数数据计划具有精确的限值，例如每月100GB，并且在规定的时间段内超过该限值的任何数据使用可以根据额外的GB来收费，或者完全不允许，或者下降到较慢的速度(例如4G到3G甚至2G)。如果与特定网络接口相关联的数据额度(allowance)接近于被满足或已经被超过，则可以谨慎的是，使其他网络接口比这个网络接口优先，以节省资金。在这方面，数据限值准则类似于成本准则。重要的是要注意，数据计划可能不是特定于单个客户端装置上的单个网络接口的。单个数据计划以及因此单个数据额度可以与同一客户端装置上的多个网络接口相关联甚至可以与跨越多个客户端装置的多个网络接口相关联。例如，客户端装置#1可以具有均与运营商#1相关联的移动宽带网络接口#1和移动宽带网络接口#2。另外，客户端装置#2可以具有也均与运营商#1相关联的移动宽带网络接口#3和移动宽带网络接口#4。进一步地，相同的数据计划，并且因此相同的数据额度，覆盖所有四个装置。基于这种情况，在一个实施例中，客户端装置可以在适当时通过查询与每个网络接口相关联的运营商来在每个网络接口的基础上确定数据限值信息。在另一个实施例中，服务器可以在客户端装置为一个网络接口与服务器建立网络连接的时间点处提供与此网络接口相关联的值。

位置准则与开始传送会话之前的客户端装置的物理位置有关。通过某种手段，客户端装置(可能与服务器联合起来)在传送会话期间跟踪其当前位置以及与传送会话相关联的性能数据。随着时间的过去，可以编译对应于位置的性能数据的数据库。如果在该位置下一次进行传输时，对于特定位置有足够的信息可用，那么某些网络接口可以优先于其他网络接口，因为可以从针对该位置累积的性能数据中注意到，在该位置某些网络接口比其他网络接口工作表现更差。例如，客户端装置可以具有与运营商#1相关联的移动宽带网络接口#1和与运营商#2相关联的移动宽带网络接口#2。在特定位置，与运营商#1相关联的移动宽带装置可能获得良好的信号，而与运营商#2相关联的移动宽带装置获得非常差的信号。可以从累积的位置数据确定这样的信息。

时刻准则与位置准则相似。通过一些手段，客户端装置(例如与服务器联合起来)基于时刻、星期几、日期等来跟踪用于传送会话的性能数据。这种方案也可以把位置考虑在内。如果已经积累了足够的性能数据，则可以确定某些方式。例如，可以记录，在平日下午5点到6点之间，不管位置如何，与运营商#1相关联的移动宽带网络接口都会工作得很差。进一步地，可以记录，与运营商#2相关联的移动宽带网络接口在相同的时间段期间工作良好，而不管位置如何。这样的数据可以用于优先级排序目的。

CMC可以使用过多的优先级准则，以便决定如何使某些网络接口优先于其他网络接口。例如，基于数据，可以决定完全禁用某些网络接口。在一个实施例中，客户端装置上的CMC可能不会与用于这种网络接口的服务器建立网络连接。作为一个示例，对于卫星网络接口，CMC可以基于成本确定将不建立与卫星网络接口的网络连接。在另一个实施例中，客户端装置上的CMC可以与用于这种网络接口的服务器建立网络连接，但是可以选择不在传送会话期间使用该网络连接来传送任何数据。

在替代实施例中，CMC可利用加权。通过将通过不同优先级排序准则确定的所有数据纳入其中，CMC可以为每个网络接口分配权重。在一个更具体的实施例中，权重可以采取百分比的形式，其中以该百分比与特定网络接口的网络连接的连接线程将从发送或重发队列取得包的所有权的速率有关。在100％，连接线程可能完全不受影响，并且可以以与之前在关于它认领新包的所有权的速率的文档中描述的方式一样的方式进行操作。然而，在50％时，其从发送或重发队列认领包的速率将是正常速率的一半。在更具体的实施例中，可以从传送会话的开始就应用这样的权重。在另一个更具体的实施例中，可以在传送会话期间随时间应用这样的权重。

CMC还可以将捆绑应用的要求纳入等式。某些捆绑应用可能比其他捆绑应用受优先级排序造成的消极影响更大。例如，在数据限值准则的情况下，对于运营商#1的数据额度可以比对于运营商#2的数据额度更快地被到达，因为通常，运营商#1的数据传送工作地更好。如果与运营商#1相关联的网络接口被赋予的权重小于与运营商#2相关联的网络接口的权重或者被完全禁用，则所得到的传送会话的总吞吐量和可靠性根据捆绑应用的要求可能是不够的。在文件传送捆绑应用的情况下，除非文件传送的速度是糟透的，否则优先级排序可能不会成为关注点。然而，在广播捆绑应用的情况下，媒体传输的质量可能是最重要的。在这种情况下，从传送会话开始时使用优先级排序技术可能对媒体传输的质量具有有害影响。在这样的环境中，优选的可能是开始传送会话而不使用任何优先级排序技术，并且一旦已经建立传送会话，逐渐应用这样的技术以便计量(gauge)它们对传送会话的影响可能比较合适。如上所述，客户端装置可以使用多个网络接口。在传送会话的背景下可以实时(或近实时地)监视网络接口的性能。在替代实施例中，可以跨不同的传送会话监视网络接口的性能。例如，服务器可以跨多个捆绑会话监视与特定客户端装置相关联的特定移动宽带网络接口，以确定特定移动宽带网络接口是否正常工作。在特定实施例中，服务器可以维护在过去已经用于从每个特定客户端装置连接到服务器的不同移动宽带装置的记录。如果当客户端装置连接到服务器时，过去已经被使用的特定移动宽带设备不再连接或表现地不稳定(与在先前捆绑会话中记录的过去行为相比)，服务器可以分析数据并且，基于某些阈值发送通知。该通知可以包括服务器内的内部通知，或者可以包括对外部装置的通知。

如上所述，各种捆绑应用可以被捆绑所使用。一种这样的捆绑应用是广播捆绑应用。广播捆绑应用被配置成为通过一个或多个因特网连接(例如通过使用绑定)从远程位置接近实时地广播高质量音频和视频提供高性能解决方案。在一个实施例中，捆绑逻辑可以是模块化捆绑库的形式，其使得能够创建捆绑应用，例如广播应用。

诸如广播捆绑应用的捆绑应用可以利用已经存在的捆绑库，并且因此不必关心捆绑的细节。在这方面，捆绑应用可以反而关注于创建捆绑应用特有的技术。

广播捆绑应用具有许多不同的架构指导方针：提供高质量的音频和视频；依赖于通过捆绑可用的带宽支持客户端与服务器之间的接近实时的延迟；支持一个或多个视频模式(例如，诸如720p59.94和1080i59.94的视频模式)。

给定了上述架构指导方针时，可以使用以下架构细节：使用高级视频和音频编码/解码能力，以便将原始视频和音频压缩到合理的大小，以便通过捆绑进行传输(以便满足接近实时的延迟指导方针)；支持视频编码的可变比特率(以满足高质量音频和视频要求和接近实时延迟指导方针)；音频和视频保持同步(以满足高质量的音频和视频指导方针)；减少或最小化联网问题的影响，以便减少媒体停顿或临时冻结的机会(以便满足高质量音频和视频要求和接近实时延迟指导方针)。

另外，存在针对广播解决方案的多个不同的硬件指导方针，其中一些遵循架构指导方针：能够经由客户端上的串行数字接口(SDI)输入端来接收音频和视频数据；能够经由服务器上的SDI输出端来输出音频和视频数据；支持在客户端上对原始视频帧的硬件编码和在服务器上对编码视频帧的硬件解码；易于运输和带到现场。SDI是数字视频接口系列，是数字视频接口的一个示例。高清串行数字接口(HD-SDI)是数字视频接口的另一个例子。可以设想到其他视频接口，例如HDMI。

广播系统可以涉及用户交互、硬件和软件。广播的事件的一般序列的示例如下：

(1)用户经由SDI电缆将音频/视频输入源连接到客户端装置。在一个实施例中，输入源是摄像机。或者，可以设想到其他输入源。

(2)用户启动客户端装置软件，其使用捆绑连接到服务器。

(3)用户与客户端装置软件交互以发起广播。

(4)当广播是活动的时：在客户端装置上，软件可以周期性地或连续地从SDI输入端检索音频样本和视频帧并对媒体数据进行编码。使编码数据对于捆绑可用，捆绑将数据发送到服务器；在服务器上，软件可以连续地或周期性地检查通过捆绑接收的被编码的音频和视频数据，并且当其变得可用时，数据被解码。该解码数据又通过SDI发送以供电视台使用，可能用于通过网络电视的直播。

(5)用户与客户端软件交互以停止广播。

(6)用户从客户端系统断开输入源。

该序列可以省略广播会话中的某些细节；然而，上述序列仍然反映了广播会话的总体状况。

图14示出了客户端装置的框图1400，其执行对媒体的编码和/或解码，并利用多个网络接口来传输经编码的媒体。如前所述，客户端装置具有一个或多个网络接口。此外，其具有执行捆绑逻辑和捆绑应用逻辑的处理器304。在这种情况下，它在执行与广播捆绑应用相关联的特定捆绑应用逻辑。如前所述，客户端装置必须具有经由SDI连接从外部输入(诸如相机)接收原始视频和音频的装置。这由硬件媒体接口1412代表，在该示例中，硬件媒体接口1412(例如通过使用SDI电缆)连接到相机1414。相机将原始视频和音频递送到硬件媒体接口，硬件媒体接口又将其递送到处理器以供进一步使用。处理器还可以出于硬件编码(例如，用于视频编码)的目的而使用硬件部件1408。出于硬件解码(例如，用于视频解码)的目的，处理器还可以使用硬件部件1410。硬件解码可以通常仅仅在以下情况中使用：在服务器上运行的捆绑应用具有生成编码媒体以供客户端装置消耗(或者更具体地，用于作为捆绑应用的一部分在客户端上运行的消费者消耗)的生产者。这种场景可能出现在诸如IFB或返回视频馈送之类的使用情况，这将在后面讨论。在一个实施例中，客户端装置102仅包括硬件编码1408。在替代实施例中，客户端装置102仅包括硬件解码1410。在另一替代实施例中，客户端装置102包括硬件编码1408和硬件解码1410。硬件编码和硬件解码可以由计算机中的物理硬件子系统提供。例如，它们可以由作为处理器304的一部分的硬件子系统提供。处理器304可以包括处理器，诸如具有包括快速同步视频的图形组件的处理器，其可以用于H.264硬件编码和/或解码。在这方面，快速同步视频包括编码和解码功能，而不需要依靠外部硬件卡来经由H.264进行编码或解码。因此，快速同步视频潜在地加速了编码和解码，同时使处理器606能够完成其他任务。存在用于编码和解码H.264视频的多种其它硬件选项。

在如前所述的硬件媒体接口用于SDI输入的情况下，用于SDI输入的一个硬件选项是内部附加卡(例如PCI 卡)。此硬件选项可用于台式机、服务器系统或使用定制机箱和可能的其他定制部件的定制系统。另一个硬件选项包括可以例如通过USB、Thunderbolt或ExpressCard连接到计算机的外部装置。

图14进一步示出数据输入(例如，经编码的视频和/或音频)和数据输出(例如，经编码的视频和/或音频)。在一个实施例中，客户端装置102经由捆绑仅输出数据。这描述了典型的广播捆绑应用布置，因为广播捆绑应用将典型地在客户端装置上提供生产者，为的是从经由硬件媒体接口输入的原始音频和视频数据生成分包的编码媒体。在替代实施例中，客户端装置102经由捆绑仅输入数据。这样的布置将不对应于典型的广播应用，因为没有数据正由客户端装置广播到服务器。在又一个实施例中，客户端装置102经由捆绑既输入又输出数据。这种布置描述了对典型的广播捆绑应用布置的增强，其中除了客户端向服务器广播数据之外，服务器为某些目的(例如，如上所述和下面讨论的IFB或返回视频馈送)向客户端提供一些数据。

客户端装置102还可以包括用于用户与客户端装置102交互的用户界面。用户界面可以包括触摸屏、鼠标和/或键盘输入。因此，一种选择是提供触摸屏并满足如上文针对图14所讨论的硬件草案的混合式膝上型/平板电脑。膝上型电脑可包括一个或多个USB端口。USB调制解调器可以包括移动宽带功能，并且可以经由USB端口连接。另一个选择是创建具有自己的机箱和可能的其他定制硬件的定制计算解决方案。

如上所述，存在广播捆绑应用可以执行以便从客户端装置上的原始音频/视频数据变成到服务器上的原始音频/视频数据的几个步骤。客户端装置可以对原始的、未压缩的媒体数据进行编码。然后，编码数据通过捆绑被发送到服务器。在服务器上，编码数据被解码，产生原始的未压缩媒体数据。可以存在将原始数据转换为其他像素格式的额外的特定于实现的步骤。

所有这些步骤导致被称为广播开销的时间成本。因此，在当客户端装置从输入源接收原始音频/视频数据的时候与当服务器输出等效的原始音频/视频数据的时候之间，将存在一些实时延迟(或者称为初始延迟或简单延迟)。例如，如果客户端装置在12:00:00PM开始广播，则服务器可能在12:00:03PM之前不会播放第一帧，指示3秒的初始延迟。上述各个步骤负责初始延迟。可以努力使不同步骤尽可能地快，同时尽可能保持最高质量的音频和视频。

如上所述，编码技术可以用作广播处理的一部分。因此，编码技术使得能够传输高质量视频。如果考虑诸如720p的视频格式，具有1280×720分辨率的逐行格式(progressiveformat)，则在单个视频帧中典型地有1843200个字节。使用59.94帧每秒(fps)的广播标准帧速率，这意味着仅仅对于原始视频数据，将需要具有至少883Mbps(兆比特每秒)的吞吐量的网络管道。这样大量的带宽在移动领域是不现实的，甚至10个移动宽带连接的总吞吐量也不能提供足够的聚合网络管道。

这样，压缩原始数据可以减少要传输的数据量。对于音频和视频，这可以使用高级编码器来执行。编码方案的一个示例是H.264/AVC编解码器，其可以用于对视频数据进行编码。另一示例压缩方案是AAC编解码器，其可以用于对音频数据进行编码。两种编解码器可以分别产生处于相对低的比特率的高质量的视频和音频结果。这意味着与使用其他编解码器相比，可以需要传输更少的数据，就能获得相同的质量水平。

H.264和AAC编解码器的实现方式有许多种。在一个实施例中，两种编解码器可以以硬件的形式实现。在替代实施例中，两种编解码器可以软件的形式实现。在另一个替代实施例中，H.264编解码器可以硬件形式实现，AAC编解码器可以软件形式实现。编码器(和解码器)的速度与广播捆绑应用相关，因为如上所述，对视频和音频进行编码所需的时间越长，在客户端装置与服务器之间的延迟就越高。

例如，由于音频编码的计算密集程度小于视频编码，所以可以使用软件AAC编码器。此外，为了向服务器递送低延迟视频，可能需要使用硬件H.264编码器。对于基于硬件的H.264编码器存在各种选项。一个选项是使用单独的附加卡或外部装置。这些选项对于在服务器端解码是很好的，但是从客户端的角度来看，这些选项可能有问题，为了便于传输希望客户端为移动的形态因素。另一个选项是使用处理器或母板的内置功能-该方法消除了仅为编码和/或解码提供单独硬件的需要。例如，快速同步视频可以用于在客户端装置上对H.264视频进行编码，并且是内置在许多Intel处理器上的图形部件中的技术。在这点上，不再需要单独的硬件产品来处理客户端装置上的H.264编码，而是快速同步视频可以与英特尔处理器结合起来使用，以在没有任何附加硬件的情况下实现H.264编码。因此，单个设备就可以用于处理和编码/解码功能。

如上所述，消费者(在上面讨论的生产者/消费者模型中)可以具有一个或多个缓冲器，CMC根据存储在包中的数据类型将接收的包置于该一个或多个缓冲器中。进一步地，在广播捆绑应用的环境中，消费者可以具有多个缓冲器，诸如视频缓冲器和音频缓冲器。

在一个实施例中，缓冲器(例如视频缓冲器和/或音频缓冲器)的大小可以是预定的。在替代实施例中，缓冲器的大小可以是动态的。例如，如上所述，在广播捆绑应用的消费者中，软件可以连续地或周期性地检查通过捆绑接收到(并且被CMC放置在音频或视频缓冲器中)的已编码的音频和视频数据，并且在该数据变得可用时，数据被解码。该已解码的数据又在SDI上播出。对已编码的视频数据进行深入探讨，在将该数据提供给H.264硬件解码器之后，解码器产生已解码的视频帧。这些视频帧是原始的未压缩视频帧，消耗着与客户端侧上的原始未压缩视频帧相同数量的字节。这样的帧在理论上适合于直接在SDI上回放，但是很可能的是，由于SDI回放硬件的要求，它们可能需要被转换为另一种像素格式。例如，快速同步视频解码成NV12像素格式，而一些SDI解决方案要求视频采用UYVY像素格式。可能需要颜色转换步骤以在两种像素格式之间转换。

一旦消费者具有处于可以通过SDI回放硬件发出的像素格式的单个视频帧，理论上，可以立即发送该帧用于回放。然而，这通常是不可取的。一旦回放开始，目的是视频和音频均应该在此时间点之后连续播放。回到59.94fps的广播标准视频帧速率，在播放第一视频帧之后，如果另一个视频帧大致在0.01668秒之后没有准备好播放，则这将不会产生流畅的视频。

而是，一个或多个缓冲器可以用于累积与视频相关联的帧。在一个实施例中，可以使用单独的缓冲器来累积准备好在SDI上回放的视频帧(和用于音频样本的另一个)。这些缓冲器与CMC将分包数据放入的音频和视频缓冲器是分离开。一旦足够大小的缓冲器已经被填充以准备好要回放的视频帧(或音频样本)，则可以开始回放。该缓冲器可以是循环缓冲器。更具体地，在回放开始后当新帧变得可用于回放时，使用FIFO方案将这些新帧插入到缓冲器中。

此外，在缓冲器中累积预定量的数据所需的时间称为初始缓冲时段。这个时间影响初始延迟。也就是说，如果缓冲器的大小使得回放仅在已经累积了X秒的媒体之后才开始，则初始延迟可以计算为X加上广播开销。与广播开销相关联的时间量是可变的。最可变的量是将数据从客户端装置发送到服务器所需的时间，因为在多个网络连接中网络条件可能不断波动。编码/解码开销也可能在较小程度上变化，这取决于视频的复杂性。

在一个实施例中，缓冲器的大小可以取决于数据流的传输的至少一个方面。在更具体的实施例中，缓冲器的大小可以基于广播开销(例如，基于广播开销的估计)。例如，缓冲器的大小可以基于广播开销和/或基于广播开销的变化。更具体地，如果网络条件通常是非常多变的，则可能选择更大的缓冲器大小以具有足够的“缓冲器”是合理的。

存在不同的方法可用于评估网络条件，作为确定广播开销的手段，因为如前所述，广播开销的最多变的方面是捆绑。一种方法是使用先前讨论的预先测试连接阶段，以便建立各个网络连接执行的良好程度。在收集该数据之后，客户端装置上的广播应用可以具有足够的信息来确定理想的缓冲器大小应该是多少。预先测试连接阶段的一个方面是确定在预先测试连接阶段中发送的每个单独包需要多长时间才能被服务器实时接收。可以基于最差结果来选择缓冲器大小。例如，如果向服务器发送包X比任何其他包花费更长的时间，则客户端装置可以利用该持续时间，将其添加到用于编码和解码的开销量的估计中，并且计算考虑了这一点的理想缓冲器大小。

或者，在广播会话期间，在网络条件可能显著改变的情况下，例如当客户端装置是移动的(例如，客户端装置在移动车辆内部)时，尝试动态地确定理想缓冲器大小可能产生不一致的结果。例如，如果客户端在广播期间处于移动的车辆中，则随着不同的移动宽带网络进入和移出范围，网络条件可能不断变化。当网络条件非常好时，可以完整地完成缓冲器大小的自动确定，并且这可能导致对于整个广播来说太小的缓冲器大小。在这种环境中，优选的可能是预先选择出相对高的固定量的缓冲器大小，以便具有足够大的“缓冲器”来适应非常多变的网络质量。

例如，如果缓冲器大小是两秒，这意味着在消费者已经累积了两秒的原始媒体(初始缓冲时段)之后，将开始回放。如果准备好回放的原始媒体继续以与在初始缓冲时段期间被变得可用的速率相同的速率变得可用，则在广播期间应当没有问题，并且缓冲器应当在广播的存在期期间继续包含大约够放两秒的媒体。然而，如果速率减小，则在缓冲器中可用于回放的帧的数量将开始减少。虽然缓冲器的大小被调整成使得其可以累积够放两秒的媒体，但是它可以仅被填充以1.5秒的媒体。此后，由于网络条件恶化，缓冲器中的数据量可以减少到1秒、0.5秒，并且最终减少到0，因为帧被全部用尽而没有足够快地重新填充。如果缓冲区中的帧数下降到0，那么将出现如前所述的问题。在此示例中，如果缓冲器大小改为4秒，那么可能被填充得足以适应非常多变的网络条件。缓冲器在开始时可能具有4秒的媒体，在网络急剧变差时具有的媒体可能下降到2秒，然后当网络稳定时，具有的媒体爬升回到4秒。

从用户的角度来说，为缓冲器选择理想尺寸可能是具有挑战性的。用户不太可能具有足够的信息和专业技术能在开始广播之前估计广播开销。一种方法是使用足够大的缓冲器大小，以便适应大多数潜在的广播开销情况。也许缓冲区大小为5秒就足够了。在这种情况下，如果例如广播开销为1.5秒，则这转换成初始延迟为6.5秒(广播开销的1.5秒和填充缓冲器的5秒)。然而，从实时移除的广播越多，对于演播室来说使用广播技术来提示和管理远程记者就变得越困难。如果记者理应在特定时间出现在广播中(称为刚好开始(hit))，则为此，记者必须在刚好开始之前6.5秒由在台上的某人来提供提示信息，以便看起来好像记者正在“现场”报告。这需要电视台处的资源，该资源否则可以用于别的东西。在理论上，不管初始延迟如何，有人必须总是给记者提供提示信息。然而，如果初始延迟为2.5秒或更短，则记者可以通过电话(或其他解决方案，例如下面讨论的可中断式反馈(IFB))倾听实况广播，并且当记者听到他/她的提示时，即广播中紧邻刚好开始之前的时间点，记者开始行动。在技术上，在另外2.5秒或更少的时段中，台上不能够出现刚好开始的情况。因此，这导致广播中的短间隙；然而，对于TV广播的目的而言，该间隙可被认为是可接受的。更高的间隙可能被观察者注意到，并将受益于在台上的某个人精确的计时。

在替代实施例中，缓冲器的大小可以由用户配置-这种方法早先在移动车辆的上下文中被暗示过。在特定实施例中，用户可以直接配置缓冲器的大小。例如，可以在客户端装置的用户界面中向用户呈现允许输入特定缓冲器大小的文本框。例如，如果指定了2.5秒的缓冲器大小，这意味着当广播会话开始时，消费者(在这种情况下，在服务器上运行)将创建大小能存储至少2.5秒的视频帧的视频缓冲器帧和大小能存储至少2.5秒的音频数据的音频缓冲器。在替代的特定实施例中，用户可间接配置缓冲器的大小。如上所述，缓冲器的大小连同广播开销一起决定了媒体的重放中的初始延迟。不是在用户界面中指定缓冲器大小，而是用户可以指定延迟。作为响应，可能有必要发起训练会话(使用如前所述的预先测试连接阶段)以便估计广播开销。一旦确定了广播开销，这就提供了足够的信息来确定适当的缓冲器大小以匹配所请求的延迟。例如，如果用户选择4秒的延迟，并且广播开销被确定为1.5秒，则缓冲器应当被调整大小成存储2.5秒的媒体。

涉及使用训练会话(例如，使用先前描述的预先测试连接阶段)的调整原始媒体缓冲器的大小的任何方法意味着当用户发起广播时不能立即开始广播。执行训练会话、分析结果以及基于这些结果做出决定需要一定量的时间。相反，如果选择了固定的缓冲器大小，则一旦用户发起广播，则广播在技术上就已经开始。消费者将不发起媒体回放，直至缓冲器已经累积了如由固定缓冲器大小指定的足够多的媒体，但是一旦发生这种情况，累积的媒体等于缓冲器大小加上广播开销，如前所述，回放开始。因此，在某些情况下优选使用固定的缓冲器大小。

联网条件可以是非常多变的。当广播开始时，跨传送会话中的不同网络连接的网络条件可以是优秀的，从而容易地允许例如4Mbps编码视频流被发送到服务器。然而，五分钟后，情况可能由于多种原因而改变，并且现在，捆绑的网络连接的组合吞吐量只能满足1.5Mbps的编码视频流(除了传送编码音频和任何附加开销所需的数据)。例如，在移动宽带的情况下，运营商与五分钟之前的情况相比可能在网络上经历更多的使用(来自其他蜂窝客户)。蜂窝信号可能以某种方式波动。或者，可能存在因特网路由问题。无论如何，联网条件可能变化。

由于联网条件的易变性，可以动态地调整用于对媒体进行编码的比特率。例如，在一个实施例中，可以动态调整视频被编码(例如通过使用H.264编码器)的比特率。通常，以比视频低的比特率对音频进行编码。因此，动态比特率调整可以仅关注调整视频编码比特率。在替代实施例中，可以调整对音频进行编码的比特率。在另一替代实施例中，可以调整对视频和音频两者进行编码的比特率。

改变比特率会改变每个时间段的编码输出数据的量。一般情况下，当编码视频流的比特率下降时，编码视频流的质量也下降。另外，当编码视频流的比特率上升时，编码视频流的质量也上升，但是如果比特率增加超过某一点，则可感知质量将仅稍微上升或根本不上升。

一个实施例包括确定是否改变比特率(和/或改变了多少)。在更具体的实施例中，该确定可以由消费者单独执行。例如，当从客户端装置向服务器广播视频时，消费者可以基于消费者对视频的处理的至少一个方面(例如，将当前存储在缓冲器中的视频帧的数量与缓冲器中能够存储的视频帧的数量相比较)来请求对比特率的调整。消费者只能做出比特率调整请求，因为它是在客户端上运行的负责将视频编码的生产者。在替代的更具体的实施例中，该确定可以由生产者单独执行。例如，当从客户端装置向服务器广播视频时，生产者设备可以响应于由CMC通知传送会话中的网络连接之一有问题而决定修改比特率，如以下更详细讨论的那样。在另一个可替代的更具体的实施例中，该确定可以由生产者和消费者执行(例如，在一个实例中，生产者可以确定是否改变比特率，以及在另一个实例中，消费者可以确定是否改变比特率)。在这方面，这种确定(无论是由生产者、消费者还是由生产者和消费者二者做出的确定)可以指示何时比特率应该增加或减少以及增加或减少多少。

如上所述，改变比特率的一种方式是通过消费者控制的比特率调整请求进行。在从客户端装置向服务器广播的环境中，消费者可以控制比特率调整。如前所述，消费者维护准备好通过SDL播出的视频帧的循环缓冲器。在确定是否改变比特率以及改变多少时，消费者可以分析缓冲器的至少一个方面(诸如缓冲器的“健康状况“)。由于在客户端装置上运行的生产者正在广播的环境中执行编码，所以在服务器上运行的消费者可以向生产者通知比特率改变请求，以便实现比特率改变。

消费者可以分析缓冲器以生成缓冲器被填充了多少的指示。例如，缓冲器的大小可以被调整成使得它可以包含X个视频帧，并且缓冲器当前可以在其中存储了Y个视频帧。可以参考X来审查Y，以便生成缓冲器被填充了多少的指示。该审查可以为缓冲器产生不同类别的健康度(healthiness)。健康度的例子包括但不限于：

非常健康：(7/8)*X<Y

中等健康：

如果X≤120:(1/2)*X<Y≤(7/8)*X

如果X>120：(11/120)*X<Y≤(7/8)*X

如果值Y不符合上面定义的非常健康或中等健康的类别，则视频缓冲器可被认为是不健康的。上述公式仅用于说明。可以设想到用于评估缓冲器的状态的其他规则。

视频缓冲器还可经历各种水平的不健康度，下文将更详细地论述。缓冲器的健康度或不健康度的各种水平仅仅是为了说明的目的。可以设想到其它指示。

消费者可以根据缓冲器的健康度水平和/或根据当前比特率来请求比特率增量。例如，消费者可以只有在缓冲器的状态在足够量的时间内保持在健康类别中的时候才请求比特率增量。消费者等待的足够多的时间量可以取决于当前比特率。例如，当前比特率越高，消费者可以在比特率增量之间等待的时间量越长。在这方面，达到更高的比特率是更难的，因为当比特率增加时，缓冲器必须在健康状态中保持更长的时间段。这是设计造成的，因为与较高比特率相关联的风险更多。在一个实施例中，消费者可以不请求超过某一执行定义的最大比特率的比特率增量。

在一个实施例中，最大比特率是静态的。在替代实施例中，最大比特率是变化的。例如，最大比特率可以根据传送会话中的活动连接(例如，发送实际数据而不是测试模式包的连接)的数量而改变。更具体地，如果仅存在单个活动连接传送数据，则可以将最大比特率设置为相当低的值，以确保单个连接能够发送视频和音频数据。对于两个连接，最大比特率可以提高一个比特，然后对于三个连接再提高一个比特，并且可以最终在四个或更多个连接处达到最大量。如果当前比特率当前被设置为最大比特率，则不可以请求另外的比特率增量。

如果在比特率增量之间的可变时间段结束时，缓冲器处于非常健康的状态(并且在该时间段的持续时间期间也保持在任一健康类别中)，则消费者可以请求生产者增大比特率。

在一个实施例中，比特率增量可以是预定的和静态的。在替代实施例中，所请求的比特率增量可以是可变的。更具体地，比特率增量可以取决于当前比特率。例如，如果当前比特率相对较低，则所请求的比特率增量可以成比例地大于如果当前比特率相对较高的情况。在一个实施例中，所使用的最低比特率是1Mbps，并且这是通常广播开始所采用的比特率。在另一实施例中，起始比特率可以大于1Mbps。如上所述，训练会话(例如，通过使用预先测试连接阶段)可以用于自动计算缓冲器大小。该训练会话也可以用于将起始比特率设置成大于1Mbps的速率，导致从广播开始的质量比利用1Mbps比特率可能实现的质量更高。

然而，如果在可变时间段结束时缓冲器处于中等健康类别，则不可以请求比特率增量。相反，它将复位定时器并在预定时间段期间重新开始检查缓冲器的健康状况。在一个实施例中，预定时间段保持相同。在替代实施例中，预定时间段可以增加到比先前在时间段中使用的值更高的值。

如果缓冲器的状态已经下降到不健康类别中，则在一个实施例中，消费者可以立即请求比特率减量，除非比特率已经处于其最低允许的值(在一个实施方式中1Mbps是最低比特速率)。或者，响应于缓冲器在预定时间量内一直处于不健康类别中，请求比特率减量。

在一个实施例中，比特率的减量可以是预定的和固定的。在替代实施例中，比特率的减量可以是可变的。比特率的减量的变化量可以取决于一个或多个因素，诸如缓冲器的大小和/或活动连接的数量。例如，如果缓冲器大小相对较小(例如，小于够放2.5秒的媒体)，则比特率可以降低到最低的允许值。对于相对较小的缓冲器大小，在一半缓冲器已经耗尽之后，缓冲器中剩余很少的时间，并且将比特率降低到其最低可能值以使缓冲器具有最佳恢复机会是更安全的。如果缓冲器大小不是相对较小的，则比特率可以递减到在最大比特率到最小比特率的范围内的固定值。例如，如果当前比特率大于或等于3Mbps，则比特率可以降低到2.5Mbps。如果大于或等于2.75Mbps(并且小于3Mbps)，则比特率可以降低到2.25Mbps。逐步递减方法可以进一步向下延伸。

另外，如果活动连接的数量降至特定数量的连接(例如四个连接)以下，则这可能导致新的最大比特率(如前所述)，这可能需要取决于当前比特率的即刻比特率下降。在这点上，可以基于一个或多个准则(例如缓冲器的健康度和/或活动连接的数量)来确定比特率。

如果消费者请求生产者改变比特率，则在此时间点之后，消费者将不会请求任何进一步的比特率调整，直至生产者已经改变比特率并且将此比特率改变通知服务器。

如上所述，对是否要改变比特率的确定可以由生产者确定。例如，在从客户端装置向服务器广播的示例中，生成器可以基于连接的至少一个方面的改变和/或基于多个连接的至少一个方面的改变来调整比特率。更具体地，生产者可以响应于连接的某些预定事件，例如：连接已经终止和/或连接已经进入测试模式，来调整比特率。在替代实施例中，生产者可以分析跨多个网络连接的数据传送会话(例如作为整体的数据传送)，以便确定是否调整比特率(例如降低比特率)。

在更具体的实施例中，响应于生产者确定捆绑的网络连接的总吞吐量在减少，生产者可以发起比特率改变。吞吐量的分析可以由生产者多次执行，第一次分析用于确定第一聚合吞吐量，第二次分析用于确定第二聚合吞吐量。然后，生产者可以将第一吞吐量与第二吞吐量进行比较，以便确定吞吐量是否在减少。并且，响应于确定吞吐量正在减少(例如减少超过预定量)，生产者可以发起比特率减量。如上所述，比特率的减小可以是静态的或者可以是动态的。作为一个示例，可以预先确定比特率的减小，而与吞吐量的减少量无关。在另一实施例中，可以基于吞吐量的减少量来动态地确定比特率的减小。在这方面，不是等待消费者指示生产者降低比特率，而是消费者可以主动地这样做。

CMC可以向广播捆绑应用通知连接状态的改变(例如，终止或进入测试模式)以及在传送会话中剩余的活动连接的数量。这可以在客户端装置或服务器上或两者上发生。

在一个实施例中，由生产者确定的比特率的变化量可以是预定的和固定的。在替代实施例中，比特率的变化量(例如，减量)可以是可变的。在一个方面，改变量可以取决于活动连接的数量和/或问题连接的最近非零吞吐量的值(在触发比特率改变的丢弃连接的示例中，比特率的改变量可以等于连接的最近非零吞吐量)。例如，如果，作为丢弃连接的结果，在传送会话中剩下少于四个的活动连接，则比特率可以立即下降，使得减少的量等于用于被丢弃的连接的最近的吞吐量值，尽管比特率不可以下降到最小比特率以下。

不管比特率变化的起源(例如，生产者或消费者)是什么，由于生产者正在对视频进行编码，所以它负责应用比特率改变。为此，生产者排空(drain)使用当前比特率编码的已编码视频帧的编码器。当排空操作正在进行时，不可以向编码器添加新的原始视频帧。一旦排空操作完成，在编码器中设置新的比特率，并且原始帧继续被传递到编码器用于编码。由于在排空操作期间新的帧不可以被传递到编码器，这稍微降低了在排空操作发生时的编码器效率，并且新的帧将简单地累积在生产者的缓冲器中直到排空操作完成。因此，明智的做法是最小化在相对短的时间段期间发起的比特率改变的数量。如果编码器花费在排空上的时间比对帧进行编码的时间多，则这将对广播会话带来负面影响。

图15-图17示出了确定是否和/或如何改变比特率的不同方式。图15示出了广播消费者的流程图1500。广播消费者可以分析传送会话和/或其自己的内部数据的多个方面，以确定是否调整编码媒体的比特率。在1502，消费者分析传送会话和/或广播处理的至少一个方面。在1504，基于该分析，确定是否修改比特率。如果否，则流程图1500返回到1502。如果是，则在1506，确定比特率改变。在1508，向生产者通知所确定的比特率改变。在1510，在适当的情况下，生产者调整比特率。在广播应用的环境中，该步骤可以发生在客户端装置上，而先前的步骤可以发生在服务器上。最后，流程图返回到1502，并且该过程在整个广播会话期间持续进行。

图16示出了用于广播消费者分析其视频缓冲器的健康状况以便确定是否调整比特率的流程图1600的一个示例。该流程图中的所有步骤是从消费者的角度执行。在1602，相对于可存储在视频缓冲器中的视频帧的总数(X)分析视频缓冲器中可用的视频帧的当前数目(Y)。基于该分析，在1604，确定视频缓冲器的状态是否健康。如果是，则在1606，健康度时间量的指示符增加1。进一步地，在1608，基于当前比特率，确定在增加比特率之前所需的健康度持续时间。在1610，确定来自1606的指示符是否大于增加比特率之前所需的健康度的时间量。如果否，则流程图循环回到1602。如果是，则在1612，确定缓冲器的状态是否非常健康(有别于如前所述的中度健康)。如果不是，则流程图返回到1602。如果是，则在1614，基于当前比特率确定增加比特率的量。在1618，通知生产者比特率改变。然后，在1620，消费者等待生产者应用或忽略比特率改变请求。流程图然后返回到1602。在消费者也已经在大约相同的时间发起相互冲突的比特率改变的情况下，消费者可以忽略比特率改变请求。如前所述，消费者也可以发起比特率改变。消费者发起的比特率改变通常可以优先于来自生产者的比特率改变请求。

如果相反，在1604，确定缓冲器的状态不健全，则在1616，基于当前比特率确定减小比特率的量。然后，进行到1618，并从那里进行下去，如已经描述的。

图17示出了生成器基于来自CMC关于网络连接的状态的通知潜在地使带外比特率递减的流程图1700。该流程图中的所有步骤从生产者的角度执行。在1702，生产者接收到来自CMC的通告(notice)：至少一个网络连接存在问题。在1704，生产者确定剩余的可行网络连接的聚合健康状况是否需要比特率降低。如果不是，流程结束。如果是，则在1706，基于分析立即减小比特率。在1708，向消费者通知带外比特率改变，即消费者未请求的比特率改变。此时，流程结束。

如上所述，消费者中的视频缓冲器的状态可触发比特率的改变。例如，缓冲器的健康状态可以导致比特率的增加，而缓冲器的不健康状态可能导致比特率的降低。另外，可以利用依赖于缓冲器的状态的其他各种技术，特别是在缓冲器处于不健康状态时。图18示出了用于对付不健康的媒体缓冲器以便使媒体缓冲器回到健康状态的一些技术的框图1800。这样的技术被描述为由广播消费者1802执行，但是一些技术可能需要来自消费者的参与(例如，改变比特率)。用于对付不健康的视频缓冲器的技术1804的示例包括但不限于以下：递减比特率1806；继续前进(move-on)技术1808；重新调整视频大小1810；降低帧速率1812；以及增加延迟1814。另外，即使之前没有详细描述，音频缓冲器也可能进入不健康状态。在音频缓冲器处于不健康状态的情况下，还存在可用于改善其健康状况的一些技术1816。这样的技术的示例包括但不限于以下：递减比特率1818；继续前进技术(用于音频)1820；和丢弃音频1822。这些技术中的每一个将在下面更详细地讨论。

已经详细描述了作为用于对付不健康的视频缓冲器的方法的递减比特率技术。这可能是对付不健康的视频缓冲器的主要技术。类似的技术可以用于音频并且将类似地工作。然而，由于音频比特率在开始时可能非常低(例如，128kbps)，所以可能从中获益很少。

重新调整视频大小的技术可以在比特率减量不够，甚至下降到最小视频比特率(例如1Mbps)的情况下使用。如果传送会话中的不同网络连接的聚合健康状况甚至不足以处理最小比特视频比特率，则消费者可以请求生产者重新调整视频帧的大小，以在对视频帧进行编码之前使用较小的帧尺寸。以这种方式重新调整视频帧的大小降低了图像质量，因为像素数据由于重新调整大小的操作而丢失。然而，这种重新调整大小过的视频可以以比通常使用的最小比特率甚至更低的比特率来编码。不同网络连接的聚合健康状况可能足以适应这种减小的比特率。在消费者方面，在对重新调整大小的视频进行解码之后，所得到的帧被重新调整大小回到原始分辨率，因为预期广播将在SDI上输出与实际输入媒体所使用的视频格式相同的视频格式。由于原始重新调整大小操作而丢失的原始像素数据将不会由此操作恢复，尽管可能使用插补(interpolation)来估计因为重新调整大小操作的一部分而丢失的像素数据。此外，如果网络连接的聚合健康状况改善，则消费者可以注意到这一点并请求生产者恢复原始帧大小。重要的是注意到，对帧大小的改变通常将导致在应用改变之前需要排空H.264编码器。

重新调整视频大小的技术对于逐行视频是相对简单的，但是直接重新调整视频帧的大小对于隔行视频将不能正常工作。通常，在重新调整大小之前，隔行视频必须首先被去隔行。或者，可独立地考虑隔行帧的顶场或底场，且可将单独场视为重新调整大小操作的目标而不必去隔行。在消费者方面，除了不得不重新调整视频的大小以使其恢复到原始帧大小之外，还可能需要去隔行。

重要的是要注意，像重新调整视频大小的技术增加了广播开销，因为它代表了生产者和消费者都需要执行的额外的步骤，并且这需要时间。如果需要去隔行，这进一步增加了广播开销。

较低帧速率技术还可在比特率减量不足，甚至下降到最小视频比特率(例如，1Mbps)的情况下使用。如果传送会话中的不同网络连接的聚合健康状况甚至不足以处理最小比特视频比特率，则较低帧速率技术可能是一个好的选择，并且可以使用这种技术而不增加广播开销，与重新调整视频大小的技术的情况不同。

对于逐行视频，修改视频被编码的帧速率是很容易的。例如，将帧速率减半意味着每隔一个的帧应该被丢弃。不需要为此执行特殊的分析。每当将帧速率除以整数(2、3、4等)时，帧速率转换是很容易应用的(例如，如果除以3，则保留一个帧并丢弃接下来的两个帧，并且重复该循环)。然而，如果H.264编码器被配置为使用这个新的帧速率，而不是与输入媒体相关联的原始帧速率，并且利用与原始帧速率所使用的相同的比特速率方案，则H.264编码器将简单地将更多细节装入到每个帧中，以满足所请求的比特率。例如，如果H.264编码器已经被配置为用于1Mbps的720p59.94，并且它改成以1Mbps的720p29.97被配置，则它仍然会生成1Mbps视频流，但会变成将更多的细节装入每个编码帧中。相反，所需要的是将H.264编码器配置为使用.5Mbps的720p29.97或将H.264编码器配置成使用1Mbps的720p59.94，但以正常速率的一半为它馈送帧。在后一种情况下，将仅将细节装入到每个编码帧中，就好像帧速率是59.94fps一样，即使编码器仅仅每隔一帧地被馈送以。以这种方式使用，编码器有效地生成它正常将生成的一半的数据。因此，例如，在1Mbps的起始比特率，视频流的实际数据量更接近0.5Mbps。

当有效帧速率降低时，帧不会那么快速地被从消费者视频缓冲器中移除。这使得缓冲器更可能在网络连接不良的情况下恢复。在视频质量方面，29.97fps通常对于新闻节目是足够的；然而，该质量可能不适合于某些类型的电视广播。在一个实施例中，硬件解码器可以提供允许在解码时智能重构丢失帧的特征，这将使得可以回到59.94fps帧速率。

此外，在隔行视频的情况下，帧速率的降低与如上所述的帧速率修改不同。相反，在将帧速率减半的情况下，用于隔行视频的“半帧速率”技术可包括仅将顶场编码为逐行视频，类似于先前讨论的用于重新调整隔行视频的大小的方法之一。例如，对于1080i59.94，每1/29.97秒递送一个隔行视频帧(使得每秒有29.97个隔行视频帧)。1080i帧中的顶场在与底场不同的时间段被捕获，此时场速率为每秒59.94个场。因此，1080i59.94中的“59.94”对应于场速率，而不与逐行视频的情况一样对应于帧速率。因此，如果仅考虑两个场中的一个并且仅考虑这个场，则所得到的帧可以被视为逐行帧，并且被编码为逐行的(诸如使用H.264编码器编码，该编码器对逐行视频进行编码比对隔行视频进行编码更擅长)。在消费者方面，消费者将视频解码为逐行视频，并通过将顶场的内容复制到隔行帧的底场来重新组装隔行帧。这样，原始视频模式被保持，而仅仅一半的数据被编码。在这种情况下，一半的视频数据丢失，导致质量的降低；然而，该降低可能对观看者不明显。

直到此时，已经在对付不健康缓冲器的上下文中讨论了重新调整视频大小和较低帧速率技术。然而，这些技术中的任一个或两者可以从广播会话起点被应用并且被配置为由使用者这样做。例如，使用者可以选择打开“半帧速率”模式，这可以是在客户端装置处于移动车辆中的情况或者在预期联网条件非常多变的任意情况中的好的选择。用户还可以配置广播会话以将所有视频的大小重新调整为大约1/2的帧大小或1/4的帧大小，这分别导致像素计数为原始像素计数的1/4或1/16。在这种配置中，这些技术不是动态应用的，而是始终应用的。

用于改善不健康视频缓冲器的另一技术包括“继续前进”技术。有时，准备好在SDI上播放的视频帧的循环缓冲器可能落入不健康状态，如先前所讨论的。这可以导致被发送给生产者的立即比特率减量请求；然而，重要的是要注意这只是请求。生产者需要一些时间进行比特率改变，然后通知消费者改变已经发生。缓冲器中的帧数可能继续下降。重要的是，如前所述，缓冲器中的帧的数目不会下降到0，即使该帧的数目有可能下降到零。响应于缓冲器的某些预定条件，“继续前进”技术可用于减少发生这种情况的可能性。

以下是“继续前进”技术的示例。通过使用捆绑，数据包可能不按顺序到达。例如，视频包1和3-10可能已经到达缓冲器，但缓冲器丢失了包2。消费者读取包1中的数据，但是随后停止前进，因为包2尚未被接收。如果应用“继续前进”技术，则广播应用可能跳过包2并继续处理包3，从而允许该应用前进。包2可包含重要数据，但是正在使用的H.264解码器可能在一定程度上能复原的并且可以处理一些数据丢失。但是，使用此技术可能会产生一些在SDI上播放时的乱码视频。因此，该技术仅仅用在准备好要播放的帧的数目降低到某个阈值以下的情况中，如下所述(使用如前所述的量X和Y)：

“继续前进”技术准则：

如果X<110：Y≤(X*2)/5

如果X≥110：Y≤44

上述公式仅用于说明。可以设想到用于触发“继续前进”技术的其他规则。

在一个实施例中，“继续前进”””技术可以仅在单个包与在其之后立即接收的另一个包存在间隙时应用。如果两个或更多个连续包丢失，则该技术将不被应用。在替代实施例中，如果存在多于一个包的间隙，例如两个包的间隙，则应用“继续前进”技术。

此外，在一个实施例中，广播应用可跳过丢失的包，如上所述。在替代实施例中，广播应用可以插入重复包，诸如紧接在丢失包之前的包或紧接在丢失包之后的包。在上面丢失包2的示例中，包1或包3的内容可以被复制并插入到缓冲器中用于包2的位置。

上面讨论的“继续前进”技术针对视频。类似的“继续前进”技术也可以应用于音频。在一个实施例中，如果可用音频样本的数量低于执行定义的阈值，并且仅存在丢失的一个音频包的间隙，则将应用用于音频的“继续前进”技术，并且该包将被跳过。因为全部样本可以被封装在音频包中，当这样做时，一些音频将简单地被丢失，但是除非这种技术被非常频繁地应用，否则观看者不太可能察觉到。在替代实施例中，如果可用音频样本的数量低于执行定义的阈值，并且存在丢失的多于一个音频包(例如两个音频包)的间隙，则用于音频的“继续前进”技术将被应用，并且这些包将被跳过。

用于克服不健康视频缓冲器的另一技术包括添加延迟技术。在一个实施例中，确定是否应用添加延迟技术的触发器可以基于对缓冲器的分析。在一个实施例中，对缓冲器的分析可以在单个时间点进行。例如，如果缓冲器的当前状态非常不健康，则可以应用添加延迟技术。在替代实施例中，对缓冲器的分析可以在不同的时间点进行。例如，对缓冲器的分析可以推断缓冲器的健康状况正在恶化。更具体地，如果可用于播放的帧的数量继续下降，则可能需要在SDL上的视频回放中添加一些延迟。即，代替立即播放循环缓冲器中的下一帧，广播应用可以将该帧推迟使得在所播放的最后一帧与该帧之间存在2、3或4个帧的间隙。在此间隙期间，屏幕不刷新，并且之前的帧保留在屏幕上。这具有的效果是与客户端相比将服务器从实时推迟得更多，使得延时增加。取决于需要添加多少延迟，这对于观看者而言可能是明显的或不明显的。此外，音频被推迟相同的量，以确保视频和音频保持同步。添加延迟技术可以按如下这样应用：

添加延迟技术准则：

如果X<110:Y≤(X/5)

如果X≥110:Y≤20

上述公式仅用于说明。可以设想到用于触发添加延迟技术的其他规则。

进一步地，在一个实施例中，响应于确定使用添加延迟技术，广播应用可以将其推迟，使得在所播放的最后一帧与该帧之间存在预定数量的帧的间隙。预定数量例如可以是2或4帧。在替代实施例中，响应于确定使用添加延迟技术，广播应用可以首先确定帧的数量，以在所播放的最后一帧与该帧之间生成间隙。确定的帧的数量可以基于缓冲器的健康状态(诸如在单个时间点的缓冲器的状态或者跨越多个时间点的缓冲器的状态)。缓冲器越不健康，可能产生越大的间隙。

另外，在一个实施例中，一旦确定了帧的数量(无论是预定的还是可变的)，广播应用可以将视频一次性推迟此数量的帧。例如，如果所确定的帧的数量是4，则视频可以被一次性推迟所有4个帧。在替代实施例中，一旦确定了帧的数量，广播应用可以逐渐推迟视频。逐渐推迟帧对于观看者来说可能不太明显。

即使在请求比特率被降低、应用“继续前进”技术并且添加延迟或使用其它技术之后，消费者仍然不可能防止缓冲器被完全耗尽。在缓冲器中没有剩余帧的情况下，现在是播放下一帧的时间，在这种情况下消费者能做的事情微乎其微。为了发生这种情况，网络连接的质量可能非常差和/或网络连接的组合吞吐量将不足以发送视频和音频流。

当这种情况发生时，消费者可以简单地保持在显示器中播放的最后一帧(即，回放将被冻结)。一旦下一帧变得可用，可以将该帧推迟足够的量，以便累积缓冲器能容放的帧。立即播放这个帧没有什么意义，因为在该帧之后的帧应该被播放的时候，另一个帧不太可能准备好，这将需要添加更多的延迟。也必须重新计算延时，取决于自从最后一帧播放以来已经经过的时间，延时可能是显著的。

在广播捆绑应用中，音频和视频数据均被发送。在一个实施例中，音频和视频数据没有被交叉存取在相同的包中。存在单独的音频流数据包和视频流数据包。当服务器上的CMC接收到音频包时，它被添加在消费者的仅音频循环缓冲器中的适当位置。相同的方法用于视频包。另外，在消费者中可以存在用于处理音频和视频的单独的软件线程，这些软件线程分别用于将数据解码为原始音频样本和原始视频帧，该原始音频样本和原始视频帧分别被添加到准备通过SDI播放的各自的循环缓冲器(用于视频的循环缓冲器如上所述；用于音频的循环缓冲器以类似的方式工作)。另外，与音频样本相关联的时间跨度可以不同于与视频帧相关联的时间跨度。每个视频帧应该播放相同的时间量，因为帧速率是恒定的。相反，音频样本由许多不同的音频“帧”组成，并且音频样本中的“帧”的数量可以变化。此外，与视频不同，音频可能不一定在客户端上连续采样。因此，在音频样本之间可能存在非常短的间隙，在该间隙期间不会播放音频。然而，不管所有这些，第一音频样本都要被保证与第一视频帧同时开始。

根据上述信息，在消费者中在累积了准备好通过SDI播放的音频样本和视频帧的足够的缓冲之后，消费者将向SDI回放硬件发出命令以同时开始视频和音频回放。可以以相同的速率回放后续视频帧，并且可以基于每个样本的开始时间来调度后续音频样本。理论上，这应该足以确保音频和视频保持同步。

如前所述，在使用添加延迟技术的情况下，音频也被推迟与帧推迟相关联的等效时间量，以便确保音频/视频同步。

消费者假定在准备好要回放的视频帧之间没有间隙。也就是说，如果要播放的下两个视频帧是帧1和帧2，当最初在客户端装置上被捕获时，它们也将是连续的帧。然而，可能不总是这样。在59.94fps的广播标准帧速率下，这意味着应该每0.01668秒从视频输入源接收到新的帧。也就是说，在每个视频帧之间存在0.01668秒的间隙。但是，可能存在某些情况使得在客户端装置上的帧抓取过程暂时减慢，导致在帧1和下一个帧之间有5个帧(或0.0834秒)的间隙，该下一个帧在技术上为帧7，但是可能看起来像是下一帧。如果消费者没有被告知这一点，它将把帧7当作帧2播放，并且如果这种事情在广播期间发生了足够多的次数，视频将变得与音频不同步(视频将在音频之前播放)，因为音频样本总是使用样本的开始时间来播放的，而视频帧是被连续播放的。生产者通过将当前帧的时间戳与其接收的最后帧的时间戳进行比较来检测这种情况，并且如果时间戳大于在给定帧速率的情况下应该使用的时间间隙，则生产者可通知消费者在适当位置处存在视频帧间隙。当消费者注意到这一点时，在它到达帧7的时间点(或者更确切地说，在该示例中它认为是帧2)，消费者将调度帧以不是立即播放，而是利用五个帧间隙。因此，帧1将出现总共六个帧的长度。在这方面，视频将暂时冻结；然而，如果丢失帧的数量相对较低，则可能不明显。

图19示出了用于同步音频和视频回放以及用于视频回放的两个并发的流程图1900。两个流程图通常将同时操作，可能在不同的软件线程上进行。每个流程图中的所有步骤是从消费者的角度执行的。在第一流程图中，在1902，消费者连续地在音频缓冲器中累积音频样本，并且在视频缓冲器中累积视频帧。在1904，它检查音频/视频回放是否已经开始。如果是，则流程图返回到1902。如果不是(如最初开始广播会话时的情况)，在1906，它检查是否有足够的缓冲器样本开始回放。如果否，则流程图返回到1902。如果是(这意味着已经累积了所请求的缓冲器大小能容放的媒体，如前所述)，则在1908，它向回放硬件发送命令以同时开始视频和音频回放。最后，它返回到1902。

在这一点上，在第一流程图为了将准备好回放的原始媒体连续累积在音频和视频缓冲器中而继续操作的同时，第二流程图可以开始。在第二流程图中，在1910，检查视频帧是否可用于回放。如果不是，流程结束。如果是，则在1912，检查是否需要使用添加延迟技术。如果是，则在1914，将视频帧调度推迟足够的量。也将音频样本调度推迟相同的量。然后进行到1916。在1912处没有使用延迟技术的情况下，也进行到1916。在1916，确定是否接收到帧间隙命令。如果是，则在1918，将视频帧调度推迟足够的量。然后进行到1920。在1916处没有接收到帧间隙命令的情况下，也进行到1920。最后，在1920，对视频帧进行调度以供回放并终止。该流程被期望重复多次，但是通常对每个帧的调度被认为是单独的过程，因此这就是为什么不连续地循环图19中的第二流程图。

如上所述，诸如广播的捆绑应用提供以下部件以便与捆绑交互：发起者(例如，用在客户端系统上以发起与服务器的广播会话)；接收者(例如，用在服务器系统上，与客户端系统上的发起者结合使用以建立广播会话)。此外，还可以提供一个或多个生产者和消费者。

以下可包括生产者/消费者组合：

数据流方向：客户端装置到服务器：客户端装置上的生产者，用于生成音频和视频包，并使音频和视频包可用于捆绑层以发送到服务器。此外，生产者可以用于有限数量的特殊包(类似于用于通知消费者视频比特率改变的包)；服务器上的消费者，用于消费由客户端装置上的生产者发送的音频和视频

数据流方向：服务器到客户端装置：服务器上的生产者，用于偶尔的返回向客户端的通信，例如请求比特率改变所需的通信；以及客户端装置上的消费者，用于消费反向信道通信。

存在两种不同类型的数据包用于广播：音频包和视频包。音频包可以包括一个或多个编码音频样本。每个音频样本包括其时间戳(例如，开始时间)、持续时间、大小和编码的音频数据。因为音频比特率可以固定为128kbps，多于一个的音频样本可以容纳进单个音频包内，尽管在音频包中几乎总是有一些未使用的空间。默认情况下，每个数据包只能保存1370字节的数据。如果有五个音频样本准备好被“分包”，并且每个音频样本占用300字节，则前四个样本可以完全容纳进单个包内。由于最后一个样本不能容纳进剩余空间中，所以它的一部分或全部可以被放置在下一个音频包中。

与音频包不同，视频包仅包括经编码的视频数据。例如，视频包可以仅仅包括来自H.264流的数据。尽管单个编码帧可能完全容纳进单个数据包中，但是这是不太可能的，特别是当比特率增加时。因为仅发送H.264流，所以在视频包中留下任何间隙都是低效的。如果通过从当前编码视频帧提取字节没有完全填满视频包，则在用来自下一个编码视频帧的足够多的数据将该视频包填满之前，该视频包不会被传递到捆绑。

例如，编码视频帧的数据是5500字节，并且用于下一个编码视频帧的数据是6500字节。第一批5480个字节将被分布在四个数据包中并传递到CMC，剩余的20个字节将存储在第六个数据包中。当它移动到下一个编码视频帧时，它将从该帧提取第一批1350个字节，将这些字节复制到第六个数据包的剩余1350字节中，并将该包传递到捆绑层。

广播应用可以跟踪与其已经发送的音频包和视频包相关联的总时间，并且在两者之间交替，以便使捆绑的数据流在时间上保持平衡。无论如何，由于最小视频比特率可以是1Mbps，并且用于音频的固定比特率可以是128kbps(.128Mbps)，因此发送的视频数据包将比音频数据包多得多。

如上所述，数据可以从客户端装置发送到服务器，从服务器发送到客户端装置，以及在客户端装置和服务器之间传输，如图4-图6所示。在广播环境中，大多数数据通常是从客户端装置发送到服务器的。在广播环境中可以存在其他实例，其中服务器上的生产者可以生成供客户端装置上的消费者消费的数据。例如，先前在具有2.5秒或更短的延时的环境中讨论了IFB。在广播环境中，记者通常可以通过蜂窝电话收听实况广播。然而，这意味着蜂窝电话正在使用中，并且如果在该时间期间进来了重要的电话呼叫，则记者可能不能接听该呼叫。优选地，广播软件隐式地提供对IFB的支持。代替记者必须呼入，记者可以激活广播应用的IFB特征，并且作为响应，广播应用将实况广播的音频从服务器流式传输到客户端装置，允许用户在使用客户端装置时收听(例如经由使用蓝牙连接到客户端系统的可拆卸入耳式接收器)。可以使用生产者/消费者组合来完成数据传输，其中生产者位于服务器上并且消费者位于客户端装置上。这将是除了用于标准广播数据传输的客户端上的生产者和服务器上的消费者之外的。

另外，IFB可以用于与在电台处的某人进行的双向音频通信(诸如在现场的记者与电视台处的生产者说话)。在该实施方式中，音频数据可以经由生产者/消费者组合发送。该音频数据将与关联于实际广播的音频数据相分离。

在替代实施例中，代替具有单向音频通信或双向音频通信或除了具有单向音频通信或双向音频通信之外，可以实现从服务器到客户端装置的返回视频馈送。这类似于IFB，除了不是简单地发送实况广播的音频，它可以发送视频(以及潜在地也可以发送音频)。这可以被认为与反向广播信道类似；然而，由于视频仅被记者观看，所以视频质量仅需要能够了解实况广播中发生了什么就足够了。

进一步地，如上所述，各种捆绑应用与捆绑一起被使用。一个这样的应用是文件传送。在一个实施例中，文件可以从客户端装置传送到服务器。在替代实施例中，文件可以从服务器传送到客户端。在另一个替换实施例中，文件可以同时从客户端装置传送到服务器，并从服务器传送到客户端。

文件传送的一个示例可以在广播环境中。该领域的记者可以生成视频，例如对一个人的采访。记者可能希望将视频传送到电视台，该视频将在实况广播期间播放。因此，在准备实况广播时，记者可以使用客户端装置将视频(以一个或多个文件的形式)传送到服务器。文件的传送可以使用捆绑逻辑来实现，通过多个网络接口(例如，多个捆绑的蜂窝卡)发送文件，从而导致更快的文件传送。此外，电视台处的用户可以登录到服务器(或者可以直接访问服务器)，以便确定传送的状况。

另一应用包括音频应用。在一个实施例中，音频应用可以将音频数据(例如音频数据的流或音频文件)从客户端传送到服务器。在替代实施例中，音频应用可以将音频数据从服务器传送到客户端装置。更具体地，客户端装置可以发送用于在无线电台广播的音频。在另一个替代实施例中，音频数据可以从客户端装置传送到服务器，并且从服务器传送到客户端装置。

客户端装置可以接收音频(或者如果客户端装置包括麦克风或其他换能器，则可以生成音频)。客户端装置可以将音频数据流传送到服务器(服务器可以使用音频数据，和/或可以将音频数据中继到无线电台以供使用)。客户端装置可以使用一个或多个网络接口来执行该传送。

在一个示例中，电台记者可以使用包括多个网络接口(例如多个移动宽带接口)的客户端装置与无线电台进行通信，并使用多个移动宽带接口来建立多个连接。除了去除视频处理能力(即，去除视频捆绑能力并维持音频捆绑能力)之外，该示例中的客户端装置可以类似于视频广播示例中的客户端装置。在另一示例中，无线电台可以使用服务器与电台记者通信，该服务器通过使用多个网络接口的多个连接将音频数据发送到客户端装置。在又一个示例中，捆绑可以使得能够在无线电台记者与无线电台之间进行双向音频通信，为了客户端装置将音频传送到服务器并且为了服务器将音频传送到客户端装置，该捆绑使用客户端装置上的多个网络接口。

又一个应用包括视频会议。视频可以从客户端装置发送到服务器(供服务器使用或供与服务器通信的装置使用)。类似地，视频可以从服务器发送到客户端装置。在这种情况下，存在两个生产者/消费者组合，其中视频从客户端/服务器和服务器/客户端发送。在这点上，上面概述的用于从客户端向服务器发送广播视频的过程可以应用于从客户端发送到服务器的视频的生产者/消费者组合。类似地，上面概述的用于从客户端向服务器发送广播视频的过程可以应用于从服务器发送到客户端的视频的生产者/消费者组合。例如，被归于上面讨论的生产者和消费者(在从客户端发送到服务器的广播视频的情况下)的各种比特率调整可以应用于客户端和服务器两者。更具体地，在客户端/服务器组合(其中客户端正在向服务器发送视频)中，归于生产者的功能可以被归咎于客户端，并且归于消费者的功能可以被归咎于服务器。在客户端/服务器组合中(其中客户端正在向服务器发送视频)，归于生产者的功能可以被归咎于服务器，并且归于消费者的功能可以被归咎于客户端。

进一步地，客户端装置可以包括可以向用户(在远离广播工作室的远程位置)提供相关信息的用户接口。可以从客户端装置输出(诸如显示在客户端装置的监视器上)的一条信息是延时的至少一个方面(例如，上面讨论的初始延时)。可以从客户端装置输出的另一条信息可以包括一个、一些或所有连接的连接状况。例如，连接状况可以包括特定网络连接是正在发送数据、处于测试模式还是断连的。可以从客户端装置输出的另一条信息可以包括视频传送、文件传送等的状况。例如，传送的状况可以包括已经从客户端装置传送到服务器的百分比。

此外，服务器(或与服务器通信的广播工作室处的计算机)可以包括用户接口，以向广播工作室的技术人员提供关于数据传送的相关信息。类似于客户端装置，服务器可以输出延时(例如，上面讨论的初始延时)、连接中的一个、一些或全部的连接状况和/或传送的状况的至少一个方面。

客户端装置可以进一步包括视频编辑功能，使记者能够编辑原始视频。之后，经编辑的视频文件可以通过使用捆绑被发送到服务器。在一个实施例中，客户端装置可以被配置为在不同模式之间切换，诸如视频编辑器模式(其中原始视频被编辑并保存到文件)和捆绑模式(其中可以使用捆绑将文件传送到服务器)。或者，在视频编辑器模式下，视频编辑器可访问捆绑库以便将编辑的视频传送到服务器。

图20示出了可编程为特定计算机系统2000的通用计算机系统2000，其可以代表本文所讨论的任何服务器或客户端装置。计算机系统2000可以包括一组指令2002的有序列表，该组指令可以被执行以使计算机系统2000执行本文公开的方法或基于计算机的功能中的任何一个或多个。计算机系统2000可以作为独立装置操作，或者可以例如通过使用网络2009连接到其他计算机系统或外围装置。

在联网部署中，计算机系统2000可以在服务器-客户端用户网络环境中作为服务器或作为客户端-用户计算机来操作，或者在对等(peer-to-peer)(或分布式)网络环境中作为对等计算机系统来操作。计算机系统2000还可以被实现为或并入各种装置，诸如能够执行指令组2002的个人计算机或移动计算装置，指令组2002指定要由该机器采取的动作，包括但不限于通过任何形式的浏览器访问互联网或网络。进一步地，所描述的每个系统可以包括子系统的任何集合，该子系统单独地或联合地执行一组或多组指令以执行一个或多个计算机功能。如上所述，指令可以表示为逻辑的形式。

计算机系统2000可以包括在用于传送信息的总线2010上的存储器2003。可操作成使计算机系统执行本文所述的任何动作或操作的代码可存储在存储器2003中。存储器2003可以是随机存取存储器、只读存储器、可编程存储器、硬盘驱动器或任何其它类型的易失性或非易失性存储器或存储装置。

计算机系统2000可以包括诸如如上所述的中央处理单元(CPU)和/或图形处理单元(GPU)的处理器2001。处理器2001可以包括一个或多个通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列、数字电路、光学电路、模拟电路，它们的组合或用于分析和处理数据的其他现在已知的或以后开发的装置。处理器2001可以执行指令集2002或其他软件程序，诸如用于实现逻辑功能的人工编程或计算机生成的代码。为了视听目的或其他数字处理目的(例如用于计算机处理的兼容性)，所描述的逻辑功能或任何系统元件可以将模拟数据源(诸如模拟电信号、音频信号或视频信号或其组合)处理和/或转换成数字数据源。

计算机系统2000还可以包括磁盘或光驱动单元2004。磁盘驱动单元2004可以包括其中可以放入一组或多组指令2002(例如软件)的计算机可读介质2005。此外，指令2002可以执行如本文所述的操作中的一个或多个。指令2002可以在由计算机系统2000执行期间完全或至少部分地驻留在存储器2003和/或处理器2008内。因此，数据库可以存储在存储器2003和/或磁盘单元2004中。

存储器2003和处理器2008还可以包括如上所述的计算机可读介质。“计算机可读介质”、“计算机可读存储介质”、“机器可读介质”、“传播信号介质”和/或“信号承载介质”可以包括：包括、存储、通信、传播或传输由指令可执行系统、设备或装置使用或与其结合使用的软件。机器可读介质可以选择性地是，但不限于：电子、磁、光学、电磁、红外或半导体系统、设备、装置或传播介质。

另外，计算机系统2000可以包括被配置为便于用户与系统2000的任何部件交互的输入装置2007，诸如键盘或鼠标。计算机系统2000可以进一步包括显示器，诸如液晶显示器(LCD)、阴极射线管(CRT)或适于传达信息的任何其它显示器。显示器可以用作便于用户看到处理器2001的功能的接口，或者具体地作为与存储在存储器2003或驱动单元2004中的软件之间的接口。如上所述，客户控制的装置可以包括显示器和输入装置，例如输入装置2007。

计算机系统2000可以包括使得能够经由通信网络2009进行通信的通信接口2008。网络2009可以包括有线网络、无线网络或其组合。如上所述，通信接口2008网络可以经由诸如802.11、802.17、802.20、WiMAX、802.15.4、蜂窝电话标准或其他通信标准这样的任何数量的通信标准来实现通信。仅仅因为列出这些标准中的一个并不意味着任何一个是优选的，因为任何数量的这些标准可能从未实际上在商业产品中被采用。

系统的不同方面的框图可以使用图20中公开的计算机功能来实现。此外，流程图可以使用由一个或多个处理器执行的计算机可读指令，以便实现所公开的功能。最后，显示器可以在I/O装置上输出。

本公开设想了一种计算机可读介质，其包括指令或者响应于传播信号来接收并执行指令，使得连接到网络的装置可以通过网络传送语音、视频、音频、图像或任何其他数据。此外，可以经由通信接口在网络上发送或接收指令。通信接口可以是处理器的一部分或者可以是单独的部件。通信接口可以以软件的形式创建或者可以是硬件形式的物理连接。通信接口可以被配置为与网络、外部介质、显示器或系统中的任何其它部件或其组合相连接。与网络的连接可以是物理连接，诸如有线以太网连接，或者可以如下讨论的那样以无线方式建立。在服务提供商服务器的情况下，服务提供商服务器可以通过通信接口与用户通信。

计算机可读介质可以是单个介质，或者计算机可读介质可以是单个介质或多个介质，例如集中式或分布式数据库，和/或相关联的缓存和服务器，其存储一个或多个指令组。术语“计算机可读介质”还可以包括能够存储、编码或携带指令组的任何介质，该指令组用于被处理器执行或可以使计算机系统执行本文公开的方法或操作中的任何一种或多种。

计算机可读介质可以包括固态存储器，例如存储卡或容纳一个或多个非易失性只读存储器的其他封装。计算机可读介质还可以是随机存取存储器或其它易失性可重写存储器。另外，计算机可读介质可以包括磁光介质或光学介质，诸如磁盘或磁带或其他存储设备，用于捕获载波信号，例如通过传输介质传输的信号。电子邮件的数字文件附件或其他自包含信息档案或档案集合可以被认为是可以是有形存储介质的分布介质。计算机可读介质优选地是有形的和非暂态的存储介质。因此，本公开可以被认为包括计算机可读介质或分布介质以及其中可以存储数据或指令的其他等同物和后继介质中的任何一个或多个。

可替换地或者作为补充，可构建专用硬件实施方案(例如专用集成电路、可编程逻辑阵列和其它硬件装置)以实施本文中所描述的方法中的一个或一个以上。可以包括各个实施例的设备和系统的应用可以广泛地包括各种电子和计算机系统。本文描述的一个或多个实施例可以使用两个或更多个特定互连的硬件模块或装置来实现功能，相关的控制和数据信号可以在这些模块之间传送和通过这些模块传送，或者作为专用集成电路的一部分。因此，本系统可以包括软件、固件和硬件实施方式。

本文所描述的方法可以由计算机系统可执行的软件程序来实现。进一步地，实施方式可以包括分布式处理、部件/对象分布式处理和并行处理。可替换地或作为补充，虚拟计算机系统处理可以被构造为实现如本文所述的方法或功能中的一个或多个。

尽管描述了可以在特定实施例中参考特定标准和协议来实现的部件和功能，但是部件和功能不限于这样的标准和协议。例如，用于因特网和其他分组交换网络传输(例如，TCP/IP，UDP/IP，HTML和HTTP)的标准代表现有技术的示例。这样的标准周期性地被具有基本上相同功能的更快或更有效的等同物所取代。因此，具有与本文公开的功能相同或相似的功能的替换标准和协议被认为是其等同物。

本文描述的图示旨在提供对各种实施例的结构的一般理解。这些图示并不旨在用作对利用本文所述的结构或方法的设备、处理器和系统的所有元件和特征的完整描述。在回顾本公开内容时，许多其他实施例对于本领域技术人员来说是显而易见的。可以利用其他实施例和从本公开推导出其他实施例，使得可以进行结构和逻辑替换和改变而不脱离本公开的范围。另外，这些图示仅是代表性的，并且可能不是按比例绘制的。图解内的某些比例可能被夸大，而其他比例可以被最小化。因此，本公开和附图被认为是说明性的而不是限制性的。

上述公开的主题被认为是说明性的，而不是限制性的，并且所附权利要求旨在覆盖落入本描述的真实精神和范围内的所有这样的修改、增强和其他实施例。因此，在法律允许的最大程度内，范围通过对所附权利要求及其等同物的最宽的可允许的解释来确定，并且不应受到前述详细描述的约束或限制。

Claims (26)

1.一种被配置成经由多个网络接口进行通信的设备，所述设备包括：

所述多个网络接口；

存储器，被配置成存储一个或多个数据流的至少一部分；以及

与所述多个网络接口和所述存储器通信的至少一个处理器，所述处理器被配置为：

对于所述多个网络接口中的每一个，建立与远程装置的相应网络连接；

将所述一个或多个数据流分包为多个包；

使用所述多个网络连接将所述多个包发送到所述远程装置；和

评估一个网络连接在发送所述包时相对于剩余的网络连接中的一个或多个连接的性能。

2.根据权利要求1所述的设备，其中，所述处理器被配置为：相对于所述剩余的网络连接的全部连接，评估所述一个网络连接的性能。

3.根据权利要求1所述的设备，其中，所述处理器被配置为：相对于所述剩余的网络连接中的一个或多个连接的第二准则，评估所述一个网络连接的第一准则。

4.根据权利要求3所述的设备，其中，所述第一准则包括确认检查；和其中所述第二准则是针对路由的至少一部分将包传送到所述远程装置的时间的指示，或者是确认针对所述路由的至少一部分从所述远程装置接收到所述包的指示。

5.根据权利要求4所述的设备，其中所述第二准则包括往返时间(RTT)；

其中所述处理器被配置为确定所述剩余的网络连接的中的一个或多个连接的平均RTT；和

其中所述处理器被配置成将其为所述一个网络连接传输的包的确认等待的时间量建立在所述剩余的网络连接中的一个或多个网络连接的平均RTT的基础上。

6.根据权利要求1所述的设备，其中，所述处理器进一步被配置成基于所述评估，停止使用所述一个网络连接来至少部分地传送所述多个包。

7.一种被配置成经由多个网络接口进行通信的设备，所述设备包括：

所述多个网络接口；

存储器，被配置成存储一个或多个数据流的至少一部分；以及

与所述多个网络接口和所述存储器通信的至少一个处理器，所述处理器被配置成：

对于所述多个网络接口中的每一个，建立与远程装置的相应网络连接；

将所述一个或多个数据流分包为多个包；

使用所述多个网络连接将所述多个包发送到所述远程装置；

评估一个网络连接在发送所述包时的性能；以及

响应于评估所述一个网络连接的性能，以测试模式操作所述一个网络连接。

8.根据权利要求7所述的设备，其中，所述处理器被配置成：通过向所述远程装置发送测试包来以所述测试模式操作所述一个网络连接；以及

其中所述处理器进一步被配置成评估所述测试包的传输。

9.根据权利要求8所述的设备，其中，所述处理器进一步被配置成：基于对所述测试包的传输的所述评估，确定是否停止以测试模式操作所述一个网络连接以及是否将来自用于传输的所述多个包的包改为分配给所述一个网络连接。

10.根据权利要求9所述的设备，其中，所述处理器被配置成：通过分析与所述测试包相关联的确认时间来评估所述测试包的传输。

11.根据权利要求9所述的设备，其中，所述处理器被配置成：通过分析与所述测试包相关联的往返时间(RTT)来评估所述测试包的传输。

12.根据权利要求7所述的设备，其中，所述处理器被配置成：相对于剩余的网络连接中的一个或多个连接的性能来评估所述一个网络连接的性能。

13.一种被配置成经由多个网络接口进行通信的设备，所述设备包括：

所述多个网络接口；

存储器，被配置成存储一个或多个数据流的至少一部分；以及

与所述多个网络接口和所述存储器通信的至少一个处理器，所述处理器被配置成：

接收将所述一个或多个数据流发送到远程装置的指示；

响应于接收到发送所述一个或多个数据流的所述指示：

为所述多个网络接口中的每一个建立与远程装置的相应网络连接；

将所述一个或多个数据流分包为多个包；以及

使用所述多个网络连接将所述多个包发送到所述远程装置，由此，包被分配给一个网络连接所使用的速率由所述一个网络连接先前发送的包被确认为已经被接收的情况下所使用的速率来确定。

14.根据权利要求13所述的设备，其中，所述多个网络连接中的每一个被分配给不超过预定数量的包；以及

其中，对于所述一个网络连接，当先前发送的包被确认为已经被接收到时，所述处理器被配置成将另一个包分配给所述一个网络连接。

15.根据权利要求14所述的设备，其中，所述多个网络连接中的每一个对于可以分配给它的所述预定数量的包使用相同的值。

16.根据权利要求14所述的装置，其中，响应于接收到发送所述一个或多个数据流的指示，所述处理器被配置成将包分配给所述多个网络连接而不必首先经历训练阶段。

17.一种被配置成确定是否指示比特率改变的设备，所述设备包括：

网络接口，被配置成从远程装置接收一个或多个包的流；

缓冲器，被配置成存储从所述一个或多个包的流导出的视频帧；和

与所述网络接口和所述缓冲器通信的至少一个处理器，所述处理器被配置成：

基于所述一个或多个包的流，导出所述视频帧；

将所述视频帧存储在所述缓冲器中；

分析所述缓冲器的充满度；

响应于所述分析，确定是否指示比特率改变；以及

响应于确定指示所述比特率改变，向所述远程装置发送对所述比特率改变的指示。

18.根据权利要求17所述的设备，其中，所述处理器被配置成通过分析存储在所述缓冲器中的视频帧的当前数量来分析所述缓冲器的充满度。

19.根据权利要求18所述的设备，其中所述处理器被配置成分析所述缓冲器的所述充满度以确定用于回放视频的所述缓冲器的健康度，所述健康度基于所述缓冲器中存储的帧的当前数量。

20.根据权利要求18所述的设备，其中所述处理器被配置成通过确定所述帧的当前数目是否小于预定量来分析所述缓冲器的充满度；和

其中所述处理器被配置成：响应于确定所述帧的当前数目小于所述预定量，指示降低比特率。

21.根据权利要求18所述的装置，其中，所述处理器被配置成：通过确定所述帧的当前数目是否小于动态确定的量来分析所述缓冲器的充满度；以及

其中所述处理器被配置成：响应于确定所述帧的当前数目小于所述动态确定的量，指示降低比特率。

22.根据权利要求18所述的设备，其中所述处理器被配置成通过确定所述帧的当前数目是否大于预定量来分析所述缓冲器的充满度；和

其中所述处理器被配置成：响应于确定所述帧的当前数目大于所述预定量而指示增加比特率。

23.根据权利要求18所述的设备，其中，所述处理器被配置成：通过确定所述帧的当前数目是否大于动态确定的量来分析所述缓冲器的充满度；以及

其中所述处理器被配置成：响应于确定所述帧的当前数目大于所述动态确定的量而指示增加比特速率。

24.根据权利要求18所述的设备，其中所述处理器被配置成：通过确定所述帧的当前数目是小于预定量并且大于另一预定量来分析所述缓冲器的充满度；和

其中所述处理器被配置成响应于该确定，保持比特速率不变。

25.根据权利要求18所述的设备，其中所述处理器被配置成通过确定所述帧的当前数目是否小于动态确定的量且大于另一动态确定的量来分析所述缓冲器的充满度；和

其中所述处理器被配置成：响应于该确定，保持比特速率不变。

26.根据权利要求17所述的设备，其中，使用所述比特率对接收到的所述一个或多个包的流进行编码。