收器传输数据包的不可靠协议可以是无连接协议(例如，UDP)。在某些实施中，从接收器设备到发送器设备的可靠信道可以通过UDP创建。用于通过UDP创建可靠信道并可被用于本公开的某些实施的开源解决方案的示例是usrsctp。在其他实施中，用于将反馈报告从接收器设备发送回发送器设备的可靠反向信道可以使用完全单独的连接(诸如单独的可靠协议(例如TCP))建立或可靠信道使用某种其他可靠协议建立。在某些实施中，与从发送器发送至接收器的源数据相比，可靠发送反馈信息可以是优选的，这是由于这种数据的不同特性和目的。
[0041]在某些实施中，发送器设备202可以标准化从接收器设备接收的反馈信息中的包丢失，如在228所指示。这可以通过将该包丢失标准化为预定量的包来实现，这可以与在常规流传输周期期间所发送包的预期数量相对应。例如，如果接收器设备将包丢失确定为所接收包与预期包的比率(如从序列信息所确定的)，那么如果实际发送的数据包的量远远少于发送器设备可能已经发送的量，则该比例可能往往高估包丢失。作为更具体的示例，如果发送器设备发送四个包，但是接收器设备仅在特定周期接收三个包，那么该接收器设备可以确定包丢失是25%。不过，如果发送器设备可在该周期发送100个包，但是仅发送四个是因为这是需要发送的所有数据，则真实的包丢失可以被更准确表述为100个包中丢失I个包，而不是4个包中丢失I个包，S卩1%代替25%。作为更一般的示例，可以预先确定在常规的流传输期间，在时间周期X内应该接收N个包。如果在X期间，接收器设备基于N/2包(例如基于数据包的序列号)报告包丢失，则任何丢失应当由发送器标准化为N个包中丢失若干包，而不是N/2个包中丢失若干包。因此，发送器设备可以经配置将从一个或多个接收器设备204接收的包丢失标准化为在时间周期内预期传输的数据包的预定量。
[0042]根据某些方面，响应于从接收器设备204接收的反馈信息(任选地进一步标准化在发送器侧)，发送器设备202可以根据本文所述的拥塞控制的某些原理调节其发送数据包的速率，如在230所指示。在某些情况下，响应于指示在该对应时间周期内包丢失在可接受水平内的一组反馈信息，发送器设备可以经配置增加流的比特率，但是也可以通过仅在最初增加发送FEC包的比特率同时保持或以其它方式不增加发送源包的比特率来实现。关于响应于反馈信息可如何调整比特率的另一方面在本说明的其他地方有描述。
[0043]重要的是要注意，在图2中描绘的示例方法可以是连续或重复的过程，并且只要源数据212在传输就可以继续。在某些实施中，反馈信息可以在数据传输期间由接收器设备204向发送器设备202周期性地发送，使得发送器设备202可以直接响应于反馈信息而周期性地调整发送数据包的比特率。需要注意的是，更频繁地发送反馈信息可以增加流的响应，但是以降低上行带宽(即，从接收器到发送器)说明所述反馈信息来折衷。在某些实施中，反馈报告可以以每秒5次(即，每200毫秒(ms))的速率发送。在另外的实施中，反馈报告可以以每10ms和每I秒的范围发送。如果反馈过于频繁地发送，例如每10ms —次以上，则接收器可能不具有足够的时间累积可用的包数量来确定包丢失，并且这对于样品大小来说太小。相反，如果不是足够频繁地发送(例如少于每一秒一次)，则可能是往往不足以有用。
[0044]需要注意的是，在某些实施中，发送器设备可以向多个接收器设备发送数据包，并且可以响应于来自多个不同目标系统的反馈报告而调整比特率。在某些实施中，这可以借助用于每个相应接收器设备的发送器设备上的相应编码器来实现，在此情况下，发送器设备可以经配置基于它们的相应反馈信息来独立地调整用于相应接收器设备的比特率。在其他实施中，发送器设备可以包括服务于多个接收器设备的一个编码器，在此情况下，用于所有接收器设备的比特率可以基于最低质量传输进行调整。
[0045]需要注意的是，由发送器设备响应于从接收器设备接收到的反馈信息来调整比特率的方式可以取决于用于任何特定反馈报告的包丢失的特性。根据本公开的某些方面响应于反馈可如何调整比特率的某些说明性方面在图3中进行描绘。具体地，图3描绘根据本公开的某些实施用于响应于反馈信息调整通过不可靠协议传送数据的比特率的示例流程图。需要注意的是，图3中描绘的调整比特率的示例方法330可以与图2中的230处所指示的比特率调整在一个或多个方面有共同之处。重要的是还需注意，图3的示例是仅用于说明可以根据本公开如何调整速率的某些方面的目的的简化示例。
[0046]在最初，重要的是要注意，由发送器发送所有数据包的速率所定义的流的总比特率包括源比特率(由发送源包的速率定义)和FEC比特率(由发送FEC包的速率定义)两者。如图3所示，响应于发送器从一个或多个接收器设备接收的反馈信息332如何调整比特率可以大体取决于该反馈信息332是否指示在相应的时间周期内包丢失在可接受水平内，如在334所指示。需要注意的是，在334所指示的可接受水平可以相对于现有条件来定义。例如，如果所指示的包丢失相对于现有条件是稳定的(例如，包丢失的水平相对恒定并且相对于现有反馈报告所指示的包丢失没有波动)，则所指示的包丢失可以在可接受水平内。如何调整比特率也可以取决于反馈信息是否指示包丢失在某个预定的总包丢失阈值之上，如在344所指示。
[0047]根据某些方面，在来自接收器设备的特定反馈报告332指示在相应周期内的包丢失在可接受水平内的情况下，这可以指示由发送器传输的总比特率可以增加，例如因为网络信道的最大可用带宽未被传输流填满。在某些实施中，当所指示的包丢失相对于即刻回传的现有反馈报告相同或在可接受的改变量内时，则所指示的包丢失可以在可接受水平内。因此，在某些实施中，只要丢失不在波动，包丢失就可增加。不过，盲目增加比特率(即使是递增)可能触发包丢失，这通常会导致不可接受的结果(例如坏帧或信号在接收器设备丢失)。
[0048]因此，本公开的某些实施可以应对这些挑战，其通过响应于指示包丢失未增加或以其它方式在某种可接受水平内(例如当指示为稳定时)的反馈报告，初始仅增加FEC比特率同时保持源比特率来增加比特率，如在338所指示。重要的是，因为即使比特率的增加导致包丢失(例如由于信道拥塞)，结果也将是更大量的FEC包，所以接收器设备将能够或至少很可能能够由于流中所得更大量的FEC包而重构任何丢失的源包。例如，将更可能是正确输送的FEC包的数量大于或至少等于传输期间所丢失的源包的数量。此外，这样的数据传输速率的增加可以向发送器设备提供所需的反馈，这是因为由发送器设备接收的后续反馈报告332将反映流中的更高总比特率并指示总比特率的增加是否(例如)由于信道拥塞引起包丢失波动。
[0049]如果包丢失响应于增加的比特率继续是稳定的(例如，响应于所提供的数据包，它不波动或增加，如一个或多个后续反馈报告332指示)，对比特率的下一次调整可以是以FEC比特率先前增加的步调进行源比特率的增加，例如与先前FEC增加的量相同，如在342所指示。在某些实施中，这可以响应于紧接着的反馈报告或者可以在具有一个以上反馈报告的某个其它时间间隔后，只要包丢失在整个时间间隔内保持为可接受的，如反馈332所指示。换句话说，如在340所指示，如果最近变化是FEC比特率增加同时保持源比特率，那么如果包丢失继续是可接受的，这种下一次调整可以是源比特率增加与先前FEC增加的量相同的量。然后这种总比特率可以继续递增增加，只要反馈332指示包丢失是稳定的。
[0050]作为示例但并不作为限制，如果最近的调整(如在340所指示)不是总比特率的增加，那么流的可用带宽可以通过增加FEC比特率100kb/s来测试，如在338所指示。如果一个或多个后续反馈报告指示没有包丢失(如在334所指示)，那么下一个次调整可以是增加源比特率100kb/S (如在342所指示)，并且FEC比特率可以在源比特率以这种方式增加时保持不变，从而产生总比特率的另外增加。总比特率可以继续以这种方式增加直到包丢失响应于增加的比特率而波动。FEC包领先以确保在由总比特率的初始增加触发包丢失的情况下，接收器设备将能够重构丢失的源数据。而且，FEC包的领先增加可以生成所需的反馈以确定源比特率是否可以增加。
[0051]作为示例但并不作为限制，假设流的总比特率是2000kb/s并且其中100kb/S是FEC包，使得1900kb/s是源包。为了测试带宽，FEC速率可以初始增加至200kb/s。现在总带宽为2100kb/s。当确定没有附加丢失时，源速率可以增加先前FEC速率增加的量。然后，源速率变成 1900kb/s+100kb/s = 2000kb/s，总速率是(2000kb/s 的源速率)+ (lOOkb/s的FEC速率)=2100kb/s的总速率，但是可使FEC再次变为200kb/s来立即测试带宽。因此，有2000kb/s的源速率+200kb/s的FEC速率。下一次迭代可以是2100kb/s的源速率+200kb/s的FEC速率在下一次迭代上，随后是2200kb/s的源速率+200kb/s的FEC速率等等，直到包丢失响应于所提供的数据而增加。
[0052]根据某些方面，需要指出的是，增加比特率的方式(例如在338，增加FEC比特率)可以取决于多种因素。例如，增加的量可以根据需要而变化。此外，在具有不同类型的源数据从而产生不同类型的源和FEC包的实施中，比特率增加分布的方式可以根据这些包的特性(例如，基于每种不同类型包的相对大小)来改变。
[0053]例如，在包括音频/视频流的实时传输的某些实施中，总比特率也可以由音频比特率(由发送音频包的速率定义)和视频比特率(由发送视频包的速率定义)定义。在这些实施中，总比特率可以包括至少四种不同类型的比特率(音频源比特率、视频源比特率、音频FEC比特率以及音频源比特率)。因为每个视频包通常可远远大于每个音频包，所以仅通过增加视频FEC包的速率来增