用于流式数据的前向纠错的制作方法

本申请要求2016年8月1日提交的美国专利申请号15/235,508的优先权益处，所述申请的全部公开内容以引用方式并入本文。

本公开涉及通过网络进行的数据输送。具体地，本公开的各方面涉及用于在包交换网络中使用不可靠传输协议进行拥塞控制的系统和方法。

背景技术：

随着数字流服务和各种基于云的计算解决方案的日渐增加，在远程装置之间快速地且准确地传送大量数据的能力是一项重要任务。通过网络(诸如互联网、广域网(wan)或局域网(lan))的共享资源向目的地系统发送数字数据通常涉及将数据布置成可具有固定或可变长度的格式化块(其被称为包)。每个数据包通常包括有效载荷或主体，所述有效载荷或主体将基本用户数据递送至目的地；以及用于路由和控制目的的某些补充信息，所述某些补充信息通常至少部分地包含在数据包的标头内。广义上说，网络、发送系统和接收系统可使用这类补充信息来确保将有效载荷正确路由和递送至预期目的地。

以此方式通过包交换网络输送数据的经常不可避免的结果是包丢失，这在一个或多个数据包不能正确地到达其目的地时发生。由于多种因素(包括信道拥塞、信号退化和其他原因)，包丢失可能出现。为了防止致使包丢失发生的某些网络条件，同时还在网络信道中有效地使用可用带宽，已经开发了多种纠错技术。此外，存在一系列传输协议，所述一系列传输协议可并入用于处置包丢失的工具，并且用于在包丢失发生时处置所述包丢失的特定方法取决于在数据传送期间使用的特定传输协议。一般而言，这些传输协议可以分为如下两种类型：可靠协议和不可靠协议，所述可靠协议和不可靠协议各自存在某些折衷，并且在任何实例中使用的协议的特定选择可取决于数据传送的性质。

可靠协议并入保证将每个数据包按序列递送至其目的地，从而在包丢失的情况下重新传输丢弃的包。可靠协议经常是但不总是面向连接的协议并且递送保证通常通过建立从接收方返回到特定通信会话的发送方的反向信道来完成，所述接收方可用来发送某种类型的确认收据以验证包是否被正确地递送。当指示数据包不能正确地到达其目的地时，发送方可使用这些确认来指导重新传输过程。可靠协议的普遍且众所周知的实例是传输控制协议(tcp)，其也是面向连接的。可靠协议(诸如tcp)也很好地适合于准确传送数据是主要问题的任务，并且为了验证是否正确递送数据包，诸如发送基于文本的电子邮件、数字内容下载和音频/视频可在目的地系统处缓冲的媒体流服务，可容忍一定量的延迟。遗憾的是，数据验证特性和数据的重新传输引入相对大的开销，从而使许多可靠协议不期望用于时间重要的应用，包括实时数据传送，诸如实况音频和/或视频流、在线视频游戏和互联网电话。

相比之下，不可靠的协议通常会放弃如上文描述的特定包的数据递送验证的类型，并且通常其特征在于如下事实：它们不能保证每个包到达其目的地，也不能确保包按正确序列递送。不可靠协议经常是但不总是无连接，并且在任何特定通信会话期间通常不会建立固定信道。每个数据包可以替代地基于包含在每个数据包中的补充信息独立地路由。不可靠协议的普遍且众所周知的实例是用户数据报协议(udp)，其也是无连接。由于不可靠协议(像udp)通过放弃上文提及的可靠性特性而具有相对减少的开销，因而它们更好地适用于其中最小化延迟是主要问题的时间敏感的应用，诸如上文提及的实时应用。

由于不可靠协议通常放弃数据包的重新传输，因而当使用不可靠服务输送数据时，被称为前向纠错(fec)的技术通常用来处置包丢失。fec提供具有独立地重构丢失数据，而无需发送方重新传输未能被正确地递送的资源包的能力的接收方装置。当使用前向纠错时，原始的源数据通常在发送方侧以fec包的形式冗余地编码，所述fec包与源包同时被传输给接收方。在丢失源包的情况下，接收方装置可利用包含在fec包中的冗余地编码的数据来重构丢失的数据，而无需等待重新传输。

在丢失的类型中，不可靠协议和连接(诸如wifi)具体地易遭受所谓的突发丢失，其中连接丢失大约50毫秒的时段。前向纠错的现有方法包括里德-所罗门fec，其中给定源帧的两个里德-所罗门编码版本在发送源帧的10毫秒内作为fec帧发送。里德-所罗门编码允许在相同分辨率下重构原始源帧。然而，如果连接丢失发生在10毫秒或更长时间内，那么源帧和fec帧两者可能丢失。然而，如果源帧或fec帧丢失，那么不会发生中断，两者都丢失将不可能重构。因此，虽然先前的方法可帮助纠正在非常短的时间段内丢失的连接，但是需要可处置更长中断突发的纠错。

重要的是，网络条件经常随时间变化，从而致使发送方通过网络信道可用的最大比特率基于信道上的当前负载而变化。当发送方系统试图在超过信道的当前可用带宽的比特率下发送数据包时，作为响应可致使产生拥塞条件，所述拥塞条件触发严重的包丢失。这可在涉及可靠数据输送(诸如tcp)的时间敏感的应用中是可容忍的，因为丢失数据的重新传输得到了保证；然而，这可在涉及不可靠输送的许多实时应用和其他应用中是不可接受的，因为包丢失可达到接收方不能重构丢失数据的程度，从而导致不期望的结果(诸如信号的漏失)。另一方面，当最大可用的比特率替代地远远超过由发送方提供的比特率时，这也是不可期望的，因为网络信道的全部传输性能被低效率地利用，并且在接收方侧的信号的质量因此可能不必要地差。因此，纠错必须能够动态地调整以适应网络条件从而确保有效覆盖包丢失，同时不会因超过带宽容量的太多纠错包而产生新的包丢失。

遗憾的是，以有效地利用网络信道的可用带宽，而不会引起导致不可接受的包丢失的拥塞条件的方式使用不可靠协议传送数据是一项重大挑战。传统的拥塞控制技术经常仅适于对内置于传输层的发送方具有反馈的可靠协议(诸如tcp)，但对通常缺乏所述反馈，除非用户通过传输层独立地添加的许多不可靠协议(诸如udp)无效。此外，虽然由比特率增加至拥塞点产生的包丢失可能在时间较不敏感的应用(其使用tcp或其他可靠协议来重新传输数据)中是可容忍的，但是在许多实时应用中由于接收方无法重构数据而可能是不可接受的。

因此，在本领域中存在对动态前向纠错和有效拥塞控制和拥塞避免技术的需要，所述动态前向纠错和有效拥塞控制和拥塞避免技术适于与udp和经历周期性和突发丢失的其他可靠传输协议一起使用。本公开的各个方面正是在此背景下产生。

技术实现要素：

根据本公开的某些实现方式，用于对帧进行编码并传输帧的方法可包括接收或生成多个未编码帧，所述多个未编码帧包括序列中的当前帧和所述序列中的一个或多个先前帧。以第一比特率对当前帧进行编码以生成一个或多个编码的源帧。以等于或低于第一比特率的第二比特率对一个或多个先前帧进行编码以生成一个或多个编码的fec帧。将所述一个或多个编码的源帧和所述一个或多个编码的fec帧打包成一个或多个数据包，所述一个或多个数据包可存储在存储器中或通过数据网络传输。所述一个或多个数据包可以是数据包的流的一部分，所述数据包的流可包括并不包括编码的fec数据的一些包。

根据本公开的某些实现方式，发送方计算系统可包括至少一个处理器单元和耦合到所述至少一个处理器单元的至少一个存储器单元。所述至少一个处理器单元和所述至少一个存储器单元可被配置来执行上述编码和传输方法。

根据本公开的某些实现方式，非暂时性计算机可读介质可包括嵌入其中的计算机可读指令。计算机可读指令可被配置来在执行时实现上述编码和传输方法。

根据本公开的某些实现方式，用于解码和重构数据包的方法可包括接收多个数据包，其中的每一个包含对应于序列中以第一比特率编码的源帧和所述序列中以等于或小于所述第一比特率的第二比特率编码为前向纠错(fec)帧的一个或多个先前帧的编码信息。将对应于所述源帧和所述多个先前帧的所述编码信息从所述多个数据包中的每个数据包中解包。对所述一个或多个编码的源帧进行解码以生成一个或多个解码的源帧。确定对应于所述序列的给定源帧的编码信息是否从所述多个数据包缺失。识别出多个数据包中的对应于给定源帧的一个或多个对应的编码的fec帧并对其进行解码以生成一个或多个解码的fec帧。然后使用一个或多个解码的fec帧生成对应于所述给定源帧的重构帧。然后可将一个或多个所述解码的源帧和所述重构的缺失帧存储在存储器中或利用显示器呈现序列中的一个或多个所述解码的源帧和所述重构的缺失帧。

根据本公开的某些实现方式，接收器计算系统可包括至少一个处理器单元和耦合到所述至少一个处理器单元的至少一个存储器单元。所述至少一个处理器单元和所述至少一个存储器单元可被配置来执行上述解码和重构方法。

根据本公开的某些实现方式，非暂时性计算机可读介质可包括嵌入其中的计算机可读指令。计算机可读指令可被配置来在执行时实现上述解码和重构方法。

附图说明

通过结合附图考虑以下详述，可以轻易地理解本公开的传授内容，在附图中：

图1是根据本公开的某些方面的示例性数据输送和前向纠错技术的示意图。

图2是根据本公开的某些方面的示例性纠错技术的流程图。

图3a是示出根据现存前向纠错方法的数据包的结构的框图。

图3b是示出根据本公开的各方面的根据前向纠错的实现方式的数据包结构的框图。

图4是根据本公开的某些方面的在流数据传输中前向纠错的详细实例的流程图。

图5是根据本公开的某些方面的在环绕声传输的上下文中实现纠错时可用的数据包结构的框图。

具体实施方式

尽管以下详述为了说明目的包括许多特定细节，但是本领域任何普通技术人员将理解的是，对于以下细节的许多变化和改变在本发明的范围内。因此，以下描述的本公开的各个示例性实现方式是在不损害本发明的一般性也不对本发明施加任何限制的情况下陈述的。

简介

本公开的各方面涉及使用特别打包的源帧和fec历史帧来补偿突发包丢失，所述突发包丢失可与不可靠传输协议(诸如udp)一起使用。具体地，wifi连接易遭受包丢失的突发。对于给定的当前帧，先前帧由第二单独的编解码器以更低比特率编码并且与当前帧一起发送。这些先前帧被称为fec帧。使用更低比特率用于fec帧减轻了用于传输包的另外的带宽要求。如果源帧丢失，那么fec帧用来重构源帧。虽然重构的或解码的fec帧可具有比源帧更低的分辨率，但是如果对重构的需要是间歇性的(例如，在音频的情况下以小于50毫秒的间隔中断)，那么在源比特率与重构比特率之间的差将低于人类感知的阈值。因此，fec帧将不会使整体感知质量退化。可与每个udp包一起发送的fec帧的数量和比特率可被调谐来改变感知的音频质量或带宽要求。udp包标头可包含关于源帧比特率和序列id以及fec帧的比特率和id的相关信息。

根据某些方面，一个或多个发送方装置可使用不可靠传输协议(诸如udp)向一个或多个接收方装置发送数据包。数据包可包括包含期望的源数据的编码的源帧以及包含来自先前帧的源数据的冗余的编码的fec帧，用于在流中先前源包中的一个或多个未能到达一个或多个接收方装置的情况下进行前向纠错。周期性反馈报告可从一个或多个接收方装置发送至一个或多个发送方装置。反馈报告可在对应的时间段期间识别包丢失，并且发送方可使用所述反馈报告来识别包丢失是否发生在所述时间段期间和/或识别在对应的时间段期间包丢失的程度。这种反馈可用于确定突发包丢失的近似间隔。

根据某些方面，一个或多个发送方装置可使用周期性反馈报告来调整流中发送给一个或多个接收方装置的数据包的比特率的各方面。可以使接收方装置获得源数据的能力优化的方式来调整比特率的各方面。在某些方面，响应于指示包丢失在可接受水平内的反馈报告，fec的比特率可增加，同时响应于初始反馈报告维持流中源包的并发比特率。根据某些方面，因为比特率可通过仅增加用于纠错的fec包的数量来调整，所以一个或多个接收方装置可能够重构源数据，即使比特率的增加导致拥塞和包丢失增加。例如，因为fec包与源包的比可增加，所以fec包可能以足够的数量被成功地递送以重构由于在递送期间源包丢失而丢失的数据。

进一步的细节

现转向图1，根据本公开的某些方面描绘了数据输送和前向纠错(fec)技术的说明性实例。在图1的实例中，一个或多个发送方装置102可通过网络106向一个或多个接收方装置104发送数据，并且所述数据可以多个数据包108的形式传输。数据包108可以是使用不可靠协议(诸如udp)发送的数据报，其中协议不保证递送每个包108并且不保证按顺序递送包108。因此，在包丢失的情况下，发送方装置102不会重新传输丢失的包；相反，接收方装置104可试图使用由所使用的特定fec技术编码到数据流中的冗余重构丢失的源数据。

如图1所示，数据包108可包括源包(图1中的阴影框)和fec包(图1中的白色/空白框)，所述源包包含递送至接收方装置104的原始源数据110，所述fec包是包含只要存在足够的可用的其他源或奇偶校验包，就允许其代替任何丢失的源包的信息的奇偶校验包。fec包可包含原始源数据110的冗余并且可由接收方装置104使用来在源包中的一个或多个不能正确地到达接收方104(例如，因为它们由网络106丢弃)的情况下重构源数据110。在所传输的数据包括音频和视频流的某些实现方式中，数据包108还可包括前述类型中的两者的音频包和视频包，例如，数据包108可包括音频源包、音频fec包、视频源包和视频fec包，并且音频包可通常小于(即，包含更少量的数据)视频包。具体地，音频包也可包括立体声源包、立体声fec包、5.1环绕声源包、5.1环绕声fec包或用于其他音频系统的音频包。

在某些实现方式中，源数据110可以是实时传输至接收方装置104的数据流，并且源数据110可由运行在发送方装置102上的应用程序生成。在这类实现方式中，实时源数据110可由按序列输出的数据的多个帧组成，并且所述帧可由生成源数据的应用程序定义。例如，源数据110可以是从运行在发送方装置102上的应用程序(诸如视频游戏、视频电话程序或其他a/v源程序)输出的实时音频/视频(a/v)流，并且应用程序可定义每个帧。

在图1的实例中，所示出的源数据块110可对应于单一帧(例如，单一a/v帧)，多个源包和fec包针对所述单一帧生成并且通过网络106传输给接收方装置104。数据流可由多个帧110组成，所述多个帧110可在发送方装置102处按序列生成，并且多个数据包108可针对每个帧形成用于传输至接收方装置104。

应注意，当使用udp或另一个不可靠协议传输数据时，数据包108，(例如，数据报)可由网络106通过不同相应路径路由，并且可不按序列到达接收方装置处。为了便于在接收方装置104处重构数据，数据包108中的每一个可由发送方装置标记有某些识别信息。例如，每个数据包108可标记有指示数据包属于序列中哪个帧的帧标识符(例如，帧号)，以及指示在每个帧内(和/或横跨帧)数据包按序列属于其中的序列标识符(例如，序列号)。因此，发送方装置102可增大形成的每个新数据包的序列号并且可增大形成的每个新帧的数据包的帧号。可选地，数据包108也可标记有进一步的识别信息(诸如在数据流是具有音频分量和视频分量的实时数据流的实现方式中识别例如包是否是音频包或视频包的类型标识符)。数据包108也可包含元数据，例如，关于帧特性(诸如源帧的比特率、fec帧的比特率和有效载荷中哪个编码帧对应于源帧以及有效载荷内哪个编码帧对应于fec帧)的信息。这类元数据可包括于数据包108的标头中。接收方装置104可根据标记至每个包的这种补充信息组装数据，并且可相应地对数据进行解码，例如用于呈现给接收方侧处的最终用户。

在包丢失的情况下，其中源包中的一个或多个被网络106丢弃或以其他方式未能到达其目的地，接收方装置104可利用冗余地编码的fec奇偶校验包来重构源数据110，而无需由发送方装置102重新传输，如图1中所示。需注意，任意数量的fec奇偶校验包可使用不同算法由一个或多个源包生成。在某些实现方式中，可使用擦除代码生成fec数据。在某些实现方式中，纠错方案可以是这样的：对于未能到达接收方的每个源包，可能需要一个fec包来重构特定数据集。例如，对于被递送至接收方装置的数据的特定帧，fec技术可以是这样的技术：其中为了在包丢失的情况下完全地重构帧，正确地到达接收方装置的fec包的数量需要至少等于丢失的源包的数量。否则，帧可能被损坏。换句话讲，如果存在n个源包并且生成m个奇偶校验包，那么当接收到至少n个总包(源和奇偶校验)时，可恢复源数据。在图1的说明中，由发送方发送的源包的数量等于发送的fec包的数量，即，为了简化说明，源包与由发送方102传输的fec包的比仅是1:1。然而，应注意，根据本公开的某些方面，可使用许多其他比，并且源包与fec包的比可以是动态的并且在流期间随时间的推移改变，如下文所述。

为了优化在数据传送期间利用可用带宽的效率，以及避免以将触发不可接受的包丢失的方式使网络信道过载，发送方装置102和/或接收方装置104可被配置来根据本公开的方面实现拥塞控制算法。图2描绘根据本公开的各方面，从在发送方201处发生的开始，通过网络202，到达接收器203的前向纠错的总处理流程的实例。首先在发送方侧201，源帧生成器212和fec帧生成器214分别产生一个或一组源帧222和fec帧224。在各种实现方式中，旨在编码到源帧222和fec帧224中的数据可包括音频数据、视频数据、游戏系统的控制输入流或可能需要传输或存储的数据的其他序列。更具体地，帧可包括音频源数据、音频fec数据、视频源数据和视频fec数据，并且音频数据通常可小于(即，包含更少量的数据)视频数据。另外，音频数据可包括立体声源数据、立体声fec数据、5.1环绕声源数据、5.1环绕声fec数据或用于另一个音频系统的音频数据。

然后对源帧222和fec帧224进行编码，如在226处所指示。通过举例但不进行限制，发送方侧201上的计算机系统可实现相同编解码器的两个实例以对源帧222和fec帧224进行编码。还可使用分别用于源帧生成和fec帧生成，或反之亦然的两个单独的硬件编解码器、两个单独的软件编解码器、硬件编解码器和软件编解码器的组合来实现所公开的内容。另外，存在本领域中可产生的将与这些传授内容一致的编解码器的进一步组合。

在226处的编码过程以比fec帧224更高的比特率对源帧222进行编码。fec帧的较小比特率减少了用来发送编码的源帧和fec帧的数据量。源帧编码比特率与fec帧编码比特率的比取决于接收侧上解码帧的最差可接受的质量。例如，如果源比特率是64kbps，并且内容为低质量语音，那么fec比特率可下降至16kbps。如果在相同情况下，源比特率是128kbps，那么fec比特率仍可以是16kbps并且比变成8:1。通过举例但不进行限制，源帧比特率与fec帧比特率的比可介于约1与约10之间，或介于约1.5与约8之间。其他比是可能的并且处于本公开的传授内容的范围内。

接着，发送方系统201使编码的源帧和fec帧经历打包过程230，所述打包过程230将编码帧打包成一个或多个数据包240用于通过网络202进行传输。一个或多个数据包240包括对应于一个或多个源帧222和一个或多个fec帧224的编码的数据。在某些实现方式中，数据包可以是统一数据报协议(udp)包。所公开的发明还适用于本领域的技术人员可在实现所公开的元素中利用的其他打包协议。另外，数据包240的某些实现方式还可包括识别信息来允许接收器正确地对接收到的包240进行排序。识别信息可包括但不限于有效载荷内编码的源帧或编码的fec帧的序列标识符或序列号、给定数据包的有效载荷中的编码的fec帧的数量、源帧的比特率、fec帧的比特率、识别有效载荷中哪个或哪些编码帧对应于源帧的信息、或识别有效载荷内哪个或哪些编码帧对应于fec帧的信息。另外，这种识别信息可放置在包240的标头中。此外，本领域技术人员可使用另一种识别方案来确定将与本公开的传授内容一致的帧的顺序。

源帧编码解码器的比特率可高于fec帧生成器编码解码器的比特率。在音频的特定情况下，可以64千比特每秒的比特率操作源帧编码解码器，而以16千比特每秒的比特率操作fec帧编码解码器。这将允许大约4个fec帧在包中采用与1个源帧相同量的数据。此外，在某些实现方式中，在数据包240中每个源帧打包的fec帧的比特率和数量可被动态地调整来补偿变化的突发丢失时段。实现fec帧的数量的动态调整的一种特定方式将是将fec帧的数量添加至给定包，所述fec帧的数量匹配由于突发丢失时段而覆盖缺失帧需要的帧的数量。反馈可以返回包的形式从接收器203返回至发送方201。

通过举例但不进行限制，接收器系统203可分析接收到的包中的包序列元数据以识别丢失的包并且随时间的变化跟踪包丢失。突发包丢失可通过在相对短的时间段内包丢失急剧增加，但发生并且更多或更少规则的时间间隔来识别。接收器系统可在某个时间窗口中聚集包丢失数据，确定在包丢失的峰值的实例之间的平均间隔和/或这类峰值的持续时间，并且发送这类信息返回至发送方系统201。然后，发送方系统可使用平均包丢失信息来调整用于对源帧212和fec帧214进行编码的比特率。发送方也可使用这种信息来调整数据包240中每个源帧打包的fec帧的数量。

突发丢失长度可通过查看接收器侧上源帧的序列号来检测。作为数值实例，如果接收到源帧n和源帧n+4，但在其之间没有其他内容，那么突发丢失长度是3个帧，或如果每个帧是10ms，那么突发丢失长度是30ms。如上所述，接收器系统203可对某个时间窗口内的突发丢失持续时间求平均值，并且将针对所述窗口确定的平均突发丢失持续时间发送至发送方系统201。发送方系统然后可相应地调整源帧和fec帧的编码比特率。还可基于总可用带宽和fec帧的期望数量来调整比特率。例如，如果在发送方201与接收器203之间存在200kbps的可用带宽用于fec帧，并且fec帧的期望数量从4改变至5，那么发送方可将用于对fec帧进行编码的比特率从50kbps改变至40kbps。

在通过网络202发送包240之前，它们可暂时地存储在存储器缓冲器245中。虽然图2具体地描绘通过网络202传输编码的数据，但是所公开的内容也涵盖包240存储在除临时缓冲器245之外的某种形式的存储器(诸如硬盘驱动器、cd、闪存驱动器或其他形式的存储器)中而不是被传输的实现方式。本公开也涵盖数据包240既存储在存储器中也通过网络202传输的实现方式。

通过网络202进行的传输可包括任何形式的无线通信，包括wifi。如图1所描绘，通过网络202进行的传输可能定期地不可靠，并且因此并非所有发送的包240可按序列到达接收器203。具体地，无线通信可易受突发丢失的影响，其中序列中的多个包丢失。这一丢失描述大约50毫秒的传输中断。如在本公开的其他地方所论述，现有的前向纠错方法包括里德-所罗门纠正，其在突发丢失发生期间并不是那么鲁棒。

当包到达接收器203时，它可被解包(如在250处所指示)成编码的源帧数据262和编码的fec帧数据264。在本公开的方面中，编码的帧数据262和264可经历解包过程270，其中帧数据被分析并且与先前接收到的帧的队列290进行比较以识别是否缺失序列中的任何帧。帧是否缺失可通过检查已知的或可确定的序列号或与每个帧相关联的某个其他识别来确定。识别信息然后可用来确定其在队列290中的位置。这可通过将识别特征或序列号与队列290中已经存在的帧进行比较来实现。此外，本领域技术人员可使用另一种识别方案来确定将与本公开的传授内容一致的帧的顺序。

接收到的源帧数据262和/或fec帧数据264可在解码/重构过程274期间进行解码。从队列290缺失的任何源帧可通过解码/重构过程274由解码的fec帧数据264重构。通常，源帧数据262在重新打包并添加至队列290之后立即被解码为输出帧280。然而，不必立即对每个接收到的包240中的fec帧进行解码。相反，编码的fec帧数据可存储在缓冲器中并且根据需要进行解码，以提供适合于按需重构缺失的源帧的一个或多个fec帧。可替代地，fec帧数据264可在它们被解包之后被解码并且所产生的fec帧存储在缓冲器中，直到它们被需要。当对应的源帧被接收和解码时，接收器系统可将fec帧从缓冲器移除。可将fec帧添加至队列290作为输出帧280，以替换对应的缺失的源帧。从队列290，输出帧280然后作为输出295被发送以例如存储在存储器中和/或由输出装置(诸如音频或视频显示器)呈现或以其他方式(例如，作为用于应用程序(诸如音频游戏)的控制输入)被使用。应注意，fec帧数据仅在需要时被解码，即，并不是接收到的每个fec帧都需要被解码。

如在本公开的其他地方所述，图2中示出的实现方式可应用于未编码的视频数据流。通常，视频帧可被压缩成三种类型中的一种：i帧、p帧和b帧。i帧或帧内编码图像是完全指定的最不可压缩的帧。p帧或预测的图片包含关于从前一帧改变的信息。最后，b帧或双向预测图片包含关于帧之间改变的信息。后两种类型的帧需要对其他类型的帧进行解码。在视频纠错的实现方式中，所公开的发明将在视频流具有最小带宽约束、i帧的最小丢失、相对低的帧内移动并且遭受突发丢失时特别有效。

另外，图2中描绘的方法也可应用于游戏的输入流。具体地，所公开的发明的实现方式将为编码游戏界面输入流针对突发丢失提供鲁棒保护。本领域的技术人员可通过可能经历突发丢失的不可靠网络将所公开发明的方法并入其他数据流的应用中。

图3a至图3b比较现有前向纠错与本说明书中公开的前向纠错。在现有前向纠错方案301(其被称为里德-所罗门)中，将如在图3a中描绘被配置的若干包发送给接收器。首先，将包310(其包括对应于内容的帧的ip标头312、udp标头314和字节数据有效载荷316)通过网络发送给接收器。在所示出的实例中，ip标头和udp标头共同地占包的28个字节，并且有效载荷占80个字节。在发送源包310之后不久(例如，在发送源包310的10毫秒内)，将两个完全相同的fec包320和330发送给接收器。fec包320、330分别包括ip标头322、332、udp标头324、334和有效载荷326、336。在所示出的实例中，ip标头322、332和udp标头324、334占fec包320、330的28个字节，并且有效载荷326、336占fec包320、330的80个字节。在接收器未得到源包310的情况下，帧可由fec包320或330替换。在这个方案中，将三个单独的包发送给接收器以用于处理和重构帧。

图3b示出根据本公开的方面的前向纠错方案350。前向纠错方案351在立体声音频传输中特别有用。根据这个方案，数据包350包括ip标头352、udp标头354和对应于序列的当前帧n的编码信息356，其以第一比特率进行编码。在udp标头354与有效载荷(当前帧n的编码信息)之间示出的另外的标头355可包含帧号和关于源和fec编码比特率的信息。数据包350还包括对应于序列的先前帧n-1、n-2、n-3、n-4、n-5的编码信息358。先前帧以小于第一比特率的第二比特率进行编码。

当由源帧n和fec帧n-1、n-2、n-3、n-4、n-5覆盖的时间间隔增加时，前向纠错方案351在突发丢失(～50毫秒)的情况下具有更大鲁棒性，这意味着可容忍连接中更大间隙，同时仍确保可重新产生序列中的给定帧。另外，如果发送方201、网络或存储器存储装置202或接收器203对它可处理的包的数量具有一定限制，那么方案351可使用更少的数据包来提供纠错。在图3b中描绘的实例中，对于共363个字节，标头352、354占共28个字节，编码的源帧信息356占80个字节，并且编码的fec帧信息358占255个字节(每个fec帧51个字节)。这类似于里德-所罗门前向纠错方案301需要的324个数据字节。对于这个特定实例，包350中每个帧的源帧数据与fec帧数据的比为约1.57。

图4描绘根据本公开的各方面的总处理流程的实现方式的特定实例。高比特率编解码器412和低比特率编解码器414用来生成源帧426和一组fec帧428。具体参考源帧生成器412和fec帧生成器414，公开的云实现相同编解码器的两个实例，以将源帧和fec帧编码成对应的源帧数据426和fec帧数据428。还可使用两个单独的硬件编解码器、两个单独的软件编解码器、硬件编解码器和软件编解码器的组合分别用于源帧生成和fec帧生成或反之亦然来实现所公开内容。另外，存在本领域中可产生的将与这些传授内容一致的编解码器的进一步组合。

编码的帧数据426、428被打包成数据包420，所述数据包420除编码的帧数据之外包括ip识别标头422和udp标头424。包420通过网络402发送。在udp标头424与有效载荷(当前帧n的编码信息)之间示出的另外的标头425可包含帧号和关于源编码比特率和fec编码比特率的信息。虽然图4具体地描绘了通过网络202传输编码的数据，但是所公开内容也涵盖如下实现方式：其中包420以某种形式的存储器(诸如硬盘驱动器、cd、闪存驱动器或其他形式的存储器)存储而不是被传输。所公开内容还涵盖如下实现方式：其中数据包420存储在存储器中(例如，临时存储器缓冲器或永久性存储介质(诸如硬盘驱动器、cd或闪存驱动器)中)，并且还通过网络202传输。

通过网络402进行的传输可包括任何形式的无线通信，包括wifi。如关于图1所论述，通过网络402进行的传输可能定期地不可靠，并且因此并非所有发送的包402可按序列到达接收器403。具体地，无线通信可易受突发丢失的影响，其中序列中的多个包丢失。这一丢失可涉及例如大约50毫秒的传输中断。如在本公开的其他地方所论述，现有的前向纠错方法在突发丢失发生期间并不是那么鲁棒。

在成功地接收之后，接收器可如在430处所指示检查数据包420，以确定其是否包含与缺失帧474相关的数据。在这个特定实现方式中，关于哪个帧或哪些帧缺失的信息可通过检查输出帧序列470来确定。例如，每个帧可在其标头中具有识别序列中的帧位置的序列信息。通过检查队列470中每个帧的序列信息，接收器可确定哪个帧或哪些帧缺失(如果有的话)。接收器侧440上的编解码器对数据包420进行解码。在这个特定实例中，解码的源帧456被成功地接收并且因此添加至输出帧队列470。解码的fec帧458和具体地与帧队列中的缺失帧474相关联的fec帧459经历帧重构过程460以生成新的输出帧，所述新的输出帧然后添加至队列470。最终，队列470中的输出帧通过输出装置(诸如音频帧情况下的扬声器或视频帧情况下的视觉显示器)呈现来发送至输出480。

图5示出包结构的一种实现方式，具体地用于将本公开的各方面应用于环绕声音频(诸如杜比5.1环绕声)。用于杜比环绕声的帧信息包括用于6个单独信道的信息：左前(fl)、右前(fr)、左环绕(sl)、右环绕(sr)、中环绕(c)和低频效果(lfe)。根据图5中描绘的实现方式，fl信道和fr信道被认为是最重要的信道并且源帧数据和fec帧数据的打包被配置为考虑到这一点。然而，应注意，图5中的实现方式的传授内容也可应用于具有多个信道的其他声系统。

在与用于杜比5.1环绕声系统的音频相关联的帧510的情况下，用于帧的数据分成通过网络202(或如别处所论述，进入存储器中)几乎或完全同时从发送方201发送至接收器203的两个单独包520和530。一个包520包含ip识别标头522、udp标头524和有效载荷，所述有效载荷包括对应于帧序列的当前帧n的2个前信道(fl和fr)的源帧信息526和对应于所述序列的先前帧n-1、n-2、n-3和n-4的fec帧信息528的编码信息。在udp标头524与有效载荷(当前帧n的编码信息)之间示出的另外的标头525可包含帧号和关于源编码比特率和fec编码比特率的信息。fec帧信息528包含可重构音频的所有6个信道的数据。对fec帧528进行编码可包括使用杜比定向逻辑编码，其可使音频信息的6个信道能够编码成2个信道，在本文被称为左信道和右信道。这种特定的实现方式具有减少所传输包的带宽和存储器要求的优点。通常，用于音频样本的定向逻辑编码的方程式如下：

左信道＝fl+s*(sl+sr)+c*c+c*lfe，并且

右信道＝fr-s*(sl+sr)+c*c+c*lfe，其中

s＝0.5至1.0

c＝0.707

fl/fr＝左前/右前信道

sl/sr＝左环绕/右环绕信道

c＝中心环绕信道

l＝低频效果信道

以上文描述的方式编码的信息可在接收器侧上解码，以提取所有6个信道的信息，例如，如下文所描述。本领域的技术人员可将用于5.1音频的其他现有编码和解码技术适用于本文所公开的传授内容。

第二包530包含单独的ip识别532和udp标头534以及包括编码的源帧信息536的用于剩余四个信道(sl、sr、c和lfe)的有效载荷。第二包530中不包含fec帧。此外，不需要为剩余的四个信道生成fec帧。将源帧分离成单独包允许每个包更小并且在丢失包的情况下能够进行更加鲁棒的帧纠错。通过分离前信道和3.1信道，如果前信道包丢失，那么接收器系统可由3.1信道重构前信道，或如果3.1信道包丢失，那么接收器系统可由前信道包的fec部分重构3.1信道。

可使用图5中的包布置来代替图4中描绘的流程中的单一数据包420。图2和图4中描绘的方法通常与本公开发明的用于5.1音频的特定实现方式相符。所论述的特定实现方式可根据哪些帧到达接收器来不同地处置纠错。

如果包含用于fl和fr信道的源帧的数据包520并未到达接收器，那么接收端上的计算系统可由序列地接收的包的fec帧重构那些信道。

如果接收器系统接收立体声，但具有5.1音频性能，那么它可对左信道信号和右信道信号进行上混合以生成其他3.1信道。在此包括用于进行上混合的先前描述的方程式：

c＝c*(lt+rt)

l＝c*(lt+rt)并且应用低通滤波器

sl＝s*(lt-rt)，时间延迟和相移+90度

sr＝s*(lt-rt)，时间延迟和相移-90度

s＝0.5至1.0

c＝0.707

本领域的技术人员可应用类似的先前发明的方程式组以在包括但不限于单声和7.1环绕声的其他音频系统之间转换。

重构还可包括使用fec帧和3.1信道源帧两者来恢复fl信道和fr信道。如果fec帧和3.1信道源帧两者用来重构帧，那么潜在地可得到比如果仅使用一者或另一者更高的分辨率输出帧。

通过举例但不进行限制，5.1音频数据可按如下被构造具有fec帧(lt/rt)和3.1数据(sl/sr、c、l)。

fl＝lt-s*(sl+sr)-c*c-c*l

fr＝rt+s*(sl+sr)-c*c-c*l

s＝0.5至1.0

c＝0.707

如果包含用于sl、sr、c和lfe信道的源帧的数据包530并未到达接收器，那么可由包含编码的3.1信道帧数据的序列包的fec帧信息重构那些信道。在这种情况下，必须使用下列方程式对定向逻辑编码的fec文件进行解码：

c＝c*(lt+rt)

l＝c*(lt+rt)并且应用低通滤波器

sl＝s*(lt-rt)，时间延迟和相移+90度

sr＝s*(lt-rt)，时间延迟和相移-90度

s＝0.5至1.0

c＝0.707

本领域的技术人员可应用类似的先前发明的方程式组以在包括但不限于单声和7.1环绕声的其他音频系统之间转换。

如果数据包520和530两者都未到达接收器，那么所有信道信息可由按序列发送和接收的fec帧重构。相关的重构方程式(使用与之前相同的缩写)如下：

fl＝lt

fr＝rt

c＝c*(lt+rt)

l＝c*(lt+rt)并且应用低通滤波器

sl＝s*(lt-rt)，时间延迟和相移+90度

sr＝s*(lt-rt)，时间延迟和相移-90度

s＝0.5至1.0

c＝0.707

本领域的技术人员可应用类似的先前发明的方程式组以在包括但不限于单声和7.1环绕声的其他音频系统之间转换。

如果数据包520和530两者都到达，那么不一定需要重构，并且可组合来自包的数据以形成输出帧。

处理立体声或某个其他多信道式音频系统的实现方式可适于能够在发送方侧上处理一个系统中的音频，并且在接收器处将所述音频存储在另一个系统中或输出所述音频。这种实现方式也可允许在环绕声与立体声编码之间进行动态切换。

一种特定实现方式如下。如果在发送方侧上由系统生成的源音频原始地是立体声，而在接收器侧上生成的输出是5.1环绕声，那么发送方系统可将音频视为仅具有两个信道的立体声，并且使用诸如图4中概述的步骤。接收器系统然后将使用相同方程式来选择输出立体声或将帧信息上混合到5.1中，以使接收到的数据进入右音频系统中。如果发送方侧上的源音频是5.1环绕声，但由于归因于输出系统的带宽约束或限制进行的动态调整，接收器系统仅可处理立体声，或发送系统受限于发送立体声，那么可覆写具有定向逻辑编码帧的正常源帧(携带关于所有5.1信道的信息)，使得立体声音频流携带定向逻辑编码源帧和fec帧。这可能够根据输出限制在接收侧上重构立体声中或5.1中。包结构将是图5中所示的一个。结合所描述的步骤，可在发送方与接收器之间实现关于被发送的音频是否是环绕声或立体声的通知。这一通知可通过控制信道经由单独数据包发送，可包括在发送的数据包的标头中，或可通过本领域技术人员可设计的一些或其他手段发送。

本领域的技术人员可将所公开的申请的传授内容应用于来自发送方的音频具有不同于接收器侧上输出的信道的其他情况。本领域的技术人员可构造其他音频系统的数据包布置，其包括但不限于立体声和杜比7.1环绕声，并且与本文所公开的传授内容相符和兼容。

上述组件可以硬件、软件、固件或其某个组合实现。

虽然以上是本公开的说明性实现方式的完整描述，但也可能使用各种替代、修改和等效物。因此，本发明的范围不应当被构造成受限于以上描述，而是应当参考所附权利要求以及其等效物的完整范围来确定。本文所述的任何特征(不论优选与否)可与本文所述的任何其他特征组合(不论优选与否)。在随附权利要求书中，不定冠词“一个”或“一种”是指冠词后的一个或多个项的量，除非其中另外明确说明。附随的权利要求书不应被解读为包括手段或步骤加功能(means-or-step-plus-function)限制，除非这种限制使用短词“用于……的装置”或“用于……的步骤”被明确地记述在给定的权利要求中。