基于服务器的视频执行、编码和传输的系统和方法

摘要

本发明描述了用于视频游戏和应用程序的低延时、基于服务器执行的系统和方法。例如，所述系统和方法的一种实施方式包括接收传送自客户端的控制信号、在所述服务器上执行所述视频游戏或应用程序以生成未经压缩的视频输出、使用低延时压缩对所述未经压缩的视频输出进行动态编码以生成压缩视频流、通过所述网络流动所述压缩视频流至所述客户端、以及在所述客户端上解码所述压缩视频流的操作，上述操作以延时被执行，以使得用户具有所选视频游戏或应用程序是对接收自所述客户端的所述控制信号进行即刻响应的感知。

权利要求

1.一种用于流动视频的计算机实施的方法，该方法包括：

在服务器处，通过一个或多个网络接口接收来自远离该服务器的客户端的执行视频游戏或应用程序的请求，所述请求通过网络被传送，所述网络的至少一部分包括公众网络；

通过包括所述公众网络的所述网络传送控制信号，当用户玩所述视频游戏或使用所述应用程序时，所述控制信号指示向所述客户端的用户输入；

在所述服务器上接收所述控制信号并响应地在服务器上执行所述视频游戏或应用程序，该视频游戏或应用程序的执行产生未经压缩的视频输出；

接收来自所述客户端的反馈信号，该反馈信号指示通过所述网络的所述服务器与所述客户端之间的通信信道的信道特性，所述通信信道的至少一部分包括所述公众网络；

使用低延时压缩对所述未经压缩的视频输出进行动态编码，以生成压缩视频流，所述未经压缩的视频输出以基于所检测的信道特性的比特率或压缩比率而被编码，其中动态编码包括对所述未经压缩的视频输出的帧动态执行帧间压缩和帧内压缩，其中所述未经压缩的视频被动态编码且具有一延时，以使当与其他系统延时组合时，所述用户具有所选视频游戏或应用程序是对接收自所述客户端的所述控制信号进行即刻响应的感知；

通过所述网络将所述压缩视频流传送至所述客户端，所述压缩视频流由所述客户端上的解码器解码并被显示于所述客户端的显示器上；

其中接收传送自所述客户端的控制信号、执行所述视频游戏或应用程序、使用低延时压缩对所述未经压缩的视频输出进行动态编码以生成压缩视频流、通过所述网络流动所述压缩视频流至所述客户端、以及在所述客户端上解码所述压缩视频流，以延时被执行，以使得用户具有所选视频游戏或应用程序是对接收自所述客户端的所述控制信号进行即刻响应的感知。

2.根据权利要求1所述的方法，该方法进一步包括：

基于所检测的所述信道特性的变化，动态调整所述比特率或压缩比率，其中所述压缩视频流以该比特率或压缩比率被压缩并被流动至所述客户端。

3.根据权利要求2所述的方法，其中所述比特率或压缩比率响应于所检测的所述服务器与所述客户端之间的所述通信信道的容量而被调整。

4.根据权利要求2所述的方法，其中所述比特率或压缩比率通过更改所述视频输出的帧速率而被调整。

5.根据权利要求2所述的方法，其中所述比特率或压缩比率通过更改所述压缩视频的品质而被调整。

6.根据权利要求2所述的方法，其中所述比特率或压缩比率通过更改所述压缩视频的图像分辨率而被调整。

7.根据权利要求6所述的方法，其中当所述图像分辨率被更改时，所述客户端上的所述解码器按比例增大该图像，以在显示屏幕上保持相同的图像大小。

8.根据权利要求1所述的方法，其中当所述服务器与所述客户端之间的通信信道意外掉线时，所述服务器暂停所述视频游戏或应用程序。

9.根据权利要求8所述的方法，其中如果所述通信信道掉线且所述客户端的第一用户正在玩多人游戏，其他用户被通知所述第一用户已掉线。

10.根据权利要求9所述的方法，其中当所述第一用户掉线时，针对所述其他用户暂停所述视频游戏。

11.根据权利要求3所述的方法，该方法进一步包括：

通过以下操作确定所述通信信道的最大容量：通过在所述网络上发送比特率越来越高的测试流至所述客户端，直至分组丢失和/或较高的延时指示所述最大容量已被超出。

12.根据权利要求11所述的方法，该方法进一步包括：

基于在所述压缩视频流被流动至所述客户端时所检测的分组丢失增大和/或延时增大，确定所述通信信道的最大信道容量已降低；以及响应地且动态地减小所述比特率或增大所述压缩比率，直至分组丢失和/或延时已到达预定可接受值。

13.根据权利要求11所述的方法，该方法进一步包括：

基于对分组丢失和/或延时的持续测量，确定所述通信信道的最大信道容量已增大；

以及

响应地且动态地增大所述比特率或减小所述压缩比率，直至分组丢失和/或延时到达预定不可接受水平。

14.根据权利要求1所述的方法，其中所述压缩视频流的数据分组由所述客户端以不同于所述数据分组被显示的顺序而被接收。

15.根据权利要求1所述的方法，该方法进一步包括：

采用前向纠错(FEC)技术来保护传送自所述客户端的所述控制信号和/或所述压缩视频流的指定部分。

16.根据权利要求15所述的方法，其中所述FEC技术仅被利用至基于所检测的所述客户端与所述服务器之间的通信信道的最大信道容量所需要的程度。

17.根据权利要求1所述的方法，该方法进一步包括：

通过降低所述客户端与所述服务器之间的通信信道的信道带宽峰值，减小延时。

18.根据权利要求1所述的方法，其中接收传送自所述客户端的控制信号、执行所述视频游戏或应用程序、使用低延时压缩对所述未经压缩的视频输出进行动态编码以生成压缩视频流、通过所述网络流动所述压缩视频流至所述客户端、以及在所述客户端上解码所述压缩视频流，以小于80ms的延时被执行。

19.根据权利要求1所述的方法，其中接收传送自所述客户端的控制信号、执行所述视频游戏或应用程序、使用低延时压缩对所述未经压缩的视频输出进行动态编码以生成压缩视频流、通过所述网络流动所述压缩视频流至所述客户端、以及在所述客户端上解码所述压缩视频流，以小于150ms的延时被执行。

20.一种用于流动视频的应用程序/视频游戏主机服务中心，该中心包括至少一用于存储程序代码的存储器以及至少一处理器，该处理器用于处理所述程序代码以使能以下操作：在服务器处，通过一个或多个网络接口接收来自远离该服务器的客户端的执行视频游戏或应用程序的请求，所述请求通过网络被传送，所述网络的至少一部分包括公众网络；

通过包括所述公众网络的所述网络传送控制信号，当用户玩所述视频游戏或使用所述应用程序时，所述控制信号指示向所述客户端的用户输入；

在所述服务器上接收所述控制信号并响应地在服务器上执行所述视频游戏或应用程序，该视频游戏或应用程序的执行产生未经压缩的视频输出；

接收来自所述客户端的反馈信号，该反馈信号指示通过所述网络的所述服务器与所述客户端之间的通信信道的信道特性，所述通信信道的至少一部分包括所述公众网络；

使用低延时压缩对所述未经压缩的视频输出进行动态编码，以生成压缩视频流，其中所述未经压缩的视频输出以基于所检测的信道特性的比特率或压缩比率而被编码，其中动态编码包括对所述未经压缩的视频输出的帧动态执行帧间压缩和帧内压缩，其中所述未经压缩的视频被动态编码且具有一延时，以使当与其他系统延时组合时，所述用户具有所选视频游戏或应用程序是对接收自所述客户端的所述控制信号进行即刻响应的感知；

通过所述网路将所述压缩视频流传送至所述客户端，所述压缩视频流由所述客户端上的解码器解码并被显示于所述客户端的显示器上；

其中接收传送自所述客户端的控制信号、执行所述视频游戏或应用程序、使用低延时压缩对所述未经压缩的视频输出进行动态编码以生成压缩视频流、通过所述网络流动所述压缩视频流至所述客户端、以及在所述客户端上解码所述压缩视频流，以延时被执行，以使得用户具有所选视频游戏或应用程序是对接收自所述客户端的所述控制信号进行即刻响应的感知。

21.根据权利要求20所述的应用程序/视频游戏主机服务中心，其中所述处理器处理所述程序代码以使能其他操作：基于所检测的所述信道特性的变化，动态调整所述比特率或压缩比率，其中所述压缩视频流以该比特率或压缩比率被压缩并被流动至所述客户端。

22.根据权利要求21所述的应用程序/视频游戏主机服务中心，其中所述比特率或压缩比率响应于所检测的所述服务器与所述客户端之间的所述通信信道的容量而被调整。

23.根据权利要求21所述的应用程序/视频游戏主机服务中心，其中所述比特率或压缩比率通过更改所述视频输出的帧速率而被调整。

24.根据权利要求21所述的应用程序/视频游戏主机服务中心，其中所述比特率或压缩比率通过更改所述压缩视频的品质而被调整。

25.根据权利要求21所述的应用程序/视频游戏主机服务中心，其中所述比特率或压缩比率通过更改所述压缩视频的图像分辨率而被调整。

26.根据权利要求25所述的应用程序/视频游戏主机服务中心，其中当所述图像分辨率被更改时，所述客户端上的所述解码器按比例增大该图像，以在显示屏幕上保持相同的图像大小。

27.根据权利要求20所述的应用程序/视频游戏主机服务中心，其中当所述服务器与所述客户端之间的通信信道意外掉线时，所述服务器暂停所述视频游戏或应用程序。

28.根据权利要求27所述的应用程序/视频游戏主机服务中心，其中如果所述通信信道掉线且所述客户端的第一用户正在玩多人游戏，其他用户被通知所述第一用户已掉线。

29.根据权利要求28所述的应用程序/视频游戏主机服务中心，其中当所述第一用户掉线时，针对所述其他用户暂停所述视频游戏。

30.根据权利要求22所述的应用程序/视频游戏主机服务中心，其中所述处理器处理所述程序代码以使能其他操作：通过以下操作确定所述通信信道的最大容量：通过在所述网络上发送比特率越来越高的测试流至所述客户端，直至分组丢失和/或较高的延时指示所述最大容量已被超出。

31.根据权利要求30所述的应用程序/视频游戏主机服务中心，其中所述处理器处理所述程序代码以使能其他操作：基于在所述压缩视频流被流动至所述客户端时所检测的分组丢失增大和/或延时增大，确定所述通信信道的最大信道容量已降低；以及响应地且动态地减小所述比特率或增大所述压缩比率，直至分组丢失和/或延时已到达预定可接受值。

32.根据权利要求30所述的应用程序/视频游戏主机服务中心，其中所述处理器处理所述程序代码以使能其他操作：基于对分组丢失和/或延时的持续测量，确定所述通信信道的最大信道容量已增大；

以及

响应地且动态地增大所述比特率或减小所述压缩比率，直至分组丢失和/或延时到达预定不可接受水平。

33.根据权利要求20所述的应用程序/视频游戏主机服务中心，其中所述压缩视频流的数据分组由所述客户端以不同于所述数据分组被显示的顺序而被接收。

34.根据权利要求20所述的应用程序/视频游戏主机服务中心，其中所述处理器处理所述程序代码以使能其他操作：采用前向纠错(FEC)技术来保护传送自所述客户端的所述控制信号和/或所述压缩视频流的指定部分。

35.根据权利要求34所述的应用程序/视频游戏主机服务中心，其中所述FEC技术仅被利用至基于所检测的所述客户端与所述服务器之间的通信信道的最大信道容量所需要的程度。

36.根据权利要求20所述的应用程序/视频游戏主机服务中心，其中所述处理器处理所述程序代码以使能其他操作：通过降低所述客户端与所述服务器之间的通信信道的信道带宽峰值，减小延时。

37.根据权利要求20所述的应用程序/视频游戏主机服务中心，其中接收传送自所述客户端的控制信号、执行所述视频游戏或应用程序、使用低延时压缩对所述未经压缩的视频输出进行动态编码以生成压缩视频流、通过所述网络流动所述压缩视频流至所述客户端、以及在所述客户端上解码所述压缩视频流，以小于80ms的延时被执行。

38.根据权利要求20所述的应用程序/视频游戏主机服务中心，其中接收传送自所述客户端的控制信号、执行所述视频游戏或应用程序、使用低延时压缩对所述未经压缩的视频输出进行动态编码以生成压缩视频流、通过所述网络流动所述压缩视频流至所述客户端、以及在所述客户端上解码所述压缩视频流，以小于150ms的延时被执行。

说明书

基于服务器的视频执行、编码和传输的系统和方法

[0001] 相关申请

[0002] 本申请要求2009年3月23日提交的题为“System And Method For Compressing Video Using Feedback”美国临时专利申请No.61/210,888的优先权，该申请为2009年1月23日提交的题为“System And Method for Protecting Certain Types of Multimedia Data Transmitted Over A Communication Channel”的共同待决的美国申请No.12/359,150的部分继续申请，并为2007年12月5日提交的题为“Hosting And Broadcasting Virtual Events Using Streaming Interactive Video”的共同待决的美国申请No.11/999,475的继续申请，该美国申请No.11/999,475为2002年12月10日提交的、题为“Apparatus and Method for Wireless Video Gaming”的、第10/315,460号的部分继续(CIP)申请，该申请已转让给本CIP申请的受让人。

技术领域

[0003] 本公开总体上涉及改善用户操作及存取音频和视频媒体的能力的数据处理系统的领域。

背景技术

[0004] 自从托马斯·爱迪生(Thomas Edison)时代以来，记录的音频及电影媒体已成为社会的一方面。在20世纪初期，记录的音频媒体(磁柱及唱片)及电影媒体(投币式自动点唱机及电影)广泛发行，但两种技术仍处于其起步阶段。在20世纪20年代后期，在大众市场的基础上将电影与音频组合，之后将彩色电影与音频组合。无线电广播逐渐演变成很大程度上支持广告的形式的广播大众市场音频媒体。当在20世纪40年代中期建立电视(TV)广播标准时，电视与无线电以广播大众市场媒体的形式接合，从而将先前记录的或现场直播的电影带入家庭中。

[0005] 至20世纪中期为止，大部分美国家庭已具有用于播放记录的音频媒体的唱片播放器(phonograph record player)、用于接收现场直播的广播音频的无线电设备，及用于播放现场直播的广播音频/视频(A/V)媒体的电视机。常常将所述3个“媒体播放器”(唱片播放器、无线电设备及TV)组合到共有公共扬声器的橱柜中，变成家庭的“媒体中心”。尽管对于消费者而言媒体选择有限，但媒体“生态系统”非常稳定。大多数消费者知道如何使用“媒体播放器”且能够享受其能力的全部范围。同时，媒体的出版商(大多为电影和电视工作室，及音乐公司)能够将其媒体分配给电影院与家庭两者，而不遭受广泛的盗版或“二次销售”(也即，已使用媒体的重新销售)。通常，出版商不会从二次销售得到收入，且因此，二次销售减少了出版商对于新的销售从原本可自已使用媒体的购买者得到的收入。尽管在20世纪中期期间的确存有已使用的唱片出售，但所述销售不会对唱片出版商有大影响，因为不同于电影或视频节目(其通常被成年人观看一次或仅数次)，音乐曲目可被收听数百次或甚至数千次。因此，音乐媒体远比电影/视频媒体“经久”(也即，对于成年消费者而言，其具有持久价值)。一旦购买了唱片，若消费者喜欢该音乐，则消费者可能将其保持很长时间。

[0006] 自20世纪中期到现在，媒体生态系统对于消费者与出版商的利益及损失来说都经历了一系列根本改变。在音频录音机(尤其是具有高质量立体声的盒式磁带)的广泛引入的情况下，的确有较高程度的消费者便利。但其也标志着现在广泛的消费者媒体实践—盗版的开始。的确，许多消费者纯粹出于便利起见而使用盒式磁带来录制其自己的唱片，但日益增加的消费者(例如，宿舍中准备存取彼此的唱片收集的学生)将进行盗版复制。而且，消费者将录制经由无线电播放的音乐，而非从出版商购买唱片或磁带。

[0007] 消费者VCR的出现导致更多的消费者便利，因为现在VCR被设置为记录TV节目，其可在稍后时间观看，且VCR也导致视频租赁业的建立，其中电影以及TV节目设计可在“点播”基础上进行存取。自20世纪80年代中期以来的大众市场家庭媒体设备的快速开发已导致消费者的空前的选择及便利程度，且也导致媒体出版市场的快速扩张。

[0008] 现今，消费者面对过多媒体选择以及过多媒体设备，其中许多被绑定到特定形式的媒体或特定出版商。热衷的媒体消费者可能将一堆设备连接到场所各房间中的TV及计算机，造成至一或多个电视机和/或个人计算机(PC)的“鼠窝式”电缆以及一群远程控制。(在本申请的上下文中，术语“个人计算机”或“PC”指代适合于在家庭或办公室中使用的任何种类的计算机)，包括台式计算机、Macintosh(麦金托什机器) 或其他非Windows(视窗)计算机、与Windows相容的设备、Unix变体、笔记本计算机等)。所述设备可包括视频游戏控制台、VCR、DVD播放器、音频环绕音效处理器/放大器、卫星机顶盒、电缆TV机顶盒等。此外，对于热衷的消费者，可能由于相容性问题而存在多个类似功能的设备。举例而言，消费者可能拥有HD-DVD与蓝光(Blu-ray)DVD播放器两者，或Microsoft Xbox(微软家用游戏机) 与Sony Playstation(索尼游戏站) 视频游戏系统两者。实际上，由于一些跨游戏控制台版本的的游戏的不相容性，消费者可能拥有XBox与稍后的版本(诸如，Xbox )两者。经常地，消费者对于使用哪个视频输入端及哪个远端感到迷惑。甚至在将光碟置放于正确的播放器(例如，DVD、HD-DVD、蓝光、Xbox或Playstation)中、选择用于该设备的视频及音频输入端且发现正确远程控制之后，消费者仍面临技术挑战。举例而言，在宽屏DVD的状况下，用户可能需要首先确定正确的纵横比(例如，4:3、完全、放大、宽放大、电影院宽等)且接着在其TV或监视器屏幕上设定正确的纵横比。类似地，用户可能需要首先确定正确的音频环绕音效系统格式(例如，AC-3、杜比数字、DTS等)且接着设定正确的音频环绕音效系统格式。时常，消费者未意识到其可能未享受到其电视或音频系统的全部能力下的媒体内容(例如，观看以错误纵横比挤压的电影，或收听立体声的音频而非环绕音效的音频)。

[0009] 日益增加地，已将以基于互联网的媒体设备添加到设备的堆栈中。类似Sonos(索罗斯) 数字音乐系统的音频设备使音频直接从互联网流动(stream)。同样地，类似TM TMSlingbox (视灵宝 )娱乐播放器的设备记录视频且使其经由家庭网络流动或经由互联网流动而出，其中可在PC上远程观看该视频。且互联网协议电视(IPTV)服务经由数字用户线(DSL)或其他家庭互联网连接而提供类似电缆TV的服务。近来还努力将多个媒体功能整合到单个设备(诸如，Moxi(摩西) 媒体中心及执行Windows XP媒体中心版本的PC)中。尽管所述设备中的每个设备对其执行的功能提供一点便利，但每个设备缺乏对大多数媒体的普遍且简单的存取。另外，常常由于昂贵的处理和/或本地储存的需要而使得所述设备经常花费数百美元来制造。另外，所述现代的消费者电子设备通常消耗大量电力，甚至当闲置时也消耗大量电力，这意谓着其随着时间而更加昂贵且浪费能源。举例而言，若消费者忘记将设备切断或将其切换到不同视频输入端，则该设备可能继续操作。此外，因为所述设备当中没有一个设备为完全的解决方案，所以必须将其与家庭中的其他设备的堆栈整合在一起，这仍对用户留下鼠窝式线及许多远程控制。

[0010] 此外，当许多较新的以互联网为基础的设备适当地工作时，其通常提供更一般形式(与其原本可能可用的形式相比)的媒体。举例而言，使视频经由互联网流动的设备常常仅使视频材料流动，而不能使常常伴随DVD的互动式“额外项目”流动，如视频的“制作”、游戏或导演评论。这是由于以下事实：互动式材料经常是以特定格式制作，该特定格式意欲用于在本地处理互动性的特定设备。举例而言，DVD、HD-DVD及蓝光光碟中每一者具有其自身的特定互动格式。任何家庭媒体设备或本地计算机(其可能经开发以支持所有流行格式)将需要一定程度的尖端性(sophistication)及灵活性，其将可能对于消费者操作而言过于昂贵及复杂。

[0011] 使该问题加重，若稍后在将来引入新格式，则本地设备可能不具有支持新格式的硬件能力，这将意味着消费者将必须购买升级的本地媒体设备。举例而言，若在稍后的日期引入较高分辨率的视频或立体视频(例如，每一只眼一个视频流)，则本地设备可能不具有解码该视频的计算能力，或其可能不具有用于以新格式输出该视频的硬件(例如，假定通过与遮光眼镜(shuttered glassess)同步的120fps视频来实现立体视觉，其中将60fps传送到每一只眼，若消费者的视频硬件仅可支持60fps视频，则该选项在缺乏升级的硬件购买的情况下将不可用)。

[0012] 当谈及尖端的互动式媒体(尤其是视频游戏)时，媒体设备废弃及复杂度的问题为严重问题。

[0013] 现代视频游戏应用基本上划分成四个主要非便携式式硬件平台：Sony 1、2及3(PS1、PS2，及PS3)；Microsoft 及Xbox 及
Nintendo Gamecube(任天堂方糖) 及WiiTM；以及以PC为基础的游戏。所述平台中的每一者不同于其他者，使得被编写以在一个平台上执行的游戏通常不会在另一平台上执行。也可能存在一代设备与下一代设备的相容性问题。即使大多数软件游戏开发者建立独立于特定平台而设计的软件游戏，为了在特定平台上执行特定游戏，也需要专有软件层(其经常被称为“游戏开发引擎」”)来调适游戏以在特定平台上使用。每一个平台以“控制台”(也即，附接到TV或监视器/扬声器的脱机盒(standalone box))的形式出售给消费者或其本身为PC。通常，视频游戏在诸如蓝光DVD、DVD-ROM或CD-ROM的光学媒体上出售，该光学媒体含有体现为尖端的实时软件应用程序的视频游戏。随着家庭宽带速度增加，视频游戏正日益变得可用于下载。

[0014] 由于高级视频游戏的实时性及高计算要求而使得实现与视频游戏软件的平台相容性的特殊性要求极端苛刻。举例而言，一个人可能期望从一代视频游戏到下一代视频游戏(例如，自XBox至XBox 360，或自Playstation 2(“PS2”)至Playstation 3(“PS3”))的完全游戏相容性，正如存在从一个PC到具有较快处理单元或核心的另一PC的生产力应用程序(例如，Microsoft Word(微软文字处理软件))的普遍相容性。然而，对于视频游戏并非是这种状况。因为当发行一代视频游戏时，视频游戏制造商通常寻求对于给定价格点的最高可能性能，所以经常对系统进行动态架构改变，以使得被编写以用于前代系统的许多游戏在稍后一代系统上不能工作。举例而言，XBox基于x86系列处理器，而XBox 360基于PowerPC系列。

[0015] 可利用技术来模仿先前架构，但假定视频游戏为实时应用程序，则在模仿中达成完全相同的行为常常不切实际。这是对消费者、视频游戏控制台制造商及视频游戏软件出版商的损失。对于消费者而言，这意味着将旧的一代视频游戏控制台与新的一代视频游戏控制台两者保持接通到TV以便能够玩所有游戏的必要性。对于控制台制造商而言，这意味着与新控制台的模仿及较慢采用相关的成本。且对于出版商而言，这意味着可能必须发行新游戏的多个版本以便涵盖所有潜在的消费者-不仅发行用于视频游戏的每个商标(例如，XBox、Playstation)的版本，而且常常发行用于给定商标的每个版本(例如，PS2及PS3)的版本。举例而言，开发艺电有限公司(Electronic Arts)的“疯狂橄榄球08”的单独版本以用于XBox、XBox 360、PS2、PS3、Gamecube、Wii及PC平台以及其他平台。

[0016] 便携式设备(诸如，移动电话及便携式媒体播放器)也对游戏开发商提出挑战。日益增加地，所述设备连接到无线数据网络且能够下载视频游戏。但是，市场中存在具有多种不同显示分辨率及计算能力的多种移动电话及媒体设备。而且，因为所述设备通常具有电力消耗、成本及重量约束，所以其通常缺乏类似于图形处理单元(“GPU”)的高级图形加速硬件(诸如，由美国加州的圣克拉拉的NVIDIA(英伟达公司)制造的设备)。因此，游戏软件开发商通常开发同时用于许多不同类型的便携式设备的给定游戏标题。用户可发现：给定游戏标题不可用于其特定移动电话或便携式媒体播放器。

[0017] 在家庭游戏控制台的状况下，硬件平台制造商通常向软件游戏开发商收取用于在其平台上发布游戏的能力的版税。移动电话无线通信公司通常也向游戏出版商收取用于将游戏下载到移动电话中的版税。在PC游戏的状况下，不存在用于发布游戏所支付的版税，但由于用于支持多种PC配置及可能引起的安装问题的较高消费者服务负担而使得游戏开发商通常面临高成本。而且，PC通常较少阻碍游戏软件的盗版，因为其可很容易地由精通技术的用户重新编程且游戏可更容易地被盗版且更容易地被分配(例如，经由互联网)。因此，对于软件游戏开发商而言，在游戏控制台、移动电话及PC上发行具有成本及不利之处。

[0018] 对于控制台及PC软件的游戏出版商而言，成本不止于此。为了经由零售通道分配游戏，出版商向零售商收取低于出售价格的批发价格以使零售商具有利润率。出版商通常也必须支付制造及分配保存游戏的物理媒体的成本。零售商经常也向出版商收取“价格保护费”以涵盖可能的意外费用(诸如，游戏售不出，或游戏的价格降低，或零售商必须退还部分或所有批发价格和/或从购买者收回游戏)。另外，零售商通常也向出版商收取用于帮助在广告传单中销售游戏的费用。此外，零售商日益增加地从已玩完游戏的用户购买回游戏，且接着将所述游戏以使用过的游戏出售，通常不与游戏出版商分享使用过的游戏的收入。以下事实增加了施加给游戏出版商的成本负担：游戏常常被经由互联网盗版及分配以供用户下载及进行免费复制。

[0019] 随着互联网宽带速度增加且宽带连接性在美国及全世界变得更广泛(更具体地，到家庭和到租赁连接互联网的PC的“网吧”)，游戏被更多地经由下载而分配到PC或控制台。而且，宽带连接更多地用于玩多人及大型多人在线游戏(该两者在本公开中由首字母缩写词“MMOG”来指代)。这些改变减轻了与零售分配相关的一些成本及问题。下载在线游戏解决了游戏出版商的一些不利之处，因为分配成本通常较小且存在较少或不存在未出售媒体的成本。但已下载的游戏仍被盗版，且由于其大小(大小常常为几十亿字节)而使得其可能花费非常长的时间来下载。另外，多个游戏可装满小磁盘驱动器，例如连同便携式计算机一起或连同视频游戏控制台一起出售的那些磁盘驱动器。然而，就游戏或MMOG需要在线连接以使得游戏可玩的程度而言，盗版问题得以减轻，因为通常需要用户具有有效的用户帐户。不同于可由相机拍摄显示屏幕的视频或由麦克风记录来自扬声器的音频来复制的线性媒体(例如，视频及音乐)，每个视频游戏体验是唯一的，且不可使用简单的视频/音频记录来复制。因此，甚至在未强力执行版权法且盗版猖獗的区域中，也可保护MMOG免于被盗版，从而可支持商业。举例而言，已成功地部署Vivendi SA(维旺迪公司)的“魔兽世界”MMOG，而在全世界未遭受盗版。且许多在线或MMOG游戏(诸如，Linden Lab(林登实验室)的“第二人生”MMOG)通过建在游戏中的经济模型而产生游戏运营商的收入，其中资产可使用在线工具而带来、出售且甚至建立。因此，可使用除传统游戏软件购买或订阅之外的机制来为在线游戏的使用付费。

[0020] 尽管由于在线或MMOG的性质而使得常常可减轻盗版，但在线游戏运营商仍面临其余挑战。许多游戏需要大量的本地(也即，家庭内)处理资源以供在线或MMOG适当地工作。若用户具有低性能的本地计算机(例如，不具有GPU的计算机，诸如低端笔记本计算机)，则其可能不能够玩该游戏。另外，随着游戏控制台老化，其远落后于目前技术状态且可能不能够处理更高级的游戏。即使假定用户的本地PC能够处理游戏的计算要求，常常也存在安装复杂度。可能存在驱动器不相容性(例如，若下载新游戏，则可能安装新版本的图形驱动器，其致使依赖于旧版本图形驱动器的先前已安装的游戏不可操作)。随着下载更多游戏，控制台可能用完本地磁盘空间。当发现缺陷并修复时或若对游戏进行了修改(例如，若游戏开发商发现游戏的级别太难玩或太容易玩)，复杂游戏通常随着时间推移而从游戏开发商接收下载的补丁(patch)。该补丁需要新的下载。但有时并非所有用户完成所有补丁的下载。在其他时候，下载的补丁引入其他相容性或磁盘空间消耗问题。

[0021] 而且，在游戏播放期间，可能需要大数据下载以将图形或行为信息提供到本地PC或控制台。举例而言，若用户进入MMOG中的一个房间中，且遇到由图形数据组成或具有在用户的本地机器上不可用的行为的场景或人物，则必须下载那个场景或人物的数据。若互联网连接不够快，则此可导致玩游戏期间的实质延迟。此外，若所遇到的场景或人物需要超过本地PC或控制台的储存空间或计算能力的储存空间或计算能力，则其可产生下述情形：其中用户不能在游戏中继续，或必须以质量降低的图形继续。因此，在线或MMOG游戏常常限制其储存和/或计算复杂度要求。另外，其常常限制游戏期间的数据传送的量。在线或MMOG游戏也可使可玩游戏的用户的市场变窄。

[0022] 此外，精通技术的用户越来越多地对游戏的本地复本进行反向工程且修改游戏以使得他们可以作弊。作弊可能与进行比用人力可能的速度快的重复按钮按压(例如，为了非常快速地射击)一样简单。在支持游戏中资产交易的游戏中，作弊可达到导致欺骗性交易涉及具有实际经济价值的资产的欺诈程度。当在线或MMOG经济模型基于所述资产交易时，这可导致对游戏运营商的实质有害后果。

[0023] 开发新游戏的成本随着PC及控制台能够制作越来越尖端的游戏(例如，具有更逼真的图形(诸如，实时光线追踪)，及更逼真的行为(诸如，实时物理学仿真))而增长。在视频游戏业的早期，视频游戏开发是应用程序软件开发非常类似的过程；也即，大多数开发成本在软件的开发中(与图形、音频及行为要素或“资产”的开发相对比)，诸如可被开发以用于具有广泛特殊效果的电影的那些软件开发。现今，许多尖端的视频游戏开发成果比软件开发更类似于富有特效的电影开发。举例而言，许多视频游戏提供3-D世界的仿真，且产生更加真实(也即，看似与摄影拍摄的实景(live action)图像一样逼真的计算机图形)的人物、道具及环境。照片一样逼真的游戏开发的最具挑战方面中的一者为创建不能区别于实景人脸的计算机产生的人脸。面部捕获技术(诸如，由加州的圣弗朗西斯科的Mova开TM TM发的Contour (轮廓 )真实性捕获系统)捕获表演者的面部的精确几何形状并在表演者处于运动中时以高分辨率追踪表演者的面部的精确几何形状。此技术允许在PC或游戏控制台上再现(render)3D面部，该3D面部实际上不能区别于所捕获的实景面部。精确地捕获及再现“照片一样逼真的”人脸在多个方面是有用的。首先，高度可识别的名人或运动员常常用于视频游戏中(常常被高成本雇用)，且不完美性可能对于用户而言显而易见，从而使观看体验(viewing experience)分心或令人不愉快。经常地，需要高度细节来实现高度的照片一样的逼真感-潜在地需要再现大量多边形及高分辨率纹理(在多边形和/或纹理在帧接帧的基础上随着面部移动而改变的情况下)。

[0024] 当具有详细纹理的高多边形计数场景快速改变时，支持游戏的PC或游戏控制台可能不具有足够的RAM来储存用于游戏片段中所产生的所需数目的动画帧的足够多边形及纹理数据。另外，通常可用于PC或游戏控制台上的单个光学驱动器或单个磁盘驱动器通常比RAM缓慢得多，且通常不能跟上GPU在再现多边形及纹理中可接受的最大数据速率。当前游戏通常将大多数多边形及纹理载入到RAM中，这意味着给定场景在复杂度及持续时间上很大程度上受RAM的容量限制。在例如面部动画制作的状况下，这可能将PC或游戏控制台限制于并无真实感的低分辨率面部，或限制于仅可在游戏暂停且载入用于更多帧的多边形及纹理(及其他数据)之前在有限数目的帧中制作成动画的真实感面部。

[0025] 当PC或控制台显示类似于“正在载入…”的消息时，观看进程条跨屏幕缓慢地移动被现今的复杂视频游戏的用户公认为是内在缺点。下一个场景从磁盘(除非另外有条件，否则本文中的“磁盘”指非易失性光学媒体或磁性媒体，以及诸如半导体“闪存”存储器的非磁盘媒体)载入时的延迟可花费若干秒或甚至若干分钟。这浪费时间且可能使游戏玩家相当沮丧。如先前所述，大量或所有延迟可能是由于来自磁盘的多边形、纹理或其他数据的载入时间，但也可能是以下状况：当PC或控制台中的处理器和/或GPU准备用于场景的数据时，花费一部分载入时间。举例而言，英式足球视频游戏可允许玩家在大量玩家、小组、运动场及天气条件当中选择。因此，取决于选择什么特定组合，可能需要用于场景的不同多边形、纹理及其他数据(统称“对象”)(例如，不同小组在其制服上具有不同色彩及图案)。可能要列举各种排列中的许多或所有排列且提前预先计算对象中的许多或所有对象并将对象储存在用于储存游戏的磁盘上。但是，若排列的数目很大，则所有对象所需的储存量可能过大以致不能安装在磁盘上(或太不切实际以致不能下载)。因此，现有的PC及控制台系统通常在给定场景的复杂度与播放持续时间两者上受约束且对于复杂场景遭受长的载入时间。

[0026] 先前技术的视频游戏系统及应用程序软件系统的另一显著限制在于：其越来越多地使用例如3D对象的大数据库(诸如，多边形及纹理)，所述大数据库需要被载入到PC或游戏控制台中以用于处理。如上所述，当将所述数据库在本地储存于磁盘上时，所述数据库可花费长时间来载入。然而，若数据库系储存于远程位置且经由互联网来存取，则载入时间通常严重得多。在此种情形下，下载大数据库可能花费几分钟、几小时或甚至几天。另外，所述数据库常常产生大量费用(例如，用于游戏、电影或历史记录片中的详细的高的有桅帆船的3D模型)且意欲用于销售给本地终端用户。然而，一旦数据库被下载至本地用户，其就有被盗版的风险。在许多状况下，用户仅为了评估数据库来观看其是否适合用户的需要(例如，当用户执行特定移动时，用于游戏人物的3D服装是否具有满意的外观或外表)的目的而希望下载数据库。对于在决定进行购买之前评估3D数据库的用户而言，长载入时间可能是阻碍。

[0027] 类似问题在MMOG(更具体地，如允许用户利用更加定制化的人物的游戏)中出现。对于显示人物的PC或游戏控制台，其需要能够存取具有3D几何形状(多边形、纹理等)以及所述人物的行为(例如，若人物具有盾牌，则盾牌是否足够强以使矛偏转)的数据库。通常，当MMOG由用户初次玩时，用于人物的大量数据库在游戏的初始复本下已经可用，游戏的初始复本在本地在游戏光盘上可用或被下载到磁盘。但是，随着游戏进展，若用户遇到数据库在本地不可用的人物或对象(例如，若另一用户已建立一定制人物)，则在可显示该人物或对象之前，必须下载其数据库。这可导致游戏的实质延迟。

[0028] 给定视频游戏的尖端性及复杂度，则在先前技术视频游戏控制台情况下对视频游戏开发商及出版商的另一挑战在于：开发视频游戏经常花费2年到3年，成本在数千万美元。假定新视频游戏控制台平台以大致每隔五年一次的速率引入，则游戏开发商需要在新游戏控制台发行之前的数年开始那些游戏的开发工作，以便在发行新平台时使视频游戏同时可用。来自竞争性制造商的若干个控制台有时大约同时发行(例如，彼此在一年或两年内)，但尚待分晓的是每个控制台的流行性(例如，哪个控制台将产生最大的视频游戏软件销售)。举例而言，在最近的控制台周期中，Microsoft XBox 360、Sony Playstation 3及Nintendo Wii计划在大约相同的大体时段引进。但在所述引进之前的数年中，游戏开发商实质上必须“压注(place bets)”哪些控制台平台将比其他者更成功，且相应地投入其开发资源。电影制作公司也必须在电影发行之前很长时间基于其估计可能成功的电影而分摊其有限的制作资源。给定视频游戏所需的投资的增长程度，则游戏制作越加变得类似电影制作，且游戏制作公司常规上基于其对特定视频游戏的将来成功的估计而投入其制作资源。但是，不同于电影公司，此压注并非仅基于制作本身的成功；而是，其依据于游戏要在其上执行的游戏控制台的成功。同时在多个控制台上发行游戏可减轻风险，但此额外努力增加成本，且经常延迟游戏的实际发行。

[0029] PC上的应用程序软件及用户环境正变得更为计算上密集、动态及互动，不仅使其在视觉上更吸引用户，而且使其更有用及直观。举例而言，新Windows Vista(视窗远景)TM操作系统与 操作系统的后续版本两者并入了视觉动画效应。高级图形工具(诸如，来自Autodesk(欧特克)公司的MayaTM(玛雅TM))提供非常尖端的3D再现及动画制作能力(其推动了目前技术状态的CPU及GPU的限制)。然而，这些新工具的计算要求对于所述产品的用户及软件开发商而言产生了许多实际问题。

[0030] 因为操作系统(OS)的视觉显示必须在多种计算机(包括不再出售但仍可随着新OS而升级的前代计算机)上工作，OS图形要求在很大程度上受OS要用于的计算机(其通常包括不包括GPU的计算机)的最少共同点限制。这严重地限制OS的图形能力。此外，电池供电的便携式计算机(例如，笔记本计算机)限制视觉显示能力，因为CPU或GPU中的高计算活动通常导致较高电力消耗及较短电池寿命。便携式计算机通常包括在不利用处理器时自动地减低处理器活动性以降低电力消耗的软件。在一些计算机型号中，用户可手动地减低处理器活动性。举例而言，Sony的VGN-SZ280P笔记本计算机包括在一侧上标记为“Stamina(持久性)”(用于低性能，更长电池寿命)且另一侧上标记为“Speed(速度)”(用于高性能，较短电池寿命)的交换器。在便携式计算机上执行的OS必须能够即使在计算机以其峰值性能能力的一小部分执行的情况下也可用地起作用。因此，OS图形性能常常保持为远低于目前技术状态的可用计算能力。

[0031] 经常出售高端的计算上密集的应用程序(如Maya)，期望所述应用程序将用于高性能PC上。此通常产生高得多的性能，及更昂贵且便携性较差、最少共同点的要求。因此，所述应用程序具有比通用OS(或通用生产力应用程序，类似Microsoft Office)有限得多的目标受众且通常以比通用OS软件或通用应用程序软件低得多的量出售。潜在的受众进一步受限制，因为预期的用户时常难以提前试用所述计算上密集的应用程序。举例而言，假设学生希望了解如何使用Maya或已经知道所述应用程序的潜在购买者在购买中希望在进行投资之前试用Maya(此可能涉及也购买能够执行Maya的高端计算机)。当学生或潜在购买者可下载Maya的演示版本或得到Maya演示版本的物理媒体复本时，若其缺乏能够执行Maya的全部潜能(例如，处理复杂3D场景)的计算机，则其将不能够进行产品的全方位评估。此实质上限制所述高端应用程序的受众。这也使出售价格变高，因为开发成本通常经过比通用应用程序的购买次数小得多的购买次数而分摊。

[0032] 高价应用程序也对使用应用程序软件的盗版复本的个体及商业产生更多刺激。因此，高端应用程序软件遭受猖獗盗版，尽管该软件的出版商进行了大量努力来通过各种技术减轻该盗版。但是，甚至当使用盗版的高端应用程序时，用户也不可能排除投资昂贵的目前技术状态的PC来执行盗版复本的需要。因此，尽管用户可以用软件应用程序的实际零售价格的一小部分获得软件应用程序的使用，但盗版软件的用户仍需要购买或获得昂贵的PC，以便完全利用该应用程序。

[0033] 此对于高性能盗版视频游戏的用户同样成立。尽管盗版者可以用游戏的实际价格的一小部分得到游戏，但其仍需要购买适当地玩游戏所需的昂贵计算硬件(例如，GPU-增强型PC，或类似XBox 360的高端视频游戏控制台)。假定视频游戏通常是消费者的娱乐，则用于高端视频游戏系统的额外成本可能是过于昂贵的。该情形在当前工人的平均年收入相当低(相对于美国的当前工人平均年收入)的国家(例如，中国)中更糟。这样，小得多的百分比的人口拥有高端视频游戏系统或高端PC。在这些国家中，用户可支付费用以使用连接到互联网的计算机的“网吧”相当普遍。经常地，所述网吧具有不具有高性能特征(诸如，原本可使玩家能够玩计算上密集的视频游戏的GPU)的较旧型号或低端PC。这是在低端PC上执行的游戏成功的关键因素(诸如，Vivendi的“魔兽世界”，其在中国高度成功，且通常是在中国的网吧中玩)。相比之下，计算上密集的游戏(如“第二人生”)更不可能在安装于中国网吧中的PC上玩。所述游戏实际上对于仅能够存取网吧中的低性能PC的用户来说是不可访问的。

[0034] 对于考虑购买视频游戏且首先愿意通过经由互联网将演示下载到其家庭而试用游戏的示范版本的用户也存在障碍。视频游戏演示常常为游戏的全能版本，其中一些特征停用，或对游戏播放的量施加限制。此可能涉及在可将游戏安装于PC或控制台上且在PC或控制台上执行之前下载数十亿字节的数据的长过程(可能几个小时)。在PC的状况下，其也可能涉及算出游戏需要哪些特殊驱动器(例如，DirectX或OpenGL驱动器)，下载正确的版本，安装正确的版本，及接着确定PC是否能够播放该游戏。后者步骤可能涉及确定PC是否具有足够的处理(CPU及GPU)能力、足够的RAM及相容的OS(例如，一些游戏在Windows XP上执行而不在Vista上执行)。因此，在试图执行视频游戏演示的长过程之后，用户可能发现在给定用户的PC配置的情况下视频游戏演示不可能玩。更糟地，一旦用户已下载新驱动器以用于尝试该演示，这些驱动器版本就可能与用户在PC上习惯使用的其他游戏或应用程序不相容，因此，演示的安装可致使先前可操作的游戏或应用程序不能操作。这些障碍不仅使用户沮丧，而且其也对视频游戏软件出版商及视频游戏开发商销售其游戏产生障碍。

[0035] 导致不具经济效益的另一问题与以下事实有关：给定PC或游戏控制台通常被设计以适应对应用程序和/或游戏的特定程度的性能要求。举例而言，一些PC具有或多或少的RAM、较慢或较快的CPU及较慢或较快的GPU(若其具有GPU)。一些游戏或应用程序利用给定PC或控制台的全计算能力，而一些游戏或应用程序却不利用给定PC或控制台的全计算能力。若用户的游戏或应用程序的选择未达到本地PC或控制台的峰值性能能力，则用户可能由于未利用的特征而在PC或控制台上浪费了财力。在控制台的状况下，控制台制造商可能支付比资助控制台成本所要的多的成本。

[0036] 存在于视频游戏的销售及享受中的另一问题涉及在用户实施购买游戏之前允许用户观看他人玩游戏。存在用于记录视频游戏以在稍后时间重放的若干先前技术方法。举例而言，美国专利第5,558,339号教导了在“游戏播放”期间将游戏状态信息(包括游戏控制器动作)记录在视频游戏客户端计算机(由同一个或不同用户拥有)中。此状态信息可在稍后时间使用以在视频游戏客户端计算机(例如，PC或控制台)上重放一些或所有游戏动作。该方法的显著缺点在于：对于观看已记录的游戏的用户，用户必须具有能够播放该游戏的视频游戏客户端计算机且必须具有在该计算机上执行的视频游戏应用程序，以使得当重放被记录的游戏状态时游戏播放是完全相同的。除此之外，视频游戏应用程序必须是以在被记录的游戏与经回放的游戏之间不存在可能的执行差异的方式编写。

[0037] 举例而言，游戏图形大体在帧接帧基础上计算。对于许多游戏，取决于场景是否特别复杂或是否存在减缓执行的其他延迟(例如，在PC上，另一过程可能正在执行，以致从游戏应用程序夺走CPU周期)，游戏逻辑有时可能花费比一帧时间短或比一帧时间长的时间来计算为下一个帧而显示的图形。在此种游戏中，以比一帧时间稍少的时间(例如，少几个CPU时钟周期)计算的“临限值”帧最终可出现。当使用完全相同的游戏状态信息再次计算该同一场景时，可能容易花费比一帧时间多几个CPU时钟周期的时间(例如，若内部CPU总线稍微与外部DRAM总线不同相，且即使不存在来自从游戏处理夺走数毫秒CPU时间的另一过程的大延迟，其也引入几个CPU周期时间的延迟)。因此，当回放游戏时，帧变成以两个帧时间计算而非以单个帧时间计算。一些行为基于游戏计算新帧的频率(例如，当游戏取样来自游戏控制器的输入时)。当播放游戏时，用于不同行为的时间参考中的该偏差不会影响游戏播放，但其可导致所回放的游戏产生不同结果。举例而言，若篮球的轨道是以稳定的60fps速率来计算，但游戏控制器输入是基于计算的帧的速率来取样，则当记录游戏时，计算的帧的速率可能为53fps，而当重放游戏时，计算的帧的速率可能为52fps，此可使得篮球是否被阻止进入篮中存在差异，从而导致不同结果。因此，使用游戏状态记录视频游戏需要非常谨慎的游戏软件设计，以确保使用同一游戏状态信息重放产生完全相同的结果。

[0038] 用于记录视频游戏的另一先前技术方法是仅记录PC或视频游戏系统的视频输出(例如，到VCR、DVD记录器，或到PC上的视频捕获板)。接着可将视频回倒及重放，或替代地，将记录的视频上传到互联网(通常在将视频压缩之后)。该方法的不利之处在于：当回放3D游戏序列时，用户限于仅从观看点(序列从该观看点被记录)来观看序列。换言之，用户不可改变场景的观看点。

[0039] 另外，当经由互联网而使在家庭PC或游戏控制台上播放的记录的游戏序列的经压缩的视频为其他用户可用时，即使视频是实时压缩，也不可能实时地将经压缩的视频上传到互联网。其原因是因为世界上连接到互联网的许多家庭具有高度不对称的宽带连接(例如，DSL及电缆调制解调器通常具有比上流带宽高得多的下流带宽)。被压缩的高分辨率视频序列常常具有比网络的上传带宽容量高的带宽，使得其不可能实时上传。因此，在播放游戏序列之后(可能几分钟或甚至几小时)，在互联网上的另一用户能够观看该游戏之前，将存在显著延迟。尽管该延迟在特定情形下(例如，观看在先前时间出现的游戏玩家的成果)可容忍，但其消除了观看游戏现场直播(例如，由优胜玩家玩的篮球锦标赛)的能力或现场直播地播放游戏时的“即刻重放”能力。

[0040] 另一先前技术方法允许具有电视接收器的观看者观看视频游戏现场直播，但仅在电视制作人员的控制下。美国与其他国家中的一些电视频道提供视频游戏观看频道，其中电视观众能够在视频游戏频道上观看特定的视频游戏用户(例如，参加锦标赛烦人顶级玩家)。这通过将视频游戏系统(PC和/或控制台)的视频输出馈送至用于电视频道的视频分配及处理设备中来完成。这正如电视频道广播现场直播的篮球比赛时的情况，其中若干个相机从篮球场周围的不同角度提供现场直播的馈送。电视频道接着能够利用其视频/音频处理及效应设备来操作来自各种视频游戏系统的输出。举例而言，电视频道可在来自视频游戏的视频之上叠加指示不同玩家的状态的文字(正如其可在现场直播的篮球比赛期间叠加文字)，且电视频道可加录来自评论员(其可论述在比赛期间出现的动作)的音频。另外，可将视频游戏输出与记录游戏的实际玩家的视频的相机(例如，显示玩家对游戏的情绪反应)组合。

[0041] 该方法的一个问题在于：必须实时地使所述现场直播的视频馈送为电视频道的视频分配及处理设备可用，以便使其具有现场直播的广播的刺激性。然而，如先前所述，当视频游戏系统从家庭执行时(尤其是当广播的一部分包括来自正捕获游戏玩家的真实世界视频的相机的现场直播的视频时)，这常常不可能。另外，在锦标赛情形下，所关注的是家庭中游戏者可修改游戏及作弊，如先前所述。由于这些原因，电视频道上的所述视频游戏广播常常配置有聚集于公共位置处(例如，在电视演播室处或在竞技场中)的播放器及视频游戏系统，其中电视制作设备可接受来自多个视频游戏系统及潜在的现场直播的相机的视频馈送。

[0042] 尽管所述先前技术视频游戏电视频道可为电视观众提供非常刺激的演出(这是与现场直播的运动事件同类(例如，与以“运动员”呈现的视频游戏玩家同类)的体验，不仅根据其在视频游戏世界中的动作，而且根据其在真实世界中的动作)，但这些视频游戏系统常常限于玩家彼此身体上极接近的情形。此外，因为电视频道被广播，所以每个被广播的频道仅可显示由电视频道的制作人员选择的一个视频流。由于这些限制及广播时间、制作设备及制作人员的高成本，所述电视频道通常仅显示参加顶级锦标赛的顶级玩家。

[0043] 另外，向全部电视观众广播视频游戏的全屏幕图像的给定电视频道每次仅显示一个视频游戏。这严重地限制电视观看者的选择。举例而言，电视观看者可能对给定时间显示的游戏不感兴趣。另一观看者可能仅对观看并非由电视频道在给定时间放映的特定玩家的游戏播放感兴趣。在其他状况下，观看者可能仅对观看内行玩家如何处理游戏中的特定级别感兴趣。其他观看者可能希望控制观看点(视频游戏从该观看点来看)，该观看点不同于由制作小组等选择的观看点。简言之，电视观看者在观看视频游戏中可能具有无数的偏好(即使若干个不同电视频道可用，电视网络的特定广播也不适应所述偏好)。由于所有上述原因，使得先前技术视频游戏电视频道在向电视观看者呈现视频游戏中具有显著限制。

[0044] 先前技术视频游戏系统及应用程序软件系统的另一缺点在于：他们很复杂，且通常遭受错误、崩溃和/或无意识且不需要的行为(统称“缺陷”)。尽管游戏及应用程序在发行之前通常经历除错及调谐过程(经常称为“软件质量保证”或SQA)，但几乎不变的是：一旦游戏或应用程序被发行到领域中的广大受众，缺陷就会突然出现。遗憾的是，软件开发商难以在发行之后识别及追踪到许多缺陷。软件开发商可能难以意识到缺陷。即使当其了解缺陷时，也可能仅存在其可用于识别是什么引起该缺陷的有限量的信息。举例而言，用户可打电话给游戏开发商的消费者服务热线且留下消息，该消息陈述：当玩游戏时，屏幕开始闪烁，接着变成固体蓝(solid blue)且PC冻结。其为SQA小组提供了在追踪缺陷中有用的非常少的信息。在线连接的一些游戏或应用程序在特定状况下有时可提供更多信息。举例而言，有时可使用”看门狗”过程来监视游戏或应用程序是否“崩溃”。看门狗过程可收集游戏或应用程序崩溃时关于游戏或应用程序过程的状态(例如，存储器堆栈使用状态、游戏或应用程序进展到的程度等)的统计，且接着经由互联网而将所述信息上传至SQA小组。但在复杂游戏或应用程序中，该信息可花费非常长的时间来解密，以便准确地确定在崩溃时用户正在进行什么。尽管如此，也不可能确定什么事件序列导致崩溃。

[0045] 与PC及游戏控制台相关联的又一问题在于：其经受使消费者极不便利的服务问题。服务问题也影响PC或游戏控制台的制造商，因为其通常需要发送特殊盒子以安全地装运破损的PC或控制台，且因而招致修理的成本(若PC或控制台处于保修期内)。游戏或应用程序软件出版商也可受处于修理状态中的PC和/或控制台引起的销售损失(或在线服务使用)影响。

[0046] 图1说明诸如Sony 3、Microsoft Xbox Nintendo WiiTM、以Windows为基础的个人计算机或Apple Macintosh的先前技术视频游戏系统。所述系统中的每一者包括用于执行程序码的中央处理单元(CPU)(通常为用于执行高级图形操作的图形处理单元(GPU))，及用于与外部设备及用户通信的多个形式的输入/输出(I/O)。为简单起见，将所述组件显示为组合在一起为单个单元100。图1的先前技术视频游戏系统也显示为包括光学媒体驱动器104(例如，DVD-ROM驱动器)；用于储存视频游戏程序代码及数据的硬盘驱动器103；用于播放多人游戏、用于下载游戏、补丁、演示或其他媒体的网络连接105；用于储存当前正由CPU/GPU 100执行的程序码的随机存取存储器(RAM)101；用于在游戏播放期间接收来自用户的输入命令的游戏控制器106；及显示设备102(例如，SDTV/HDTV或计算机监视器)。

[0047] 图1中所显示的先前技术系统受到若干限制。首先，与RAM101的存取速度相比较，光学驱动器104及硬碟机103往往具有慢得多的存取速度。当直接通过RAM 101工作时，由于RAM 101通常具有高得多的带宽且不会受到磁盘机构相对长的搜寻延迟的事实，CPU/GPU 100在实践中可处理比直接从硬盘驱动器103或光学驱动器104读出程序代码及数据时可能的每秒多边形数多得多的每秒多边形数。但仅有限量的RAM提供于这些先前技术系统中(例如，256-512兆字节)。因此，常常需要“正在载入…”序列，其中RAM 101被周期性地填充有用于视频游戏的下一个场景的数据。

[0048] 一些系统试图同时地重迭程序代码的载入与游戏播放，但这仅可在存在已知序列的事件时进行(例如，若正沿道路驾驶车，则可在驾驶车的同时载入路旁的正接近的建筑物的几何形状)。对于复杂和/或快速场景改变，此类型的重迭通常不起作用。举例而言，在用户处于战役进行之中且在那时刻的视图内RAM 101完全被填满表示对象的数据的状况下，若用户将视图快速地向左移动以观看当前未载入在RAM 101中的对象，则将导致动作的不连续性，因为不存在足够的时间来将新对象自硬盘驱动器103或光学媒体104载入到RAM 101中。

[0049] 图1的系统的另一问题是由于硬盘驱动器103及光学媒体104的储存容量的限制引起。尽管磁盘储存设备可被制造成有相对较大的储存容量(例如，500亿字节或500亿字节以上)，但其仍不提供用于在当前视频游戏中所遇到的特定情况的足够储存容量。举例而言，如先前所述，英式足球视频游戏可允许用户在全世界的许多小组、玩家及运动场当中选择。对于每个小组、每个玩家及每个运动场，需要大量纹理映射及环境映射来特征化世界上的3D表面(例如，每个小组具有唯一运动衫，每一者需要唯一纹理映射)。

[0050] 用于解决上述后者问题的一个技术是：对于游戏，一旦用户选择了纹理及环境映射，就预先计算纹理及环境映射。此可涉及许多计算上密集的过程，包括解压缩图像、3D映射、加阴影、组织数据结构等。因此，当视频游戏执行这些计算时，对于用户可能存在延迟。减少此延迟的一个方法原则上为：最初开发游戏时执行所有这些计算-包括小组、玩家名册及运动场的每个排列。游戏的发行版本因而将包括储存在光学媒体104上或互联网上的一个或多个服务器上的所有所述经预先处理的数据，当用户作出选择时，仅经由互联网将用于给定小组、玩家名册、运动场选择的选定的预先处理的数据下载到硬盘驱动器103。然而，作为实际问题，游戏播放中可能的每个排列的该预先载入的数据可能轻易地为几兆兆字节(terabyte)的数据，其远超过现今的光学媒体设备的容量。此外，用于给定小组、玩家名册、运动场选择的数据可能轻易地为几亿字节的数据或几亿字节以上的数据。在家庭网络连接的情况下(例如，10Mbps)，经由网络连接105下载该数据将比在本地计算数据花费更长时间。

[0051] 因此，图1中所显示的先前技术游戏架构使用户在复杂游戏的较大场景转变之间经受显著延迟。

[0052] 诸如图1中所显示的先前技术方法的先前技术方法的另一问题在于：这些年来，视频游戏倾向于变得更高级且需要更多CPU/GPU处理能力。因此，即使采用无限量的RAM，视频游戏硬件要求也超过所述系统中可用的处理能力的峰值水平。因此，需要用户每隔几年升级游戏硬件以保持同步(或以较低质量水准玩较新游戏)。比以往更高级的视频游戏的趋势的后果为：用于家庭用途的玩视频游戏的机器通常不具经济效益，因为其成本通常由其可支持的最高性能游戏的要求来确定。举例而言，可能使用XBox 360来玩类似“战争机器(Gears of War)”的游戏，该游戏要求高性能的CPU、GPU及几亿字节的RAM，或者可能使用XBox 360来玩“吃豆(Pac Man)”，其为来自20世纪70年代的游戏，其仅需要几千字节的RAM及非常低性能的CPU。实际上，XBox 360具有同时主机代管许多同时的“吃豆”游戏的足够计算能力。

[0053] 在一周的大多数小时中，通常关闭视频游戏机。根据2006年7月Nielsen(尼尔森)娱乐对13岁及13岁以上的活跃游戏者的研究，平均起来，活跃游戏者一周中花费十四个小时或一周中的全部小时的仅12％来玩控制台视频游戏。这意味着平均视频游戏控制台在88％的时间内闲置，这是昂贵资源的无效率使用。假定视频游戏控制台常常是由制造商来资助以降低购买价格(期望该资助将通过来自未来视频游戏软件购买的版税来赚回)，则这特别有意义。

[0054] 视频游戏控制台也造成与几乎任何消费者电子设备相关的成本。举例而言，需要将系统的电子设备及机构容纳于外壳中。制造商需要提供服务保证。出售该系统的零售商需要收取关于系统的销售和/或关于视频游戏软件的销售的利润。所有这些因素添加视频游戏控制台的成本，该成本必须由制造商来资助、传递至消费者，或者由制造商与消费者两者来资助。

[0055] 另外，盗版是视频游戏工业的较大问题。实际上每个较大视频游戏系统上所利用的安全机构这些年来已“破裂”，导致视频游戏的未经授权的复制。举例而言，Xbox 360安全系统在2006年7月破裂且用户现在能够在线下载非法复本。可下载的游戏(例如，用于PC或Mac的游戏)特别容易经受盗版。在世界的特定区域(其中盗版管制不强)中，实质上不存在独立视频游戏软件的可行市场，因为用户可与合法复本一般容易地以成本的非常小一部分购买盗版复本。而且，在世界的许多地方，游戏控制台的成本占收入的高百分比，以致即使盗版受控制，也很少有人可买得起目前技术状态的游戏系统。

[0056] 另外，已使用的游戏的市场减少了视频游戏业的收入。当用户变得对游戏厌倦时，其可将游戏出售给将游戏转售给其他用户的店铺。这种未经授权但普遍的实践显著减少了游戏出版商的收入。类似地，当每隔几年存在平台转变时，通常出现大约50％的销售减少。这是因为：当用户知道即将发行较新版本的平台时，用户停止购买用于较旧平台的游戏(例如，当即将发行Playstation 3时，用户停止购买Playstation 2游戏)。组合起来，销售的损失及与新平台相关的增加的开发成本可对游戏开发商的收益性有非常显著的不利影响。

[0057] 新游戏控制台也非常昂贵。Xbox 360、Nintendo Wii及Sony Playstation 3均以数百美元零售。高能力的个人计算机游戏系统可花费高达$8000。这表示用户的显著投资，具体来说，考虑到硬件在几年后变陈旧及许多系统是为孩子而购买的事实。

[0058] 上述问题的一个方法是在线游戏，其中将游戏程序代码及数据主机代管于服务器上且按要求将其传送至客户端机器，经压缩的视频及音频经由数字宽带网络而流动。一些公司(诸如，芬兰的G-Cluster(G-群集公司)，其现在为日本的SOFTBANK Broadmedia(软银宽媒)的子公司)当前在线提供所述服务。类似游戏服务变得在本地网络(诸如，旅馆内及由DSL及电缆电视提供者提供的那些网络)中可用。这些系统的较大缺点是延时的问题，也即，信号行进到游戏服务器及从游戏服务器行进所花费的时间，游戏服务器通常定位在运营商的“前端”中。快速动作视频游戏(也称为“极速(twitch)”视频游戏)在用户通过游戏控制器执行动作的时间与更新显示屏幕以显示用户动作的结果的时间之间需要非常低的延时。需要低延时，以使得用户感觉到游戏“即刻地”响应。可视游戏的类型及用户的熟练程度而以不同延时间隔来满足用户。举例而言，对于缓慢的非正式游戏(类似西洋双陆棋)或慢动作角色扮演游戏而言，100毫秒的延时可能是可容忍的，但在快动作游戏中，超过70毫秒或80毫秒的延时可引起用户在游戏中更拙劣地表现，且因此不可接受。举例而言，在需要快反应时间的游戏中，当延时自50毫秒增加至100毫秒时，存在准确度的锐降。

[0059] 当游戏或应用服务器安装在附近的受控网络环境或至用户的网络路径可预测和/或可容忍带宽峰值的网络环境中时，在最大延时以及延时的一致性方面，控制延时容易得多(例如，因此用户经由网络观察到来自数字视频流动的稳定运动)。该程度的控制可在以下达成：在电缆TV网络前端到电缆TV用户的家庭之间，或自DSL中央办公室至DSL用户的家庭，或在来自服务器或用户的商业办公室区域网络(LAN)环境中。而且，有可能获得商业之间的具有得到保证的带宽及延时的特定分级的点到点私用连接。但在将游戏主机代管于连接到通用互联网的服务器中心中且接着经由宽带连接而使经压缩的视频流动(stream)到用户的游戏或应用系统中，许多因素造成延时，导致先前技术系统的部署中的严重限制。

[0060] 在典型的连接宽带的家庭中，用户可具有用于宽带服务的DSL或电缆调制解调器。所述宽带服务通常造成用户的家庭与通用互联网之间的多达25毫秒的来回行程延时(且有时更多)。另外，存在由于经由互联网将数据路由到服务器中心而造成的来回行程延时。经由互联网的延时基于给出数据的路线及数据被路由时数据所造成的延迟而改变。除路由延迟之外，还由于光穿过使大多数互联网互连的光纤的速度而造成来回行程延时。举例而言，对于每1000英里，由于光穿过光纤的速度及其他耗用而造成约22毫秒的来回行程延时。

[0061] 额外延时可由于经由互联网流动的数据的数据速率而造成。举例而言，若用户具有以“6Mbps DSL服务”出售的DSL服务，则在实践中，用户将很可能最多得到小于5Mbps的下行输送量，且将可能周期性地看见由于各种因素(诸如，峰值载入时间期间在数字用户线接入复用器(DSLAM)处的拥挤)产生的连接降级。若经由相邻者循环的本地共用同轴电缆中存在拥挤或电缆调制解调器系统网络中的其他地方存在拥挤，则类似问题可出现，从而将用于以“6Mbps电缆调制解调器服务”出售的连接的电缆调制解调器的数据速率减小至远小于该数据速率。若使4Mbps的稳定速率下的数据分组以用户数据报协议(UDP)格式单向地从服务器中心经由所述连接而流动，若一切都适当地工作，则数据分组将通过而不造成额外延时，但若存在拥挤(或其他妨碍)且仅3.5Mbps可用于使数据流动到用户，则在典型情形下，包将被丢弃，导致丢失数据，或者分组将在拥挤点处排队直至它们可被发送为止，从而引入了额外延时。不同拥挤点具有用于保存被延迟的分组的不同队列容量，因此在一些状况下，立即将不可成功解决拥挤的分组丢弃。在其他状况下，将几百万比特的数据排队且最终将其发送。但是，在几乎所有状况下，拥挤点处的排队具有容量限制，且一旦超过该限制，队列将溢出且分组将被丢弃。因此，为了避免造成额外延时(或更糟地，分组丢失)，必须避免超过从游戏或应用服务器到用户的数据速率容量。

[0062] 还由于在服务器中压缩视频及在客户端设备中解压缩视频所需的时间而造成延时。当在服务器上执行的视频游戏正在计算待显示的下一个帧时，进一步造成延时。当前可用的视频压缩算法受到高数据速率或高延时。举例而言，运动JPEG为仅帧内有损的压缩算法，该压缩算法特征为低延时。视频的每个帧独立于视频的每个其他帧而压缩。当客户端设备接收经压缩的运动JPEG视频的一个帧时，其可立即解压缩该帧且显示该帧，从而导致非常低的延时。但因为每个帧分开进行压缩，所以算法不能够利用连续帧之间的类似性，且因此仅帧内视频压缩算法受到非常高的数据速率。举例而言，60fps(每秒帧数)640×480运动JPEG视频可能需要40Mbps(每秒百万比特)或40Mbps(每秒百万比特)以上的数据。用于所述低分辨率视频窗的所述高数据速率在许多宽带应用程序中将是过于昂贵的(且对于大多数消费者的基于互联网的应用程序的确如此)。另外，因为每个帧经独立压缩，所以可能由于有损压缩而产生的帧中的假影可能出现于连续帧中的不同位置处。这可导致当解压缩视频时，在观看者看来为移动的视觉假影。

[0063] 其他压缩算法(诸如，来自Microsoft公司的MPEG2、H.264或VC9)当用于先前技术的配置中时，可实现高压缩比率，但以高延时为代价。所述算法利用帧间压缩以及帧内压缩。周期性地，所述算法执行帧的仅帧内压缩。这种帧被称为关键帧(通常称作“I”帧)。接着，该算法通常将I帧与先前帧与相继帧两者相比较。并非独立地压缩先前帧及相继帧，而是算法确定图像从I帧到先前帧及相继帧有什么改变，且接着将该改变储存为：“B”帧(对于I帧之前的改变)及“P”帧(对于I帧之后的改变)。这导致比仅帧内压缩低得多的数据速率。但是，其通常以较高延时为代价。I帧通常比B帧或P帧大得多(常常大10倍)，且因此，以给定数据速率传输成比例地花费较长的时间。

[0064] 考虑(例如)一个i情形：其中I帧为B帧及P帧的大小的10倍，且对于每个单个I帧内，存在29个B帧+30个P帧＝59个帧间，或对于每个“帧群”(GOP)总共60个帧。因此，在60fps下，每秒存在1个60帧GOP。假设传输信道具有2Mbps的最大数据速率。为了在信道中达成最高质量的视频，压缩算法将产生2Mbps数据流，且给定上述比率，这将产生每帧内2百万比特(Mb)/(59+10)＝30,394个比特及每I帧303,935个比特。当通过解压缩算法接收经压缩的视频流时，为了稳定地播放视频，需要以规则间隔(例如，60fps)解压缩及显示每个帧。为了实现该结果，若任何帧受到传输延时，则需要将所有帧延迟至少该延时，因此最糟状况的帧延时将限定用于每个视频帧的延时。因为I帧最大，所以I帧引入最长传输延时，且整个I帧将必须在可解压缩及显示I帧(或取决于I帧的任何帧间)之前接收。假定信道数据速率为2Mbps，则传输I帧将花费303,935/2Mb＝145毫秒。

[0065] 使用传输信道的带宽的大百分比的帧间视频压缩系统(如上所述)将由于I帧相对于帧的平均大小的大的大小而经受长延时。或者，换言之，当先前技术帧间压缩算法达成比仅帧内压缩算法低的平均每帧数据速率(例如，2Mbps对40Mbps)时，其由于大I帧而仍遭受高的峰值每帧数据速率(例如，303,935*60＝18.2Mbps)。但请记住：上述分析假定P帧及B帧均比I帧小得多。尽管这大体成立，但对于具有与先前帧、高运动或场景改变不相关的高图像复杂度的帧，这不成立。在所述情形下，P帧或B帧可变得与I帧一般大(若P帧或B帧变得比I帧大，则尖端压缩算法通常将“强制”I帧且用I帧替换P帧或B帧)。因此，I帧大小的数据速率峰值可在任何时刻出现于数字视频流中。因此，对于经压缩的视频，当平均视频数据速率接近传输信道的数据速率容量时(经常为该状况，给定对于视频的高数据速率要求)，来自I帧或大的P帧或B帧的高峰值数据速率导致高帧延时。

[0066] 当然，上述论述仅特征化由GOP中的大的B帧、P帧或I帧产生的压缩算法延时。若使用B帧，则延时将更高。原因是因为在可显示B帧之前，必须接收B帧之后的所有B帧及I帧。因此，在诸如BBBBBIPPPPPBBBBBIPPPPP的图片群(GOP)序列中，其中在每个I帧之前存在5个B帧，只有在接收到随后的B帧及I帧之后才可由视频解压缩器显示第一B帧。
因此，若使视频以60fps(也即，16.67毫秒/帧)流动，则在可解压缩第一B帧之前，不管信道带宽如何快，接收五个B帧及I帧将花费16.67*6＝100毫秒，且这是仅5个B帧的情况。具有30个B帧的经压缩的视频序列相当普遍。此外，在如2Mbps的低信道带宽下，由于I帧的大小而引起的延时影响很大程度上增加到由于等待B帧到达而产生的延时影响。
因此，在2Mbps信道上，在大量B帧的情况下，使用先前技术视频压缩技术超过500毫秒或
500毫秒以上的延时相当容易。若不使用B帧(对于给定质量水准，以较低压缩比率为代价)，则不招致B帧延时，但仍招致上文所描述的由于峰值帧大小而引起的延时。

[0067] 问题恰恰由于许多视频游戏的性质而加重。利用上文所描述的GOP结构的视频压缩算法很大程度上被最佳化以用于连同要用于被动观看的现场直播的视频或电影材料一起使用。通常，相机(真实相机，或者计算机产生的动画的状况下的虚拟相机)及场景相对稳定，仅因为若相机或场景太颠簸地来回移动，则视频或电影材料(a)通常观看起来令人不愉快，且(b)若其正被观看，当相机突然来回颠簸时，观看者通常不能够紧密地跟随该动作(例如，若相机在拍摄吹灭生日蛋糕上的蜡烛的孩子时被扰动且突然在蛋糕之间来回颠簸，则观看者通常集中于孩子及蛋糕上，而不理会相机突然移动时的简短中断)。在视频会谈或视频电话会议的状况下，可将相机固持于固定位置中且根本不移动，从而导致根本非常少的数据峰值。但3D高动作视频游戏通过恒定运动来被特征化(例如，考虑3D竞赛，其中整个帧在竞赛的持续时间中处于快速运动中，或者考虑第一人称射击游戏，其中虚拟相机恒定地颠簸地来回移动)。所述视频游戏可产生具有大的及频繁的峰值的帧序列，其中用户可能需要清楚地看见在该突然运动期间发生了什么。因此，在3D高动作视频游戏中，压缩假影远不可容忍。因此，许多视频游戏的视频输出(由于其性质)产生具有非常高且频繁的峰值的经压缩的视频流。

[0068] 假定快动作视频游戏的用户对于高延时具有小的容忍度，且给定所有上述延时原因，至今存在对于使视频在互联网上流动的服务器主机代管的视频游戏的限制。另外，若需要高度互动性的应用程序被主机代管于通用互联网上且使视频流动，则所述应用程序的用户遭受类似限制。所述服务需要网络配置，其中主机代管服务器直接设置于前端(在电缆宽带的状况下)或中央办公室(在数字用户线(DSL)的状况下)中，或商业背景中的LAN内(或特别分级的私用连接上)，以便控制自客户端设备至服务器的路线及距离以最小化延时且可适应峰值而不造成延时。LAN(通常额定在100Mbps-1Gbps)及具有足够带宽的租用线路通常可支持峰值带宽要求(例如，18Mbps峰值带宽为100Mbps LAN容量的一小部分)。

[0069] 若进行特殊适应，则峰值带宽要求也可由住宅宽带基础架构来适应。举例而言，在电缆TV系统上，可为数字视频通信给出专用带宽，该专用带宽可处理诸如大I帧的峰值。此外，在DSL系统上，可供应较高速度的DSL调制解调器(考虑高峰值)，或可供应可处理较高数据速率的特别分级的连接。但是，附接至通用互联网的传统电缆调制解调器及DSL基础架构对于用于压缩的视频的峰值带宽要求而言远不能容忍。因此，在线服务(将视频游戏或应用程序主机代管于距客户端设备长距离的服务器中心中，且接着经由传统的住宅宽带连接经由互联网而使经压缩的视频输出流动)遭受显著的延时及峰值带宽要求-尤其对于需要非常低的延时的游戏及应用程序(例如，第一人称射击游戏及其他多用户、互动式动作游戏，或需要快响应时间的应用程序)。

发明内容

[0070] 描述了用于视频游戏和应用程序的低延时、基于服务器执行的系统和方法。通过一个或多个网络接口由服务器从自客户端接收执行视频游戏或应用程序的请求。客户端通过包括网络传送控制信号，当用户玩所述视频游戏或使用所述应用程序时，所述控制信号指示向所述客户端的用户输入。所述服务器接收所述控制信号并响应地执行所述视频游戏或应用程序，该视频游戏或应用程序的执行产生未经压缩的视频输出。此外，接收来自所述客户端的反馈信号，该反馈信号指示通过所述网络的所述服务器与所述客户端之间的通信信道的信道特性。使用低延时压缩对所述未经压缩的视频输出进行动态编码，以生成压缩视频流，所述未经压缩的视频输出以基于所检测的信道特性的比特率或压缩比率而被编码。在一种实施方式中，动态编码包括对所述未经压缩的视频输出的帧动态执行帧间压缩和帧内压缩。通过所述网络将所述压缩视频流传送至所述客户端，所述压缩视频流由所述客户端上的解码器解码并被显示于所述客户端的显示器上。在一种实施方式中，接收传送自所述客户端的控制信号、执行所述视频游戏或应用程序、使用低延时压缩对所述未经压缩的视频输出进行动态编码以生成压缩视频流、通过所述网络流动所述压缩视频流至所述客户端、以及在所述客户端上解码所述压缩视频流的操作以延时被执行，以使得用户具有所选视频游戏或应用程序是对接收自所述客户端的所述控制信号进行即刻响应的感知。

附图说明

[0071] 根据下面的详细描述并根据附图可以更完整地理解本公开，然而，所述附图并不用来将公开的主题限制到所示特定实施方式中，而只是用作解释和理解。

[0072] 图1示出了先前技术视频游戏系统的架构。

[0073] 图2a至图2b示出了根据一个实施例的高级系统架构。

[0074] 图3示出了用于客户端与服务器之间的通信的实际的、额定的及所需的数据速率。

[0075] 图4a示出了根据一个实施例而使用的主机服务及客户端。

[0076] 图4b示出了与客户端与主机服务之间的通信相关的例示性延时。

[0077] 图4c示出了根据一个实施例的客户端设备。

[0078] 图4d示出了根据另一个实施例的客户端设备。

[0079] 图4e示出了图4c中的客户端设备的实例方块图。

[0080] 图4f示出了图4d中的客户端设备的实例方块图。

[0081] 图5示出了可根据一个实施例而使用的视频压缩的一个实例。

[0082] 图6a示出了可在另一个实施例中使用的视频压缩的一个实例。

[0083] 图6b示出了与传输低复杂度、低动作视频序列相关的数据速率中的峰值。

[0084] 图6c示出了与传输高复杂度、高动作视频序列相关的数据速率中的峰值。

[0085] 图7a至图7b示出了在一个实施例中使用的实例视频压缩技术。

[0086] 图8示出了在一个实施例中使用的额外实例视频压缩技术。

[0087] 图9a至图9c示出了在本发明一个实施例中使用的帧速率处理技术。

[0088] 图10a至图10b示出了将图像图像块有效地封装于分组内的一个实施例。

[0089] 图11a至图11d示出了使用前向纠错技术的实施例。

[0090] 图12示出了使用多核心处理单元来进行压缩的一个实施例。

[0091] 图13a至图13b示出了根据各种实施例的主机服务之间的地理定位及通信。

[0092] 图14示出了与客户端与主机服务之间的通信相关的示例性延时。

[0093] 图15示出了实例主机服务服务器中心架构。

[0094] 图16示出了包括多个现场直播的视频窗的用户接口的一个实施例的实例屏幕拍摄。

[0095] 图17示出了在选择特定视频窗之后的图16的用户接口。

[0096] 图18示出了在将特定视频窗放大至全屏幕大小之后的图17的用户接口。

[0097] 图19示出了叠加在多人游戏的屏幕上的实例合作用户视频数据。

[0098] 图20示出了用于主机服务上的游戏玩家的实例用户页面。

[0099] 图21示出了实例3D互动式广告。

[0100] 图22示出了用于自现场直播的表演的表面捕获产生具有纹理表面的照片般逼真的图像的实例步骤序列。

[0101] 图23示出了允许选择线性媒体内容的实例用户接口页面。

[0102] 图24为示出了在现场直播网页之前消逝的时间量与连接速度的曲线图。

[0103] 图25a-b示出了本发明的采用从客户端设备至主机服务的反馈信道的实施方式。

[0104] 图26a-b示出了一实施例，其中基于最后已知的已成功接收的图像块/帧来对图像块/帧进行编码。

[0105] 图27a-b示出了一实施例，其中游戏或应用程序的状态被从第一主机服务或服务器运送(ported)至第二主机服务或服务器。

[0106] 图28示出了一实施例，其中通过使用差异数据来运送游戏或应用程序的状态。

[0107] 图29示出了本发明一实施例，该实施例在客户端设备上采用临时解码器。

[0108] 图30示出了根据本发明一实施例的如何在“R帧”之间散布“I图像块”。

[0109] 图31a-h示出了本发明的生成直播流和/或一个或多个HQ流的实施例。

具体实施方式

[0110] 在以下描述中列举了特定细节(诸如，设备类型、系统配置、通信方法等)，以便提供对本公开的彻底理解。然而，一般本领域的技术人员应了解，实践所描述的所述实施例可能不需要这些特定细节。

[0111] 图2a至图2b提供两个实施例的高级架构，其中视频游戏及软件应用程序由主机服务210主机代管且在订阅服务下由用户场所211(注意，“用户场所”意思是用户所定位的无论何处的位置，若使用移动设备则包括室外)处的客户端设备205经由互联网206(或其他公众网络或私用网络)来存取。客户端设备205可为具有至互联网的有线或无线连接、具有内部或外部显示设备222的通用计算机(诸如，以Microsoft Windows或Linux为基础的PC或Apple公司的Macintosh计算机)，或者其可为将视频及音频输出到监视器或电视机222的诸如机顶盒的专用客户端设备(具有至互联网的有线或无线连接)，或者其可为推测起来具有至互联网的无线连接的行动设备。

[0112] 所述设备中的任一者可具有其自身的用户输入设备(例如，键盘、按钮、触摸屏幕、追踪板(track pad)或惯性感测棒(inertial-sensing wand)、视频捕获相机和/或运动追踪相机等)，或者其可使用通过有线或无线连接的外部输入设备221(例如，键盘、鼠标、游戏控制器、惯性感测棒、视频捕获相机和/或运动追踪相机等)。如下文更详细描述，主机服务210包括各种性能水平的服务器(包括具有高能力CPU/GPU处理能力的那些服务器)。在播放游戏或使用主机服务210上的应用程序期间，家庭或办公室客户端设备205接收来自用户的键盘和/或控制器输入，且接着其将控制器输入经由互联网206传输至主机服务210，主机服务210作为响应来执行游戏程序代码并产生用于游戏或应用程序软件的视频输出(视频图像序列)的相继帧(例如，若用户按压将会指引屏幕上的人物向右移动的按钮，则游戏程序接着将产生显示人物向右移动的视频图像序列)。接着使用低延时视频压缩器压缩该视频图像序列，且主机服务210接着经由互联网206而传输低延时视频流。家庭或办公室客户端设备接着解码经压缩的视频流并将经解压缩的视频图像再现于监视器或TV上。因此，显著地减少客户端设备205的计算及图形硬件要求。客户端205仅需要具有用于将键盘/控制器输入转发到互联网206且解码并解压缩从互联网206所接收的经压缩的视频流的处理能力，实际上现今任何个人计算机均能够在其CPU上以软件来进行这些(例如，以约2GHz执行的Intel公司双核CPU能够解压缩使用诸如H.264及Windows媒体VC9的压缩器编码的720p HDTV)。此外，在任何客户端设备的状况下，专用芯片也可以比通用CPU低得多的成本及比通用CPU少得多的电力消耗(诸如，现代PC所需的)来实时地执行用于所述标准的视频解压缩。值得注意地，为了执行转递控制器输入及解压缩视频的功能，家庭客户端设备205不需要任何专门化的图形处理单元(GPU)、光学驱动器或硬盘驱动器(诸如，图1中所显示的先前技术视频游戏系统)。

[0113] 随着游戏及应用程序软件变得更复杂及更具照片般逼真感，其将需要较高性能的CPU、GPU、较多RAM，及较大且较快的磁盘驱动器，且可使主机服务210处的计算能力不断地升级，但终端用户将不需要使家庭或办公室客户端平台205升级，因为将通过给定视频解压缩算法而使家庭或办公室客户端平台205的处理要求对于显示分辨率及帧速率保持恒定。因此，图2a至图2b中所说明的系统中不存在现今所见的硬件限制及相容性问题。

[0114] 另外，因为游戏及应用程序软件仅在主机服务210中的服务器中执行，所以在用户的家庭或办公室(除非另外有条件，否则如本文中所使用的“办公室”将包括任何非住宅背景，包括(例如)教室)中决不存在游戏或应用程序软件的复本(光学媒体的形式，或者为下载的软件)。这显著减轻游戏或应用程序软件被非法复制(盗版)的可能性，以及减轻可由游戏或应用程序软件使用的有价值的数据库被盗版的可能性。实际上，若需要专门化的服务器(例如，需要非常昂贵的、大的或有噪音的设备)来播放对于家庭或办公室使用不可行的游戏或应用程序软件，则即使获得游戏或应用程序软件的盗版复本，其也将不可在家庭或办公室中操作。

[0115] 在一个实施例中，主机服务210向设计视频游戏的游戏或应用程序软件开发商(其大体指代软件开发公司、游戏或电影工作室，或游戏或应用程序软件出版商)220提供软件开发工具，以使得其可设计能够在主机服务210上执行的游戏。所述工具允许开发商利用主机服务的特征(所述特征通常在独立PC或游戏控制台中将不可用)(例如，快速存取复杂几何形状的非常大的数据库(除非另外有条件，否则“几何形状”将在本文中用于指代限定3D数据集的多边形、纹理、索具、照明、行为及其他组件及参数))。

[0116] 在该架构下，不同商业模型是可能的。在一个模型下，主机服务210从终端用户收取订阅费用且向开发商220支付版税，如图2a中所显示。在替代实施中(图2b中所显示)，开发商220直接从用户收取订阅费用且向主机服务210支付用于主机代管游戏或应用程序内容的费用。这些基本原理不限于用于提供在线游戏或应用程序主机代管的任何特定商业模型。

[0117] 经压缩的视频特性

[0118] 如先前所论述，在线提供视频游戏服务或应用程序软件服务的一个显著问题在于延时。70毫秒-80毫秒的延时(自输入设备被用户致动(actuate)的时刻到在显示设备上显示响应时的时刻)为用于需要快响应时间的游戏及应用程序的上限。然而，由于大量实际及物理约束而使得这在图2a及图2b中所显示的架构的情况下非常难以达成。

[0119] 如图3中所指示，当用户订阅互联网服务时，连接通常额定为到用户的家庭或办公室的标定最大数据速率301。取决于提供者的策略及路由设备能力，该最大数据速率可或多或少被严格地强制执行，但通常由于许多不同原因中的一者而使得实际可用数据速率较低。举例而言，可能在DSL中央办公室处或在本地电缆调制解调器回路上存在过多网络通信通信，或可能在电缆线上存在噪音，从而引起丢弃的分组，或提供者可能建立每用户每月最大数目的比特。当前，用于电缆及DSL服务的最大下行数据速率通常在数百千比特/秒(Kbps)到30Mbps的范围内。蜂窝式服务通常限于数百Kbps的下行数据。然而，宽带服务的速度及订阅宽带服务的用户的数目将随着时间而急剧增加。当前，一些分析者估计33％的美国宽带用户具有2Mbps或2Mbps以上的下行数据速率。举例而言，一些分析者预测：至2010年止，超过85％的美国宽带用户将具有2Mbps或2Mbps以上的数据速率。

[0120] 如图3中所指示，实际可用最大数据速率302可随着时间而波动。因此，在低延时、在线游戏或应用程序软件情况下，有时难以预测用于特定视频流的实际可用数据速率。若对于特定量的场景复杂度及运动在给定数目的每秒帧数(fps)下以给定分辨率(例如，
640×480@60fps)维持给定质量水平所需的数据速率303升高高于实际可用最大数据速率
302(如通过图3中的峰值指示)，则可出现若干问题。举例而言，一些互联网服务将仅丢弃分组，从而导致用户的视频屏幕上的丢失的数据及失真的/丢失的图像。其他服务将暂时缓冲(也即，排队)额外分组且以可用数据速率将所述分组提供到客户端，从而导致延时的增加-对于许多视频游戏及应用程序而言为不可接受的结果。最后，一些互联网服务提供者将数据速率的增加视为恶意攻击(诸如，否认服务攻击(由计算机黑客用以使网络连接停用的公知技术))，且将在特定时间周期中切断用户的互联网连接。因此，本文中所描述的实施例设法确保用于视频游戏的所需数据速率不会超过最大可用数据速率。

[0121] 主机服务架构

[0122] 图4a说明根据一个实施例的主机服务210的架构。主机服务210可位于单个服务器中心中，或者可跨越多个服务器中心而分散(以为具有比其他者低延时的至特定服务器中心的路径的用户提供低延时连接，以在用户之间提供负载平衡，且在一或多个服务器中心出故障的状况下提供冗余)。主机服务210最终可包括成千上万个或甚至数百万个服务器402，从而服务非常大的用户基础(user base)。主机服务控制系统401提供对主机服务210的总体控制，且指引路由器、服务器、视频压缩系统、计费及帐务系统等。在一个实施例中，主机服务控制系统401实施在基于Linux的分散式处理系统上，该处理系统绑定到用于储存用于用户信息、服务器信息及系统统计数据的数据库的RAID阵列。在上述描述中，除非归因于其他特定系统，否则由主机服务210实施的各种动作由主机服务控制系统401来起始及控制。

[0123] 主机服务210包括许多服务器402，诸如当前可从Intel(因特尔公司)、IBM(美国国际商用机器公司)及Hewlett Packard(惠普公司)及其他者得到的所述服务器。或者，可将服务器402装配成定制组件配置，或者最终可将服务器402整合以便将整个服务器实施为单个芯片。尽管此图为说明起见而显示少数服务器402，但在实际部署中，可能存在少至一个服务器402或多达数百万个或数百万个以上服务器402的服务器。服务器402均可以相同方式配置(作为一些配置参数的实例，具有相同CPU类型及性能；具有或不具有GPU，且若具有GPU，则具有相同GPU类型及性能；具有相同数目的CPU及GPU；具有相同量及相同类型/速度的RAM；及具有相同RAM配置)，或服务器402的各种子集可具有相同配置(例如，25％的服务器可以一个特定方式配置，50％的服务器以不同方式配置，且25％的服务器以又一个方式配置)，或每个服务器402可不同。

[0124] 在一个实施例中，服务器402无磁盘，也即，并非具有其自身的本地大容量储存器(其为光学或磁性储存器，或者基于半导体的储存器，诸如闪存或服务类似功能的其他大容量储存装置)，每一个服务器经由快速底板或网络连接而存取共用的大容量储存器。在一个实施例中，该快速连接为连接到独立冗余磁盘阵列(RAID)405系列的储存区域网络(SAN)403，在使用超高速以太网实施的设备之间具有连接。如本领域的技术人员已知的，SAN 403可用于将许多RAID阵列405组合在一起，从而导致极高的带宽-接近或可能超过可自用于当前游戏控制台及PC中的RAM得到的带宽。此外，尽管基于诸如磁性媒体的旋转媒体的RAID阵列经常具有显著的搜寻时间存取延时，但基于半导体储存器的RAID阵列可实施为具有低得多的存取延时。在另一配置中，一些或所有服务器402在本地提供一些或所有其自身的大容量储存器。举例而言，服务器402可将频繁存取的信息(诸如，其操作系统及视频游戏或应用程序的复本)储存在基于低延时本地闪存的储存器上，但其可利用SAN来存取基于旋转媒体的具有较高搜寻延时的RAID阵列405，以较不频繁地存取几何形状或游戏状态信息的大数据库。

[0125] 另外，在一个实施例中，主机服务210使用下文详细描述的低延时视频压缩逻辑404。视频压缩逻辑404可以软件、硬件或其任何组合来实施(下文描述其特定实施例)。
视频压缩逻辑404包括用于压缩音频以及视觉材料的逻辑。

[0126] 在操作中，当经由键盘、鼠标、游戏控制器或其他输入设备421而玩视频游戏或使用用户场所211处的应用程序时，客户端415上的控制信号逻辑413将表示由用户促使的按钮按压(及其他类型的用户输入)的控制信号406a-b(通常为UDP分组的形式)传输到主机服务210。将来自给定用户的控制信号路由到适当服务器(或若多个服务器响应于用户的输入设备，则路由至多个服务器)402。如图4a中所说明，可经由SAN而将控制信号406a路由至服务器402。可替换地或另外，可经由主机服务网络(例如，基于以太网的区域网络)而将控制信号406b直接路由至服务器402。不管控制信号406a-b是如何被传输，该或所述服务器均响应于控制信号406a-b而执行游戏或应用程序软件。尽管图4a中未说明，但各种网络连接组件(诸如，防火墙和/或网关)可处理主机服务210的边缘处(例如，主机服务210与互联网410之间)和/或用户场所211的边缘处(互联网410与家庭或办公室客户端415之间)的传入及传出的通信。所执行的游戏或应用程序软件的图形及音频输出(也即，新的视频图像序列)提供至低延时视频压缩逻辑404，低延时视频压缩逻辑404根据低延时视频压缩技术(诸如，本文中所描述的所述技术)而压缩视频图像序列且经由互联网410(或，如下文所描述，经由绕过通用互联网的最佳高速网络服务)而将经压缩的视频流(通常具有经压缩或未经压缩的音频)传输回至客户端415。接着，客户端415上的低延时视频解压缩逻辑412解压缩视频及音频流并再现经解压缩的视频流，且通常在显示设备422上播放经解压缩的音频流。或者，可在与显示设备422分开的扬声器上播放音频或根本不播放音频。注意，尽管输入设备421及显示设备422在图2a及图2b中显示为独立式设备，但其可集成在诸如便携式计算机或行动设备的客户端设备内。

[0127] 家庭或办公室客户端415(先前在图2a及图2b中描述为家庭或办公室客户端205)可为非常低廉且低能力的设备，其具有非常有限的计算或图形性能且可能具有非常有限的本地大容量储存器或不具有本地大容量储存器。相比之下，耦合至SAN 403及多个RAID 405的每一个服务器402可为格外高性能的计算系统，且实际上，若多个服务器以并列处理配置合作地使用，则几乎不存在对可承受的计算量及图形处理能力的限制。此外，由于低延时视频压缩404及低延时视频解压缩412(由用户感知地)，所以将服务器402的计算能力提供给用户。当用户按压输入设备421上的按钮时，显示器422上的图像被响应于按钮按压而更新(在感知上无有意义的延迟)，好像游戏或应用程序软件在本地执行。因此，对于为非常低性能的计算机或只是实施低延时视频解压缩及控制信号逻辑413的低廉芯片的家庭或办公室客户端415，自看来在本地可用的远程位置有效地为用户提供任意计算能力。此为用户给出用于玩最高级、处理器密集的(通常为新的)视频游戏及最高性能的应用程序的能力。

[0128] 图4c显示非常基础且低廉的家庭或办公室客户端设备465。该设备为根据图4a及图4b的家庭或办公室客户端415的一个实施例。其大约2英寸长。其具有与具有以太网供电(PoE)的以太网电缆相接口的以太网插孔462，该设备从以太网插孔462得到其电力及其到互联网的连接性。该设备能够在支持网络地址转换(NAT)的网络内执行NAT。在办公室环境中，许多新的以太网交换器具有PoE且将PoE直接带到办公室中的以太网插孔。在此种情形下，所需的为从壁式插孔到客户端465的以太网电缆。若可用的以太网连接不运输电力(例如，在具有DSL或电缆调制解调器但无PoE的家庭中)，则存在可用的低廉的壁式“砖块(brick)”(也即，电源)，其将接受无电力的以太网电缆且输出具有PoE的以太网。

[0129] 客户端465含有耦合至蓝牙无线接口的控制信号逻辑413(图4a)，该蓝牙无线接口与诸如键盘、鼠标、游戏控制器和/或麦克风和/或耳机的蓝牙输入设备479相接口。而且，客户端465的一个实施例在与显示设备468耦合的情况下能够以120fps输出视频，显示设备468能够支持120fps视频且向一对遮光眼镜466发信号(通常经由红外)以对于每个相继帧交替地遮蔽一只眼接着遮蔽另一只眼。用户所感觉的效果为“跳出”显示屏幕的立体3D图像。支持该操作的一种该显示设备468为Samsung HL-T5076S。因为用于每一只眼的视频流是单独的，所以在两个独立视频流由主机服务210压缩的一个实施例中，帧在时间上交错，且帧在客户端465内以两个独立解压缩过程来解压缩。

[0130] 客户端465也含有低延时视频解压缩逻辑412，其解压缩传入的视频及音频且经由HDMI(高清晰度多媒体接口)、连接器463输出，HDMI(高清晰度多媒体接口)、连接器463插入到SDTV(标准清晰度电视)或HDTV(高清晰度电视)468中，从而向TV提供视频及音频，或插入到支持HDMI的监视器468中。若用户的监视器468不支持HDMI，则可使用HDMI至DVI(数字视觉接口)，但音频将丢失。在HDMI标准下，显示能力(例如，所支持的分辨率，帧速率)464从显示设备468表达，且接着经由互联网连接462将该信息传回到主机服务210，因此主机服务210可使经压缩的视频以适合于该显示设备的格式流动。

[0131] 图4d显示家庭或办公室客户端设备475，除了客户端设备475具有更多外部接口之外，其与图4c中所显示的家庭或办公室客户端设备465相同。而且，客户端475可接受PoE来供电，或者其可占用插入墙壁中的外部电源适配器(未图示)。视频相机477使用客户端475USB输入将经压缩的视频提供到客户端475，经压缩的视频由客户端475上传到主机服务210以用于下文所描述的用途。将利用下文所描述的压缩技术将低延时压缩器创建到相机477中。

[0132] 除具有用于其互联网连接的以太网连接器之外，客户端475还具有到互联网的802.11g无线接口。两种接口均能够在支持NAT的网络内使用NAT。

[0133] 而且，除具有用于输出视频及音频的HDMI连接器之外，客户端475还具有双链接DVI-I连接器，双链接DVI-I连接器包括模拟输出端(且具有将提供VGA输出的标准适配器电缆)。其还具有用于复合视频及S视频的模拟输出端。

[0134] 对于音频，客户端475具有左/右模拟立体RCA插孔，且对于数字音频输出，其具有TOSLINK(光纤)输出端。

[0135] 除了到输入设备479的蓝牙无线接口之外，其还具有用于接口到输入设备的USB插孔。

[0136] 图4e显示客户端465的内部架构的一个实施例。该图中所显示的所有设备或一些设备可实施在场可程序化逻辑阵列、定制ASIC中或若干个离散设备(定制设计或者现成的)中。

[0137] 具有PoE的以太网497附接到以太网接口481。电力499才具有PoE的以太网497得到且连接到客户端465中的其余设备。总线480为用于设备之间的通信的公同总线。

[0138] 执行来自闪存476的小客户端控制应用程序的控制CPU 483(几乎任何小CPU都是适当的，诸如具有嵌入式RAM的100MHz下的MIPSR4000系列CPU)实施用于网络(也即，以太网接口)的协议栈且还与主机服务210通信，并配置客户端465中的所有设备。其还处理与输入设备469的接口并将分组(必要时，连同受前向纠错保护的用户控制器数据一起)发送回至主机服务210。而且，控制CPU 483监视分组通信(例如，分组是丢失还是延迟，以及其到达的时间戳)。将此信息发送回至主机服务210，以使得其可恒定地监视网络连接且相应地调整其发送的内容。最初在制造时为闪存476载入用于控制CPU 483的控制程序以及对于特定客户端465单元而言唯一的序号。此序号允许主机服务210唯一地识别客户端465单元。

[0139] 蓝牙接口484经由其天线(在客户端465内部)无线地通信至输入设备469。

[0140] 视频解压缩器486为经配置以实施本文中所描述的视频解压缩的低延时视频解压缩器。大量视频解压缩设备存在，或者为现成产品，或者作为具有可整合在FPGA或定制ASIC中的设计的知识产权(IP)。一个提供用于H.264解码器的IP的公司为澳大利亚新南威尔士州(NSW Australia)的Ocean Logic of Manly。使用IP的优点在于：本文中所使用的压缩技术与压缩标准不相符。一些标准解压缩器足够灵活以经配置以适应本文中的压缩技术，但一些标准解压缩器可能并非如此。但是，在IP的情况下，在视需要而重新设计解压缩器中存在完全灵活性。

[0141] 视频解压缩器的输出端耦合至视频输出子系统487，视频输出子系统487将视频耦合至HDMI接口490的视频输出端。

[0142] 音频解压缩子系统488或者使用可用的标准音频解压缩器来实施，或者其可实施为IP，或者可在可(例如)实施Vorbis音频解压缩器(可在Vorbis.com上找到)的控制处理器483内实施音频解压缩。

[0143] 实施音频解压缩的设备耦合到音频输出子系统489，音频输出子系统489将音频耦合至HDMI接口490的音频输出端。

[0144] 图4f显示客户端475的内部架构的一个实施例。如可见，除额外接口及来自插入墙壁中的电源适配器的可选外部DC电力(且若如此使用，则可选外部DC电力替换将来自以太网PoE 497的电力)之外，该架构与客户端465的架构相同。下文中将不重复与客户端465共同的功能性，但将额外功能性描述如下。

[0145] CPU 483与额外设备通信且配置额外设备。

[0146] WiFi子系统482经由其天线提供无线互联网存取，作为对以太网497的替代。WiFi子系统可购自多家制造商，包括美国加州的圣克拉拉的Atheros Communications(阿特赫鲁斯通信公司)。

[0147] USB子系统485提供对用于有线USB输入设备479的蓝牙通信的替代。USB子系统相当标准且可容易地用于FPGA及ASIC，且经常创建到执行如视频解压缩的其他功能的现成设备中。

[0148] 与客户端465内的视频输出相比较，视频输出子系统487产生较宽范围的视频输出。除提供HDMI 490视频输出之外，其提供DVI-I 491、S-视频492及合成视频493。而且，当DVI-I 491接口用于数字视频时，将显示能力464自显示设备传回至控制CPU 483，以使得其可向主机服务210通知显示设备478的能力。由视频输出子系统487提供的所有接口均为相当标准的接口且容易以许多形式可用。

[0149] 音频输出子系统489经由数字接口494(S/PDIF和/或Toslink)数字地输出音频且经由立体模拟接口495输出模拟形式的音频。

[0150] 来回行程延时分析

[0151] 当然，为了实现前一段的利益，用户使用输入设备421的动作与在显示设备420上看见该动作的后果之间的来回行程延时应不大于70毫秒-80毫秒。此延时必须考虑在自用户场所211中的输入设备421到主机服务210及再次返回到用户场所211至显示设备422的路径中的所有因素。图4b说明各种组件及网络(信号必须经由该组件或网络行进)，且该组件及网络上方的为时间线，该时间线列出实际实施中可预期的例示性延时。注意，图4b经简化以便仅显示重要路径路由。下文描述用于系统的其他特征的数据的其他路由。双头箭头(例如，箭头453)指示来回行程延时且单头箭头(例如，箭头457)指示单向延时，且“～”表示近似量测。应指出，将存在所列的延时不可达成的真实世界情形，但在大量状况下，在美国，使用至用户场所211的DSL及电缆调制解调器连接，该延时可在下一段中所描述的情形中达成。而且，注意，尽管至互联网的蜂窝式无线连接性的确将在所显示的系统中工作，但大多数当前美国蜂窝式数据系统(诸如，EVDO)招致非常高的延时且将不能够达成图4b中所显示的延时。然而，这些基本原理可在可能能够实施该水平的延时的未来蜂窝式技术上实施。进一步地，存在这样的游戏及应用程序实例(例如，不要求快速用户反应时间的游戏，诸如象棋)，其中通过当前US蜂窝数据系统所产生的延时虽然对于用户而言是显而易见的，但对于该游戏及应用程序而言是可接受的。

[0152] 自用户场所211处的输入设备421开始，一旦用户致动输入设备421，就将用户控制信号发送至客户端415(其可为诸如机顶盒的独立设备，或其可为在诸如PC或行动设备的另一设备中执行的软件或硬件)，且将其分组化(在一个实施例中以UDP格式)并为分组给出目的地地址以到达主机服务210。分组将也含有用于指示控制信号来自哪个用户的信息。接着经由防火墙/路由器/NAT(网络地址转换)设备443将控制信号分组转发到WAN接口442。WAN接口442为由用户的ISP(互联网服务提供者)提供到用户场所211的接口设备。WAN接口442可以是电缆或DSL数据机、WiMax收发器、光纤收发器、蜂窝式数据接口、电力线互联网协议接口(Internet Protocol-over-powerline interface)，或到互联网的许多接口中的任何其他接口。另外，可将防火墙/路由器/NAT设备443(及(可能地)WAN接口442)整合到客户端415中。该一个实例将为移动电话，其包括用于实施家庭或办公室客户端415的功能性的软件，以及用于经由某标准(例如，802.11g)而无线地路由及连接到互联网的装置。

[0153] WAN接口442接着将控制信号路由至本文中所称的用于用户的互联网服务提供者(ISP)的“存在点”441，WAN接口442为提供连接至用户场所211的WAN输送器与通用互联网或私用网络之间的接口的设施。存在点的特性将视所提供的互联网服务的性质而改变。对于DSL，其通常是DSLAM位于的电话公司中央办公室。对于电缆调制解调器，其通常是电缆多系统运营商(MSO)前端。对于蜂窝式系统，其通常是与蜂窝式塔相关的控制室。但无论存在点的性质怎样，其均将接着将控制信号分组路由至通用互联网410。接着经由将最可能系光纤收发器接口的接口将控制信号分组路由至WAN接口444至主机服务210。WAN
444将接着将控制信号分组路由至路由逻辑409(其可以许多不同方式来实施，包括以太网交换器及路由服务器)，路由逻辑409估计用户的地址且将控制信号路由至用于给定用户的正确的服务器402。

[0154] 服务器402接着将所述控制信号视为在服务器402上执行的游戏或应用程序软件的输入且使用所述控制信号来处理游戏或应用程序的下一个帧。一旦产生下一个帧，就将视频及音频自服务器402输出至视频压缩器404。可经由各种装置将视频及音频自服务器402输出至压缩器404。首先，可将压缩器404创建到服务器402中，因此可在服务器402内在本地实施压缩。或者，可经由到网络(其或者是服务器402与视频压缩器404之间的私用网络，或者是经由诸如SAN 403的共用网络的网络)的网络连接(诸如，以太网连接)以分组化的形式输出视频和/或音频。或者，可经由视频输出连接器(诸如，DVI或VGA连接器)将视频自服务器402输出，且接着由视频压缩器404来捕获。而且，可将音频自服务器402输出为数字音频(例如，经由TOSLINK或S/PDIF连接器)或模拟音频，模拟音频由视频压缩器404内的音频压缩逻辑来数字化并编码。

[0155] 一旦视频压缩器404已捕获来自服务器402的视频帧及在该帧时间期间所产生的音频，则视频压缩器将使用下文所描述的技术压缩视频及音频。一旦视频及音频被压缩，就通过一地址将其分组化以将其发送回至用户的客户端415，且将其路由至WAN接口444，WAN接口444接着经由通用互联网410路由视频及音频分组，通用互联网410接着将视频及音频分组路由至用户的ISP的存在点441，存在点441将视频及音频分组路由至用户场所处的WAN接口442，WAN接口442将视频及音频分组路由至防火墙/路由器/NAT设备443，防火墙/路由器/NAT设备443接着将视频及音频分组路由至客户端415。

[0156] 客户端415解压缩视频及音频，且接着在显示设备422(或客户端的内置显示设备)上显示视频并将音频发送到显示设备422或到单独的放大器/扬声器或到创建到客户端中的放大器/扬声器。

[0157] 为使用户感觉到刚才所描述的整个过程在感知上没有滞后，来回行程延迟需要小于70毫秒或80毫秒。所描述的来回行程路径中的一些延时延迟受主机服务210和/或用户的控制，而其他的延时延迟不受主机服务210和/或用户的控制。尽管如此，基于大量真实世界情况的分析及测试，以下为近似量测。

[0158] 用于发送控制信号的单向传输时间451通常小于1毫秒，经由用户场所的来回行程路由452通常使用以太网上的易得的消费者级防火墙/路由器/NAT交换器而在约1毫秒内完成。用户ISP广泛地改变其来回行程延迟453，但在DSL及电缆调制解调器提供者的情况下，通常看见其在10毫秒与25毫秒之间。通用互联网410上的来回行程延时可视频务被如何路由及路在线是否存在任何故障(且该问题在下文加以论述)而极大地改变，但通常通用互联网提供相当最佳的路由且延时很大程度上由光穿过光纤的速度(给定到目的地的距离)来确定。如下文进一步论述，已确定1000英里作为期望将主机服务210远离用户场所211置放的大致最远距离。在1000英里处(来回行程2000英里)，用于信号经由互联网的实际传输时间为约22毫秒。至主机服务210的WAN接口444通常为具有可忽略的延时的商业级光纤高速接口。因此，通用互联网延时454通常在1毫秒与10毫秒之间。经由主机服务210的单向路由455延时可在小于1毫秒内达成。服务器402通常将在小于一帧时间(其在60fps下为16.7毫秒)的时间中计算用于游戏或应用程序的新帧，因此16毫秒为将使用的合理的最大单向延时456。在本文中所描述的视频压缩及音频压缩算法的最佳硬件实施中，压缩457可在1毫秒内完成。在次佳版本中，压缩可花费多达6毫秒(当然，更欠佳的版本可花费更长时间，但所述实施将影响来回行程的总延时且将需要其他延时较短(例如，可减小经由通用互联网的可允许的距离)以维持70毫秒-80毫秒延时目标)。已经考虑互联网454、用户ISP 453及用户场所路由452的来回行程延时，因此剩余的为视频解压缩458延时，视频解压缩458延时取决于视频解压缩458是实施于专用硬件中还是实施于客户端设备415(诸如，PC或行动设备)上的软件中，可视显示器的大小及解压缩CPU的性能而改变。通常，解压缩458花费1毫秒与8毫秒之间的时间。

[0159] 因此，可通过将在实践中所见的所有最糟状况的延时加在一起来确定图4a中所显示的系统的用户可预期将经历的最糟状况的来回行程延时。他们是：1+1+25+22+1+16+6+8＝80毫秒。此外，实际上，在实践中(具有下文所论述的防止误解的说明)，此大致为使用图4a中所显示的系统的原型版本(在美国使用现成的Windows PC作为客户端设备及家庭DSL及电缆调制解调器连接)所见的来回行程延时。当然，优于最糟状况的情况可导致短得多的延时，但不可依赖其来开发广泛使用的商业服务。

[0160] 为了经由通用互联网达成图4b中所列出的延时，需要客户端415中的视频压缩器404及视频解压缩器412(来自图4a)产生具有非常特定的特性的分组流，以使得经由自主机服务210至显示设备422的整个路径所产生的分组序列不经受延迟或过多分组丢失，且详言之，始终如一地落在经由用户的互联网连接(经由WAN接口442及防火墙/路由器/NAT 433)而可用于用户的带宽的约束内。另外，视频压缩器必须产生足够强健的分组流，以使得其可容忍在正常互联网及网络传输中出现的不可避免的分组丢失及分组重排序。

[0161] 低延时视频压缩

[0162] 为了完成上述目标，一个实施例采用新的视频压缩方法，该方法降低用于传输视频的延时及峰值带宽要求。在描述该实施例之前，将关于图5及图6a至图6b提供对当前视频压缩技术的分析。当然，若用户具备足以处理所述技术所需的数据速率的带宽，则该技术可根据基本原理来使用。注意，本文中不解决音频压缩，而是陈述音频压缩与视频压缩同时且同步地来实施。满足用于该系统的要求的先前技术音频压缩技术存在。

[0163] 图5说明用于压缩视频的一个特定先前技术，其中由压缩逻辑520使用特定压缩算法来压缩每个个别视频帧501-503以产生一系列经压缩的帧511-513。该技术的一个实施例是“运动JPEG”，其中根据联合图像专家群(JPEG)压缩算法基于离散余弦变换(DCT)来压缩每一帧。可使用各种不同类型的压缩算法，然而，仍遵守该基本原理(例如，以小波为基础的压缩算法，诸如JPEG-2000)。

[0164] 此类型压缩的一个问题在于：其减小了每个帧的数据速率，但其不利用连续帧之间的类似性来减小总视频流的数据速率。举例而言，如图5中所说明，假定640×480×24比特/像素＝640*480*24/8/1024＝900千字节/帧(KB/帧)的帧速率，则对于给定质量的图像，运动JPEG可能仅将该流压缩1/10，从而产生90KB/帧的数据流。在60帧/秒下，此将需要90KB*8比特*60帧/秒＝42.2Mbps的信道带宽，其对于美国现今几乎所有的家庭互联网连接而言将为极高的带宽，且对于许多办公室互联网连接而言为过高的带宽。实际上，假定其在此种高带宽的情况下要求恒定数据流，且其将仅服务一个用户，则即使在办公室LAN环境中，其也将消耗100Mbps以太网LAN的带宽的大百分比及支持LAN的负担沉重的以太网交换器。因此，当与其他压缩技术(诸如下文所描述的那些技术)相比较时，用于运动视频的压缩无效率。此外，使用有损压缩算法的单个帧压缩算法(如JPEG及JPEG-2000)产生在静止图像中可能不引人注意的压缩假影(例如，场景中的密集树叶内的假影可能不呈现为假影，因为眼并不确切地知道密集树叶应如何呈现)。但是，一旦场景在运动中，假影就可能突出，因为眼侦测到自帧至帧而改变的假影，尽管假影在场景的区域(在该区域中，假影在静止图像中可能不引人注意)中。此导致帧序列中的“背景噪音”的感知，该“背景噪音”的外观与边缘模拟TV接收期间可见的“雪花”杂音类似。当然，该类型的压缩仍可用于本文中所描述的特定实施例中，但一般而言，为了避免场景中的背景噪音，对于给定感知质量，需要高数据速率(也即，低压缩比率)。

[0165] 其他类型的压缩(诸如，H.264，或Windows媒体VC9、MPEG2及MPEG4)在压缩视频流中均更有效，因为其利用连续帧之间的类似性。这些技术均依赖于用于压缩视频的相同的一般技术。因此，尽管将描述H.264标准，但相同的一般原理适用于各种其他压缩算法。大量H.264压缩器及解压缩器可用，包括用于压缩H.264的x264开放源软件库及用于解压缩H.264的FFmpeg(一种视频和音频流方案)开放源软件库。

[0166] 图6a及图6b说明例示性先前技术压缩技术，其中由压缩逻辑620将一系列未经压缩的视频帧501-503、559-561压缩成一系列“I帧”611、671；“P帧”612-613；及“B帧”670。图6a中的垂直轴大体表示经编码的帧中的每一者的所得大小(尽管所述帧未按比例进行绘制)。如上所述，本领域的技术人员良好地理解使用I帧、B帧及P帧的视频写码。简言之，I帧611为完全未压缩的帧501的基于DCT的压缩(类似于如上所述的经压缩的JPEG图像)。P帧612-613的大小通常显著小于I帧611的大小，因为其利用先前I帧或P帧中的数据；也即，其含有指示先前I帧或P帧之间的改变的数据。除B帧使用随后参考帧中的帧以及(可能地)之前参考帧中的帧之外，B帧670类似于P帧。

[0167] 对于以下论述，将假定所要的帧速率为60帧/秒，每个I帧为约160Kb，平均P帧及B帧为16Kb且每隔一秒产生一新的I帧。在该组参数下，平均数据速率将为：160Kb+16Kb*59＝1.1Mbps。该数据速率适当地落在用于到家庭及办公室的许多当前宽带互联网连接的最大数据速率内。该技术也倾向于避免来自仅帧内编码的背景噪音问题，因为P帧及B帧追踪帧之间的差异，因此压缩假影倾向于不自帧至帧而呈现及消失，从而减少上文所描述的背景噪音问题。

[0168] 上述类型的压缩的一个问题在于：尽管平均数据速率相对低(例如，1.1Mbps)，但单个I帧可能花费若干个帧时间来传输。举例而言，使用先前技术，2.2Mbps网络连接(例如，DSL或电缆调制解调器，其具有来自图3a的最大可用数据速率302的2.2Mbps峰值)通常将足够使视频以1.1Mbps流动，每60个帧一个160Kbps的I帧。这将通过使解压缩器在解压缩视频之前将1秒视频排入队列来完成。在1秒内，将传输1.1Mb的数据，其将通过2.2Mbps最大可用数据速率来容易地适应，即使假定可用数据速率可能周期性地下降多达
50％也如此。遗憾地，此先前技术方法将由于接收器处的1秒视频缓冲而导致视频的1秒延时。此种延迟对于许多先前技术应用程序(例如，线性视频的回放)而言足够，但对于不可容忍大于70毫秒-80毫秒的延时的快动作视频游戏而言其为极长的延时。

[0169] 若进行尝试来消除1秒视频缓冲，其仍将不会导致用于快动作视频游戏的足够延时减少。举例而言，如先前所述，B帧的使用将需要接收I帧的前的所有B帧以及I帧。若假定在P帧与B帧之间大致分裂59个非I帧，则将存在至少29个B帧且可显示任何B帧之前所接收的I帧。因此，不管信道的可用带宽如何，均需要29+1＝30个帧每一者1/60秒持续时间的延迟，或500毫秒的延时。显而易见，该时间极长。

[0170] 因此，另一方法将是消除B帧且仅使用I帧及P帧。(其中一个后果是：对于给定质量水平，数据速率将增加，但出于此实例中的一致性起见，继续假定每个I帧的大小为160Kb且平均P帧的大小为16Kb，且因此数据速率仍为1.1Mbps)。该方法消除了由B帧引入的不可避免的延时，因为每个P帧的解码仅依赖于先前所接收的帧。该方法仍存在的问题在于：I帧比平均P帧大得多，以致在低带宽信道上(如大多数家庭中及许多办公室中典型的)，I帧的传输添加实质延时。此在图6b中加以说明。视频流数据速率624低于可用最大数据速率621(除对于I帧之外)，其中I帧所需的峰值数据速率623远超过可用最大数据速率622(且甚至超过额定最大数据速率621)。P帧所需的数据速率小于可用最大数据速率。即使在2.2Mbps的可用最大数据速率峰值稳定地保持在其2.2Mbps峰值速率，也将花费160Kb/2.2Mb＝71毫秒来传输I帧，且若可用最大数据速率622下降50％(1.1Mbps)，则将花费142毫秒来传输I帧。因此，传输I帧中的延时将落在71毫秒与142毫秒之间的某处。该延时添加到图4b中所识别的延时(所述延时在最糟状况下总计达70毫秒)，因此，这将导致从用户致动输入设备421的时刻直到图像呈现于显示设备422上的为141-222毫秒的总来回行程延时，其极高。且若可用最大数据速率下降至低于2.2Mbps，则延时将进一步增加。

[0171] 还注意到，以远超过可用数据速率622的峰值数据速率623使ISP“堵塞”通常存在严重后果。不同ISP中的设备将不同地表现，但当以比可用数据速率622高得多的数据速率接收分组时，以下行为在DSL及电缆调制解调器ISP当中相当普遍：(a)通过将分组排入队列而使分组延迟(引入延时)，(b)丢弃一些或所有分组，(c)将连接停用一时间周期(最可能因为ISP担忧其为恶意攻击，诸如“否认服务”攻击)。因此，以全数据速率传输分组流(具有诸如图6b中所显示的所述特性的特性)并非为可行的选项。可在主机服务210处将峰值623排入队列且以低于可用最大数据速率的数据速率进行发送，从而引入前一段中所描述的不可接受的延时。

[0172] 另外，图6b中所显示的视频流数据速率序列624为非常“驯服的(tame)”视频流数据速率序列，且将是由于压缩来自视频序列的视频而预期产生的该种数据速率序列，该视频序列并不改变很大且具有非常少的运动(例如，如在视频电话会议中将是普遍的，在视频电话会议中，相机处于固定位置中且具有非常少的运动，且场景(例如，就座的人谈话)中的对象显示较少运动)。

[0173] 图6c中所显示的视频流数据速率序列634为从具有多得多的动作的视频(诸如，可能在电影或视频游戏中或在某应用程序软件中产生)预期可见的典型序列。注意，除I帧峰值633之外，还存在相当大且在许多场合上超过可用最大数据速率的P帧峰值(诸如，635及636)。尽管所述P帧峰值并不如I帧峰值一般相当大，但其仍极大以致不能由信道以全数据速率来运输，且如同I帧峰值一样，P帧峰值必须缓慢地传输(借此增加延时)。

[0174] 在高带宽信道(例如，100Mbps LAN，或高带宽100Mbps私用连接)上，网络将能够容忍诸如I帧峰值633或P帧峰值636的大峰值，但原则上，可维持低延时。但是，所述网络经常在许多用户当中共用(例如，在办公室环境中)，且该“有峰”数据将影响LAN的性能，尤其在网络通信经路由至私用共用连接(例如，从远程数据中心到办公室)的情况下。首先，记住此实例是60fps下640×480像素的相对低分辨率的视频流的实例。60fps下的1920×1080的HDTV流容易由现代计算机及显示器来处理，且60fps下的2560×1440分辨率显示器日益可用(例如，Apple公司的30"显示器)。使用H.264压缩，60fps下的1920×1080的高动作视频序列可能需要4.5Mbps以获得合理质量水平。若假定I帧峰值为标定数据速率的10倍，则其将产生45Mbps峰值，以及较小但仍相当大的P帧峰值。若若干个用户正在同一100Mbps网络(例如，办公室与数据中心之间的私用网络连接)上接收视频流，则容易看见来自若干用户的视频流的峰值可如何碰巧对准，从而淹没网络的带宽，且可能淹没网络上支持用户的交换器的底板的带宽。即使在超高速以太网的状况下，若足够的用户具有同时对准的足够峰值，则其可淹没网络或网络交换器。此外，一旦2560×1440分辨率视频变得更常见，平均视频流数据速率就可能为9.5Mbps，从而或许产生95Mbps峰值数据速率。不用说，数据中心与办公室之间的100Mbps连接(其在现今为格外快的连接)将完全被来自单一用户的峰值通信击溃。因此，即使LAN及私用网络连接对有峰流动视频可具有更高容忍度，具有高峰值的流动视频也是不需要的且可能需要办公室的IT部门的特殊计划及适应。

[0175] 当然，对于标准线性视频应用程序，该问题并不是问题，因为数据速率在传输点“经平滑化”且用于每一帧的数据低于最大可用数据速率622，且在解压缩I帧、P帧及B帧序列之前，客户端中的缓冲器储存I帧、P帧及B帧序列。因此，网络上的数据速率保持接近于视频流的平均数据速率。很遗憾地，这引入延时，即使不使用B帧，对于诸如需要快响应时间的视频游戏及应用程序的低延时应用程序而言，这也是不可接受的。

[0176] 用于减轻具有高峰值的视频流的一个先前技术解决方法是使用常常被称作“恒定比特速率”(CBR)编码的技术。尽管术语CBR看来似乎暗示将所有帧压缩以具有相同比特速率(也即，大小)，但其经常提及的为压缩范例，在压缩范例中，允许跨越特定数目的帧(在我们的状况下，1个帧)的最大比特速率。举例而言，在图6c的状况下，若对编码施加CBR约束(其将比特速率限于(例如)额定最大数据速率621的70％)，则压缩算法将限制所述帧中的每一者的压缩，以使得通常将使用额定最大数据速率621的70％以上来压缩的任何帧将以较少比特来压缩。这个结果是：将使通常将需要更多比特来维持给定质量水平的帧“极度缺乏”比特且所述帧的图像质量将比不需要比额定最大数据速率621的70％多的比特的其他帧的图像质量糟。此方法对于特定类型的经压缩视频(其中(a)预期较少运动或场景改变且(b)用户可接受周期性的质量降级)可产生可接受的结果。适合CBR的应用的良好实例为视频电话会议，因为存在较少峰值，且在质量暂时降级的情况下(例如，若使相机扫视，从而导致显著场景运动及大峰值，则在扫视期间可能不存在足够的比特用于高质量图像压缩，其将导致降级的图像质量)，大多数用户可接受。很遗憾地，CBR并非良好地适合具有高复杂度的场景或大量运动和/或需要合理恒定的质量水平的许多其他应用。

[0177] 在一个实施例中所使用的低延时压缩逻辑404使用若干不同技术来解决流动低延时经压缩视频同时维持高质量的许多问题。首先，低延时压缩逻辑404仅产生I帧及P帧，从而缓解等待若干个帧时间来解码每个B帧的需要。另外，如图7a中所说明，在一个实施例中，低延时压缩逻辑404将每个未经压缩的帧701-760再分成一系列“图像块(tile)”且将每个图像块个别地编码为I帧或P帧。在本文中将该群经压缩的I帧及P帧称作“R帧”711-770。在图7a中所显示的特定实例中，将每个未经压缩的帧再分成4×4矩阵的16个图像块。然而，所述基本原理不限于任何特定再分机制。

[0178] 在一实施例中，低延时压缩逻辑404将视频帧划分成许多图像块，且将来自每个帧的一个图像块编码(也即，压缩)为I帧(也即，将该图像块压缩，好像其为全图像的大小的1/16的单独视频帧，且用于此“迷你型”帧的压缩为I帧压缩)并将剩余图像块编码为P帧(也即，用于每个“迷你型”1/16帧的压缩为P帧压缩)。经压缩为I帧的图像块及经压缩为P帧的图像块将分别被称作“I图像块”及“P图像块”。随着每个相继视频帧而改变待编码为I图像块的图像块。因此，在给定帧时间中，视频帧中的所述图像块中仅一个图像块为I图像块，且所述图像块中的剩余者为P图像块。举例而言，在图7a中，未经压缩的帧701的图像块0经编码为I图像块I0且剩余的1-15图像块经编码为P图像块(P1至P15)以产生R帧711。在下一个未经压缩的视频帧702中，未经压缩的帧701的图像块1经编码为I图像块I1且剩余的图像块0及2至15经编码为P图像块(P0，及P2至P15)以产生R帧712。因此，用于图像块的I图像块及P图像块在相继帧上逐渐地在时间上交错。该过程继续，直至产生R图像块770(矩阵中最末图像块经编码为I图像块(也即，I15))为止。
该过程接着重新开始，从而产生诸如帧711(也即，对于图像块0，编码I图像块)等的另一个R帧。尽管图7a中未说明，但在一个实施例中，R帧的视频序列的第一R帧仅含有I图像块(也即，以使得随后的P帧具有参考图像数据(自其开始计算运动))。或者，在一实施例中，启动序列使用与正常相同的I图像块型样，但不包括用于尚未连同I图像块一起编码的所述图像块的P图像块。换言之，在第一I图像块到达之前不连同任何数据一起编码特定图像块，从而避免图9a中的视频流数据速率934中的启动峰值，其在下文进一步详细说明。此外，如下所述，各种不同大小及形状可用于所述图像块同时仍遵守所述基本原理。

[0179] 在客户端415上执行的视频解压缩逻辑412解压缩每个图像块，好像其为小I帧及P帧的单独视频序列，且接着将每个图像块再现给驱动显示设备422的帧缓冲器。举例而言，使用来自R帧711至770的I0及P0来解压缩并再现视频图像的图像块0。类似地，使用来自R帧711至770的I1及P1来重建图像块1，等等。如上所述，I帧及P帧的解压缩是这项技术中众所熟知的，且I图像块及P图像块的解压缩可通过使视频解压缩器的多个执行个体在客户端415上执行来完成。尽管倍增过程看来似乎增加客户端415上的计算负担，但实际上其不会增加客户端415上的计算负担，因为图像块本身成比例地较小(相对于额外处理的数目而言)，因此所显示的像素的数目相同，好像存在一个处理且使用传统的全大小的I帧及P帧。

[0180] 该R帧技术显著减轻通常与I帧相关联的带宽峰值(图6b及图6c中所说明)，因为任何给定帧主要是由通常比I帧小的P帧构成。举例而言，再次假定典型I帧为160Kb，则图7a中所说明的帧中的每一者的I图像块将为该量的大致1/16或10Kb。类似地，假定典型P帧为16Kb，则用于图7a中所说明的图像块中的每一者的P帧可为大致1Kb。最终结果为约10Kb+15*1Kb＝25Kb的R帧。因此，每一60帧序列将是25Kb*60＝1.5Mbps。因此，在60帧/秒下，这将需要能够维持1.5Mbps的带宽的信道，但由于I图像块是贯穿60帧间隔而分散而使得具有低得多的峰值。

[0181] 注意，在先前实例中，在用于I帧及P帧的相同假定数据速率情况下，平均数据速率为1.1Mbps。这是因为在先前实例中，每隔60个帧时间仅引入新I帧，而在此实例中，构成I帧的16个图像块在16个帧时间中循环，且因此，每隔16个帧时间引入I帧的均等物，从而导致稍高的平均数据速率。尽管如此，但在实践中，引入更频繁的I帧并不会线性地增加数据速率。这是由于以下事实：P帧(或P图像块)主要编码自先前帧至下一个帧的差异。因此，若先前帧与下一个帧相当类似，则P帧将非常小，若先前帧与下一个帧相当不同，则P帧将非常大。但因为P帧很大程度上是自先前帧导出，而非自实际帧导出，所以所得的经编码帧可能含有比具有足够数目的比特的I帧多的错误(例如，视觉假影)。此外，当一个P帧跟随另一P帧时，可出现错误累加(当存在长P帧序列时，变得更糟)。现在，尖端的视频压缩器将侦测到图像的质量在一序列P帧的后降级的事实，且必要时，其将更多比特分配给随后的P帧以提高质量，或若其为最有效的动作过程，则用I帧替换P帧。因此，当使用长P帧序列(例如，59个P帧，如上文先前实例中)时，特定言的当场景具有大量复杂度和/或运动时，通常，对于P帧而言需要更多比特(因为其变得距I帧更远)。

[0182] 或者，自相对观看点看P帧，紧密地跟随I帧的P帧倾向于需要比距I帧更远的P帧少的比特。因此，在图7a中所显示的实例中，没有P帧比距I帧隔开15个帧更远(在I帧之前)，而在先前实例中，P帧可能从I帧隔开59个帧。因此，在更频繁的I帧情况下，P帧较小。当然，确切相对大小将基于视频流的性质而改变，但在图7a的实例中，若I图像块为10Kb，则P图像块的大小平均可为仅0.75kb，从而导致10Kb+15*0.75Kb＝21.25Kb，或在60帧/秒下，数据速率将为21.25Kb*60＝1.3Mbps，或比1.1Mbps下的具有I帧随后跟着
59个P帧的流的数据速率高约16％。再一次，用于视频压缩的所述两种方法之间的相对结果将视视频序列而改变，但通常，我们凭经验发现，对于给定质量水平，使用R帧比使用I/P帧序列需要多约20％的比特。但是，当然，R帧急剧地减少峰值，这使视频序列在远小于I/P帧序列的延时下可用。

[0183] 可视视频序列的性质、信道的可靠性及可用数据速率而以多种不同方式来配置R帧。在替代实施例中，在4×4配置中使用不同于16的数目的图像块。举例而言，可在2×1或1×2配置中使用2个图像块，可在2×2、4×1或1×4配置中使用4个图像块，可在3×2、2×3、6×1或1×6配置中使用6个图像块或可在4×2(如图7b中所显示)、2×4、8×1或
1×8配置中使用8个图像块。注意，图像块不需要为方形，视频帧也不必为方形，或甚至矩形。可将图像块分解成最佳地适合所使用的视频流及应用程序的无论什么形状。

[0184] 在另一实施例中，I图像块及P图像块的循环不锁定到图像块的数目。举例而言，在8图像块4×2配置中，仍可如图7b中所说明而使用16循环序列。顺序的未经压缩的帧721、722、723各自经划分成8个图像块0-7，且每个图像块被个别压缩。自R帧731，仅图像块0被压缩为I图像块，且剩余图像块被压缩为P图像块。对于随后的R帧732，所有8个图像块被压缩为P图像块，且接着对于随后的R帧733，图像块1被压缩为I图像块且其他图像块均被压缩为P图像块。此外，如此对于16个帧继续进行排序，仅每隔一帧产生一个I图像块，因此在第15个帧时间期间(图7b中未图示)及在第16个帧时间期间产生用于图像块7的最末I图像块(使用所有的P图像块压缩R帧780)。接着，序列再次以图像块0被压缩为I图像块且其他图像块被压缩为P图像块开始。如在先前实施例中，整个视频序列的第一帧通常将均为I图像块，以提供用于从该点向前的P图像块的参考。I图像块及P图像块的循环甚至不需要为图像块的数目的偶倍数。举例而言，在8个图像块的情况下，在使用另一I图像块之前，具有一个I图像块的每一帧之后可为所有都为P图像块的
2个帧。在又一实施例中，若(例如)已知屏幕的特定区域具有更多运动(需要更频繁的I图像块)，而其他区域更为静态(例如，显示游戏的分数)(需要较不频繁的I图像块)，则与其他图像块相比，可更经常地将特定图像块连同I图像块一起进行排序。此外，尽管在图
7a-图7b中说明每个帧具有单个I图像块，但可在单个帧中编码多个I图像块(取决于传输信道的带宽)。相反地，特定帧或帧序列可在不具有I图像块(也即，仅P图像块)的情况下传输。

[0185] 前一段的方法适当起作用的原因在于：尽管不具有跨越每个单个帧而分散的I图像块看来似乎导致较大峰值，但系统的行为并不如此简单。因为每个图像块是与其他图像块分开进行压缩，所以当图像块变小时，每个图像块的编码可变得较不有效，因为给定图像块的压缩器不能够利用来自其他图像块的类似图像特征及类似运动。因此，与将屏幕划分成8个图像块相比较，将屏幕划分成16个图像块通常将导致较不有效的编码。但是，若将屏幕划分成8个图像块且其引起每隔8个帧(而非每隔16个帧)引入一个完全I帧的数据，则其导致总体上高得多的数据速率。因此，通过每隔16个帧(而非每隔8个帧)引入一个完全I帧，减小了总数据速率。而且，通过使用8个较大图像块(而非16个较小图像块)，减小了总数据速率，其也将由较大图像块引起的数据峰值减轻至某种程度。

[0186] 在另一实施例中，图7a及图7b中的低延时视频压缩逻辑404通过基于待压缩的视频序列的已知特性而通过设定预先配置或者基于每个图像块中的图像质量的正在进行的分析而自动地控制至R帧中的各图像块的比特的分配。举例而言，在一些竞赛视频游戏中，玩家的汽车(其为场景中相对无运动的)的前方占据屏幕的下半部的大部分，而屏幕的上半部完全被填满正接近的道路、建筑物及风景，其几乎总是在运动中。若压缩逻辑404将相等数目的比特分配给每个图像块，则图7b中的未经压缩的帧721中的屏幕的下半部上的图像块(图像块4-7)通常将以比图7b中的未经压缩的帧721中的屏幕的上半部中的图像块(图像块0-3)高的质量而压缩。若已知该特定游戏或游戏的此特定场景具有所述特性，则主机服务210的运营商可配置压缩逻辑404以将更多比特分配给屏幕的顶部的图像块(与分配给屏幕的底部处的图像块的比特相比)。或者，压缩逻辑404可在压缩帧之后估计图像块的压缩质量(使用许多压缩质量度量中的一者或多者，诸如峰值信号噪音比(PSNR))，且若确定在特定时间窗上，特定图像块始终如一地产生较佳质量结果，则其逐渐地将更多比特分配给产生较低质量结果的图像块，直至各种图像块达到类似水平的质量为止。在替代实施例中，压缩器逻辑404分配比特以在特定图像块或图像块群中达成较高质量。举例而言，其可提供较佳的总体感知外观，以在屏幕的中心具有比边缘处高的质量。

[0187] 在一个实施例中，为了改良视频流的特定区域的分辨率，视频压缩逻辑404使用较小图像块来编码视频流的具有相对多的场景复杂度和/或运动的区域(与视频流的具有相对少的场景复杂度和/或运动的区域相比)。举例而言，如图8中所说明，在一个R帧811(可能随后跟着具有相同图像块大小的一系列R帧(未图示))的一个区域中的移动人物805的周围使用较小图像块。接着，当人物805移动至图像的新区域时，在另一R帧812内的此新区域的周围使用较小图像块，如所说明。如上所述，各种不同大小及形状可用作“图像块”同时仍遵守所述基本原理。

[0188] 尽管上文所描述的循环I/P图像块实质上减小视频流的数据速率中的峰值，但其并不完全消除峰值，尤其在快速改变或高度复杂的视频图像(诸如在电影、视频游戏及某一应用程序软件下出现)的状况下。举例而言，在突然场景转变期间，复杂帧可能随后跟着完全不同的另一复杂帧。即使若干个I图像块可领先于场景转变仅几个帧时间，其在该情形下也没有帮助，因为新帧的材料与先前I图像块无关。在这种情形下(及在即使并非一切都改变，大量图像也改变的其他情形下)，视频压缩器404将确定将许多(若并非所有)P图像块更有效地写码为I图像块，且所导致的是所述帧的数据速率中的非常大的峰值。

[0189] 如先前所论述，其仅为对于大多数消费者级互联网连接(及许多办公室连接)的状况，其仅不可“堵塞”超过图6c中显示为622的可用最大数据速率以及额定最大数据速率621的数据。注意，额定最大数据速率621(例如，“6Mbps DSL”)实质上为对于考虑购买互联网连接的用户的销售数字，但通常其不保证性能水平。出于该应用的目的，其是不相关的，因为我们仅关注经由连接使视频流动时的可用最大数据速率622。因此，在图9a及图9c中，当描述对峰值问题的解决方法时，自曲线图省略额定最大数据速率，且仅显示可用最大数据速率922。视频流数据速率不得超过可用最大数据速率922。

[0190] 为了解决此问题，视频压缩器404进行的第一件事是确定峰值数据速率941，其为信道能够稳定地处理的数据速率。该速率可通过许多技术来确定。一种该技术是将越加变高的数据速率测试流自主机服务210逐渐发送至客户端415(图4a及图4b中)，且使客户端将关于分组丢失及延时的水平的反馈提供至主机服务。当分组丢失和/或延时开始显示尖锐增加时，其为达到可用最大数据速率922的指示。之后，主机服务210可逐渐地减小测试流的数据速率，直至客户端415报告在合理的时间周期中已接收到测试流(分组丢失处于可接受水平，且延时接近最小)为止。这确定峰值最大数据速率941，其接着将用作用于流动视频的峰值数据速率。随着时间的推移，峰值数据速率941将波动(例如，若家庭中的另一用户开始严重地使用互联网连接)，且客户端415将需要恒定地监视峰值数据速率941以观看分组丢失或延时是否增加(指示可用最大数据速率922下降至低于先前所确定的峰值数据速率941)，且若如此，则峰值数据速率941。类似地，若随着时间的推移，客户端415发现分组丢失及延时保持在最佳水平，则其可请求视频压缩器缓慢地增加数据速率以观看可用最大数据速率是否增加(例如，若家庭中的另一用户已停止对互联网连接的严重使用)，且再次等待直至分组丢失和/或较高延时指示已超过可用最大数据速率922为止，且可再次发现用于峰值数据速率941的较低水平，但该较低水平可能高于测试增加的数据速率之前的水平。因此，可通过使用该技术(及类似其的其他技术)而发现峰值数据速率941，且视需要而周期性地进行调整。峰值数据速率941确定可由视频压缩器404使用以使视频流动至用户的最大数据速率。用于确定峰值数据速率的逻辑可在用户场所211处和/或在主机服务210上加以实施。在用户场所211处，客户端设备415执行计算以确定峰值数据速率且将此信息传输回至主机服务210；在主机服务210处，主机服务处的服务器402执行计算以基于自客户端415所接收的统计数据(例如，峰值丢失、延时、最大数据速率等)而确定峰值数据速率。

[0191] 图9a显示具有实质场景复杂度和/或运动的实例视频流数据速率934，其是使用先前所描述且在图7a、图7b及图8中加以说明的循环I/P图像块压缩技术而产生。视频压缩器404经配置而以低于峰值数据速率941的平均数据速率输出经压缩的视频，且注意，大部分时间，视频流数据速率保持低于峰值数据速率941。数据速率934与图6c中所显示的视频流数据速率634(其是使用I/P/B或I/P帧而产生)的比较显示循环I/P图像块压缩产生平滑得多的数据速率。但在帧2倍峰值952(其接近2倍峰值数据速率942)及帧4倍峰值954(其接近4倍峰值数据速率944)下，数据速率仍超过峰值数据速率941，这是不可接受的。在实践中，即使对于来自快速改变的视频游戏的高动作视频，超过峰值数据速率941的峰值也在小于2％的帧中出现，超过2倍峰值数据速率942的峰值很少出现，且超过
3倍峰值数据速率943的峰值难得出现。但是，当其确实出现时(例如，在场景转变期间)，其所需的数据速率必须产生良好质量的视频图像。

[0192] 解决此问题的一个方式是简单地配置视频压缩器404以使得其最大数据速率输出为峰值数据速率941。遗憾地，峰值帧期间的所得视频输出质量不良，因为压缩算法“极度缺乏”比特。所导致的为当存在突然转变或快速运动时出现压缩假影，且及时地，用户开始认识到：当存在突然改变或快速运动时假影总是突然出现，且其可变得相当讨厌。

[0193] 尽管人的视觉系统对在突然改变或快速运动期间出现的视觉假影相当敏感，但对在所述情形下侦测到帧速率的减小并不是非常敏感。事实上，当所述突然改变出现时，看来似乎人的视觉系统专注于追踪所述改变，且若帧速率暂时从60fps下降到30fps且接着立即返回到60fps，则人的视觉系统不会注意到。此外，在非常急剧的转变(如突然场景改变)的状况下，若帧速率下降到20fps或甚至15fps且接着立即返回到60fps，则人的视觉系统不会注意到。只要帧速率减小仅偶尔出现，对于人观察者而言，看来似乎视频以60fps不断地执行。

[0194] 通过图9b中所说明的技术来利用人的视觉系统的此特性。服务器402(来自图4a及图4b)以稳定帧速率(在一个实施例中，在60fps下)产生未经压缩的视频输出流。时间线显示每个1/60秒每个帧961-970输出。自帧961开始，将每个未经压缩的视频帧输出至低延时视频压缩器404，低延时视频压缩器404在小于一帧时间的时间中压缩所述帧，产生用于第一帧的经压缩的帧1 981。经产生用于经压缩的帧1 981的数据可视如先前所描述的许多因素而较大或较小。若数据足够小以致可以峰值数据速率941在一帧时间(1/60秒)或小于一帧时间内将其传输至客户端415，则在传输时间(xmit时间)991(指示传输时间的持续时间的箭头的长度)期间将其传输。在下一个帧时间中，服务器402产生未经压缩的帧2 962，将其压缩成经压缩的帧2 982，且在小于一帧时间的传输时间992期间以峰值数据速率941将其传输至客户端415。

[0195] 接着，在下一个帧时间中，服务器402产生未经压缩的帧3 963。当由视频压缩器404来压缩未经压缩的帧3963时，所得的经压缩的帧3 983为比可以峰值数据速率941在一帧时间中传输的数据多的数据。因此，在传输时间(2倍峰值)993期间将其传输，其占据所有帧时间及下一个帧时间的一部分。现在，在下一个帧时间期间，服务器402产生另一未经压缩的帧4964且将其输出至视频压缩器404，但数据被忽略且通过974来说明。这是因为视频压缩器404经配置以忽略在其仍传输先前经压缩的帧时到达的其他未经压缩的视频帧。当然，客户端415的视频解压缩器将未能接收到帧4，但其简单地继续在显示设备422上显示帧3历时2个帧时间(也即，暂时将帧速率自60fps减小至30fps)。

[0196] 对于下一个帧5，服务器402输出未经压缩的帧5 965，将其压缩成经压缩的帧5985且在传输时间995期间在1帧内将其传输。客户端415的视频解压缩器解压缩帧5并将其显示于显示设备422上。接着，服务器402输出未经压缩的帧6 966，视频压缩器404将其压缩成经压缩的帧6 986，但此时所得的数据非常大。在传输时间(4倍峰值)996期间以峰值数据速率941传输经压缩的帧，但花费几乎4个帧时间来传输帧。在接下来的3个帧时间期间，视频压缩器404忽略来自服务器402的3个帧，且客户端415的解压缩器将帧6稳定地保持在显示设备422上历时4个帧时间(也即，暂时将帧速率自60fps减小至
15fps)。接着最后，服务器402输出帧10 970，视频压缩器404将其压缩成经压缩的帧10
987，且在传输时间997期间将其传输，且客户端415的解压缩器解压缩帧10并将其显示于显示设备422上且再一次视频以60fps重新开始。

[0197] 注意，尽管视频压缩器404丢弃了来自由服务器402产生的视频流的视频帧，但其不会丢弃音频数据(不管音频是以什么形式来的)，且当丢弃视频帧时视频压缩器404继续压缩音频数据并将其传输至客户端415，客户端415继续解压缩音频数据并将音频提供至由用户使用以回放音频的无论什么设备。因此在丢弃帧的周期期间，音频继续而不减弱。与经压缩的视频相比，经压缩的音频消耗相对小百分比的带宽，且因此不会对总数据速率有较大影响。尽管在数据速率图中的任一者中都未说明，但峰值数据速率941内总是存在经保留用于经压缩音频流的数据速率容量。

[0198] 选择刚刚在图9b中所描述的实例来说明在数据速率峰值期间帧速率如何下降，但未说明的是当使用先前所描述的循环I/P图像块技术时，所述数据速率峰值及随的发生的丢弃的帧很少，即使在高场景复杂度/高动作序列(诸如在视频游戏、电影及某个应用程序软件中出现的那些)期间也如此。因此，减小的帧速率罕有且暂时，且人的视觉系统不会侦测到它们。

[0199] 若将刚刚所描述的帧速率减小机制应用于图9a中所说明的视频流数据速率，则在图9c中说明所得的视频流数据速率。在此实例中，2倍峰值952已减小至平坦化的2倍峰值953，且4倍峰值955已减小至平坦化的4倍峰值955，且整个视频流数据速率934保持处于或低于峰值数据速率941。

[0200] 因此，使用上文所描述的技术，可经由通用互联网及消费者级互联网连接而以低延时来传输高动作视频流。另外，在LAN(例如，100Mbs以太网或802.11g无线网络)上或私用网络(例如，数据中心与办公室之间的100Mbps连接)上的办公室环境中，可在无峰值情况下传输高动作视频流，以使得多个用户(例如，以4.5Mbps传输60fps下的1920×1080)可使用LAN或共用私用数据连接，而不使重迭峰值淹没(overwhelm)网络或网络交换器底板。

[0201] 数据速率调整

[0202] 在一个实施例中，主机服务210最初评估信道的可用最大数据速率622及延时以确定用于视频流的适当数据速率且接着响应于此而动态地调整数据速率。为了调整数据速率，主机服务210可(例如)修改待发送至客户端415的视频流的图像分辨率和/或每秒帧数。而且，主机服务可调整经压缩视频的质量水平。当改变视频流的分辨率时(例如，自1280×720分辨率至640×360)，客户端415上的视频解压缩逻辑412可将图像按比例增加以在显示屏幕上维持相同图像大小。

[0203] 在一个实施例中，在信道完全掉线(drop out)的情形下，主机服务210将游戏暂停。在多人游戏的状况下，主机服务向其他用户报告该用户游戏已掉线和/或针对其他用户暂停所述游戏。

[0204] 丢弃或延迟的分组

[0205] 在一个实施例中，若数据由于图4a或图4b中的视频压缩器404与客户端415之间的分组丢失而丢失，或由于到达得过晚以致不能解压缩及满足经解压缩帧的延时要求的分组被无次序地接收而丢失，则视频解压缩逻辑412能够减轻视觉假影。在流动I/P帧实施中，若存在丢失/延迟的分组，则整个屏幕受影响，从而可能引起屏幕完全冻结一段时间周期或显示其他屏幕宽视觉假影。举例而言，若丢失/延迟的分组引起I帧的丢失，则在接收新的I帧之前，解压缩器将缺乏用于跟随的所有P帧的参考。若丢失P帧，则其将影响跟随的用于整个屏幕的P帧。视I帧出现之前有多久，这将具有较长或较短的视觉影响。使用如图7a及图7b中所显示的交错I/P图像块，丢失/延迟的分组不太可能影响整个屏幕，因为其仅影响受影响的分组中所含有的图像块。若每个图像块的数据是在个别分组内发送，则若分组丢失，则其仅影响一个图像块。当然，视觉假影的持续时间将取决于I图像块分组是否丢失及在P图像块丢失的情况下在I图像块出现之前将花费多少个帧。但是，假定屏幕上的不同图像块是通过I帧非常频繁地(可能每个帧)更新，则即使屏幕上的一图像块受影响，其他图像块也可能不受影响。另外，若某一事件引起若干分组同时丢失(例如，邻接DSL线的电力中的暂时中断数据流的尖峰信号)，则一些图像块将比其他图像块受到更大影响，但因为一些图像块将通过新的I图像块迅速地更新，所以其仅暂时受影响。而且，在流动I/P帧实施的情况下，不仅I帧为最关键帧，而且I帧极大，因此若存在引起丢弃/延迟的分组的事件，则与小得多的I图像块相比，I帧受影响存在较高机率(也即，若I帧的任何部分丢失，则根本不可能可解压缩I帧)。由于所有所述原因，与I/P帧的情况相比，当分组被丢弃/延迟时，使用I/P图像块导致小得多的视觉假影。

[0206] 一个实施例试图通过将经压缩的图像块智能地封装于TCP(传输控制协议)分组或UDP(用户数据报协议)分组内而减少丢失分组的效应。举例而言，在一个实施例中，只要可能，即将图像块与分组边界对准。图10a说明可如何在不实施此特征的情况下将图像块封装于一系列分组1001-1005内。具体言之，在图10a中，图像块越过分组边界且经无效率地封装以致单一分组的丢失导致多个帧的丢失。举例而言，若分组1003或1004丢失，则丢失三个图像块，导致视觉假影。

[0207] 相比之下，图10b说明用于将图像块智能地封装于分组内以减少分组丢失的效应的图像块封装逻辑1010。首先，图像块封装逻辑1010将图像块与分组边界对准。因此，图像块T1、T3、T4、T7及T2分别与分组1001-1005的边界对准。图像块封装逻辑也试图以可能的更有效的方式将图像块组合于分组内，而不越过分组边界。基于图像块中的每一者的大小，将图像块T1与T6组合于一个分组1001中；将T3与T5组合于一个分组1002中；将图像块T4与T8组合于一个分组1003中；将图像块T8添加至分组1004；且将图像块T2添加至分组1005。因此，在此方案下，单个分组丢失将导致不多于2个图像块(而非如图10a中所说明的3个图像块)的丢失。

[0208] 图10b中所显示的实施例的一个额外益处在于：图像块是以其在图像内被显示的不同次序进行传输。若邻近分组由于干扰传输的同一事件(其将影响屏幕上彼此不接近的区域)而丢失，则此方式在显示器上产生较不引人注意的假影。

[0209] 一个实施例使用前向纠错(FEC)技术来保护视频流的特定部分以使其免受信道错误的影响。如此项技术中已知，诸如里德-所罗门及Viterbi(维特比)的FEC技术产生纠错数据信息并将其附加至经由通信信道而传输的数据。若错误在基本数据(例如，I帧)中出现，则FEC可用于校正该错误。

[0210] FEC码增加传输的数据速率，因此理想地，其仅在最需要时使用。若数据正被发送，且其将不导致非常引人注意的视觉假影，则可较佳不使用FEC码来保护数据。举例而言，紧接于丢失的I图像块之前的P图像块将仅在屏幕上产生1/60秒的视觉假影(也即，屏幕上的图像块将不被更新)。此种视觉假影几乎不能被人眼侦测到。随着P图像块自I图像块进一步向后，丢失P图像块越加变得更引人注意。举例而言，若图像块循环型样为在I图像块再次可用之前I图像块随后跟着15个P图像块，则若紧接于I图像块之后的P图像块丢失，则其导致该图像块显示不正确的图像历时15个帧时间(在60 fps下，这将为250毫秒)。人眼将容易侦测到250毫秒的流的中断。因此，P图像块距新的I图像块越向后(也即，P图像块跟随I图像块越接近)，则假影越引人注意。如先前所论述，尽管如此，但一般而言，P图像块跟随I图像块越接近，用于该P图像块的数据越小。因此，跟随I图像块的P图像块不仅对于保护以免丢失而言更关键，而且其大小较小。此外，一般而言，需要保护的数据越小，保护其所需的FEC码越小。

[0211] 因此，如图11a中所说明，在一个实施例中，由于I图像块在视频流中的重要性，仅I图像块具备FEC码。因此，FEC 1101含有用于I图像块1100的纠错码且FEC 1104含有用于I图像块1103的纠错码。在此实施例中，对于P图像块不产生FEC。

[0212] 在图11b中所说明的一个实施例中，对于在丢失时最可能引起视觉假影的P图像块也产生FEC码。在此实施例中，FEC 1105提供用于前3个P图像块但不用于跟随的P图像块的纠错码。在另一实施例中，对于数据大小最小的P图像块产生FEC码(其将倾向于自选在I图像块的后最早出现的P图像块，其对于保护最为关键)。

[0213] 在另一实施例中，并非将FEC码连同图像块一起发送，而是将图像块传输两次，每次在不同分组中传输。若一分组丢失/延迟，则使用另一分组。

[0214] 在图11c中所显示的一个实施例中，产生分别用于与视频同时自主机服务传输的音频分组1110及1112的FEC码1111及1113。维持视频流中的音频的完整性特别重要，因为失真的音频(例如，滴答声或嘶嘶声)将导致特别不合需要的用户体验。FEC码帮助确保音频内容在客户端计算机415处无失真地再现。

[0215] 在另一实施例中，并非将FEC码连同音频数据一起发送，而是将音频数据传输两次，每次在不同分组中传输。若一个分组丢失/延迟，则使用另一分组。

[0216] 另外，在图11d中所说明的一个实施例中，FEC码1121及1123分别用于自客户端415上行传输到主机服务210的用户输入命令(例如，按钮按压)1120及1122。这是重要的，因为在视频游戏或应用程序中漏掉按钮按压或鼠标运动可能导致不合需要的用户体验。

[0217] 在另一实施例中，并非将FEC码连同用户输入命令数据一起发送，而是将用户输入命令数据传输两次，每次在不同分组中传输。若一个分组丢失/延迟，则使用另一分组。

[0218] 在一个实施例中，主机服务210评估与客户端415的通信信道的质量，以确定是否使用FEC，且若使用，则确定应对视频、音频及用户命令的何部分应用FEC。评估信道的“质量”可包括如上所述的诸如估计分组丢失、延时等的功能。若信道特别不可靠，则主机服务210可对所有I图像块、P图像块、音频及用户命令应用FEC。相比之下，若信道可靠，则主机服务210可仅对音频及用户命令应用FEC，或可不对音频或视频应用FEC，或可根本不使用FEC。可使用FEC的应用的各种其他排列，同时仍遵守所述基本原理。在一个实施例中，主机服务210不断地监视信道的状况且相应地改变FEC策略。

[0219] 在另一实施例中，参看图4a及图4b，当分组丢失/延迟，从而导致图像块数据的丢失时，或若可能由于特别糟的分组丢失而使得FEC不能够校正丢失的图像块数据，客户端415评估在将接收新的I图像块之前剩余多少个帧且将其与自客户端415至主机服务210的来回行程延时相比较。若来回行程延时小于新的I图像块应到达之前的帧的数目，则客户端415向主机服务210发送消息，请求新的I图像块。将此消息路由至视频压缩器404，且其并非产生用于数据已丢失的图像块的P图像块，而是产生I图像块。假定图4a及图
4b中所显示的系统经设计以提供通常小于80毫秒的来回行程延时，则这导致图像块被校正于80毫秒内(在60 fps下，帧具有16.67毫秒的持续时间，因此在全帧时间中，80毫秒延时将导致83.33毫秒内的经校正的图像块，83.33毫秒为5个帧时间，其为引人注意的中断，但远不及(例如)对于15个帧250毫秒中断引人注意)。当压缩器404脱离其通常的循环次序而产生此种I图像块时，若I图像块将引起所述帧的带宽超过可用带宽，则压缩器
404将延迟其他图像块的循环，以使得其他图像块在所述帧时间期间接收P图像块(即使在所述帧期间一个图像块通常将应为I图像块)，且接着通常的循环将自下一个帧开始继续，且通常将已接收到先前帧中的I图像块的图像块将接收I图像块。尽管此动作暂时延迟R帧循环的阶段，但其通常将在视觉上不引人注意。

[0220] 视频及音频压缩器/解压缩器实施

[0221] 图12说明一个特定实施例，其中使用多核和/或多处理器1200来并行地压缩8个图像块。在一实施例中，使用在2.66 GHz或更高下执行的双核处理器、四核Xeon(至强)CPU计算机系统，每个核心作为独立过程实施开源x264 H.264压缩器。然而，可使用各种其他硬件/软件配置，同时仍遵守所述基本原理。举例而言，CPU核心中的每一者可通过以FPGA实施的H.264压缩器来替换。在图12中所显示的实例中，核心1201-1208用于作为八个独立线绪来同时处理I图像块及P图像块。如此项技术中众所周知的，当前多核及多处理器计算机系统与诸如Microsoft Windows XP专业版(64比特版或者32比特版)及Linux的多线绪处理操作系统整合时，其固有地能够进行多线绪处理。

[0222] 在图12中所说明的实施例中，因为该8个核心中的每一者仅负责一个图像块，所以其很大程度上独立于其他核心而操作，每一者执行x264的单独实例化。使用以PCI Express x1为基础的DVI捕获卡(诸如，来自Netherlands的Microtronix of Oosterhout的Sendero视频成像IP开发板)来捕获640×480、800×600或1280×720分辨率下的未经压缩的视频，且卡上的FPGA使用直接存储器存取(DMA)来将所捕获的视频经由DVI总线传送至系统RAM中。将所述图像块配置成4×2配置1205(尽管其说明为方形图像块，但在该实施例中，其具有160×240分辨率)。x264的每个实例化被配置成压缩该8个160×240图像块中的一者，且其经同步化以使得在初始I图像块压缩的后每一核心进入一循环，每一帧与另一帧不同相，以压缩一I图像块继的以七个P图像块，如图12中所说明。

[0223] 在每一帧时间，使用先前所描述的技术将所得的经压缩图像块组合成分组流，且接着将经压缩图像块传输至目的地客户端415。

[0224] 尽管图12中未说明，但若组合的8个图像块的数据速率超过指定峰值数据速率941，则所有8个x264过程将暂时中止历时达必要的帧时间，直至已传输用于组合的8个图像块的数据为止。

[0225] 在一个实施例中，将客户端415实施为执行FFmpeg的8个实例化的PC上的软件。接收过程接收8个图像块，且将每一图像块路由至FFmpeg实例化，FFmpeg实例化解压缩图像块并将其再现至显示设备422上的适当图像块位置。

[0226] 客户端415接收来自PC的输入设备驱动器的键盘、鼠标或游戏控制器输入并将其传输到服务器402。服务器402接着应用所接收的输入设备数据并将其应用于在服务器402上执行的游戏或应用程序，服务器402为使用Intel 2.16GHz双核CPU执行Windows的PC。服务器402接着产生新帧并经由其DVI输出端将新帧自以主机板为基础的图形系统或者经由NVIDIA 8800GTX PCI Express卡的DVI输出端输出。

[0227] 同时，服务器402经由其数字音频输出端(例如，S/PDIF)输出由游戏或应用程序产生的音频，该数字音频输出端耦合至实施视频压缩的以双四核Xeon为基础的PC上的数字音频输入端。Vorbis开源音频压缩器用于使用可用于处理线绪的无论什么核心来与视频同时地压缩音频。在一个实施例中，完成压缩其图像块的核心首先执行音频压缩。接着将经压缩的音频连同经压缩的视频一起传输，并在客户端415上使用Vorbis音频解压缩器来解压缩经压缩的音频。

[0228] 主机服务服务器中心分配

[0229] 经由玻璃(诸如，光纤)的光以光在真空中的速度的某一部分行进，且因此可确定光在光纤中的确切传播速度。但是，在实践中，考虑用于路由延迟、传输无效率及其他耗用的时间，我们观察到互联网上的最佳延时反映较接近光速的50％的传输速度。因此，最佳1000英里来回行程延时为约22毫秒，且最佳3000英里来回行程延时为约64毫秒。因此，一美国海岸上的单个服务器将距离过远以致不能以所要的延时伺服另一海岸上的客户端(其可能达3000英里远)。然而，如图13a中所说明，若主机服务210服务器中心1300定位于美国的中心(例如，堪萨斯州、内布拉斯加州等)，以致至美国大陆中的任何点的距离为约1500英里或1500英里以下，来回行程互联网延时可低至32毫秒。参看图4b，注意：尽管用户ISP 453所允许的最糟状况延时为25毫秒，但通常，在DSL及电缆调制解调器系统的情况下我们观察到较接近10-15毫秒的延时。而且，图4b假定自用户场所211至主机代管中心210的最大距离为1000英里。因此，在所使用的典型的15毫秒的用户ISP来回行程延时及对于32毫秒的来回行程延时的1500英里的最大互联网距离的情况下，自用户致动输入设备421的时刻至在显示设备422上看见响应的总来回行程延时为1+1+15+32+1+16+6+8＝80毫秒。因此，通常可在1500英里的互联网距离上达成80毫秒响应时间。这将允许美国大陆中具有足够短的用户ISP延时453的任何用户场所存取在中心定位的单个服务器中心。

[0230] 在图13b中所说明的另一实施例中，主机服务210服务器中心HS1-HS6战略上定位于美国(或其他地理区域)的周围，特定较大的主机服务服务器中心接近高人口中心而定位(例如，HS2及HS5)。在一个实施例中，服务器中心HS1-HS6经由网络1301交换信息，网络1301可为互联网或私用网络或两者的组合。在多个服务器中心的情况下，可以较低延时向具有高用户ISP延时453的用户提供服务。

[0231] 尽管互联网上的距离的确为对经由互联网的来回行程延时有影响的因素，但有时很大程度上与延时无关的其他因素也起作用。有时经由互联网将分组流路由至距离远的位置且再次返回，从而导致来自长循环的延时。有时在路径上存在不适当操作的路由设备，从而导致传输的延迟。有时存在使路径超载的通信，其引入延迟。此外，有时，根本是存在防止用户的ISP路由至给定目的地的故障。因此，尽管通用互联网通常以相当可靠且最佳的路由及延时来提供从一点到另一点的连接，该相当可靠且最佳的路线及延时很大程度上是通过距离来确定(尤其是在导致路由至用户的本地区域的外部的长距离连接的情况下)，但该可靠性及延时得不到任何保证且常常不可自用户的场所至通用互联网上的给定目的地而达成。

[0232] 在一个实施例中，当用户客户端415最初连接到主机服务210以玩视频游戏或使用应用程序时，客户端在启动时与可用的主机服务服务器中心HS1-HS6中的每一者通信(例如，使用上文所描述的技术)。若延时对于特定连接而言足够低，则使用该连接。在一个实施例中，客户端与所有主机服务服务器中心或主机服务服务器中心的一个子集通信，选择具有最低延时连接的主机服务服务器中心。客户端可选择具有最低延时连接的服务中心，或服务器中心可识别具有最低延时连接的服务器中心并将此信息(例如，以互联网地址的形式)提供给客户端。

[0233] 若特定主机服务服务器中心超载和/或用户的游戏或应用程序可容忍至另一、较少载入的主机服务服务器中心的延时，则可将客户端415重定向至另一主机服务服务器中心。在此种情形下，将使用户正执行的游戏或应用程序在用户的超载服务器中心处的服务器402上暂停，且将游戏或应用程序状态数据传送至另一主机服务服务器中心处的服务器402。接着将重新开始该游戏或应用程序。在一个实施例中，主机服务210将等待直至游戏或应用程序达到自然暂停点(例如，游戏中的级别之间，或者在用户在应用程序中起始“保存”操作之后)才进行传送。在又一实施例中，主机服务210将等待直至用户活动停止历时指定时间周期(例如，1分钟)为止且接着将在这时起始传送。

[0234] 如上所述，在一个实施例中，主机服务210订阅图14的互联网旁路服务440以试图将得到保证的延时提供给其客户端。如本文中所使用的互联网旁路服务是提供自互联网上的一点至另一点的具有得到保证的特性(例如，延时、数据速率等)的私用网络路线的服务。举例而言，若主机服务210正使用在圣弗朗西斯科提供的AT&T的DSL服务接收来自用户的大量通信(而非路由至以AT&T的圣弗朗西斯科为基地的中央办公室)，则主机服务210将在以圣弗朗西斯科为基地的中央办公室与用于主机服务210的服务器中心中的一或多者之间租用来自服务提供者(可能为AT&T本身或另一提供者)的高容量私用数据连接。
接着，若自所有主机服务服务器中心HS1-HS6经由通用互联网至圣弗朗西斯科中使用AT&T DSL的用户的路线导致过高延时，则可改为使用私用数据连接。尽管私用数据连接通常比经由通用互联网的路线更昂贵，但只要其保持主机服务210的一小百分比连接至用户，总成本影响就低，且用户将体验到更一贯的服务体验。

[0235] 在电力故障的情况下，服务器中心常常具有两个备用电力层。第一层通常为来自电池(或来自替代的立即可用的能量源，诸如保持运转且附接至发电机的飞轮)的备用电力，其在电力干线出故障时立即提供电力且保持服务器中心运转。若电力故障为暂时的，且电力干线迅速返回(例如，在一分钟内)，则电池所需的是保持服务器中心运转。但若电力故障历时较长的时间周期，则通常启动发电机(例如，柴油机供电)来取代电池且发电机只要具有燃料即可运转。所述发电机极昂贵，因为其必须能够产生多达服务器中心通常自电力干线所得到的电力。

[0236] 在一个实施例中，主机服务HS1-HS5中的每一者彼此共用用户数据，以便在一个服务器中心具有电力故障时，其可将在进行中的游戏及应用程序暂停，且接着将游戏或应用程序状态数据自每个服务器402传送至其他服务器中心处的服务器402，且接着将通知每一用户的客户端415以指导其传达至新的服务器402。假定所述情形偶尔出现，则将用户转移至不能够提供最佳延时的主机服务服务器中心(也即，用户将仅必须容忍较高延时历时电力故障的持续时间)可为可接受的，其将允许用于转移用户的宽得多的范围的选项。举例而言，给定跨越美国的时区差，则东海岸上的用户在11:30PM可能将要睡眠，而西海岸上的用户在8:30PM正开始在视频游戏使用上达到峰值。若那时西海岸上的主机服务服务器中心中存在电力故障，则其他主机服务服务器中心处可能不存在用于处理所有用户的足够的西海岸服务器402。在此种情形下，可将一些用户转移至东海岸上具有可用服务器402的主机服务服务器中心，且对于用户而言的唯一后果将是较高延时。一旦将用户自失去电力的服务器中心转移，服务器中心接着就可开始其服务器及设备的有序切断，以便在电池(或其他立即电力备用)耗尽之前切断所有设备。以此方式，可避免用于服务器中心的发电机的成本。

[0237] 在一个实施例中，在主机服务210的严重载入的时间期间(或者由于峰值用户载入，或者因为一个或多个服务器中心出故障)，基于用户正使用的游戏或应用程序的延时要求将用户转移至其他服务器中心。因此，将为使用需要低延时的游戏或应用程序的用户给出对存在有限供应的可用低延时服务器连接的优选。

[0238] 主机服务特征

[0239] 图15说明在以下特征描述中利用的用于主机服务210的服务器中心的组件的实施例。如同图2a中所说明的主机服务210一样，除非另外有条件，否则此服务器中心的组件由主机服务210控制系统401来控制及协调。

[0240] 将来自用户客户端415的入埠互联网通信1501指引至入埠路由1502。通常，入埠互联网通信1501将经由至互联网的高速光纤连接而进入服务器中心，但具有足够带宽、可靠性及低延时的任何网络连接装置将是足够的。入埠路由1502是网络(该网络可实施为以太网、光纤信道网络，或经由任何其他输送装置)交换器及支持所述交换器的路由服务器的系统，其取得到达的分组且将每个分组路由到适当应用程序/游戏服务器1521-1525。在一实施例中，传送至特定应用程序/游戏服务器的分组表示自客户端所接收的数据的一子集和/或可由数据中心内的其他组件(例如，网络连接组件，诸如网关及路由器)来转译/改变。在一些状况下，(例如)若游戏或应用程序同时并行地在多个服务器上执行，则每次将分组路由至一个以上服务器1521-1525。RAID阵列1511-1512连接至入埠路由网络
1502，以使得应用程序/游戏服务器1521-1525可读取RAID阵列1511-1512及写入RAID阵列1511-1512。另外，RAID阵列1515(其可实施为多个RAID阵列)也连接至入埠路由
1502，且来自RAID阵列1515的数据可自应用程序/游戏服务器1521-1525来读取。入埠路由1502可在多种先前技术网络架构(包括树结构的交换器，入埠互联网通信1501在其根部)中实施；在互连所有各种设备的网状结构中实施；或作为互连的子网络序列(互通设备当中的集中通信与其他设备当中的集中通信隔离)来实施。一类型的网络配置为SAN(存储区域网络)，其尽管通常用于储存设备，但其也可用于设备之间的通用高速数据传送。又，应用程序/游戏服务器1521-1525可各自具有至入埠路由1502的多个网络连接。举例而言，服务器1521-1525可具有至附接至RAID阵列1511-1512的子网络的网络连接及至附接至其他设备的子网络的另一网络连接。

[0241] 应用程序/游戏服务器1521-1525可经相同地、有些不同地或全部不同地来配置，如先前关于图4a中所说明的实施例中的服务器402所描述的。在一实施例中，每一用户当使用主机服务时通常为至少一应用程序/游戏服务器1521-1525。出于说明的简单起见，将假定给定用户正使用应用程序/游戏服务器1521，但多个服务器可由一用户使用，且多个用户可共用单一应用程序/游戏服务器1521-1525。自客户端415(如先前所描述)所发送的用户的控制输入经接收为入埠互联网通信1501，且经由入埠路由1502而路由至应用程序/游戏服务器1521。应用程序/游戏服务器1521使用用户的控制输入作为至在服务器上执行的游戏或应用程序的控制输入，且计算视频及与其相关联的音频的下一个帧。应用程序/游戏服务器1521接着将未经压缩的视频/音频1529输出至共用视频压缩1530。应用程序/游戏服务器可经由任何装置(包括一或多个超高速以太网连接)而输出未经压缩的视频，但在一实施例中，视频是经由DVI(交互式数字视频系统)连接而输出，且音频及其他压缩及通信信道状态信息系经由通用串列总线(USB)连接而输出。

[0242] 共用视频压缩1530压缩来自应用程序/游戏服务器1521-1525的未经压缩的视频及音频。该压缩可完全以硬件或以执行软件的硬件来实施。可存在用于每个应用程序/游戏服务器1521-1525的专用压缩器，或若压缩器足够快，则可使用给定压缩器来压缩来自一个以上应用程序/游戏服务器1521-1525的视频/音频。举例而言，在60fps下，视频帧时间为16.67毫秒。若压缩器能够在1毫秒内压缩1帧，则该压缩器可用于通过取得来自一个接一个的服务器的输入而压缩来自多达16个应用程序/游戏服务器1521-1525的视频/音频，该压缩器保存每个视频/音频压缩过程的状态且当其在来自服务器的视频/音频流当中循环时切换背景。这导致压缩硬件的实质成本节省。因为不同服务器将在不同时间完成帧，所以在一个实施例中，压缩器资源是处于具有用于储存每个压缩过程的状态的共用储存装置(例如，RAM，闪存)的共用集区1530中，且当服务器1521-1525帧完整且准备被压缩时，控制装置确定那时哪个压缩资源可用，为该压缩资源提供服务器的压缩过程的状态及待压缩的未经压缩的视频/音频的帧。

[0243] 注意，用于每个服务器的压缩过程的状态的一部分包括关于压缩本身的信息，诸如先前帧的经解压缩的帧缓冲数据(其可用作用于P图像块的参考)、视频输出的分辨率；压缩的质量；图像块结构；每图像块的比特的分配；压缩质量、音频格式(例如，立体声、环绕音效、 AC-3 AC-3)。但是压缩过程状态也包括关于以下的通信信道
状态信息：峰值数据速率941，及先前帧(如图9b中所说明)当前是否正被输出(且因此应忽略当前帧)，及潜在地是否存在应在压缩中考虑的(诸如，过多分组丢失)影响压缩决策(例如，在I图像块的频率方面，等)的信道特性。因为峰值数据速率941或其他信道特性随着时间而改变，如由支持每个用户监视从客户端415发送的数据的应用程序/游戏服务器1521-1525所确定的，所以应用程序/游戏服务器1521-1525将相关信息发送至共用硬件压缩1530。

[0244] 共用硬件压缩1530也使用诸如先前所描述的所述装置的装置将经压缩的视频/音频分组化，且在适当时，应用FEC码，复制特定数据，或采取其他步骤，以便充分地确保视频/音频数据流由客户端415接收且以可行的高质量及可靠性解压缩的能力。

[0245] 一些应用程序(诸如，下文所描述的应用程序)需要给定应用程序/游戏服务器1521-1525的视频/音频输出同时在多个分辨率下(或以其他多个格式)可用。若应用程序/游戏服务器1521-1525如此通知共用硬件压缩1530资源，则该应用程序/游戏服务器1521-1525的未经压缩的视频音频1529将被以不同格式、不同分辨率和/或在不同分组/纠错结构中同时压缩。在一些状况下，一些压缩资源可在压缩同一视频/音频的多个压缩过程当中共用(例如，在许多压缩算法中，存在借以在应用压缩的前将图像按比例调整成多个大小的步骤。若需要输出不同大小的图像，则该步骤可用于同时服务若干个压缩过程)。在其他状况下，对于每个格式将需要单独的压缩资源。在任何状况下，将用于给定应用程序/游戏服务器1521-1525(一或多个)所需的所有各种分辨率及格式的经压缩的视频/音频1539同时输出到出埠路由1540。在一个实施例中，经压缩的视频/音频1539的输出是处于UDP格式，因此其为单向分组流。

[0246] 出埠路由网络1540包含一系列路由服务器及交换器，该系列路由服务器及交换器将每个经压缩的视频/音频流经由出埠互联网通信1599接口(其通常将连接到至互联网的光纤接口)而指引到有意的用户或其他目的地和/或返回至延迟缓冲器1515，和/或返回至入埠路由1502，和/或经由私用网络(未图示)而输出以供进行视频分配。注意(如下所述)：出埠路由1540可将给定视频/音频流同时输出至多个目的地。在一实施例中，这是使用互联网协议(IP)多播来实施，其中广播意欲同时流动到多个目的地的给定UDP流，且该广播由出埠路由1540中的路由服务器及交换器来重复。广播的该多个目的地可经由互联网而至多个用户的客户端415、经由入埠路由1502而到多个应用程序/游戏服务器1521-1525，和/或到一个或多个延迟缓冲器1515。因此，将给定服务器1521-1522的输出压缩成一个或多个格式，且将每个经压缩的流指引到一个或多个目的地。

[0247] 另外，在另一实施例中，若多个应用程序/游戏服务器1521-1525同时由一个用户使用(例如，在用于产生具有复杂场景的3D输出的并行处理配置中)且每个服务器产生所得图像的部分，则可由共用硬件压缩1530将多个服务器1521-1525的视频输出组合成一组合帧，且自该点向前如上所述处理该组合帧，好像其来自单个应用程序/游戏服务器1521-1525。

[0248] 注意，在一个实施例中，将由应用程序/游戏服务器1521-1525产生的所有视频的复本(至少以由用户观看的视频的分辨率或更高分辨率)记录于延迟缓冲器1515中历时至少某一数目的分钟(在一个实施例中为15分钟)。这允许每个用户“回放”来自每个会话的视频，以便核查先前工作或业绩(在游戏的状况下)。因此，在一个实施例中，将路由至用户客户端415的每个经压缩视频/音频输出1539流也多播至延迟缓冲器1515。当将视频/音频储存于延迟缓冲器1515上时，延迟缓冲器1515上的目录提供应用程序/游戏服务器1521-1525(其为延迟的视频/音频的来源)的网络地址与延迟缓冲器1515上可发现延迟的视频/音频的位置之间的交叉参考。

[0249] 现场直播的、可即刻观看的、可即刻播放的游戏

[0250] 应用程序/游戏服务器1521-1525不仅可用于执行用户的给定应用程序或视频游戏，而且其可用于建立用于支持经由主机服务210的导航及其他特征的主机服务210的用户接口应用程序。一种该用户接口应用程序的屏幕拍摄显示在图16中(“游戏取景器(Game Finder)”屏幕)。该特定用户接口屏幕允许用户观看由其他用户现场玩的(或延迟的)15个游戏。“缩略图”视频窗中的每一者(诸如，1600)为在运动中的现场直播的视频窗，其显示来自一个用户的游戏的一个视频。缩略图中所显示的视图可为用户正看的同一视图，或其可为延迟的视图(例如，若用户正玩搏斗游戏，则用户可能不希望其他用户看见其隐藏在哪里且其可选择将其游戏播放的任何视图延迟一时间周期(例如，10分钟))。视图也可为不同于任何用户的视图的游戏的相机视图。通过菜单选择(此说明中未图示)，用户可基于多种标准来选择要同时观看的游戏的选择。作为例示性选择的小取样，用户可选择游戏的随机选择(诸如图16中所显示的游戏)、所有一个类别的游戏(均由不同玩家来玩)、仅游戏的顶级玩家、游戏中的给定级别的玩家，或较低级玩家(例如，若玩家正学习基础)、是“搭档”(或为竞争者)的玩家、具有最多数目观看者的游戏等。

[0251] 注意，通常，每个用户将决定来自其游戏或应用程序的视频是否可由他人观看，且若如此，则决定该视频可由哪些他人观看及何时可由他人观看，决定该视频是否只可在具有延迟的情况下观看。

[0252] 产生图16中所显示的用户接口屏幕的应用程序/游戏服务器1521-1525通过向每个用户(该应用程序/游戏服务器1521-1525正请求来自该用户的游戏)的应用程序/游戏服务器1521-1525发送消息而获取该15个视频/音频馈送。该消息经由入埠路由1502或另一网络来发送。该消息将包括被请求的视频/音频的大小及格式，且将识别观看用户接口屏幕的用户。给定用户可选择选择“盗版”模式且不准许任何其他用户观看其游戏的视频/音频(自其观看点或者自另一观看点)，或如先前的段中所描述，用户可选择允许观看来自其游戏的视频/音频，但延迟所观看的视频/音频。用户应用程序/游戏服务器1521-1525(其接收并接受允许其视频/音频被观看的请求)将因此向请求服务器确认，且其也将通知共用硬件压缩1530需要产生被请求格式或屏幕大小(假定格式及屏幕大小不同于已经产生的格式及屏幕大小)的额外经压缩视频流，且其也将指示经压缩视频的目的地(也即，请求服务器)。若被请求的视频/音频仅被延迟，则请求应用程序/游戏服务器1521-1525将被这样通知，且其将通过查找延迟缓冲器1515上的目录中的视频/音频的位置及为延迟的视频/音频的来源的应用程序/游戏服务器1521-1525的网络地址而自延迟缓冲器1515获取延迟的视频/音频。一旦所有该请求被产生并处理，则将高达15个现场直播的缩略图大小的视频流从出埠路由1540路由到入埠路由1502、到产生用户接口屏幕的应用程序/游戏服务器1521-1525，且将由该服务器来解压缩及显示。延迟的视频/音频流可能处于过大的屏幕大小，如果这样，则应用程序/游戏服务器1521-1525将解压缩所述流并将视频流按比例缩减至缩略图大小。在一个实施例中，将对音频/视频的请求发送到与图4a的主机服务控制系统类似的中央“管理”服务(图15中未显示)(且由中央“管理”服务来管理)，中央“管理”服务接着将所述请求重定向到适当应用程序/游戏服务器
1521-1525。此外，在一个实施例中，可能不需要请求，因为缩略图被“推送”至允许其的那些用户的客户端。

[0253] 来自15个游戏的所有同时混合的音频可能产生刺耳的声音。用户可选择以此方式将所有声音混合在一起(可能就为得到由被观看的所有动作产生的“喧嚣”的感觉)，或者用户可选择每次仅收听来自一个游戏的音频。单个游戏的选择是通过将黄色选择帧1601(显示为图16的黑白再现中的黑色矩形轮廓线)移动到给定游戏来完成(黄色帧移动可通过使用键盘上的箭头键、通过移动鼠标、通过移动操纵杆或通过推动诸如移动电话的另一设备上的方向按钮来完成)。一旦选择了单个游戏，则只有来自该游戏的音频播放。
而且，显示游戏信息1602。在该游戏的状况下，例如，出版商标志(例如，“电子艺界公司(Electronic Arts)”的“EA”)及游戏标志例如“极品飞车卡本峡谷”及橙色横条(在图16中被再现为具有垂直条纹的横条)在相对条件下指示在该特定时刻玩游戏或观看游戏的人的数目(在此状况下，许多，因此游戏为“热门”)。另外提供“状态”(即，统计)，指示存在145个玩家正积极地玩极品飞车游戏的80个不同具体实例(也即，该游戏可通过个别玩家游戏或多人游戏来玩)，且存在680个观看者(此用户是其中之一)。注意，该统计数据(及其他统计数据)由主机服务控制系统401来收集并储存于RAID阵列1511-1512上，以用于保持主机服务210操作的日志且用于适当地向用户计费并向提供内容的出版商支付费用。一些统计数据是由于由服务控制系统401进行的动作而记录，且一些统计数据是由个别应用程序/游戏服务器1521-1525报告给服务控制系统401。举例而言，当游戏正被观看时(及当游戏被停止观看时)，执行此游戏取景器应用程序的应用程序/游戏服务器
1521-1525向主机服务控制系统401发送消息，以使得主机服务控制系统401可更新多少个游戏处于观看中的统计数据。一些统计数据可为用户接口应用程序(诸如，此游戏取景器应用程序)所用。

[0254] 若用户单击其输入设备上的启动按钮，则在继续播放现场直播视频的同时，其将看见黄色帧中的缩略图视频放大为全屏幕大小。该效果显示在图17中的过程中。注意，视频窗1700的大小增大。为了实施该效果，应用程序/游戏服务器1521-1525从运行选定的游戏的应用程序/游戏服务器1521-1525请求具有路由到其的游戏的全屏幕大小(以用户的显示设备422的分辨率)的视频流的复本。执行游戏的应用程序/游戏服务器1521-1525通知共用硬件压缩器1530不再需要游戏的缩略图大小的复本(除非另一应用程序/游戏服务器1521-1525需要这种缩略图)，且接着其指引共用硬件压缩器1530将视频的全屏幕大小的复本发送至放大视频的应用程序/游戏服务器1521-1525。玩该游戏的用户可或可不具有分辨率与将游戏放大的用户的所述显示设备的分辨率相同的显示设备422。另外，游戏的其他观看者可或可不具有分辨率与将游戏放大的用户相同的显示设备422(且可具有不同的音频回放装置，例如，立体声或环绕音效)。因此，共用硬件压缩器1530确定是否已经产生满足请求视频/音频流的用户的要求的合适的经压缩视频/音频流，且若合适的经压缩视频/音频流确实存在，则共用硬件压缩器1530通知出埠路由1540将该流的复本路由至放大该视频的应用程序/游戏服务器1521-1525，且若合适的经压缩视频/音频流不存在，则压缩视频的适合于所述用户的另一复本并指导出埠路由将该流发送回至入埠路由1502及放大该视频的应用程序/游戏服务器1521-1525。现在接收选定视频的全屏幕版本的该服务器将解压缩该全屏幕版本并将其逐渐地按比例放大至全大小。

[0255] 图18说明在将游戏完全放大至全屏幕且以用户的显示设备422的全分辨率显示游戏之后屏幕看起来如何(如通过箭头1800指向的图像所指示的)。执行游戏取景器应用程序的应用程序/游戏服务器1521-1525向提供缩略图的其他应用程序/游戏服务器1521-1525发送消息以指示所述缩略图不再需要且向主机服务控制服务器401发送消息以指示不再观看其他游戏。此时，产生的唯一显示为屏幕顶部的叠加层(overlay)1801，其将信息及菜单控制提供给用户。注意，随着该游戏进展，观众增长至2,503个观看者。在如此多的观看者的情况下，必然存在具有显示设备422的许多观看者，所述显示设备422具有相同或接近相同的分辨率(每个应用程序/游戏服务器1521-1525具有按比例调整视频以用于调整配合度的能力)。

[0256] 因为所显示的游戏为多人游戏，所以用户可决定在某时刻加入该游戏。由于多种原因，主机服务210可或可不允许用户加入该游戏。举例而言，用户可能必须支付玩游戏的费用而选择不支付，用户可能不具有足以加入所述特定游戏的足够等级(例如，对于其他玩家而言，其将不有竞争性)，或者用户的互联网连接可能不具有足以允许用户玩的足够低的延时(例如，不存在用于观看游戏的延时约束，因此可在无延时关注的情况下观看被远距离地(实际上，在另一大陆上)玩的游戏，但对于待玩的游戏而言，延时必须足够低以使用户(a)享受该游戏，且(b)处于与可能具有较低延时连接的其他玩家相等的地位)。若准许用户玩，则为用户提供游戏取景器用户接口的应用程序/游戏服务器1521-1525将请求主机服务控制服务器401初始化(也即，定位并启动)被合适地配置以用于播放特定游戏的应用程序/游戏服务器1521-1525从而从RAID阵列1511-1512载入该游戏，且接着主机服务控制服务器401将指导入埠路由1502将来自用户的控制信号传送至现在对游戏进行主机代管的应用程序/游戏服务器且现在对游戏进行主机代管的应用程序/游戏服务器将指导共用硬件压缩1530自压缩来从主机代管游戏取景器应用程序的应用程序/游戏服务器的视频/音频切换至压缩来自现在对游戏进行主机代管的应用程序/游戏服务器的视频/音频。游戏取景器应用程序/游戏服务与对游戏进行主机代管的新的应用程序/游戏服务器的垂直同步并不同步，且因此在该两个同步之间可能存在时间差。因为共用视频压缩硬件1530将在应用程序/游戏服务器1521-1525完成视频帧之后即开始压缩视频，所以来自新服务器的第一帧可比旧服务器的全帧时间完成得早，来自新服务器的第一帧可能在先前经压缩的帧完成其传输之前(例如，考虑图9b的传输时间992：若未经压缩的帧3 963早一帧时间的一半地完成，则其将影响(impinge)传输时间992)。在这种情形下，共用视频压缩硬件1530将忽略来自新服务器的第一帧(例如，如忽略(974)帧4 964)，且客户端415将来自旧服务器的最末帧保持额外一帧时间，且共用视频压缩硬件1530将开始压缩来自对游戏进行主机代管的新应用程序/游戏服务器的下一帧时间视频。对于用户而言，在视觉上，从一个应用程序/游戏服务器至另一应用程序/游戏服务器的转变将是无缝的。
主机服务控制服务器401接着将通知对游戏取景器进行主机代管的应用程序/游戏服务器
1521-1525切换至闲置状态，直至再次需要其为止。

[0257] 用户接着能够玩该游戏。此外，例外的是游戏将在感知上即刻地播放(因为游戏已被以十亿比特/秒速度从Raid阵列1511-1512载入到应用程序/游戏服务器1521-1525上)，且将通过理想的驱动器、暂存器配置(在Windows的状况下)将游戏连同被正确配置以用于该游戏的操作系统一起载入到准确适合于该游戏的服务器上，且没有可能与该游戏的操作竞争的其他应用程序在该服务器上执行。

[0258] 而且，随着用户在游戏中进展，游戏的片段中的每一者将以十亿比特/秒的速度(也即，在8秒内载入十亿字节)从RAID阵列1511-1512载入服务器中，且由于RAID阵列1511-1512的巨大储存容量(因为其为许多用户的共用资源，所以其可能非常大，但仍具成本效益)，使得可预先计算几何形状设置或其他游戏片段设置并将其储存于RAID阵列1511-1512上且极快速地进行载入。此外，因为每个应用程序/游戏服务器1521-1525的硬件配置及计算能力是已知的，所以可预先计算像素及顶点着色。

[0259] 因此，游戏可几乎即刻启动，其将在理想环境中执行，且随后的片段将几乎即刻载入。

[0260] 但是，除这些优点之外，用户将能够观看他人玩游戏(经由先前所描述的游戏取景器，及其他装置)，且两者均决定游戏是否有趣，如果这样，则自观看他人来学习技巧。此外，用户将能够即刻地演示该游戏，而不必等待大的下载和/或安装，且用户将能够即刻玩该游戏(可能在较小费用的试用基础上，或在较长期的基础上)。此外，用户将能够通过足够低延时的无线连接(虽然对于仅观看而言，延时不是一个问题)而在Windows PC、Macintosh上、在电视机上、在家里、在行进时且甚至在移动电话上玩该游戏。此外，这均可在并非曾经实体拥有游戏复本的情况下完成。

[0261] 如先前所叙述，用户可决定不允许其游戏播放可被他人观看，允许其游戏可在延迟之后观看，允许其游戏可被选定用户观看，或允许其游戏可被所有用户观看。不管怎样，在一个实施例中，将视频/音频储存于延迟缓冲器1515中历时15分钟，且用户将能够“回倒”并观看其先前的游戏播放，且将游戏暂停，将游戏缓慢地回放，将游戏快进等，正如其在观看具有数字视频记录器(DVR)的TV时所能够进行的。尽管在该实例中，用户在玩游戏，但若用户正使用应用程序，则相同“DVR”能力是可用的。这在核查先前工作中及在如下详述的其他应用中可是有用的。另外，若游戏经设计为具有基于利用游戏状态信息而回倒的能力，以便可改变相机视图等，则也将支持此“3D DVR”能力，但其将需要将游戏设计为支持“3D DVR”能力。使用延迟缓冲器1515的“DVR”能力将连同任何游戏或应用程序(当然，限于在使用游戏或应用程序时所产生的视频)一起起作用，但在具有3D DVR能力的游戏的状况下，用户可控制先前所播放的片段的3D“飞越(fly-through)”，且使延迟缓冲器1515记录所得视频并记录游戏片段的游戏状态。因此，将特定“飞越”记录为经压缩的视频，但因为也将记录游戏状态，所以不同的飞越将可能在游戏的同一片段的稍后日期。

[0262] 如下所述，主机服务210上的用户将各自具有一个用户页面，在该用户页面中，用户可公布关于其本身的信息及其他数据。用户将能够公布的事情之一为来自其已保存的游戏播放的视频片段。举例而言，若用户已克服游戏中的特别困难的挑战，则用户可刚好“回倒”到其在游戏中获得其大成果的地点之前，且接着指导主机服务210将某一持续时间(例如，30秒)的视频片段保存在用户的用户页面上以供其他用户观看。为了实施这些，用户正使用的应用程序/游戏服务器1521-1525仅要做的事情是将储存于延迟缓冲器1515中的视频回放至RAID阵列1511-1512且接着在用户的用户页面上给所述视频片段编索引。

[0263] 若游戏具有3D DVR的能力，如上所述，则也可由用户来记录3D DVR所需的游戏状态信息且使其为用户的用户页面可用。

[0264] 在游戏经设计为除具有活跃玩家外还具有“旁观者”(也即，能够在不参与的情况下在3D世界行进并观察到动作的用户)的情况下，则游戏取景器应用程序将使用户能够作为旁观者以及玩家加入游戏。从观看的实施点看，对于主机系统210而言，用户是旁观者而不是活跃玩家是不存在差异的。将游戏载入应用程序/游戏服务器1521-1525上且用户将控制该游戏(例如，控制观看世界的虚拟相机)。唯一的差异是用户的游戏体验。

[0265] 多个用户合作

[0266] 主机服务210的另一特征是多个用户在观看现场直播的视频的同时合作的能力(即使使用迥然不同的设备来观看也如此)。当玩游戏时及当使用应用程序时，这都有用。

[0267] 许多PC及移动电话装备有视频相机且具有进行实时视频压缩的能力(尤其当图像小时)。而且，小相机是可用的，可附接到电视，且以软件或使用用于压缩视频的许多硬件压缩设备中的一者来实施实时压缩并不困难。而且，许多PC及所有移动电话具有麦克风，且耳机在具有麦克风情况下可用。

[0268] 组合有本地视频/音频压缩能力(具体来说，使用本文中所描述的低延时视频压缩技术)的所述相机和/或麦克风将使用户能够将视频和/或音频连同输入设备控制数据一起从用户场所211传输到主机服务210。当使用所述技术时，则可实现图19中所说明的能力：用户可使其视频及音频1900出现在另一用户的游戏或应用程序内的屏幕上。该实例为多人游戏，其中队友在赛车中合作。用户的视频/音频仅可被其队友选择性地观看/听到。此外，因为使用上文所描述的技术将有效地不存在延时，所以玩家将能够实时地彼此谈话或进行运动而没有可感知的延迟。

[0269] 该视频/音频整合是通过使来自用户的相机/麦克风的经压缩视频和/或音频作为入埠互联网通信1501到达而完成。接着，入埠路由1502将该视频和/或音频路由到被准许观看/听到视频和/或音频的应用程序/游戏服务器1521-1525。接着，选择使用视频和/或音频的各别应用程序/游戏服务器1521-1525的用户解压缩视频和/或音频且视需要而将其整合以出现于游戏或应用程序内，诸如通过1900所说明的。

[0270] 图19的实例显示如何在游戏中使用该合作，但该合作可为用于应用程序的极其强大的工具。考虑一各情形：其中一大建筑物正由在芝加哥的建筑师为以纽约为基地的房地产开发商为纽约市设计，但该决策涉及在旅游中且碰巧在迈阿密机场的财务投资者，且需要进行关于建筑物的特定设计要素(在其如何搭配其附近的建筑物方面)的决策，以满足投资者与房地产开发商两者。假定建筑公司在芝加哥具有具有附接到PC的相机的高分辨率监视器，房地产开发商在纽约具有带相机的笔记本计算机，且投资者在迈阿密具有带相机的移动电话。建筑公司可使用主机服务210来对能够进行高度逼真3D再现的强大的建筑设计应用程序进行主机代管，且其可利用纽约市的建筑物的大数据库，以及正设计的建筑物的数据库。建筑设计应用程序将在应用程序/游戏服务器1521-1525中的一者上(或若其需要大量计算能力，则在若干者上)执行。处于全异(disparate)位置处的3个用户中的每一者将连接至主机服务210，且每一者将具有对建筑设计应用程序的视频输出的同时观看，但其将被针对每个用户具有的给定设备及网络连接特性而由共用硬件压缩1530适当地设定大小(例如，建筑公司可经由20Mbps商用互联网连接看见2560×1440 60fps显示，纽约的房地产开发商可经由其笔记本计算机上的6Mbps DSL连接看见1280×72060fps图像，且投资者可经由其移动电话上的250Kbps蜂窝式数据连接看见320×180
60fps图像)。每一方将听到其他方的语音(将通过应用程序/游戏服务器1521-1525中的许多广泛可用的会议呼叫套装软件中的任一者来处理会议呼叫)，且经由用户输入设备上的按钮的致动，用户将能够使用其本地相机使视频出现。随着会议进行，建筑师将能够通过极具照片般逼真感的3D再现显示当其使建筑物旋转且使其邻接该区域中的另一建筑物飞越(fly-by)时建筑物看起来像什么，且所有方均将在各方的显示设备的分辨率下可见到相同视频。由任何方使用的本地设备中的任一者均能够以该真实感处理3D动画不是问题，更不用说下载或甚至储存再现纽约市的周围建筑物所需的巨大数据库。自用户中的每一者的观点看，尽管距离很远，且尽管是全异本地设备，但其将简单地在难以置信的真实感程度下具有无缝体验。此外，当一方希望其面部被看来较佳地传达其情绪状态时，其可如此进行。另外，若房地产开发商或投资者希望控制建筑程序且使用其自身的输入设备(其为键盘、鼠标、小键盘或触摸屏幕)，则其可如此，且其可以用无感知的延时来响应(假定其网络连接不具有不合理的延时)。举例而言，在移动电话的状况下，若移动电话连接至机场的WiFi网络，则其将具有非常低的延时。但若其使用美国现今可用的蜂窝式数据网络，则其很可能将遭受引人注意的滞后。但是，对于会议的大多数目的(其中投资者正观看建筑师控制建筑物飞越或正谈论视频电话会议)，甚至蜂窝式延时也应是可接受的。

[0271] 最后，在合作性会议呼叫结束时，房地产开发商及投资者将进行其评论且从主机服务停播，建筑公司将能够“回倒”已记录在延迟缓冲器1515上的会议的视频且核查在会议期间进行的应用于建筑物的3D模型的评论、面部表情和/或动作。若存在其希望保存的特定片段，则可将视频/音频的所述片段自延迟缓冲器1515移动至RAID阵列1511-1512以用于档案储存及稍后回放。

[0272] 而且，从成本观点看，若建筑师仅需要使用纽约市的计算能力及大数据库历时15分钟的会议呼叫，则其仅需要支付所述资源被使用的时间的费用，而不必拥有高能力的工作台且不必购买大数据库的昂贵复本。

[0273] 视频丰富的社区服务

[0274] 主机服务210使得有空前机会来在互联网上建立视频丰富的社区服务。图20显示用于主机服务210上的游戏玩家的例示性用户页面。如同游戏取景器应用程序一样，用户页面为在应用程序/游戏服务器1521-1525中的一者上执行的应用程序。该页面上的所有缩略图及视频窗显示恒定地移动的视频(若片段短，则其循环)。

[0275] 使用视频相机或通过上传视频，用户(其用户名为“KILLHAZARD”)能够公布其本身的视频2000(其他用户可观看该视频)。该视频储存于RAID阵列1511-1512上。而且，当其他用户来到KILLHAZARD的用户页面时，若KILLHAZARD此时正使用主机服务210，则将显示其正进行的无论什么的现场直播的视频2001(假定KILLHAZARD准许观看其用户页面的用户观看该视频)。这将由对用户页面应用程序进行主机代管的应用程序/游戏服务器1521-1525从服务控制系统401请求KILLHAZARD是否为活跃的(且若如此，则请求其正使用的应用程序/游戏服务器1521-1525)来完成。接着，使用由游戏取景器应用程序使用的相同方法，将合适分辨率及格式的经压缩的视频流发送至执行用户页面应用程序的应用程序/游戏服务器1521-1525且将其显示。若用户选择具有KILLHAZARD的现场直播的游戏播放的窗口且接着适当地单击其输入设备，则该窗口将放大(再次使用与游戏取景器应用程序相同的方法)，且现场直播的视频将以观看用户的显示设备422的分辨率(适合于观看用户的互联网连接的特性)填充屏幕。

[0276] 这优于先前技术方法的关键优点是：观看用户页面的用户能够看见用户不拥有的现场直播地播放的游戏，且可不具有能够玩该游戏的本地计算机或游戏控制台。其为用户提供看用户页面中显示为“活动中”的用户玩游戏的极好机会，且这是了解观看用户可能希望尝试或较擅长的游戏的机会。

[0277] 来自KILLHAZARD的搭档2002的相机记录的或上传的视频剪辑也显示于用户页面上，且每个视频剪辑的下方为指示该搭档是否在线玩游戏的文字(例如，six_shot正玩游戏“龙骑士(Eragon)”(在此显示为Game4)且MrSnuggles99离线等)。通过单击菜单项(未图示)，搭档视频剪辑自显示已记录的或上传的视频切换至当前正玩主机服务210上的游戏的搭档在所述时刻在其游戏中正在进行的内容的现场直播的视频。因此，其变成为搭档分群的游戏取景器。若选择搭档的游戏且用户单击该游戏，则该游戏将放大至全屏幕，且用户将能够观看全屏幕现场直播地播放的游戏。

[0278] 再次，观看搭档的游戏的用户不拥有游戏的复本，也不拥有用于玩该游戏的本地计算/游戏控制台资源。游戏观看是有效瞬时的。

[0279] 如上文先前所描述，当用户玩主机服务210上的游戏时，用户能够“回倒”游戏且发现其希望保存的视频片段，且接着将该视频片段保存到其用户页面。这被称为“自赏剪辑(Brag Clip)”。视频片段2003都是由KILLHAZARD从其所玩的先前游戏保存的自赏剪辑2003。数字2004显示自赏剪辑已被观看多少次，及自赏剪辑何时被观看，用户具有对其评定等级的机会，且橙色(显示为黑色轮廓线)钥匙孔形状的图示2005的数目指示等级是多高。当用户观看用户页面时，自赏剪辑2003连同页面上的其余视频一起恒定地循环。若用户选择并单击自赏剪辑2003中的一者，则其放大以呈现自赏剪辑2003，以及允许播放、暂停、回倒、快进、步进等该剪辑的DVR控制。

[0280] 自赏剪辑2003回放是通过应用程序/游戏服务器1521-1525载入用户记录自赏剪辑时储存于RAID阵列1511-1512上的经压缩视频片段且将其解压缩并将其回放来实施。

[0281] 自赏剪辑2003也可为来自支持3D DVR能力的游戏的“3DDVR”视频片段(也即，来自可被重放且允许用户改变相机观看点的游戏的游戏状态序列)。在此状况下，除用户在记录游戏片段时进行的特定“飞越”的经压缩视频记录之外，也储存游戏状态信息。当用户页面正被观看且所有缩略图及视频窗均恒定地循环时，3D DVR自赏剪辑2003将使在用户记录游戏片段的“飞越”时记录为经压缩视频的自赏剪辑2003恒定地循环。但是，当用户选择3D DVR自赏剪辑2003并单击3D DVR自赏剪辑2003时，除允许播放经压缩视频自赏剪辑的DVR控制之外，用户将能够单击给出其用于游戏片段的3D DVR能力的按钮。其将能够独立地控制游戏片段期间的相机“飞越”，且若其希望(且拥有用户页面的用户允许如此)，则其将能够以经压缩的视频的形式记录替代性自赏剪辑“飞越”，替代性自赏剪辑“飞越”将接着可为用户页面的其他观看者所用(立即地，或者在用户页面的拥有者具有核查自赏剪辑的机会之后)。

[0282] 该3D DVR自赏剪辑2003能力是通过启动将要在另一应用程序/游戏服务器1521-1525上重放已记录的游戏状态信息的游戏来启用。因为游戏可被几乎瞬时地启动(如先前所描述)，所以启动其(其播放限于由自赏剪辑片段记录的游戏状态)且接着允许用户在将经压缩视频记录到延迟缓冲器1515的同时用相机进行“飞越”并不困难。一旦用户完成进行“飞越”，则将游戏撤销启动。

[0283] 从用户的观点看，启动具有3D DVR自赏剪辑2003的“飞越”并不比控制线性自赏剪辑2003的DVR控制难。用户可不知道该游戏或甚至不知道如何玩该游戏。用户指示盯着看另一操作者记录的游戏片段期间的3D世界的虚拟相机操作者。

[0284] 用户将也能够将其自身的音频加录于自赏剪辑上(或者自麦克风记录或者上传)。以这种方式，可使用自赏剪辑来使用来自游戏的人物及动作产生定制动画。此动画制作技术通常被称为“游戏电影(machinima)”。

[0285] 随着用户在游戏中进展，其将达成不同技能级别。所播放的游戏将成果报告给服务控制系统401，且所述技能级别也将显示于用户页面上。

[0286] 互动式动画广告

[0287] 在线广告已自文字转变至静态图像、视频，且现在转变至互动式片段，通常使用如Adobe Flash的动画精简型客户端来实施。使用动画精简型客户端的原因在于：用户通常对于因向其推销产品或服务的特权而被延迟较无耐心。而且，精简型客户端在非常低性能的PC上执行，且因此广告商可具有高度信心：互动式广告将适当地工作。很遗憾地，诸如Adobe Flash的动画精简型客户端在互动性的程度及体验(以减少下载时间，且可用于几乎所有的用户设备，包括不具有GPU或高性能CPU的低性能PC及苹果电脑)的持续时间上受限制。

[0288] 图21说明一个互动式广告，其中用户将在汽车在陈列室中旋转时选择汽车的外部及内部色彩，同时实时射线追踪显示汽车看起来如何。接着用户选择角色来驾驶汽车，且接着用户可采用该汽车来用于在竞赛轨道上或者穿过诸如摩纳哥的外国场所驾驶。用户可选择较大引擎或较佳轮胎，且接着可看见改变的配置如何影响汽车加速或保持稳定的能力。

[0289] 当然，广告有效地的为尖端的3D视频游戏。但对于可在PC或视频游戏控制台上播放的这种广告，其将需要可能100MB下载，且在PC的状况下，其可能需要安装特殊驱动器，且可能在PC缺乏足够CPU或GPU计算能力时根本不执行。因此，所述广告在先前技术配置中不切实际。

[0290] 在主机服务210中，所述广告几乎即刻地投放，且较佳地执行，无论用户的客户端415能力如何。因此，其比精简型客户端互动式广告更迅速地投放，体验上更加丰富，且高度可靠。

[0291] 实时动画期间流动的几何形状

[0292] RAID阵列1511-1512及入埠路由1502可提供如此快的数据速率且具有如此低的延时，以致有可能设计依赖于RAID阵列1511-1512及入埠路由1502来在实时动画(例如，具有复杂数据库的飞越)期间于游戏播放的中间或应用程序中可靠地直接传送几何形状的视频游戏及应用程序。

[0293] 在先前技术的系统(诸如，图1中所显示的视频游戏系统)下，可用的大量储存设备(尤其是在实用的家庭设备中)极缓慢以致不能在游戏播放期间流动几何形状(除了所需的几何形状稍微可预测的情形之外)。举例而言，在存在指定道路的驾驶游戏中，可合理地适当预测用于进入视野内的建筑物的几何形状且大量储存设备可提前搜寻即将到来的几何形状所定位的位置。

[0294] 但在具有不可预测的改变的复杂场景中(例如，在周围具有复杂人物的战役场景中)，若PC或视频游戏系统上的RAM完全被填满用于当前在视图中的对象的几何形状，且接着用户突然将其人物转向以观看其人物之后是什么，若未将几何形状预先载入RAM中，则可能在可显示几何形状之前存在延迟。

[0295] 在主机服务210中，RAID阵列1511-1512可以超过超高速以太网速度的速度使数据流动，且在SAN网络下，有可能达到优于10个十亿比特以太网或优于其他网络技术的100亿比特/秒的速度。100亿比特/秒将在小于一秒内载入十亿字节的数据。在60fps帧时间(16.67毫秒)内，可载入约170百万比特(21MB)的数据。当然，甚至在RAID配置中，旋转媒体也仍将导致大于一帧时间的延时，但以闪存为基础的RAID储存器最终将与旋转媒体RAID阵列一般大且将不会招致该高延时。在一各实施例中，使用经由大量RAM写入的高速缓存来提供非常低延时的存取。

[0296] 因此，在足够高的网络速度，以及足够低延时的大量储存器下，可与CPU和/或GPU可处理3D数据一般快地将几何形状流动到应用程序/游戏服务器1521-1525中。因此，在先前所给出的实例中，其中用户突然将其人物转向且向后看，可在人物完成旋转之前载入其身后的所有人物的几何形状，且因此，对于用户而言，将看来似乎其处于与现场直播的动作一般真实的照片般逼真的世界中。

[0297] 如先前所论述，照片般逼真的计算机动画中的最后的边界中的一者是人脸，且由于人眼对于不完全性的敏感性，来自照片般逼真的面部的最轻微错误可导致来自观看者的TM负面反应。图22显示使用Contour 真实性捕获技术(以下共同待审申请中的申请的主题：2004年9月15日申请的第10/942,609号“Apparatus and method for capturing the motion of a performer”；2004年9月15日申请的第10/942,413号“Apparatus and method for capturing the expression of a performer”；2005年2月25日申请的第
11/066,954号“Apparatus and method for improving marker identification within a motion capture system”；2005年3月10日申请的第11/077,628号“Apparatus and method for performing motion capture using shutter synchronization”；2005 年
10月20日申请的第11/255,854号“Apparatus and method for performing motion capture using a random pattern on capture surfaces”；2006年6月7日申请的第
11/449,131号“System and method for performing motion capture using phosphor application techniques”；2006年6月7日申请的第11/449,043号“System and method for performing motion capture by strobing a fluorescent lamp”；2006年6月7日申请的第11/449,127号“System and method for three dimensional capture of stop-motion animated characters”，上述申请中的每一者都被转让给本CIP申请的受让人)捕获的现场直播的表演如何导致非常平滑的捕获表面，既而达成高多边形计数的追踪表面(也即，多边形运动精确地追随面部的运动)。最后，当将现场直播的表演的视频映射于追踪表面上以产生纹理表面时，产生照片般逼真的结果。

[0298] 尽管当前GPU技术能够再现追踪表面及纹理中的许多多边形且实时地照明该表面，但若多边形及纹理每一帧时间改变(其将产生最具照片般逼真感的结果)，则其将迅速地消耗现代PC或视频游戏控制台的所有可用RAM。

[0299] 使用上文所描述的流动几何形状技术，将几何形状不断地馈送至应用程序/游戏服务器1521-1525中以使得其可不断地动画制作照片般逼真的面部从而允许产生具有几乎不能区别于现场直播的动作面部的面部的视频游戏变得实际。

[0300] 线性内容与互动式特征的整合

[0301] 电影、电视节目及音频材料(统称“线性内容”)广泛地以许多形式可用于家庭及办公室用户。线性内容可在如CD、DVD、及蓝光媒体的实体媒体上获取。其也可通过来自卫星及电缆TV广播的DVR来记录。此外，其可以经由卫星及电缆TV的即付即看(PPV)内容及以电缆TV上的视频点播(VOD)可用。

[0302] 日益增加的线性内容可经由互联网以下载的内容及流动内容可用。现今，确实不存在一个能体验与线性媒体相关的所有特征的位置。举例而言，DVD及其他视频光学媒体通常具有在其他位置处不可用的互动式特征(如导演的评论、“花絮”短片等)。在线音乐站点具有通常在CD上不可用的封面艺术及歌曲信息，但并非所有CD在线可用。且与电视节目相关联的网站常常具有额外特征、博客及有时来自演员或创作人员的评论。

[0303] 另外，在许多电影或运动事件的情况下，通常有经常连同线性媒体一起发行(在电影的状况下)或(在运动的状况下)可以被紧密地联系到真实世界事件(例如，玩家的交易)的视频游戏。

[0304] 主机服务210非常适合于在将全异形式的相关内容连结在一起时传送线性内容。的确，传送电影不如传送高度互动式视频游戏有挑战，且主机服务210能够将线性内容传送至家庭或办公室中的多种设备，或传送至移动设备。图23显示用于主机服务210的例示性用户接口页面，其显示线性内容的选择。

[0305] 但是，不同于大多数线性内容传送系统，主机服务210还能够传送相关的互动式成份(例如，DVD上的菜单及特征、HD-DVD上的互动式叠加层，及网站上的Adobe Flash动画(如下文所述))。因此，客户端设备415限制不再引入哪些特征可用的限制。

[0306] 另外，主机代管系统210能够动态且实时地将线性内容与视频游戏内容连结在一起。举例而言，若用户正观看哈利波特电影中的Quidditch(魁地奇)比赛，且决定其愿意尝试玩Quidditch，则其可仅仅单击按钮且电影将暂停且其将被立即输送到哈利波特视频游戏的Quidditch片段。在玩Quidditch比赛的后，另一次单击按钮，且电影将即刻重新开始。

[0307] 在照片般逼真的图形及制作技术的情况下，其中摄影捕获的视频不能区别于现场直播的动作人物，当用户进行自现场直播的动作电影中的Quidditch游戏至主机服务上的视频游戏中的Quidditch游戏的转变时(如本文中所述)，该两个场景实际上不能区别。此为线性内容与互动式(例如，视频游戏)内容两者的导演提供全新的创作选项，因为该两个世界之间的线变得不能区别。

[0308] 利用图14中所显示的主机服务架构，可将3D电影中的虚拟相机的控制提供给观看者。举例而言，在发生于列车内的场景中，将有可能允许观看者在故事进展时控制虚拟相机且环顾列车。此假定列车中的所有3D对象(“资产”)以及能够实时地再现所述场景以及原始电影的足够计算能力水平可用。

[0309] 且甚至对于非计算机产生的娱乐，存在可提供的非常刺激的互动式特征。举例而言，2005电影“傲慢与偏见”具有装饰华丽的旧英国大厦中的许多场景。对于特定大厦场景，用户可将视频暂停且接着控制相机以巡视大厦，或可能的周围区域。为了实施这些，可携带具有鱼眼镜头的相机穿过大厦，当其追踪其位置时，非常类似于实施先前技术Apple(苹果)公司的QuickTime VR。各种帧接着将被转换，因此图像不失真，且接着其连同电影一起被储存于RAID阵列1511-1512上，且在用户选择继续虚拟巡视时被回放。

[0310] 在运动事件的情况下，可经由主机服务210来使现场直播的运动事件(诸如，篮球比赛)流动以供用户观看(如同其对于常见TV所想要的那样)。在用户观看特定播放之后，游戏的视频游戏(最终篮球玩家看起来与真实玩家一般照片般逼真)可赶上在同一位置中开始的玩家，且用户(可能各自控制一玩家)可重新玩以观看其是否可比所述玩家做得更佳。

[0311] 本文中所描述的主机服务210极其适合于支持此未来世界，因为其能够承受不切实际以致不能安装于家庭中或大多数办公室背景中的计算能力及大容量储存资源，而且其计算资源总是最新的(在可用的最新的计算硬件的情况下)，但是在家庭背景中，将总是存在具有较旧代的PC及视频游戏的家庭。此外，在主机服务210中，用户被隐瞒所有此计算复杂度，因此，即使用户可能正使用非常尖端的系统，自用户的观点看，也如改变电视上的信道一般简单。另外，用户将能够存取所有计算能力及计算能力将自任何客户端415带来的体验。

[0312] 多人游戏

[0313] 对于游戏为多人游戏的程度，则游戏将能够不仅经由入埠路由1502网络传达到应用程序/游戏服务器1521-1525，而且通过网络桥接器传达至具有不在主机服务210中执行的服务器或游戏机器的互联网(未图示)。当通过通用互联网上的计算机玩多人游戏时，则应用程序/游戏服务器1521-1525将具有极快访问互联网的益处(与游戏在家庭中的服务器上执行的情况相比)，但其将受在较缓慢连接上玩游戏的其他计算机的能力限制，且也潜在地受互联网上的游戏服务器被设计以适应最少共同点(common denominator)(所述游戏服务器是相对较慢的消费者互联网连接上的家庭计算机)的事实限制。

[0314] 但当完全在主机服务210服务器中心内玩多人游戏时，则可达到极大差异。对用于用户的游戏进行主机代管的每个应用程序/游戏服务器1521-1525将与其他应用程序/游戏服务器1521-1525以及用极高速度、极低延时连接性及巨大、非常快的储存阵列对针对多人游戏的中央控制进行主机代管的任何服务器互连。举例而言，若超高速以太网用于入埠路由1502网络，则应用程序/游戏服务器1521-1525将在彼此当中传达，且传达到以十亿比特/秒速度在潜在的仅1毫秒或1毫秒以下的延时下对针对多人游戏的中央控制进行主机代管的任何服务器。另外，RAID阵列1511-1512将能够非常快速地响应且接着以十亿比特/秒速度传送数据。作为一个实例，若用户在外表及服装方面定制人物，以使得人物具有对于人物而言唯一的大量几何形状及行为，在限于在家庭中在PC或游戏控制台上执行的游戏客户端的先前技术系统下，若所述人物将进入另一用户的视野中，则用户将必须等待直到长的缓慢下载完成为止，以便将所有几何形状及行为数据载入其计算机中。在主机服务210内，所述相同下载可优于以十亿比特/秒速度从RAID阵列1511-1512服务的超高速以太网。即使家庭用户具有8Mbps互联网连接(其根据现今的标准来看极快)，超高速以太网也快100倍。因此，在快的互联网连接上花费一分钟进行的工作在超高速以太网上将花费小于一秒。

[0315] 顶级玩家分群及锦标赛

[0316] 主机服务210极其适合于锦标赛。因为无游戏在本地客户端中执行，所以不存在用户作弊的机会(例如，在现有技术的锦标赛中，他们可能通过修改运行于他们本地PC上的游戏副本来给予他们不公平的好处)。而且，由于输出路由1540多播UDP流的能力，使得主机服务210能够同时向观众中的数千人或更多广播较大锦标赛。

[0317] 事实上，当存在如此风行以致数千名用户正接收相同流的特定视频流时(例如，显示较大锦标赛的视图)，可以更有效的将视频流发送到内容传送网络(CDN)(诸如，Akamai(阿卡迈公司)或Limelight(聚光灯公司))以用于大量分配到许多客户端设备415。

[0318] 当使用CDN来显示顶级玩家分群的游戏取景器页面时，可获得类似水平的效率。

[0319] 对于较大锦标赛，可使用现场直播的名人解说员来在特定比赛期间提供评论。尽管大量用户将是在观看较大锦标赛，且相对小数目将是在锦标赛中玩。可将来自名人解说员的音频路由到对在锦标赛中玩的用户进行主机代管且对锦标赛中的游戏的任何旁观者模式复本进行主机代管的应用程序/游戏服务器1521-1525，且可将音频加录于游戏音频之上。可在游戏上(也可能刚好在旁观者视图上)叠加名人解说员的视频。

[0320] 网页载入的加速

[0321] 全球信息网及其主要传送协议、超文本传输协议(HTTP)是被构想并被限定在其中仅商业具有高速互联网连接，且在线的消费者使用拨号数据机或ISDN的时代中。此时，用于快速连接的“黄金标准”是T1线，其对称地提供1.5Mbps数据速率(也即，两个方向中具有相等数据速率)。

[0322] 现今，情形完全不同。大量发达世界中经由DSL或电缆调制解调器连接的平均家庭连接速度具有比T1线高得多的下行数据速率。事实上，在世界的一些地方中，光纤到路边(fiber-to-the-curb)正将高达50Mbps至100Mbps的数据速率带入家庭。

[0323] 遗憾地，HTTP没有被架构(也没有被实施)成有效地利用该急剧的速度改善。网站为远程服务器上的档案的集合。非常简单地说，HTTP请求第一档案，等待下载该档案，且接着请求第二档案，等待下载该档案等。事实上，HTTP允许一个以上“开放连接”(也即，每次请求一个以上档案)，但由于商定的标准(及防止网络服务器被超载的愿望)而使得仅准许非常少的开放连接。此外，由于网页被构造的方式，浏览器常常未意识到可用于立即下载的多个同时页面(也即，仅在剖析一个页面之后才变得显而易见：需要下载如图像的新档案)。因此，网站上的档案实质上是逐个地载入。此外，由于由HTTP使用的请求及响应协议，存在与所载入的每个档案相关的大致(访问美国的典型网络服务器)100毫秒的延时。

[0324] 在相对低速连接的情况下，这不会引入大量问题，因为用于档案本身的下载时间决定网页的延时。但是，随着连接速度增大(尤其是复杂网页情况下)，开始引起问题。

[0325] 在图24中所显示的实例中，显示了典型商业网站(该特定网站来自较大的运动鞋商标)。网站上具有54个档案。档案包括HTML、CSS、JPEG、PHP、JavaScript及Flash档案，且包括视频内容。在现场直播网页(也即，用户可单击该网页并开始使用该网页)之前，必须载入总共1.5M字节。对于大量档案存在许多原因。首先，该网页为复杂且尖端的网页，且其次，该网页为基于关于存取该页面的用户的信息动态地组合的网页(例如，用户来自哪个国家，何种语言，用户之前是否进行购买等)，且视所有这些因素而下载不同档案。但是，其仍为非常典型的商业网页。

[0326] 图24显示随着连接速度增大在现场直播网页之前经过的时间量。在1.5Mbps连接速度2401下，使用具有传统网络浏览器的传统网络服务器，在现场直播网页之前花费13.5秒。在12Mbps连接速度2402下，载入时间减少至6.5秒，或约快一倍。但在96Mbps连接速度2403下，载入时间仅减少至约5.5秒。这个原因是因为在这种高下载速度下，下载档案本身的时间最小，但每个档案各自大致100毫秒的延时仍保持，从而导致54个档案*100毫秒＝5.4秒的延时。因此，无论到家庭的连接多快，该网站在现场直播之前将总是花费至少5.4秒。另一因素是服务器侧排队；每个HTTP请求是在队列的后部添加，因此在忙碌的服务器上这将具有显著影响，因为对于要从网络服务器得到的每个小项目，HTTP请求需要等待其返回。

[0327] 解决这些问题的一个方式是废弃或重新限定HTTP。或者，可能使网站拥有者较佳地将其档案合并成单一档案(例如，以Adobe Flash格式)。但是，作为一个实际问题，该公司以及许多他人在其网站架构中具有大量投资。另外，尽管一些家庭具有12-100Mbps连接，但大多数家庭仍具有较缓慢的速度，且HTTP在缓慢速度下确实工作良好。

[0328] 一个替代方法是在应用程序/游戏服务器1521-1525上对网络浏览器进行主机代管，且在RAID阵列1511-1512上(或潜在地在对网络浏览器进行主机代管的应用程序/游戏服务器1521-1525上的RAM中或本地储存器上)对用于网络服务器的档案进行主机代管。由于经由入埠路由1502(或至本地储存器)的非常快的互连，并非在使用HTTP下每档案具有100毫秒的延时，而是在使用HTTP下将存在每档案最小延时。接着，并非使家庭中的用户经由HTTP存取网页，而是用户可经由客户端415存取网页。接着，甚至在1.5Mbps连接下(因为此网页不需要大量带宽来用于其视频)，网页也将在每个线2400小于1秒的时间内处于现场直播。实质上，在应用程序/游戏服务器1521-1525上执行的网络浏览器显示现场直播的页面之前将不存在延时，且在客户端415显示来自网络浏览器的视频输出之前将不存在可侦测到的延时。当用户使用鼠标搜寻网页和/或在网页上键入字时，将用户的输入信息发送至在应用程序/游戏服务器1521-1525上执行的网络浏览器，且网络浏览器将相应地作出响应。

[0329] 此方法的一个不利之处是：若压缩器正恒定地传输视频数据，则使用带宽，即使网页变成静态也如此。这可通过配置压缩器以仅在(并且如果)网页改变时才传输数据且接着仅将数据传输到发生改变的页面部分来补救。当存在具有恒定地改变的闪烁标语等的一些网页时，所述网页往往令人讨厌，且除非存在要移动某物(例如，视频剪辑)的原因，否则通常网页为静态的。对于所述网页，可能为以下状况：使用主机服务210将传输较少数据(与传统网络服务器相比)，因为将仅传输实际显示的图像，没有精简型客户端可执行代码，且没有可能从不被观看的大对象(诸如，滚动翻转图像)。

[0330] 因此，使用主机服务210来对旧版网页进行主机代管，可将网页载入时间减少到打开网页是类似改变电视上的频道的程度：有效地即刻地现场直播该网页。

[0331] 便于游戏及应用程序的除错

[0332] 如先前所述，具有实时图形的视频游戏及应用程序为非常复杂的应用程序且通常当其被发行到该领域中时，其含有缺陷。尽管软件开发商将自用户得到关于缺陷的反馈，且其可能具有用于在崩溃之后将机器状态传回的一些方式，但确切地识别是什么引起游戏或实时应用程序崩溃或不适当地执行非常困难。

[0333] 当游戏或应用程序在主机服务210中执行时，将游戏或应用程序的视频/音频输出恒定地记录在延迟缓冲器1515上。另外，看门狗进程执行每个应用程序/游戏服务器1521-1525，该看门狗进程将向主机服务控制系统401定期地报告应用程序/游戏服务器
1521-1525正平稳地执行。若看门狗进程未能报告，则服务器控制系统401将试图与应用程序/游戏服务器1521-1525通信，且若成功，则将收集可用的无论什么机器状态。将无论什么可用的信息连同由延迟缓冲器1515记录的视频/音频一起发送到软件开发商。

[0334] 因此，当游戏或应用程序软件开发商自主机服务210得到崩溃的通知时，其得到导致崩溃的原因的帧接帧的纪录。该信息在追踪到缺陷并将缺陷修复中可能是极具价值的。

[0335] 还应该注意，当应用程序/游戏服务器1521-1525崩溃时，在最近的可重新启动的时刻重新启动服务器，且将消息提供给用户，从而就技术困难道歉。

[0336] 资源共用及成本节省

[0337] 图4a及图4b中所显示的系统为终端用户与游戏及应用程序开发商两者提供多种益处。举例而言，通常，家庭及办公室客户端系统(例如，PC或游戏控制台)仅在一周中的小百分比的小时中处于使用中。根据由Nielsen(尼尔森)娱乐“Active Gamer Benchmark Study(活跃游戏者基准点研究)”(http://www.prnewswire.com/cgi-bin/stories.pl？ACCT＝104&STORY＝/www/st ory/10-05-2006/0004446115&EDATE＝)的2006年10月5日通信稿，活跃的游戏者一周平均花费14个小时来在视频游戏控制台上玩且约一周17个小时在手持设备上玩。该报告还陈述：对于所有游戏播放活动(包括控制台、手持设备及PC游戏播放)，活跃的游戏者平均一周13个小时。考虑较高数字的控制台视频游戏播放时间，存在一周24*7＝168个小时，这暗示在活跃游戏者的家中，视频游戏控制台仅在一周的17/168＝10％的小时中处于使用中。或者，90％的时间，视频游戏控制台是闲置的。给定视频游戏控制台的高成本，及制造商资助所述设备的事实，这是昂贵资源的非常无效率的使用。商业内的PC通常也仅在一周的一部分小时中使用，尤其是高端应用程序(诸如，Autodesk Maya)常常所需的非便携式台式PC。尽管一些商业在所有小时及假日都操作，且一些PC(例如，带回家以用于在晚上进行工作的便携式PC)是在所有小时及假日使用，但大多数商业活动倾向于在给定商业时区中集中在从周一至周五的约9AM至5PM、较少的假日以及休息时间(诸如，午餐)，且因为大多数PC使用在用户积极地利用PC时出现，所以其遵循：台式PC的利用倾向于遵循这些操作小时数。若假定一周中的五天的自9AM至5PM不断地使用PC，则这将暗示PC在一周的40/168＝24％的小时中被使用。高性能台式PC是用于商业的非常昂贵的投资，且这反映了非常低的利用度。在台式计算机上教学的学校可在一周的甚至更小部分中使用计算机，且尽管其视教学的小时数而改变，但大多数教学在自周一至周五的日间小时期间出现。因此，一般而言，PC及视频游戏控制台仅在一周的小部分小时中被利用。

[0338] 值得注意地，因为许多人在非假日的周一至周五的日间小时期间在商业或在学校工作，所以这些人通常在这些小时期间不玩视频游戏，且因此当其确实玩视频游戏时，其通常是在其他小时期间(诸如，晚上、周末及假日)。

[0339] 给定图4a中所显示的主机服务的配置，则上述两段中所描述的使用模式导致资源的非常有效的利用。显而易见，存在对于可在给定时间由主机服务210来服务的用户的数目的限制，尤其在用户需要用于复杂应用程序(如尖端3D视频游戏)的实时响应性的情况下。但是，不同于家庭中的视频游戏控制台或由商业使用的PC(其通常在大多数时间闲置放置)，服务器402可由不同用户在不同时间重新利用。举例而言，具有高性能双CPU及双GPU及大量RAM的高性能服务器402可由商业及学校在非假日的9AM至5PM利用，但由玩尖端视频游戏的游戏者在晚上、周末及假日利用。类似地，低性能应用程序可由商业及学校在商业小时期间在具有Celeron(赛扬)CPU、无GPU(或非常低端的GPU)及有限RAM的低性能服务器402上利用且低性能游戏可在非商业小时期间利用低性能服务器402。

[0340] 另外，在本文中所描述的主机服务配置的情况下，资源是在数千名(若非数百万名)用户当中有效地共用。一般而言，在线服务仅具有其总用户基础的小百分比在给定时间使用服务。若考虑先前所列出的Nielsen视频游戏使用统计数据，则容易了解为什么。若活跃游戏者一周仅17个小时玩控制台游戏，且若假定游戏的峰值使用时间是在晚上(5-12AM，7*5天＝35小时/周)及周末(8AM-12AM，16*2＝32小时/周)的典型非工作、非商业小时期间，则对于17个小时的游戏播放，一周存在35+32＝65个峰值小时。由于以下许多原因而使得难以估计系统上的确切峰值用户负载：一些用户将在峰值外时间期间玩，可能存在特定日间时间存在用户的丛集(clustering)峰值，峰值时间可受所玩游戏的类型(例如，孩子的游戏将可能是在晚上的较早时间玩)等影响。但是，假定当游戏者可能玩游戏时，游戏者玩的平均小时数远小于日间的小时数，则仅主机服务210的一部分数目的用户将是在给定时间使用主机服务210。为了该分析，我们假定峰值负载为12.5％。因此，仅12.5％的计算、压缩及带宽资源是在给定时间使用，从而由于资源的再使用而导致仅12.5％的硬件成本来支持给定用户玩性能游戏的给定级别。

[0341] 此外，假定一些游戏及应用程序需要比其他者多的计算能力，则可基于被用户玩的游戏或由用户执行的应用程序来动态地分配资源。因此，选择低性能游戏或应用程序的用户将被分配低性能(较低廉)服务器402，且选择高性能游戏或应用程序的用户将被分配高性能(较昂贵)服务器402。实际上，给定游戏或应用程序可能具有游戏或应用程序的较低性能及较高性能区，且可在游戏或应用程序的区之间将用户从一个服务器402切换到另一服务器402，以保持用户在满足游戏或应用程序的需要的最低成本服务器402上执行。注意，比单个磁盘快得多的RAID阵列405将可以被甚至低性能服务器402所用，这具有较快磁盘传送速率的益处。因此，跨越所有所玩游戏或所使用的应用程序的每服务器402平均成本比玩最高性能游戏或应用程序的大多数昂贵服务器402的成本小得多，然而，即使低性能服务器402也会从RAID阵列405得到磁盘性能益处。

[0342] 另外，主机服务210中的服务器402可能只是不具有磁盘或周边接口(不同于网络接口)的PC主机板，且恰好，可向下整合成刚好具有到SAN 403的快速网络接口的单个芯片。而且，RAID阵列405可能将在比存在磁盘的情况多得多的用户当中共用，因此每个活跃的用户的磁盘成本将远小于一个磁盘驱动器。所有该设备将可能驻留于环境上受控制的服务器室环境中的支架中。若服务器402出故障，则其可容易地在主机服务210处进行修理或替换。相比之下，家庭或办公室中的PC或游戏控制台必须坚固，必须能够幸免于合理的磨损及撕裂以防被重击或降落的独立器具需要外壳，具有至少一个磁盘驱动器，必须幸免于不利的环境条件(例如，被勉强塞入具有其他用具的过热AV橱柜中)，需要服务保证，必须被封装及装运，且由可能收取零售利润的零售商来出售。另外，PC或游戏控制台必须被配置以满足将在未来某一时刻使用的计算上最密集的预期游戏或应用程序的峰值性能，即使较低性能游戏或应用程序(或游戏或应用程序的区)也可能在大多数时间玩。此外，若PC或控制台出故障，则使其得到修理是昂贵且耗时的过程(不利地影响制造商、用户及软件开发商)。

[0343] 因此，假定图4a中所显示的系统将相当于本地计算资源的体验的体验提供给用户，以供用户在家庭、办公室或学校中体验给定水平的计算能力，则通过图4a中所显示的架构提供所述计算能力要低廉得多。

[0344] 消除对升级的需要

[0345] 另外，用户不必再担忧将PC和/或控制台升级以玩新游戏或处理较高性能的新应用程序。主机服务210上的任何游戏或应用程序(不管所述游戏或应用程序需要何类型的服务器402)均可为用户所用，且所有游戏及应用程序接近即刻地执行(也即，快速地从RAID阵列405或服务器402上的本地储存器载入)且适当地具有最新更新及缺陷修复(也即，软件开发商将能够选择用于执行给定游戏或应用程序的服务器402的理想服务器配置，且接着将服务器402配置有最佳驱动器，且接着随着时间的推移，开发商将能够同时将更新、缺陷修复等提供给主机服务210中的游戏或应用程序的所有复本)。实际上，在用户开始使用主机服务210之后，用户可能发现游戏及应用程序继续提供较佳体验(例如，经由更新和/或缺陷修复)且可能是以下状况：用户一年后发现新游戏或应用程序可用于利用计算技术(例如，较高性能的GPU)(其在一年前甚至不存在)的服务210上，因此对于用户而言，将不可能购买将在一年后玩游戏或执行应用程序的一年前的技术。因为玩游戏或执行应用程序的计算资源对于用户而言不可见(也即，自用户的观点看，用户仅选择开始接近即刻地执行的游戏或应用程序-更像用户改变电视上的信道)，所以用户的硬件将在用户甚至未意识到升级的情况下已被“升级”。

[0346] 消除对于备份的需要

[0347] 对于商业、学校及家庭中的用户的另一较大问题是备份。若磁盘出故障，或若存在无意擦除，则储存在本地PC或视频游戏控制台中的信息(例如，在控制台的状况下，用户的游戏成果及等级)可能丢失。存在提供用于PC的手动或自动备份的许多可用的应用程序，且可将游戏控制台状态上传至在线服务器以供备份，但通常将本地备份复制至必须储存于安全且有组织的某处的另一本地磁盘(或其他非挥发性储存设备)，且由于经由典型低成本互联网连接可用的缓慢上行速度而使得对于在线服务的备份常常有限。在图4a的主机服务210下，储存于RAID阵列405中的数据可使用为本领域技术人员所熟知的先前技术RAID配置技术来配置，以使得当磁盘出故障时，将不丢失数据，且将通知在容纳出故障的磁盘的服务器中心处的技术员，且接着技术员将替换该磁盘，该磁盘接着将被自动地更新以使得RAID阵列再一次容忍故障。另外，因为所有磁盘驱动器彼此接近且其间具有经由SAN403的快速本地网络，所以在服务器中心中将所有磁盘系统配置定期地备份到次级储存器(其可储存于服务器中心处或者经易地重新定位)并不困难。从主机服务210的用户的观点看，其数据始终完全安全，且其从不必考虑备份。

[0348] 对演示的存取

[0349] 用户经常希望在购买游戏或应用程序的前试用游戏或应用程序。如先前所述，存在先前技术装置，通过该先前技术装置来演示(“演示”的动词形式意思是试用演示版本，演示版本也被称为“演示”，但作为名词)游戏及应用程序，但其中的每一者遭受限制和/或不便利。使用主机服务210，对于用户而言，容易且便于试用演示。实际上，用户所进行的系经由用户接口(诸如，下文所描述的用户接口)选择演示且试用该演示。演示将几乎即刻地载入适合于该演示的服务器402上，且其将完全类似任何其他游戏或应用程序而执行。无论演示需要非常高性能的服务器402还是低性能的服务器402，且无论用户使用的家庭或办公室客户端415是何类型，自用户的观点看，演示均将工作。游戏演示或应用程序演示的软件出版商将能够确切地控制准许用户试用何演示及试用多长时间，且当然，演示可包括为用户提供获得对所演示的游戏或应用程序的全版本的存取机会的用户接口要素。

[0350] 因为演示可能是低于成本价或免费提供，所以一些用户可能试图使用重复的演示(尤其是重复地玩可能有趣的游戏演示)。主机服务210可使用各种技术来限制用于给定用户的演示使用。最直接的方法是建立用于每个用户的用户ID且限制允许给定用户ID播放演示的次数。然而，用户可设置多个用户ID，尤其是其是自由的情况下。用于解决此问题的一个技术是限制允许给定客户端415播放演示的次数。若客户端为独立设备，则该设备将具有一序号，且主机服务210可限制演示可由具有所述序号的客户端存取的次数。若客户端415正以PC或其他设备上的软件执行，则可由主机服务210来指派序号且将该序号储存于PC上并使用该序号来限制演示使用，但假定PC可由用户来重新程序化，且序号被擦除或改变，则另一选项是主机服务210保持PC网络适配器媒体访问控制(MAC)地址(和/或其他机器特定识别符，诸如硬盘驱动器序号等)的纪录并将演示使用限制于该MAC地址。假定可改变网络适配器的MAC地址，然而，这并非极简单的方法。另一方法是限制演示可被播放到给定IP地址的次数。尽管可由电缆调制解调器及DSL提供者来周期性地重新指派IP地址，但其在实践中不会非常频繁地发生，且若可确定(例如，通过联系ISP)IP是处于用于住宅DSL或电缆调制解调器存取的IP地址的区块中，则通常可建立用于给定家庭的小数目的演示使用。而且，在家庭中在共用同一IP地址的NAT路由器之后可能存在多个设备，但通常在住宅背景中，将存在有限数目的所述设备。若IP地址是处于服务商业的区块中，则可建立用于商业的较大数目的演示。但是，最后，所有先前所述方法的组合是限制PC上的演示的数目的最佳方式。尽管可能不存在使得所确定的且技术上熟练的用户可能在重复播放演示的数目中受到限制的极简单的方式，但建立大量障碍可建立足够阻碍以使得大多数PC用户不值得费神去滥用演示系统，且相反，其在其意欲试用新游戏及应用程序时使用演示。

[0351] 对学校、商业及其他机构的益处

[0352] 显著益处尤其出现在利用图4a中所显示的系统的商业、学校及其他机构。商业及学校具有与安装、维护及升级PC相关联的实质成本，尤其当谈及执行诸如Maya的高性能应用程序的PC时。如先前所陈述，PC通常仅在一周的小时的一部分中被利用，且如在家庭中，具有给定水平的性能能力的PC在办公室或学校环境中的成本远高于在服务器中心环境中的成本。

[0353] 在较大商业或学校(例如，大的大学)的状况下，所述实体的IT部门设置服务器中心且维护经由LAN级连接而远程地存取的计算机可以是实际的。存在用于经由LAN或经由办公室之间的私用高带宽连接而远程存取计算机的许多解决方法。举例而言，通过Microsoft的Windows终端机服务器，或者通过虚拟网络计算应用程序(如来自RealVNC(远程控制)有限公司的VNC)或者通过来自Sun Microsystems(太阳计算机系统公司)的精简型客户端装置，用户可获得对PC或服务器的远程存取，在图形响应时间及用户体验中具有一定范围的质量。另外，所述自行管理的服务器中心通常专用于单个商业或学校，且因此不能够利用在全异应用程序(例如，娱乐及商业应用程序)在一周的不同时间利用同一计算资源时所可能的使用的重叠。因此，许多商业及学校缺乏独立设置具有至每一用户的LAN速度的网络连接的服务器中心的规模、资源或专门技能。实际上，大百分比的学校及商业具有与家庭相同的互联网连接(例如，DSL、电缆调制解调器)。

[0354] 然而，所述组织仍可能具有对于非常高性能的计算的需要(或者定期地或者周期性地)。举例而言，小建筑公司可能仅具有小数目的建筑师，当进行设计工作时，具有相对适度的计算需要，但其可能周期性地需要非常高性能的3D计算(例如，当建立用于客户端的新建筑设计的3D飞越时)。图4a中所显示的系统极其适合于所述组织。所述组织仅需要为提供至家庭的同一种类的网络连接(例如，DSL、电缆调制解调器)且通常非常低廉。其可利用低廉的PC作为客户端415，或者完全没有PC也可以，而利用简单实施控制信号逻辑413及低延时视频解压缩412的低廉的专用设备。该特征对于可能具有PC的偷窃或对PC内的专用组件的损坏的问题的学校特别有吸引力。

[0355] 这种配置解决了用于所述组织的许多问题(且许多这种优点也为进行通用计算的家庭用户共用)。举例而言，操作成本(其最终必须以某种形式传递回至用户以便具有可行的商业)可能低得多，因为(a)计算资源是与在一周中具有不同峰值使用时间的其他应用程序共用，(b)所述组织可仅在需要时获得(且招致成本)对高性能计算资源的存取，(c)所述组织不必提供用于备份或以其他方式维护高性能计算资源的资源。

[0356] 盗版的消除

[0357] 另外，游戏、应用程序、互动式电影等可能不再如现今这样被盗版。因为每一游戏是在主机服务210处被存储及执行，所以用户不具备对于基本程序码的存取，因此不存在盗版。即使用户将要复制原始码，用户也不能够在标准游戏控制台或家庭计算机上执行该码。此打开了标准视频游戏不可用的世界各地(诸如，中国)的市场。已使用的游戏的重新销售也是不可能的，因为没有游戏副本分发给用户。

[0358] 对于游戏开发商而言，如同现今的状况，新一代的游戏控制台或PC被引入市场，存在较少市场不连续性。与全新的一代控制台或PC技术迫使用户及开发商升级且游戏开发商取决于硬件平台的及时传送给用户(例如，在游戏机3的情况下，引入被推迟了超过一年，且开发者必须等待直至其可得到并且大量单元被购买)的当前情形对比，可随着时间随着游戏要求改变而利用更先进的计算技术逐渐地更新主机服务210。

[0359] 流动互动式视频

[0360] 以上描述提供由以通用互联网为基础的低延时流动互动式视频(其隐含地也包括连同视频一起的音频，如本文中所使用)的新颖基本概念致能的多种应用。经由互联网而提供流动视频的先前技术系统仅具有可通过高延时互动实施的所致能的应用。举例而言，用于线性视频的基本回放控制(例如，暂停、回倒、快进)在高延时下适当地工作，且有可能在线性视频馈送当中进行选择。此外，如先前所陈述，一些视频游戏的性质允许其以高延时来播放。但是，用于流动视频的先前技术方法的高延时(或低压缩比率)严重限制流动视频的潜在应用或使其部署变窄到专门化的网络环境，且甚至在所述环境中，先前技术也引入网络上的实质负担。本文中所描述的技术打开了在经由互联网的低延时流动互动式视频下可能的多种应用的大门，尤其是经由消费者级互联网连接而致能的所述应用。

[0361] 实际上，在与图4c的客户端465一般小的客户端设备下，足以通过有效的任意量的计算能力、任意量的快速储存及强大服务器之间的极快网络连接而提供增强的用户体验，其使新的计算时代成为可能。另外，因为带宽要求并不随着系统的计算能力增长而增长(也即，因为带宽要求仅关于显示分辨率、质量及帧速率)，所以一旦宽带互联网连接性是普遍存在的(例如，经由分布广的低延时无线涵盖)、可靠的且具有足以满足所有用户的显示设备422的需要的足够高的带宽，则问题将是典型消费者及商业应用所必要的是厚重客户端(诸如，执行Windows、Linux、OSX等的PC或移动电话)还是甚至精简型客户端(诸如，Adobe Flash或Java)。

[0362] 流动互动式视频的出现导致关于计算架构的结构的假定的重新考虑。该一个实例是图15中所显示的主机服务210服务器中心实施例。用于延迟缓冲器和/或分群视频1550的视频路径是反馈回路，其中应用程序/游戏服务器1521-1525的经多播的流动互动式视频输出经由路径1552而实时地或者经由路径1551在可选择的延迟之后被反馈回到应用程序/游戏服务器1521-1525中。这使得通过先前技术服务器或本地计算架构将是不可能或不可行的多种实际应用(例如，诸如图16、图17及图20中所说明的应用)成为可能。
但是，作为更一般的架构特征，反馈回路1550所提供的是流动互动式视频水平下的递归，因为可在应用程序需要视频时将视频无限地循环。这使得之前从未可用的多种应用可能性成为可能。

[0363] 另一关键架构特征在于：视频流是单向UDP流。这有效地实现流动互动式视频的任意程度的多播(相比之下，诸如TCP/IP流的双向流将随着用户的数目增加而在来自来回通信的网络上产生越来越多的通信停滞)。多播是服务器中心内的重要能力，因为其允许系统对互联网用户(且实际上，世界的人口)的增长的需要作出响应以在一对多或甚至多对多基础上通信。再次，本文中所论述的说明流动互动式视频递归与多播两者的使用的实例(诸如，图16)仅为具有可能性的非常大的冰山的尖端。

[0364] 非转接对等(NON-TRANSIT PEERING)

[0365] 在一实施例中，主机服务210具有至一个或多个互联网服务提供商(ISP)的一个或多个对等连接，该互联网服务提供商(ISP)也向用户提供互联网服务，这样主机服务210可通过保持在ISP网络内的非转接路由而与用户通信。例如，如果主机服务210WAN接口441直接连接到康卡斯特电缆通信有限公司的网络，为用户场所211通过康卡斯特电缆调制解调器而被提供宽带服务，主机服务210和客户端415之间的路由可全部在康卡斯特的网络内建立。其潜在的优点将包括：较低的通信费用(因为可避免两个或多个ISP网络之间的IP转接费用)，潜在的更可靠的连接(可防止ISP网络之间存在拥塞或其他转接中断)和较低延时(可防止ISP网络之间存在拥塞、低效路由或其他延迟)。

[0366] 该实施例中，在通话初期，当客户端415开始联系主机服务210时，主机服务210接收用户场所211的IP地址。之后其使用例如来自ARIN(美国网络地址注册管理组织)的有效IP地址表，查看该IP地址是否是分配给连接到主机服务210的特定ISP的IP地址，该主机服务210能够路由到用户场所211而无需通过另外的ISP来IP转接。例如，如果IP地址位于76.21.0.0和76.21.127.255之间，则IP地址被分配给康卡斯特电缆通信有限公司。在该示例中，如果主机服务210保持至康卡斯特、AT&T和Cox ISP的连接，则其选择康卡斯特作为最可能向该特定用户提供最佳路由的ISP。

[0367] 使用反馈的视频压缩

[0368] 在一实施例中，从客户端设备向主机服务提供反馈以表明成功的(或不成功的)图像块和/或帧传送。从客户端提供的反馈信息之后被用于调节主机服务处的视频压缩操作。

[0369] 例如，图25a-b示出了本发明的一个实施例，其中在客户端设备205和主机服务210之间建立反馈信道2501。客户端设备205使用该反馈信道2501发送成功接收的图像块/帧的分组化确认和/或不成功接收的图像块/帧的指示。

[0370] 在一实施例中，成功接收每个图像块/帧之后，客户将确认信息发送到主机服务210。该实施例中，如果在指定时段后没有接收到确认和/或如果接收到客户端设备205所接收的比已发送的图像块/帧靠后的图像块/帧的确认，则主机服务210检测分组丢失。可选地，或另外地，客户端设备205可检测分组丢失并将分组丢失的指示连同受该分组丢失影响的图像块/帧的指示一起发送给主机服务210。该实施例中，并不需要成功传送的图像块/帧的连续确认。

[0371] 不管如何检测分组丢失，在图25a-b所例示的实施例中，生成用于图像的I-图像块的初始组(图25a中未示出)后，编码器随后仅生成图像的P-图像块，直到检测到分组丢失。注意在图25a中，诸如2510的每一个帧被示为4个纵向的图像块。该帧可以按不同的配置被铺放，例如2×2，2×4，4×4等，或者该帧可以在没有图像块的情况下整个被编码(例如作为1个大的图像块)。为了示例本发明的该实施例而提供了帧铺放配置的上述实例。本发明下面的原理并不限于任何特定的帧铺放配置。

[0372] 只传送P-图像块降低了因为上面提出的所有原因的信道带宽需求(例如，p-图像块通常比I-图像块小)。当经由反馈信道2501检测到分组丢失时，如图25b所示，由编码器2500生成新的I-图像块，以重新初始化客户端设备205上解码器2502的状态。如图所示，在一实施例中，I-图像块分布于多个编码帧上，以限制由每个单独的编码帧消耗的带宽。例如图25中，其中每个帧包括4个图像块，在4个连续的编码帧内的不同位置处传送单个I-图像块。

[0373] 编码器2500可将所描述的和该此实施例相关的技术与此处描述的其他编码技术组合。例如，除了响应于所检测的分组丢失而生成I-图像块外，编码器2500可在其他情况中生成I-图像块，在该情况中，I-图像块可能有益于正确地再现图像序列(例如，响应于突然的场景转换)。

[0374] 图26a示出了本发明的另一个实施例，其依赖于客户端设备205和主机服务210之间的反馈信道2601。并非响应于所检测的分组丢失而生成新的I-图像块/帧，此实施例的编码器2600调整P-图像块/帧的相依性。作为初始问题，需要注意的是：此实例中所提出的具体细节无需符合本发明的基本原理。例如，虽然通过使用P-图像块/帧描述本实例，但本发明的基本原理并不限于任何特定的编码格式。

[0375] 图26a中，编码器2600将多个未压缩的图像块/帧2605编码为多个P-图像块/帧2606，并通过通信信道(例如互联网)将该P-图像块/帧传送给客户端设备205。客户端设备205上的解码器2602解码P-图像块/帧2606，生成多个解压缩的图像块/帧2607。编码器2600过去的状态2611存储于主机服务210上的存储设备2610内，而解码器2602过去的状态2621存储于客户端设备205上的存储设备2620内。解码器的“状态”是诸如MPEG-2和MPEG-4的视频编码系统领域中公知的术语。在一实施例中，存储器内所存储的过去“状态”包含来自在先P-图像块/帧的组合数据。存储器2611和2621可分别集成到编码器2600和解码器2602中，而非与编码器2600和解码器2602分离，正如图26a所示。此外，可以使用各种类型的存储器，包括(以示例而非限制的方式)随机存取存储器。

[0376] 在一实施例中，当没有分组丢失发生时，编码器2600将每个P-图像块/帧编码为依赖于之前的P-图像块/帧。因此，正如图26a使用的符号所指示，P-图像块/帧4依赖于P-图像块/帧3(使用符号43标识)；P-图像块/帧5依赖于P-图像块/帧4(使用符号54标识)；而P-图像块/帧6依赖于P-图像块/帧5(使用符号65标识)。在该实例中，P-图像块/帧43在编码器2600和解码器2602之间的传送期间已被丢失。可以各种方式将该丢失传送到编码器2600，包括但不限于上述的那些方式。例如，每次解码器2606成功地接收和/或解码图像块/帧时，可将此信息从解码器2602传送到编码器2600。如果编码器2600并未在一时段之后接收到特定图像块/帧已被接收和/或解码的指示，则编码器2600将假定所述图像块/帧未被成功接收。可选地，或者另外地，当特定图像块/帧未被成功接收时，解码器2602可通知编码器2600。

[0377] 在一实施例中，不管如何检测丢失的图像块/帧，一旦出现该情况，则编码器2600通过使用已知的由解码器2602成功接收的上一个图像块/帧，编码下一个图像块/帧。在图26a所示的实例中，图像块/帧5和6不认为是“成功接收”，由于图像块/帧4的丢失，其不能由解码器2602正确地解码(即，图像块/帧5的解码依赖于图像块/帧4而图像块/帧6的解码依赖于图像块/帧5)。因此在图26a所示的实例中，编码器2600将图像块/帧7编码为依赖图像块/帧3(上一个成功接收的图像块/帧)而非解码器2602不能正确解码的图像块/帧6。虽然图26a中没有示出，随后将图像块/帧8编码为依赖于图像块/帧7而将图像块/帧9编码为依赖于图像块/帧8，假定未检测到另外的分组丢失。

[0378] 如上所提及，编码器2600和解码器2602将过去的解码器和编码器状态2611和2621，分别保持于存储器2610和2620内。因此当编码图像块/帧7时，编码器2600从存储器2610中获取与图像块/帧3相关的先前编码器状态。同样地，和解码器2602相关的存储器2620至少存储上一个已知的好解码器状态(实例中与图像块/帧3相关的状态)。
因此，解码器2602获取与图像块/帧3相关的过去状态信息以使得图像块/帧7可被解码。

[0379] 由于上述技术，可使用相对小的带宽来对实时、低延时、交互的视频进行编码和并使其流动，因为不曾需要I-图像块/帧(除了在流开始处初始化解码器和编码器)。此外，虽然解码器产生的视频图像可能临时包括因丢失的图像块/帧4和图像块/帧5以及6而产生的不想要的失真(由于图像块/帧4的丢失，其不能被正确解码)，但该失真仅在非常短的持续时间可见。此外，如果使用图像块(而非全视频帧)，此失真将被限定到所再现的视频图像的特定区域。

[0380] 图26b示出了根据本发明一个实施例的方法。在2650处，基于之前生成的图像块/帧而生成图像块/帧。在2651处，检测到丢失的图像块/帧。在一实施例中，基于从编码器传送到解码器的信息来检测丢失的图像块/帧，如上所述。在2652处，基于已知的在解码器处已被成功接收和/或解码的图像块/帧，生成下一个图像块/帧。在一实施例中，通过从存储器加载与成功接收和/或解码的图像块/帧有关的状态，该编码器生成下一个图像块/帧。同样地，当解码器接收到新的图像块/帧时，其通过从存储器加载与成功接收和/或解码的图像块/帧有关的状态而解码该图像块/帧。

[0381] 在一实施例中，基于编码器处成功接收和/或解码的上一个图像块/帧而生成下一个图像块/帧。在另一实施例中，生成的下一个图像块/帧是I图像块/帧。再一个实施例中，选择基于先前成功接收的图像块/帧生成下一个图像块/帧还是生成为I帧是基于：丢失了多少图像块/帧和/或信道的延时。在丢失了相对小数量(例如1或2)的图像块/帧以及来回行程延时相对低(例如1或2帧时间)的情况下，生成P图像块/帧可能是最佳的，因为上一次成功接收的图像块/帧和新生成的图像块/帧之间的差异可能相对小。如果丢失了若干个图像块/帧且来回行程延时高，则生成I图像块/帧可能是最佳的，因为上一次成功接收的图像块/帧和新生成的图像块/帧之间的差异可能大。在一实施例中，设定图像块/帧丢失阈值和/或延时阈值以确定是传送I图像块/帧还是P图像块/帧。如果丢失的图像块/帧的数量低于图像块/帧丢失阈值和/或如果来回行程延时低于延时阈值，则生成新的I图像块/帧；否则生成新的P图像块/帧。

[0382] 在一实施例中，编码器总是尝试生成与上次成功接收的图像块/帧有关的P图像块/帧，而若编码过程中编码器确定P图像块/帧将可能大于I图像块/帧时(例如，如果其已压缩1/8的图像块/帧且压缩的大小大于先前压缩的I图像块/帧平均大小的1/8)，则编码器将放弃压缩P图像块/帧且将改为压缩I图像块/帧。

[0383] 如果丢失的分组很少发生，则上述使用反馈来报告丢弃的(dropped)图像块/帧的系统会典型地导致至用户的视频流中出现非常微小的中断，因为由丢失分组所中断的图像块/帧在客户端设备205和主机服务210之间大概一个来回行程的时间内被替换，假定编码器2600在短时间内压缩该图像块/帧。而且因为被压缩的新图像块/帧是基于未压缩视频流中稍后的帧，所以视频流并没有落后于未压缩视频流。但是如果含有新图像块/帧的包也被丢失，则这将导致至少两个来回行程的延迟以再次请求和发送另一个新图像块/帧，在许多实际情况下其将导致视频流的显著中断。因而，从主机服务210向客户端设备205成功发送在丢失的图像块/帧之后发送的新编码的图像块/帧是非常重要的。

[0384] 在一实施例中，前向纠错(FEC)技术，例如先前在图11a、11b、11c和11d中所描述和示出的那些技术，被用于减轻丢失新编码的图像块/帧的可能性。如果传送图像块/帧时FEC编码已被使用，则更强的FEC码用于新编码的图像块/帧。

[0385] 丢失分组的一个潜在原因是信道带宽的突然损耗，例如，如果用户场所211处宽带连接的其他某些用户开始使用大量的带宽。如果新生成的图像块/帧也因丢弃分组(即使使用了FEC)而丢失，则在一实施例中：当客户端415通知主机服务210第二个新编码的图像块/帧丢失，视频压缩器404在其编码随后新编码的图像块/帧时，降低数据速率。不同的实施例使用不同的技术降低数据速率。例如在一实施例中，通过增加压缩比，降低编码图像块/帧的品质，从而达到此数据速率的降低。在另一实施例中，通过降低视频的帧速率(例如从60fps到30fps)并相应地减慢数据传输的速率而降低数据速率。在一实施例中，用于降低数据速率的技术都被使用(例如既降低帧速率又增加压缩比)。如果数据传输的较低速率对减轻丢弃分组是成功的，则依照先前所述的信道数据速率检测和调节方法，主机服务210将继续以较低的数据速率编码，之后随着信道所允许而逐渐地向上或向下调节数据速率。与丢弃分组和/或延时有关的反馈数据的连续接收允许主机服务210基于当前信道条件动态调节数据速率。

[0386] 在线游戏系统中的状态管理

[0387] 该发明的一个实施例使用技术来有效地存储和运送服务器间活跃游戏的当前状态。虽然此处描述的实施例是关于在线游戏的，但该发明的基本原理可用于其他各种类型的应用程序(例如设计应用程序、文字处理软件、诸如电邮或即使消息接发的通信软件等)。图27a示出了用于实施该实施例的示例性系统架构而图27b示出了示例性的方法。虽然将同时描述该方法和系统架构，但图27b所示的方法并不限于任何特定的系统架构。

[0388] 图27b中的2751处，用户从客户端设备205上启动主机服务210a上的新在线游戏。作为响应，在2752处，将游戏的“洁净(clean)”图像2702a从存储器(例如硬盘驱动器，无论是直接连接到执行游戏的服务器，还是通过网络连接到服务器)加载至主机服务210a上的存储器(例如RAM)。“洁净”图像包括在任何游戏播放启动之前，游戏的运行时间程序代码和数据(例如，就像当首次执行游戏时那样)。之后在2753处，用户玩游戏，使得“洁净”图像变为非洁净图像(例如，由图27a中“状态A”所表示的正执行的游戏)。在
2754处，游戏由用户或主机服务210a中的任一个暂停或终止。在2755处，主机服务210a上的状态管理逻辑电路2700a确定游戏的“洁净”图像和当前游戏状态(“状态A”)之间的差异。各种已知的技术可用于计算两个二值图像之间的差异，该技术例如包括UNIX操作系统上的公知“diff”工具所使用的那些技术。当然，本发明的基本原理并不限于任何用于差异计算的特定技术。

[0389] 不管如何计算该差异，一旦使用它们，则差异数据会被本地存储于存储设备2705a内和/或被传送给不同主机服务210b。如果被传送到不同的主机服务210b，该差异数据可能被存储到新主机服务210b的存储设备(未示出)上。在任一种情况中，差异数据与主机服务上的用户帐号相关，以使得其可在下一次用户登陆主机服务并启动该游戏时被识别。在一实施例中，并非立刻传送，该差异数据不被传送到新的主机服务，直到下一次用户尝试玩该游戏(而不同的主机服务被确定为作为该游戏的主机的最佳选择)。

[0390] 返回到图27b所示的方法，在2757处，用户从客户端设备重启游戏，所述客户端设备可以是用户最初玩该游戏使用客户端设备205或不同的客户端设备(未示出)。作为响应，在2758处，主机服务210b上的状态管理逻辑2700b从存储设备获取游戏的“洁净”图像和差异数据。在2759处，状态管理逻辑路2700b将洁净图像和差异数据组合以重新构建游戏在原始主机服务210a上的状态(“状态A”)。可以使用各种已知的技术来使用所述差异数据，重新创建二值图像的状态，该技术例如包括UNIX操作系统上公知的“修补(patch)”工具中所使用的那些技术。也可使用在诸如PC备份的公知备份程序中使用差异计算技术。本发明的基本原理不限于任意使用差异数据重建二值图像的特定技术。

[0391] 此外，在2760处，平台相关(platform-dependent)数据2710被合并到最终的游戏图像2701b中。平台相关数据2710可包括唯一对应于目标服务器平台的任意数据。以示例而非限制的方式，平台相关数据2710可包括新平台的媒体访问控制(MAC)地址、TCP/IP地址、时刻、硬件序列号(例如用于硬盘驱动器和CPU)、网络服务器地址(例如DHCP/Wins服务器)以及软件序列号/激活码(包括操作系统序列号/激活码)。

[0392] 其他与客户/用户有关的平台相关数据可包括(但不限于)下列各项：

[0393] 1.用户的屏幕分辨率。当用户恢复游戏时，用户可使用具有不同分辨率的不同设备。

[0394] 2.用户的控制器配置。当游戏恢复时，用户可能已从游戏控制器切换到键盘/鼠标。

[0395] 3.用户权限，例如是否折扣率已经期满(例如：如果用户曾在促销期间玩游戏，且现在正在较高消费的普通时段玩)，或者用户或设备是否有某些年龄限制(例如，用户的父母可能已经改变用于孩子的设置，这样孩子不允许看成人资料，或者如果正在播放游戏的设备(例如公共图书馆的计算机)在是否显示成人资料方面具有某些限制)。

[0396] 4.用户的等级。用户可能已被允许在某一联盟中玩多人游戏，但是因为其他某些用户已经超过该用户的等级，所以用户可能已被降级到较小的联盟中。

[0397] 为了解释本发明该实施例而提供了平台相关数据2710的前述实例。本发明的基本原理并不限于平台相关数据的任意特定集合。

[0398] 图28图形化地示出了第一主机服务处的状态管理逻辑2700a如何从正执行的游戏2701a中提取差异数据2800。之后，第二主机服务处的状态管理逻辑2700b将洁净图像2702b和差异数据2800以及平台相关数据2710组合，以重新生成正执行的游戏2701b的状态。大体如图28所示，差异数据的大小显著地小于整个游戏图像2701a的大小，因此通过仅仅存储/传输差异数据而节省了大量的存储空间和带宽。虽然图28中未示出，但是平台相关数据2700在其被合并到最终的游戏图像2701b时，可改写某些差异数据。

[0399] 虽然上面描述了在线视频游戏的实施，但本发明的基本原理并不限于视频游戏。例如可在任意类型的在线主机应用程序的环境中实现前述状态管理技术。

[0400] 用于保持客户端解码器的技术

[0401] 在本发明一实施例中，每当用户请求连接主机服务210时，主机服务210便将新的解码器传送到客户端设备205。因而，在该实施例中，客户端设备所使用的解码器总是最新的(up-to-date)且为客户端设备上实施的软件/硬件特别量身定做的。

[0402] 如图29所示，该实施例中，永久地安装于客户端设备205上的应用程序并不包括解码器。相反地，是客户端下载器应用程序2903来在每次客户端设备205连接主机服务210时，管理临时解码器2900的下载和安装。该下载器应用程序2903可被实施为硬件、软件、固件或其任意组合。响应于新的在线会话的用户请求，下载器应用程序2903通过网络(例如互联网)传送与客户端设备205相关的信息。该信息可包括识别客户端设备和/或客户端设备硬件/软件配置(例如，处理器、操作系统等)的识别数据。

[0403] 基于此信息，主机服务210上的下载器应用程序2901选择合适的临时解码器2900以用于客户端设备205上。主机服务上的下载器应用程序2901之后传送临时解码器2900，之后客户端设备上的下载器应用程序2903在客户端设备205上验证和/或安装解码器。编码器2902之后使用此处所述的任意技术来编码音频/视频内容，并将内容2910传送到解码器2900。一旦安装了新的解码器2900，其解码用于当前在线会话的内容(即，使用此处所述的一个或多个音频/视频解压缩技术)。在一实施例中，当会话终止时，解码器2900被从客户端设备205上移除(例如卸载)。

[0404] 在一实施例中，随着临时解码器2900正被下载，下载器应用程序2903通过做出信道评估(例如，信道上可达到的数据速率(例如，通过确定其花多长时间下载数据)、信道上的分组丢失率以及信道的延时)来描绘信道特性。下载器应用程序2903生成描述所述信道评估的信道特征化数据。之后将该信道特征化数据从客户端设备205传送到主机服务下载器2901，其使用信道特征化数据来确定如何最好地利用信道将媒体传送到客户端设备205。

[0405] 在下载临时解码器2900期间，客户端设备205一般会发送消息回主机服务205。这些消息可包括指示无误还是有误地接收到分组的确认信息。此外，该消息提供反馈至下载器2901，该反馈针对关于数据速率(基于接收分组的速率进行计算)、分组错误率(基于所报告的有误接收的分组的百分比)和信道来回行程延时(基于下载器2901接收反馈之前所花的时间量，所述反馈关于已被传输的给定分组)。

[0406] 以示例的方式，如果数据速率被确定为2Mbps，则和若数据速率被确定为5Mbps(例如1280×720，60fps)相比，下载器选择较小的视频窗口分辨率用于编码器
2902(例如640×480，60fps)。可依赖于分组丢失率，选择不同的向前纠错(FEC)或分组结构。

[0407] 如果分组丢失非常低，则可无纠错地传送压缩的音频和视频。如果是分组丢失适中，则可用纠错编码技术(例如，像之前图11a、11b、11c和11d中描述和示出的那些)传送压缩的音频和视频。如果分组丢失非常高，则可确定不能传送优等质量的视听流，而客户端设备205可通知用户无法通过通信信道(例如，“链路(link)”)获得主机服务，或者其可能尝试建立至具有较低分组丢失的主机服务的不同路由(如下所述)。

[0408] 如果延时短，则可以以低延时传输压缩的音频和视频并建立会话。如果延时太高(例如高于80ms)，则对于需要短延时的游戏来说，客户端设备205可通知用户无法通过链路获得主机服务(该链路可用但对用户输入的响应时间将是迟缓的或“滞后的”)，或者用户可以尝试建立至具有较低延时的主机服务的不同路由(如下所述)。

[0409] 客户端设备205可尝试通过网络(例如互联网)经由另一条路由连接至主机服务210，查看是否降低了减损(例如，分组丢失更小、延时更短、或者甚至数据速率更高)。例如，主机服务210可从多个地理位置(例如，主机中心在洛杉矶而一个在丹佛)连接到互联网，由于洛杉矶拥挤所以可能有更高的分组丢失，但是在丹佛没有拥挤。此外，主机服务210可通过多个互联网服务提供商(例如AT&T和康卡斯特)连接到互联网。

[0410] 因为主机设备205和服务提供商之一(例如AT&T)之间的拥挤或其他问题，分组丢失和/或高延时和/或受约束的数据速率可能发生。然而，如果客户端设备205通过另一个服务提供商(例如康卡斯特)连接到主机服务210，其可能可以连接而无拥挤问题和/或较低的分组丢失和/或较短延时和/或更高的数据速率。因此，当下载临时解码器2900时，如果客户端设备205经历了高于指定阈值(例如，指定持续时间上，指定数量的分组丢弃)的分组丢失、高于指定阈值的延时和/或低于指定阈值的数据速率，在一实施例中，其尝试通过可选的路由重新连接到主机服务210(一般通过连接到不同的IP地址或不同的域名)，以确定是否可获得更好的连接。

[0411] 可选连接选项耗尽后，如果连接依旧经历不可接受的减损，则其可能是：客户端设备205到互联网的本地连接遭受减损，或者是：离主机服务210太远而不能获得适当的延时。在此情况下，客户端设备205可能通知用户无法通过链路获得主机服务或者主机服务仅仅是有损可用的、和/或只有某些类型的低延时游戏/应用程序是可用的。

[0412] 因为主机服务210和客户端设备205之间的链路特征的评估和潜在的改进是在临时解码器正被下载时进行的，所以其降低了客户端设备205分别下载临时解码器2900和评估链路特征所需的花费的时间量。但是在另一实施例中，客户端设备205将下载临时解码器2900与链路特征的评估和潜在改进(例如，通过使用虚构的测试数据而非解码器程序代码)分开执行。为什么这可能是较佳实施有很多原因。例如在某些实施例中，客户端设备205部分或全部实施为硬件。因此，对于这些实施例，本身没有必要下载软件解码器。

[0413] 使用基于标准的图像块大小的压缩

[0414] 如上所提及，当使用基于图像块的压缩时，本发明的基本原理并不限于任何特定的图像块大小、形状或方向。例如在诸如MPEG-2和MPEG-4的基于DCT的压缩系统中，图像块可能是宏块(macroblock)(数据压缩中使用的部件，其一般表示16×16像素的块)的大小。此实施例提供了用于与图像块一起工作的非常精细的粒度等级。

[0415] 此外，不管图像块大小如何，可以使用各种类型的铺放模式。例如，图30示出了一实施例，其中R帧3001-3004的每一个中都使用了多个I-图像块。使用了旋转模式，其中在每个R帧散布I-图像块，使得每四个R帧生成一个完整的I-帧。以这种方式散布I-图像块将降低分组丢失的影响(将丢失限制到显示器的小区域内)。

[0416] 图像块的大小还可为基本压缩算法的整体自然结构。例如，如果在一个实施例中使用H.264压缩算法，图像块被设定为H.264“片(slice)”的大小。这允许此处所述的技术易于集成到各种不同标准压缩算法的环境中，该算法例如是H.264和MPEG-4。一旦图像块大小被设定为自然压缩结构，可实施如上所述的那些技术同样的技术。

[0417] 用于流倒回(REWIND)和回放操作的技术

[0418] 如之前连同图15所描述的，由应用程序/游戏服务器1521-1525生成的未经压缩的视频/音频流1529可由共用硬件压缩1530以多种分辨率压缩，同时生成多个经压缩的视频/音频流1539。例如，由应用程序/游戏服务器1521生成的视频/音频流可由共用硬件压缩1530以1280×720×60fps压缩，并作为出埠互联网通信1599经由出埠路由1540传送给用户。同样的那种视频/音频流同时可由共用硬件压缩1530按比例缩小到缩略图尺寸(例如200×113)，并经由路径1552(或通过延迟缓冲器1515)发送到应用程序/游戏服务器1522，以显示为图16中缩略图集合的一个缩略图1600。当缩略图1600经过图17中级尺寸1700而被放大到图18中的尺寸1800(1280×720×60fps)时，并非对缩略图流进行解压缩，应用程序/游戏服务器1522可解压缩发送到应用程序/游戏服务器1521的用户的1280×720×60fps流的复本，并且缩放到较高分辨率的视频，便如同其被从缩略图尺寸而缩放到1280×720尺寸那样。该方法具有两次重用1280×720压缩流的优点。但其具有若干缺点：(a)发送到用户的经压缩的视频流可能在图像质量上变化，如果用户互联网连接的数据吞吐量变化导致由应用程序/游戏服务器1522的“出席观看(spectating)”的用户观看的图像质量变化，即使用户的互联网连接并未变化，(b)应用程序/游戏服务器1522将不得不使用处理资源来解压缩整个1280×720图像，而且之后缩放此图像(可能应用重采样滤波器)以在缩放期间显示小得多的尺寸(例如640×360)，(c)如果由于有限的互联网连接带宽和/或丢失的/损坏的分组而丢帧，出席观看的用户“倒回”并“暂停”延迟缓冲器1515中记录的视频，出席观看的用户将发现延迟缓冲器中的丢帧丢失(如果用户逐帧“步进”，这将会格外明显)，以及(d)如果出席观看的用户倒回以延迟缓冲器中所记录的视频中寻找特定帧，则应用程序/游戏服务器1522将不得不在延迟缓冲器中所记录的视频流中寻找先于所寻帧的I帧或I图像块，之后解压缩所有的P帧/图像块，直到达到想要的帧。同样的限制将不仅存在于“出席观看”视频/音频流直播的用户，而且还存在于观看视频/音频流的存档复本(例如“精彩剪辑(Brag Clip)”)复本的用户(包括生成视频/音频流的用户)。

[0419] 本发明的可选实施例通过用不止一种的尺寸和/或结构来压缩视频流来解决这些问题。如此处所描述的，一个流(“直播”流)基于网络连接的特征(例如数据带宽、分组可靠性)和用户的本地客户端能力(例如解压缩能力、显示器分辨率)而被最佳地压缩并流向终端用户。其他流以高质量、一个或更多分辨率、以及可经受视频回放检验的结构来压缩(此处被称为“HQ”流)，这种HQ流被路由和存储到服务器中心210中。例如在一实施例中，所述HQ压缩流存储于RAID磁盘阵列1515并用于提供诸如暂停、倒回的功能以及其他回放功能(例如“精彩剪辑”，其可发布给其他用户进行观看)。

[0420] 如图31a所示，本发明的一个实施例包括解码器3100，其至少能够以至少两种格式压缩视频流：一种格式3110为周期性包括I-图像块或I-帧，一种格式3111不包括I-图像块和I-帧，除非由于流的中断或因为I-图像块或I-帧被确定为可能小于I-图像块或I-帧(如上所述)而有必要包括I-图像块和I-帧。例如，当播放视频游戏时传送到用户的“直播“流3111可仅仅使用P-帧(除非I-图像块或I-帧是必要的或者更小，如上所述)压缩。此外，此发明的编码器3100同时以第二种格式压缩直播视频流3111，在一实施例中，所述第二种格式周期性地包括I-图像块或I-帧(或者相似类型的图像格式)。

[0421] 虽然上述实施例使用I-图像块、I-帧、P-图像块和P-帧，但本发明的基本原理并不限于任何特定的压缩算法。例如，可使用任意类型的图像格式取代P-图像块或P-帧，在该图像格式中，帧依赖于先前或随后的帧。同样地，可使用任意类型的图像格式代替上述的I-图像块或I帧，该图像格式并不依赖先前或随后帧。

[0422] 如上所提及的，HQ流3110包括周期性的I-帧(例如在一实施例中，大约每12个帧)。这是很重要的，因为如果用户总是想将所存储视频流快速倒回到特定点，则需要I-图像块或I-帧。在只有P-帧(例如，序列的第一帧不是I-帧)的压缩流的情况下，解码器必须回到序列的第一帧(其可能有数小时长)，之后将P帧解压缩，直至到达用户想倒回的点。通过HQ流3110内每12帧存储的I-帧，用户可决定倒回到特定点，且HQ流的最接近的前一I-帧仅比想要的帧靠前不超过12帧。即使解码器最大解码率是实时的(例如：对于60帧/秒的流来说是一秒的1/60)，则离I-帧为12(帧)/60(帧/秒)＝1/5秒远。而在许多情况下，解码器能够比实时操作得更快，所以例如以2×实时的解码率，解码器能够在
6帧的时间中解码12帧，用于“倒回“的延迟仅为一秒延迟的1/10。不用说，如果最接近的前一I-帧先于倒回点大量帧，即使快速解码器(例如10×实时)亦将具有不可接受的延迟(例如，它将花1小时/10＝6分钟来做一次倒回)。在另一实施例中，使用周期性I-图像块，在此情况下，当用户寻求倒回时，解码器将会寻找先于倒回点的最接近的前一I-图像块，之后着手从那点开始该图像块的解码，直到解码所有图像块到该倒回点。虽然周期性I-图像块或I-帧与完全没有I-帧相比会导致更低效的压缩，但是主机服务210一般具有足够多的本地可用带宽和存储能力来管理HQ流。

[0423] 在另一实施例中，编码器3100编码具有周期性I-图像块或I-帧的HQ流，该I-图像块或I-帧跟随有P-图像块或P-帧，如前所述，且之前还存在B-图像块或B-帧。如之前所述，B-帧是先前于I-帧的帧，且基于在时间上往回(backward)工作时与I-帧的帧差异。B-图像块是图像块副本，先前于I-图像块且基于时间上往回(backward)工作时与I-图像块的帧差异。此该实施例中，如果想要的倒回点是B-帧(或包含B-图像块)，则解码器会寻找最接近的下一I-帧或I-图像块，并在时间上往回解码，直到想要的倒回点被解码，之后视频回放从该点向前进行，解码器将逐帧向前解码B-帧、I-帧和P-帧(或它们的图像块副本)。除了I和P类型之外，使用B-帧或B图像块的优点在于：在给定压缩比下，通常能够达到更高的质量。

[0424] 在再一个实施例中，编码器3100将HQ流编码为全部的I-帧。此方法的优点在于：每个倒回点都是I-帧，从而为了达到该倒回点，不需要解码其他帧。缺点在于：和I、P或I、P、B流编码相比，经压缩的数据速率将会非常高。

[0425] 其他视频流回放操作(例如：快速或慢速倒回，快速或慢速前向等)，一般由周期I-帧或I-图像块(单独或组合使用P和/或B副本)更加实际地完成，因为在每种情况下，与在时间上逐帧前向相比，流均以不同的帧顺序被回放，从而解码器需要寻找和解码序列中特定的(通常是任意的)帧。例如，在非常快速的快进(例如100×速度)情况下，所播放的每下一帧均在先前帧100帧之后。即使利用具有以10×实时运行且在1个帧时间内解码10帧的解码器，它将仍然是10×，太慢而不能获得100×的快进。然而，利用如前所述的周期I-帧或I-图像块，解码器能寻找最接近下一次播放所需的帧的适用I-帧和I-图像块，且仅解码至目标帧的点的中间帧或图像块。

[0426] 在另一实施例中，I帧以一致的周期数(例如总是每8个帧)被编码入HQ流中，用户可用于快进和倒回的倍速就是I-帧周期数的精确倍数，所述快进和倒回比I-帧速率更快。例如，如果I-帧周期数是8帧，则使得用户可用的快进或倒回速度可能是1×，2×，3×，4×，8×，16×，64×和128×以及256×。对于比I-帧周期数更快的速度，解码器将首先以该速度向前跳转到一定数量的帧之前的最接近的I-帧(例如，如果当前所显示的帧比I-帧领先3帧，则以128×，解码器将跳到靠前128+3帧的帧)，之后对于每个后续的帧来说，解码器将随着所选速度(例如以128×的所选速度，解码器将跳转128帧)跳转精确数量的帧，每次它将精确地落在I-帧上。因此假定比I-帧周期数快的所有速度是I-帧周期数的精确倍数，解码器将永不需要解码任何先前或后继帧来寻找想要的帧，且仅需要针对每一显示的帧，解码一个I-帧。对于比I-帧周期数更慢的速度(例如：1×，2×，3×，4×)，或者对于作为I-帧周期数的非倍数的更快速度，对于所显示的每个帧，解码器寻求一帧，该帧使得显示想要的帧所需要的额外新解码的帧的数量最少，该帧可为未解码的I-帧或且仍为解码形式的已解码的帧(在RAM或其他快速存储器中)，之后，如果必要，可解码中间帧，直到想要的帧被解码和显示。例如以4×的速度快进，在具有8×I-帧周期数的I、P编码序列中，如果当前帧是靠后I-帧1帧的P-帧，而将被显示的想要的帧为4帧之后帧，其为之前的I-帧之后的第5个P-帧。如果当前显示的帧(其刚被解码)被用作起始点，该解码器将需要再解码4个P-帧来显示想要的帧。如果使用之前的I-帧，为了显示想要的帧，解码器将需要解码6帧(I-帧和随后的5个P-帧)。(明显地，在这种情况下，使用当前显示的帧来最小化需额外解码的帧是有利的)。之后，下一个将被解码的靠前4帧，为I-帧之后的第一个P-帧。这种情况下，如果当前解码的帧被用作起始点，解码器还需解码
4个帧(2个P-帧、一个I-帧和一个P-帧)。但是，如果使用下一个I-帧来替代，解码器将仅需要解码I-帧和后续的P-帧。(明显地，在这种情况下，使用下一个I-帧作为起始点来最小化需额外解码的帧是有利的。)因此，在此实例中，解码器可在使用当前解码的帧作为起始点与使用随后的I-帧作为起始点之间交替。作为一主要原则，不管HQ视频流回放模式(快进、倒回或步进)和速度如何，对于该回放模式和速度下所显示的每个后续帧，解码器将从一使得显示想要的帧所需要的新解码的帧的数量最少的帧开始，即I-帧或之前解码的帧。

[0427] 如图31b所示，主机服务210的一个实施例包括用于管理重放HQ流3110的用户请求的流重放逻辑3112。流重放逻辑3112接收客户请求(该请求含有视频回放命令(例如：暂停、倒回、从一指定点回放等))、翻译该命令并从指定点解码HQ流3110(开始于I-帧或之前解码的帧，视情况而定，之后向前或向后进行到指定点)。在一实施例中，向编码器3100提供经解码的HQ流(可能是同一个编码器3100，如果其一次能够编码不止一个流，或者是单独的编码器3100)，以便其可被重新压缩(使用此处所述的技术)并被传送给客户端设备205。客户端设备上的解码器3102之后如上所述地解码并再现该流。

[0428] 在一实施例中，流重放逻辑3112并不解码HQ流并在之后使编码器3100重新编码该流。相反地，其简单地从指定点将HQ流3110直接流向客户端设备205。客户端设备205上的解码器3102之后解码HQ流。因为此处所述的回放功能一般不具有像播放实时视频游戏那样的低延时需求(例如：如果玩家只是简单地查看先前的游戏播放，而不是主动玩该游戏)，所增加的普通高质量HQ流一般固有的延时可导致可接受的终端用户体验(例如，具有更长延时但是高质量的视频)。

[0429] 以示例而非限制的方式，如果用户正在玩视频游戏，则编码器3100提供具有本质上所有P-帧的直播流，所述P-帧针对用户的连接和本地客户端而被优化(例如，大约1.4Mbps，640×360的分辨率)。同时，编码器3100还在主机服务310内将视频流压缩为HQ流3100，并将该HQ流存储在本地数码视频解码器RAID阵列上，例如以1280×720、10Mbps，每12帧具有I-帧。如果用户击“暂停”按钮，则游戏将暂停在客户最后解码的帧上，且屏幕将冻结。之后如果用户击“倒回”按钮，流重放逻辑3112将从DVRRAID中读取开始于最近的I-帧或可用的已被解码的帧的HQ流3110，如上所述。若有需要的话，流重放逻辑3112将解压缩中间的P或B帧，若有需要的话并对帧进行重新排序，以便以想要的倒回速度倒退(backward)回放序列，之后调整(使用本领域公知的现有技术的图像缩放技术)想要解码的、打算从以1280×720进行显示变为以640×360进行显示的流，之后直播流编码器3100将以640×360的分辨率重新压缩重排序的流并将其传送给用户。如果用户再次暂停，并单步浏览视频以近距离地观看序列，DVR RAID上的HQ流3110可具有可用于单步执行的每个帧(即使原始直播流可能由于此处所述众多原因中的任何原因而丢帧)。此外，HQ流中每一点上的视频回放的质量将非常高，而在直播流中可能存在某些点因带宽受损而导致经压缩的图像的质量的临时降低。当受损图像质量持续一简短时段或在运动图像中时，其是可被用户接受的，如果用户在特定的帧处停止(或者缓慢地单步执行)并仔细近距离地研究帧，受损质量可能不被接受。通过指定HQ流内的点(例如，前2分钟)，还向用户提供快进或跳特定点的能力。在直播视频流仅是P-帧或者很少(或者不可预测的)有I-帧的情况下，所有这些操作都是无法以其完全通用性及高质量执行的。

[0430] 在一实施例中，向用户提供视频窗口(未示出，诸如Apple QuickTime或Adobe Flash视频窗口)，该视频窗口具有“刷子(scrubber)”(即，左-右滑动块控制)，其早在HQ流存储视频之前，就允许用户向前或向后扫描浏览视频流。虽然对用户来说便好像是他或她正“刷”过直播流，事实上他或她正“刷”过所存储的HQ流3110，该HQ流3110之后被调整大小并被重新压缩为直播流。此外，如前所述，如果同一时刻的其他任何人或不同时刻的用户观看HQ流，该HQ流可以以比当同时编码HQ流时的直播流的分辨率更高的(或更低)的分辨率被观看，而质量将和观看者的直播流的质量一样高，潜在地可达到HQ流的质量。

[0431] 因此，通过同时编码直播流(如此处所述，以针对其低延时、带宽和分组容错要求的合适方式)和具有其高质量、流回放操作需求的HQ流，从而向用户提供这两种场景的想要的配置。而事实上，对用户来说高效透明的是：存在两种被不同编码的不同流。从用户的角度看，该体验高度响应的，具有很低的延时，尽管运行于高度可变的且相对低带宽的互联网连接上，但数码视频记录(DVR)功能是非常高质量的，具有灵活的操作和灵活的速度。

[0432] 因为上述技术，用户在在线游戏游玩或其他在线交互期间受益于直播和HQ视频流，不受直播流或HQ流中任一个的限制。

[0433] 图31c示出了执行上述操作的系统架构的一个实施例。如图所示，在此实施例中，编码器3100分别编码一系列的“直播”流3121L、3122L和3125L以及对应系列的“HQ”流3121H1-H3、3122H1-H3和3125H1-H3。每个HQ流H1被全分辨率编码，而每个编码器H2和H3在编码之前将视频流缩放到的更小尺寸。例如，如果视频流是1280×720的分辨率，H1将以1280×720的分辨率编码，而H2可缩放到640×320且以该分辨率编码，而H3可缩放到320×180并以该分辨率编码。可使用任意数量的同时的Hn缩放器/编码器，提供各种分辨率的多个同时HQ编码。

[0434] 每个直播流响应于经由入埠互联网连接3101接收的信道反馈信号3161、3162和3165而工作，如上所述(例如参见图25-26中反馈信号2501和2601的论述)。直播流经由出埠路由逻辑3140在互联网(或其他的网络)上向外传送。直播压缩器3121L-3125L包括基于信道反馈(包括缩放、丢帧等)而调节(adapting)压缩视频流的逻辑。

[0435] 入埠路由逻辑3141和1502经由信号路径3151将HQ流路由到内部延迟缓冲器(例如RAID阵列3115)或其他数据存储设备，和/或经由信号路径3152将HQ流反馈给用于额外处理的应用程序/游戏服务器和编码器3100。如上所述，一旦请求，HQ流3121Hn-3125Hn随后被流入到终端用户(例如参见图31b和关联内容)。

[0436] 在一实施例中，编码器3100被实施为图15中所示的共用硬件压缩逻辑1530。在另一实施例中，某些或所有编码器和缩放器是单独的子系统。本发明的基本原理不限于任何特定的缩放或压缩资源的共用或硬件/软件配置。

[0437] 图31c配置的优点在于：需要小于全尺寸视频窗口的视频窗口的应用程序/游戏服务器3121-3125将无需处理和解压缩全尺寸的窗口。此外，需要介于中间的窗口尺寸的应用程序/游戏服务器3121-3125可接收接近于所要窗口尺寸的经压缩的流，之后按比例增大或缩小至想要的窗口尺寸。此外，如果多个应用程序/游戏服务器3121-3125向另一个应用程序/游戏服务器3121-3125请求同样尺寸的视频流，入埠路由3141可执行IP多播技术，例如本领域公知的那些技术，并将所请求的流一次性广播到多个应用程序/游戏服务器3121-3125上，无需将单独的流广播到做出请求的每个应用程序/游戏服务器。如果接收广播的应用程序/游戏服务器改变视频窗口的尺寸，其可切换至不同视频尺寸的广播上。因此任意大数量的用户能够同时观看应用程序/游戏服务器视频流，每一用户可灵活缩放其视频窗口，并总是获得缩放到接近想要窗口尺寸的视频流的好处。

[0438] 图31c所示方法的一个缺点在于：在主机服务210的许多实际实施中，从未有出现过所有的压缩HQ流被一起观看的情况，更不用说所有压缩HQ流的所有尺寸。当编码器3100被实现为共用资源(例如：缩放器/压缩器，可实现为软件或硬件)时，减轻了此浪费。
但是，由于涉及带宽，将大量的未压缩流连接到公共的共用资源时可能会存在实际的问题。
例如，每个1080p60流几乎是3Gbps，其甚至远远超过千兆位以太网。下面的可选实施例解决了该问题。

[0439] 图31d示出了主机服务210的可选实施例，其中每个应用程序/游戏服务器3121-3125具有两个分配给它的压缩器：(1)直播流压缩器3121L-3125L，其基于信道反馈
3161-3165调节经压缩的视频流，以及(2)输出全分辨率的HQ流的HQ流压缩器，如上所述。
值得注意的是，直播压缩器是动态和自适应的，与客户端205使用双向通信，而HQ流是非自适应性的和单向的。流之间的其他差异为：直播流质量可以动态地变化，依赖于信道条件和视频资料的特性。一些帧可能是低质量的，可能存在丢帧。此外，直播流可能几乎全部是P-帧或P-图像块，少有I-帧和I-图像块出现。HQ流和直播流相比一般具有更高的数据速率，其将提供一致的高质量，不会丢弃任何帧。HQ流可能全是I-帧，或者可具有频繁的和/或规律的I-帧或I-图像块。HQ流还可包括B-帧或B-图像块。

[0440] 在一实施例中，共用视频缩放和重新压缩3142(下面详述)只选择某些HQ视频流3121H1-3125H1，在发送到如前所述的用于路由的入埠路由3141之前，其将以一个或多个不同的分辨率而被缩放和重新压缩。其他HQ视频流或者以全尺寸通过之前所述的用于路由的入埠路由3141，或者根本不通过。在一实施例中，基于是否有请求特定分辨率(或者接近于缩放的分辨率或全分辨率)的特定HQ流的应用程序/游戏服务器3121-3125来做出该决定：哪些HQ流被缩放和重新压缩，和/或哪些HQ流完全通过。通过该方法，只有被缩放和重新压缩的HQ流(或者潜在地完全通过)是实际需要的HQ流。在主机服务210的众多应用中，这导致缩放和压缩资源的显著减少。此外，假定每个HQ流至少由压缩器3121H1-3125H1以全分辨率压缩，和若其是接受的未经压缩的视频相比，被路由所需的带宽以及共用视频缩放和重新压缩3142中的带宽会显著地降低。例如，3Gbps未经压缩的
1080p60流将被压缩到10Mbps，且仍然保留非常高的质量。因此，利用千兆位以太网连接，虽然不能传送(carry)一个未压缩的3Gbps视频流，但可传送许多的10Mbps视频流，在质量上并不会具有明显的减少。

[0441] 图31f示出了共用视频缩放和重新压缩3142以及大量HQ视频压缩器HQ3121H1-3131H1的细节。内部路由3192根据来自应用程序/游戏服务器3121-3125的将特定视频流缩放到特定尺寸的请求，一般从HQ视频压缩器HQ 3121H1-3131H1中选择一个子集的经压缩HQ流。如果所请求的流要被缩放，则通过解压缩器3161-3164路由该所选流子集中的流，或者如果所请求的流是全分辨率，则在未经缩放的视频路径3196上路由该所选流子集中的流。要被缩放的流由解压缩器3161-3164解压缩为未经压缩的视频，之后由缩放器3171-3174将每一个缩放到所请求的尺寸，之后由压缩器3181-3184将每一个压缩。注意：如果以不止一种分辨率请求特定的HQ流，则内部路由3192将该流多播(使用本领域从业者公知的IP多播技术)到一个或多个解压缩器3161-3164上和(如果所请求的尺寸之一是全分辨率)出埠路由3193上。所有所请求的流，无论其被缩放(从压缩器3181-3184)与否(从内部路由3192)，之后被发送到出埠路由3193。路由3193之后将每个所请求的流发送到请求它的应用程序/游戏服务器3121-3125上。在一实施例中，如果不止一个应用程序/游戏服务器请求同样分辨率的同一流，则出埠路由3193将该流多播到做出该请求的所有应用程序/游戏服务器3121-3125上。

[0442] 在共用视频缩放和重新压缩3142的当前优选实施例中，所述路由通过使用千兆位以太网开关来实施，所述解压缩、缩放以及压缩通过执行每一功能的离散的专门的半导体器件来实施。同样的功能可以以更高集成度实施在硬件中或由非常快的处理器实施。

[0443] 图31e显示了主机服务210的另一个实施例，其中之前所述的延迟缓冲器3115的功能在共用视频延迟缓冲、缩放和解压缩子系统3143中实现。图31g示出了子系统3143的细节。子系统3143的操作类似于图31f中所示的子系统3142的操作，除了3191首先根据来自应用程序/游戏服务器3121-3125的请求，选择哪些HQ视频流将被路由，之后请求延迟的HQ流通过延迟缓冲器3194(在本实施例被实施为RAID阵列(但其可被实施为具有足够带宽和能力的任何存储媒体))被路由，未被请求延迟的流通过未经延迟视频路径3195被路由。之后，延迟缓冲器3194和未经延迟视频3195的输出基于所请求的流将被缩放或不被缩放而由内部路由3192路由。经缩放的流通过解压缩器3161-3164、缩放器3171-3174和压缩器3181-3184而被路由至出埠路由3193。未经缩放的视频3196也被发送至出埠路由3193，之后，以之前图31f的子系统3142中所述的同样方式，出埠路由3193以单播或多播模式将视频发送到应用程序/游戏服务器。

[0444] 视频延迟缓冲、缩放和解压缩子系统3143的另一个实施例示于图31h中。在该实施例中，针对每个HQ流提供单独的延迟缓冲器HQ 3121D-HQ 3131D。假定RAM和闪存ROM的成本快速下降，其可用于延迟单独的经压缩的视频流，与具有共用延迟缓冲器3194相比，这将最终使得成本更低和/或更灵活。或者，在再一实施例中，单个延迟缓冲器3197(以虚线示出)可以以高性能集合资源(例如，非常快的RAM、闪存或磁盘)单独为所有HQ流提供延迟。在任何一种情况中，每个延迟缓冲器HQ 3121D-3131D能够对来自HQ视频源的进行可变地延迟，或者无延迟地通过该流。在另一实施例中，每个延迟缓冲器能够提供具有不同延迟量的多个流。所有的延迟或未经延迟均由应用程序/游戏服务器3121-3125来请求。在所有这些情况中，延迟和未经延迟的视频流3198被发送到内部路由3192，并通过之前所述的与图31g有关的子系统3143的其他部分继续下去。

[0445] 与各种图31n相关的前述实施例中，注意：直播流使用双向连接，且是为特定用户量身定做的，具有最小的延时。HQ流使用单向连接，且为单播和多播。注意：虽然多播功能在这些图中被示为单个单元，例如可被实施为千兆位以太网开关，但在大规模系统中，多播功能可能通过由多个开关构成的树结构来实施。实际上，对于来自高等级视频游戏玩家的视频流，即为这一情况，该玩家的HQ流被上百万用户同时观看。在这种情况下，在广播被多播的HQ流的连续阶段，有可能有大量的单独开关。

[0446] 出于诊断的目的，且为了向用户提供反馈(例如，让用户知道他的游戏玩法表演是多么的流行)，在一实施例中，主机服务210将明了每个应用程序/游戏服务器3121-3125的视频流同时有多少观众。这可由用于特定视频流的应用程序/游戏服务器通过保持计算有效请求的数量来实现。因此，同时具有100000名观众的玩家将知道他或她的游戏玩法是非常流行的，它将为游戏玩家造成激励，以做出更好的成绩并吸引观众。当(例如视频游戏锦标赛比赛的)视频流具有非常高度收视率时，可能需要讲解员来在电视游戏比赛期间进行讲解，这样观看该多播的某些用户或所有用户能够听到他们的解说词。

[0447] 应用程序/游戏服务器上运行的应用程序和游戏将被提供应用程序编程接口(API)，其中应用程序和/或游戏可提交对具有特定特征(例如，分辨率和延迟量)的特定视频流的请求。此外，服从于应用程序/游戏服务器上运行的操作环境或者图4a的主机服务控制系统401的这些API可以因为各种原因拒绝这些请求。例如，所请求的视频流可能具有某些许可权限限制(例如，使得它仅可由单个观众观看，而不会被广播给其他人)，可能有订阅限制(例如，观众可能必须付费才有权观看该流)，可能有年龄限制(例如，观众可能必须有18岁才能观看该流)，可能有保密限制(例如，使用该应用程序或玩该游戏的人可能仅限定所选数量或类别的观众可以观看(例如他或她的“朋友”)，或者可能根本不允许观看)，可能有需要资料被延迟的限制(例如，如果用户正在玩隐蔽类游戏，其中他或她的位置可被暴露)。有任意数量的可能限制流的观看的其他限制。在任意的这些情况中，应用程序/游戏服务器的请求将被拒绝，出具该拒绝的原因，在一实施例中，出具可选方案(例如，申明须交什么费用来进行订阅)，通过该可选方案，所述请求可被接受。

[0448] 之前任意实施例中存储于延迟缓冲器中的HQ视频流可被导出到主机服务210外的其他目的中。例如，特定的感兴趣的视频流可由应用程序/游戏服务器请求(一般由用户请求)导出到YouTube上。这种情况下，视频流和合适的描述信息(例如，玩家的姓名、游戏、时间、得分等)一起以与YouTube格式一致的格式通过互联网而被传送。这可通过通过在单独流中将解说音频多播到请求这种解说的所有游戏/应用程序服务器3121-3125上来实现。通过使用本领域从业者公知的音频混合技术，游戏/应用程序服务器将解说的音频与发送到用户场所211的音频流相合并。很可能存在多个讲解员(例如，具有不同观点，或者用不同语言)，而用户能够在其中间选择。

[0449] 以相似的方式，分离的音频流可被混合，或者起作为主机服务210中特定视频流(或单独的流)的音频轨的替换，混合或替换实时的或来自延迟缓冲器的视频流中的音频。这种音频可以是解说词或叙述，或者其能够为视频流中角色提供声音。这将使引擎电影(Machinima)(来自视频游戏视频流的用户生成动画)很容易被用户创建。

[0450] 全篇文档描述的视频流被示为：从应用程序/游戏服务器的视频输出中被捕捉的视频流，之后该视频流被流出和/或延迟并以各种方式而被再使用或发布。同样的延迟缓冲器可用于保留来自非应用程序/游戏服务器源的视频资料并提供用于回放和发布的相同灵活度，具有适当的限制。这种源包括来自电视台的直播馈送(或者无线电通信，或者非无线电通信，例如CNN，或者付费的，例如HBO，或者免费的)。这种资源还包括预录制的电影或电视节目、家庭电影、广告以及直播视频电视会议馈送。直播馈送可像游戏/应用服务器的直播输出那样被处理。预录制的资料可像延迟缓冲器的输出那样被处理。

[0451] 在一个实施例中，本文中所说明的各种功能模组及相关联的步骤可由含有用于执行所述步骤的固线式逻辑的特定硬件组件(诸如，特殊用途集成电路(“ASIC”))或由被编程的计算机组件与定制硬件组件的任何组合来执行。

[0452] 在一个实施例中，可将所述模组实施于诸如Texas仪器的TMS320x架构(例如，TMS320C6000、TMS320C5000，…等)的可编程数字信号处理器(“DSP”)上。可使用各种不同的DSP，同时仍遵守所述基本原理。

[0453] 实施例可包括如上文所阐述的各种步骤。所述步骤可体现于引起通用或专用处理器执行特定步骤的机器可执行指令中。已将与这些基本原理无关的各种元件(诸如，计算机存储器、硬碟机、输入设备)从图中省去以避免混淆相关方面。

[0454] 所公开的标的物的要素也可作为用于储存机器可执行指令的机器介质来提供。机器可读介质可包括(但不限于)闪存、光碟、CD-ROM、DVD ROM、RAM、EPROM、EEPROM、磁卡或光卡、传播媒体或适合于储存电子指令的其他类型的机器可读介质。举例而言，本发明可作为计算机程序来下载，该计算机程序可经由通信链路(例如，数据机或网络连接)借助于体现在载波或其他传播媒体中的数据信号而从远程计算机(例如，服务器)传送到请求计算机(例如，客户端)。

[0455] 还应理解，所公开的标的物的要素也可作为计算机程序产品来提供，该计算机程序产品可包括在上面储存有指令的机器可读介质，所述指令可用于程序化计算机(例如，处理器或其他电子设备)以执行一序列操作。或者，所述操作可通过硬件与软件的组合来执行。机器可读介质可包括(但不限于)软盘、光盘、CD-ROM，及磁光盘、ROM、RAM、EPROM、EEPROM、磁卡或光卡、传播媒体或适合于储存电子指令的其他类型的媒体/机器可读介质。举例而言，所公开的标的物的要素可作为计算机程序产品来下载，其中程序可经由通信链路(例如，数据机或网络连接)借助于体现于载波或其他传播媒体中的数据信号而自远程计算机或电子设备传送至请求过程。

[0456] 另外，尽管已结合特定实施例描述所公开的标的物，但众多修改及变更将适当地处于本公开的范畴内。因此，说明书及图式应视为说明性的而非限制性的意义。