将线性内容与压缩后的交互式内容一起组合为流动交互式视频的方法

专利名称：将线性内容与压缩后的交互式内容一起组合为流动交互式视频的方法
技术领域：
本公开总体上涉及改善用户操作及存取音频和视频媒体的能力的数据处理系统 的领域。
背景技术：
自从托马斯·爱迪生(Thomas Edison)时代以来，记录的音频及电影媒体已成为 社会的一方面。在20世纪初期，记录的音频媒体(磁柱及唱片)及电影媒体(投币式自动 点唱机及电影)广泛发行，但两种技术仍处于其起步阶段。在20世纪20年代后期，在大 众市场的基础上将电影与音频组合，之后将彩色电影与音频组合。无线电广播逐渐演变成 很大程度上支持广告的形式的广播大众市场音频媒体。当在20世纪40年代中期建立电视 (TV)广播标准时，电视与无线电以广播大众市场媒体的形式接合，从而将先前记录的或现 场直播的电影带入家庭中。至20世纪中期为止，大部分美国家庭已具有用于播放记录的音频媒体的唱片播 放器(phonograph record player)、用于接收现场直播的广播音频的无线电设备，及用于 播放现场直播的广播音频/视频(A/V)媒体的电视机。常常将所述3个“媒体播放器”(唱 片播放器、无线电设备及TV)组合到共有公共扬声器的橱柜中，变成家庭的“媒体中心”。尽 管对于消费者而言媒体选择有限，但媒体“生态系统”非常稳定。大多数消费者知道如何使 用“媒体播放器”且能够享受其能力的全部范围。同时，媒体的出版商(大多为电影和电视 工作室，及音乐公司)能够将其媒体分配给电影院与家庭两者，而不遭受广泛的盗版或“二 次销售”(也即，已使用媒体的重新销售)。通常，出版商不会从二次销售得到收入，且因此， 二次销售减少了出版商对于新的销售从原本可自己使用媒体的购买者得到的收入。尽管在 20世纪中期期间的确存有已使用的唱片出售，但所述销售不会对唱片出版商有大影响，因 为不同于电影或视频节目(其通常被成年人观看一次或仅数次)，音乐曲目可被收听数百 次或甚至数千次。因此，音乐媒体远比电影/视频媒体“经久”(也即，对于成年消费者而 言，其具有持久价值)。一旦购买了唱片，若消费者喜欢该音乐，则消费者可能将其保持很长 时间。自20世纪中期到现在，媒体生态系统对于消费者与出版商的利益及损失来说都 经历了一系列根本改变。在音频录音机(尤其是具有高质量立体声的盒式磁带)的广泛 引入的情况下，的确有较高程度的消费者便利。但其也标志着现在广泛的消费者媒体实 践_盗版的开始。的确，许多消费者纯粹出于便利起见而使用盒式磁带来录制其自己的唱片，但日益增加的消费者(例如，宿舍中准备存取彼此的唱片收集的学生)将进行盗版复 制。而且，消费者将录制经由无线电播放的音乐，而非从出版商购买唱片或磁带。消费者VCR的出现导致更多的消费者便利，因为现在VCR被设置为记录TV节目， 其可在稍后时间观看，且VCR也导致视频租赁业的建立，其中电影以及TV节目设计可在“点 播”基础上进行存取。自20世纪80年代中期以来的大众市场家庭媒体设备的快速开发已 导致消费者的空前的选择及便利程度，且也导致媒体出版市场的快速扩张。现今，消费者面对过多媒体选择以及过多媒体设备，其中许多被绑定到特定形式 的媒体或特定出版商。热衷的媒体消费者可能将一堆设备连接到房屋各房间中的TV及计 算机，造成至一或多个电视机和/或个人计算机(PC)的“鼠窝式”电缆以及一群远程控制。 (在本申请的上下文中，术语“个人计算机”或“PC”指代适合于在家庭或办公室中使用的任 何种类的计算机)，包括台式计算机、Macintosh麦金托什机器)⑧或其他非Windows (视 窗)计算机、与Windows相容的设备、Unix变体、笔记本计算机等)。所述设备可包括视频 游戏控制台、VCR、DVD播放器、音频环绕音效处理器/放大器、卫星机顶盒、电缆TV机顶盒 等。此外，对于热衷的消费者，可能由于相容性问题而存在多个类似功能的设备。举例而 言，消费者可能拥有HD-DVD与蓝光(Blu-ray) DVD播放器两者，或Microsoft Xbox (微软 家用游戏机) 与Sony Playstation(索尼游戏站) 视频游戏系统两者。实际上，由于 一些跨游戏控制台版本的的游戏的不相容性，消费者可能拥有XBox与稍后的版本(诸如， Xbox 360 )两者。经常地，消费者对于使用哪个视频输入端及哪个远端感到迷惑。甚至 在将光碟置放于正确的播放器(例如，DVD、HD-DVD、蓝光、Xbox或Playstation)中、选择用 于该设备的视频及音频输入端且发现正确远程控制之后，消费者仍面临技术挑战。举例而 言，在宽屏DVD的状况下，用户可能需要首先确定正确的纵横比(例如，4 3、完全、放大、 宽放大、电影院宽等)且接着在其TV或监视器屏幕上设定正确的纵横比。类似地，用户可 能需要首先确定正确的音频环绕音效系统格式(例如，AC-3、杜比数字、DTS等)且接着设 定正确的音频环绕音效系统格式。时常，消费者未意识到其可能未享受到其电视或音频系 统的全部能力下的媒体内容(例如，观看以错误纵横比挤压的电影，或收听立体声的音频 而非环绕音效的音频)。日益增加地，已将以基于互联网的媒体设备添加到设备的堆栈中。类似Sonos (索 罗斯) 数字音乐系统的音频设备使音频直接从互联网流动(stream)。同样地，类似 Slingbox (视灵宝 )娱乐播放器的设备记录视频且使其经由家庭网络流动或经由互联网 流动而出，其中可在PC上远程观看该视频。且互联网协议电视(IPTV)服务经由数字用户 线(DSL)或其他家庭互联网连接而提供类似电缆TV的服务。近来还努力将多个媒体功能 整合到单个设备(诸如，Moxi (摩西) 媒体中心及执行Windows XP媒体中心版本的PC) 中。尽管所述设备中的每个设备对其执行的功能提供一点便利，但每个设备缺乏对大多数 媒体的普遍且简单的存取。另外，常常由于昂贵的处理和/或本地储存的需要而使得所述 设备经常花费数百美元来制造。另外，所述现代的消费者电子设备通常消耗大量电力，甚至 当闲置时也消耗大量电力，这意谓着其随着时间而更加昂贵且浪费能源。举例而言，若消费 者忘记将设备切断或将其切换到不同视频输入端，则该设备可能继续操作。此外，因为所述 设备当中没有一个设备为完全的解决方案，所以必须将其与家庭中的其他设备的堆栈整合 在一起，这仍对用户留下鼠窝式线及许多远程控制。
此外，当许多较新的以互联网为基础的设备适当地工作时，其通常提供更一般形 式(与其原本可能可用的形式相比)的媒体。举例而言，使视频经由互联网流动的设备常 常仅使视频材料流动，而不能使常常伴随DVD的互动式“额外项目”流动，如视频的“制作”、 游戏或导演评论。这是由于以下事实互动式材料经常是以特定格式制作，该特定格式意 欲用于在本地处理互动性的特定设备。举例而言，DVD、HD-DVD及蓝光光碟中每一者具有其 自身的特定互动格式。任何家庭媒体设备或本地计算机(其可能经开发以支持所有流行格 式)将需要一定程度的尖端性(sophistication)及灵活性，其将可能对于消费者操作而言 过于昂贵及复杂。使该问题加重，若稍后在将来引入新格式，则本地设备可能不具有支持新格式的 硬件能力，这将意味着消费者将必须购买升级的本地媒体设备。举例而言，若在稍后的日期 引入较高分辨率的视频或立体视频(例如，每一只眼一个视频流)，则本地设备可能不具有 解码该视频的计算能力，或其可能不具有用于以新格式输出该视频的硬件(例如，假定通 过与遮光眼镜(shuttered glassess)同步的120fps视频来实现立体视觉，其中将60fps 传送到每一只眼，若消费者的视频硬件仅可支持60fps视频，则该选项在缺乏升级的硬件 购买的情况下将不可用)。当谈及尖端的互动式媒体(尤其是视频游戏)时，媒体设备废弃及复杂度的问题 为严重问题。现代视频游戏应用基本上划分成四个主要非便携式式硬件平台 Sony PlayStation 1、2 及 3 (PSl、PS2，及 PS3) ； Microsoft Xbox 及 Xbox 360 ;及
Nintendo Gamecube (任天堂方糖)⑧及Wi i ；以及以PC为基础的游戏。所述平台中的每一 者不同于其他者，使得被编写以在一个平台上执行的游戏通常不会在另一平台上执行。也 可能存在一代设备与下一代设备的相容性问题。即使大多数软件游戏开发者建立独立于特 定平台而设计的软件游戏，为了在特定平台上执行特定游戏，也需要专有软件层(其经常 被称为“游戏开发引擎」”)来调适游戏以在特定平台上使用。每一个平台以“控制台”(也 即，附接到TV或监视器/扬声器的脱机盒(standalone box))的形式出售给消费者或其本 身为PC。通常，视频游戏在诸如蓝光DVD、DVD_R0M或⑶-ROM的光学媒体上出售，该光学媒 体含有体现为尖端的实时软件应用程序的视频游戏。随着家庭宽带速度增加，视频游戏正 日益变得可用于下载。由于高级视频游戏的实时性及高计算要求而使得实现与视频游戏软件的平台相 容性的特殊性要求极端苛刻。举例而言，一个人可能期望从一代视频游戏到下一代视频游 戏(例如，自 XBox 至 XBox 360，或自 Playstation 2(“PS2”)至 Playstation 3(“PS3”)) 的完全游戏相容性，正如存在从一个PC到具有较快处理单元或核心的另一 PC的生产力应 用程序(例如，MicrosoftWord(微软文字处理软件))的普遍相容性。然而，对于视频游戏 并非是这种状况。因为当发行一代视频游戏时，视频游戏制造商通常寻求对于给定价格点 的最高可能性能，所以经常对系统进行动态架构改变，以使得被编写以用于前代系统的许 多游戏在稍后一代系统上不能工作。举例而言，XBox基于x86系列处理器，而XBox 360基 于PowerPC系列。可利用技术来模仿先前架构，但假定视频游戏为实时应用程序，则在模仿中达成 完全相同的行为常常不切实际。这是对消费者、视频游戏控制台制造商及视频游戏软件出版商的损失。对于消费者而言，这意味着将旧的一代视频游戏控制台与新的一代视频游戏 控制台两者保持接通到TV以便能够玩所有游戏的必要性。对于控制台制造商而言，这意味 着与新控制台的模仿及较慢采用相关的成本。且对于出版商而言，这意味着可能必须发行 新游戏的多个版本以便涵盖所有潜在的消费者_不仅发行用于视频游戏的每个商标(例 如，XBohPlaystation)的版本，而且常常发行用于给定商标的每个版本(例如，PS2及PS3) 的版本。举例而言，开发艺电有限公司(Electronic Arts)的“疯狂橄榄球08”的单独版本 以用于XBox、XBox 360、PS2、PS3、Gamecube、Wii及PC平台以及其他平台。便携式设备(诸如，移动电话及便携式媒体播放器)也对游戏开发商提出挑战。日 益增加地，所述设备连接到无线数据网络且能够下载视频游戏。但是，市场中存在具有多种 不同显示分辨率及计算能力的多种移动电话及媒体设备。而且，因为所述设备通常具有电 力消耗、成本及重量约束，所以其通常缺乏类似于图形处理单元(“GPU”)的高级图形加速 硬件(诸如，由美国加州的圣克拉拉的NVIDIA(英伟达公司)制造的设备)。因此，游戏软 件开发商通常开发同时用于许多不同类型的便携式设备的给定游戏标题。用户可发现给 定游戏标题不可用于其特定移动电话或便携式媒体播放器。在家庭游戏控制台的状况下，硬件平台制造商通常向软件游戏开发商收取用于在 其平台上发布游戏的能力的版税。移动电话无线通信公司通常也向游戏出版商收取用于将 游戏下载到移动电话中的版税。在PC游戏的状况下，不存在用于发布游戏所支付的版税， 但由于用于支持多种PC配置及可能引起的安装问题的较高消费者服务负担而使得游戏开 发商通常面临高成本。而且，PC通常较少阻碍游戏软件的盗版，因为其可很容易地由精通 技术的用户重新编程且游戏可更容易地被盗版且更容易地被分配(例如，经由互联网)。因 此，对于软件游戏开发商而言，在游戏控制台、移动电话及PC上发行具有成本及不利之处。对于控制台及PC软件的游戏出版商而言，成本不止于此。为了经由零售通道分配 游戏，出版商向零售商收取低于出售价格的批发价格以使零售商具有利润率。出版商通常 也必须支付制造及分配保存游戏的物理媒体的成本。零售商经常也向出版商收取“价格保 护费”以涵盖可能的意外费用(诸如，游戏售不出，或游戏的价格降低，或零售商必须退还部 分或所有批发价格和/或从购买者收回游戏)。另外，零售商通常也向出版商收取用于帮助 在广告传单中销售游戏的费用。此外，零售商日益增加地从已玩完游戏的用户购买回游戏， 且接着将所述游戏以使用过的游戏出售，通常不与游戏出版商分享使用过的游戏的收入。 以下事实增加了施加给游戏出版商的成本负担游戏常常被经由互联网盗版及分配以供用 户下载及进行免费复制。随着互联网宽带速度增加且宽带连接性在美国及全世界变得更广泛(更具体地， 到家庭和到租赁连接互联网的PC的“网吧”)，游戏被更多地经由下载而分配到PC或控制 台。而且，宽带连接更多地用于玩多人及大型多人在线游戏(该两者在本公开中由首字母 缩写词“MM0G”来指代)。这些改变减轻了与零售分配相关的一些成本及问题。下载在线游 戏解决了游戏出版商的一些不利之处，因为分配成本通常较小且存在较少或不存在未出售 媒体的成本。但已下载的游戏仍被盗版，且由于其大小(大小常常为几十亿字节)而使得 其可能花费非常长的时间来下载。另外，多个游戏可装满小磁盘驱动器，例如连同便携式计 算机一起或连同视频游戏控制台一起出售的那些磁盘驱动器。然而，就游戏或MMOG需要在 线连接以使得游戏可玩的程度而言，盗版问题得以减轻，因为通常需要用户具有有效的用户帐户。不同于可由相机拍摄显示屏幕的视频或由麦克风记录来自扬声器的音频来复制的 线性媒体(例如，视频及音乐)，每个视频游戏体验是唯一的，且不可使用简单的视频/音 频记录来复制。因此，甚至在未强力执行版权法且盗版猖獗的区域中，也可保护MMOG免于 被盗版，从而可支持商业。举例而言，已成功地部署Vivendi SA(维旺迪公司)的“魔兽世 界”MM0G，而在全世界未遭受盗版。且许多在线或MMOG游戏(诸如，Linden Lab (林登实验 室)的“第二人生”MM0G)通过建在游戏中的经济模型而产生游戏运营商的收入，其中资产 可使用在线工具而带来、出售且甚至建立。因此，可使用除传统游戏软件购买或订阅之外的 机制来为在线游戏的使用付费。尽管由于在线或MMOG的性质而使得常常可减轻盗版，但在线游戏运营商仍面临 其余挑战。许多游戏需要大量的本地(也即，家庭内)处理资源以供在线或MMOG适当地工 作。若用户具有低性能的本地计算机(例如，不具有GPU的计算机，诸如低端笔记本计算 机)，则其可能不能够玩该游戏。另外，随着游戏控制台老化，其远落后于目前技术状态且 可能不能够处理更高级的游戏。即使假定用户的本地PC能够处理游戏的计算要求，常常也 存在安装复杂度。可能存在驱动器不相容性(例如，若下载新游戏，则可能安装新版本的图 形驱动器，其致使依赖于旧版本图形驱动器的先前已安装的游戏不可操作)。随着下载更 多游戏，控制台可能用完本地磁盘空间。当发现缺陷并修复时或若对游戏进行了修改(例 如，若游戏开发商发现游戏的级别太难玩或太容易玩)，复杂游戏通常随着时间推移而从游 戏开发商接收下载的补丁(patch)。该补丁需要新的下载。但有时并非所有用户完成所有 补丁的下载。在其他时候，下载的补丁引入其他相容性或磁盘空间消耗问题。而且，在游戏播放期间，可能需要大数据下载以将图形或行为信息提供到本地PC 或控制台。举例而言，若用户进入MMOG中的一个房间中，且遇到由图形数据组成或具有在 用户的本地机器上不可用的行为的场景或人物，则必须下载那个场景或人物的数据。若互 联网连接不够快，则此可导致玩游戏期间的实质延迟。此外，若所遇到的场景或人物需要超 过本地PC或控制台的储存空间或计算能力的储存空间或计算能力，则其可产生下述情形 其中用户不能在游戏中继续，或必须以质量降低的图形继续。因此，在线或MMOG游戏常常 限制其储存和/或计算复杂度要求。另外，其常常限制游戏期间的数据传送的量。在线或 MMOG游戏也可使可玩游戏的用户的市场变窄。此外，精通技术的用户越来越多地对游戏的本地复本进行反向工程且修改游戏以 使得他们可以作弊。作弊可能与进行比用人力可能的速度快的重复按钮按压(例如，为了 非常快速地射击)一样简单。在支持游戏中资产交易的游戏中，作弊可达到导致欺骗性交 易涉及具有实际经济价值的资产的欺诈程度。当在线或MMOG经济模型基于所述资产交易 时，这可导致对游戏运营商的实质有害后果。开发新游戏的成本随着PC及控制台能够制作越来越尖端的游戏(例如，具有更逼 真的图形(诸如，实时光线追踪)，及更逼真的行为(诸如，实时物理学仿真))而增长。在 视频游戏业的早期，视频游戏开发是应用程序软件开发非常类似的过程；也即，大多数开发 成本在软件的开发中(与图形、音频及行为要素或“资产”的开发相对比)，诸如可被开发以 用于具有广泛特殊效果的电影的那些软件开发。现今，许多尖端的视频游戏开发成果比软 件开发更类似于富有特效的电影开发。举例而言，许多视频游戏提供3-D世界的仿真，且产 生更加真实(也即，看似与摄影拍摄的实景(live action)图像一样逼真的计算机图形)的人物、道具及环境。照片一样逼真的游戏开发的最具挑战方面中的一者为创建不能区别 于实景人脸的计算机产生的人脸。面部捕获技术(诸如，由加州的圣弗朗西斯科的Mova开 发的Contour (轮廓 )真实性捕获系统)捕获表演者的面部的精确几何形状并在表演者 处于运动中时以高分辨率追踪表演者的面部的精确几何形状。此技术允许在PC或游戏控 制台上再现3D面部，该3D面部实际上不能区别于所捕获的实景面部。精确地捕获及再现 “照片一样逼真的”人脸在多个方面是有用的。首先，高度可识别的名人或运动员常常用于 视频游戏中(常常被高成本雇用)，且不完美性可能对于用户而言显而易见，从而使观看体 验(viewing experience)分心或令人不愉快。经常地，需要高度细节来实现高度的照片一 样的逼真感_潜在地需要再现大量多边形及高分辨率纹理(在多边形和/或纹理在帧接帧 的基础上随着面部移动而改变的情况下)。当具有详细纹理的高多边形计数场景快速改变时，支持游戏的PC或游戏控制台 可能不具有足够的RAM来储存用于游戏片段中所产生的所需数目的动画帧的足够多边形 及纹理数据。另外，通常可用于PC或游戏控制台上的单个光学驱动器或单个磁盘驱动器通 常比RAM缓慢得多，且通常不能跟上GPU在再现多边形及纹理中可接受的最大数据速率。当 前游戏通常将大多数多边形及纹理载入到RAM中，这意味着给定场景在复杂度及持续时间 上很大程度上受RAM的容量限制。在例如面部动画制作的状况下，这可能将PC或游戏控制 台限制于并无真实感的低分辨率面部，或限制于仅可在游戏暂停且载入用于更多帧的多边 形及纹理(及其他数据)之前在有限数目的帧中制作成动画的真实感面部。当PC或控制台显示类似于“正在载入...”的消息时，观看进程条跨屏幕缓慢地 移动被现今的复杂视频游戏的用户公认为是内在缺点。下一个场景从磁盘(除非另外有 条件，否则本文中的“磁盘”指非易失性光学媒体或磁性媒体，以及诸如半导体“闪存”存储 器的非磁盘媒体)载入时的延迟可花费若干秒或甚至若干分钟。这浪费时间且可能使游戏 玩家相当沮丧。如先前所述，大量或所有延迟可能是由于来自磁盘的多边形、纹理或其他数 据的载入时间，但也可能是以下状况当PC或控制台中的处理器和/或GPU准备用于场景 的数据时，花费一部分载入时间。举例而言，英式足球视频游戏可允许玩家在大量玩家、小 组、运动场及天气条件当中选择。因此，取决于选择什么特定组合，可能需要用于场景的不 同多边形、纹理及其他数据(统称“对象”)(例如，不同小组在其制服上具有不同色彩及图 案)。可能要列举各种排列中的许多或所有排列且提前预先计算对象中的许多或所有对象 并将对象储存在用于储存游戏的磁盘上。但是，若排列的数目很大，则所有对象所需的储存 量可能过大以致不能安装在磁盘上(或太不切实际以致不能下载)。因此，现有的PC及控 制台系统通常在给定场景的复杂度与播放持续时间两者上受约束且对于复杂场景遭受长 的载入时间。先前技术的视频游戏系统及应用程序软件系统的另一显著限制在于其越来越多 地使用例如3D对象的大数据库(诸如，多边形及纹理)，所述大数据库需要被载入到PC或 游戏控制台中以用于处理。如上所述，当将所述数据库在本地储存于磁盘上时，所述数据库 可花费长时间来载入。然而，若数据库系储存于远程位置且经由互联网来存取，则载入时间 通常严重得多。在此种情形下，下载大数据库可能花费几分钟、几小时或甚至几天。另外， 所述数据库常常产生大量费用(例如，用于游戏、电影或历史记录片中的详细的高的有桅 帆船的3D模型)且意欲用于销售给本地终端用户。然而，一旦数据库被下载至本地用户，其就有被盗版的风险。在许多状况下，用户仅为了评估数据库来观看其是否适合用户的需 要(例如，当用户执行特定移动时，用于游戏人物的3D服装是否具有满意的外观或外表) 的目的而希望下载数据库。对于在决定进行购买之前评估3D数据库的用户而言，长载入时 间可能是阻碍。类似问题在MMOG (更具体地，如允许用户利用更加定制化的人物的游戏)中出现。 对于显示人物的PC或游戏控制台，其需要能够存取具有3D几何形状(多边形、纹理等)以 及所述人物的行为(例如，若人物具有盾牌，则盾牌是否足够强以使矛偏转)的数据库。通 常，当MMOG由用户初次玩时，用于人物的大量数据库在游戏的初始复本下已经可用，游戏 的初始复本在本地在游戏光盘上可用或被下载到磁盘。但是，随着游戏进展，若用户遇到数 据库在本地不可用的人物或对象(例如，若另一用户已建立一定制人物)，则在可显示该人 物或对象之前，必须下载其数据库。这可导致游戏的实质延迟。给定视频游戏的尖端性及复杂度，则在先前技术视频游戏控制台情况下对视频游 戏开发商及出版商的另一挑战在于开发视频游戏经常花费2年到3年，成本在数千万美 元。假定新视频游戏控制台平台以大致每隔五年一次的速率引入，则游戏开发商需要在新 游戏控制台发行之前的数年开始那些游戏的开发工作，以便在发行新平台时使视频游戏同 时可用。来自竞争性制造商的若干个控制台有时大约同时发行(例如，彼此在一年或两年 内)，但尚待分晓的是每个控制台的流行性(例如，哪个控制台将产生最大的视频游戏软件 销售)。举例而言，在最近的控制台周期中，Microsoft XBox 360、SonyPlaystation 3及 Nintendo Wii计划在大约相同的大体时段引进。但在所述引进之前的数年中，游戏开发商 实质上必须“压注(place bets)”哪些控制台平台将比其他者更成功，且相应地投入其开 发资源。电影制作公司也必须在电影发行之前很长时间基于其估计可能成功的电影而分 摊其有限的制作资源。给定视频游戏所需的投资的增长程度，则游戏制作越加变得类似电 影制作，且游戏制作公司常规上基于其对特定视频游戏的将来成功的估计而投入其制作资 源。但是，不同于电影公司，此压注并非仅基于制作本身的成功；而是，其依据于游戏要在其 上执行的游戏控制台的成功。同时在多个控制台上发行游戏可减轻风险，但此额外努力增 加成本，且经常延迟游戏的实际发行。PC上的应用程序软件及用户环境正变得更为计算上密集、动态及互动，不仅使其 在视觉上更吸引用户，而且使其更有用及直观。举例而言，新Windows Vista(视窗远景) 操作系统与Macintosh 操作系统的后续版本两者并入了视觉动画效应。高级图形工具 (诸如，来自Autodesk(欧特克)公司的Maya (玛雅 ))提供非常尖端的3D再现及动画 制作能力(其推动了目前技术状态的CPU及GPU的限制)。然而，这些新工具的计算要求对 于所述产品的用户及软件开发商而言产生了许多实际问题。因为操作系统(OS)的视觉显示必须在多种计算机(包括不再出售但仍可随着新 OS而升级的前代计算机)上工作，OS图形要求在很大程度上受OS要用于的计算机(其通 常包括不包括GPU的计算机)的最少共同点限制。这严重地限制OS的图形能力。此外，电 池供电的便携式计算机(例如，笔记本计算机)限制视觉显示能力，因为CPU或GPU中的高 计算活动通常导致较高电力消耗及较短电池寿命。便携式计算机通常包括在不利用处理 器时自动地减低处理器活动性以降低电力消耗的软件。在一些计算机型号中，用户可手动 地减低处理器活动性。举例而言，Sony的VGN-SZ280P笔记本计算机包括在一侧上标记为"Stamina (持久性)”(用于低性能，更长电池寿命)且另一侧上标记为“Speed (速度)”(用 于高性能，较短电池寿命)的交换器。在便携式计算机上执行的OS必须能够即使在计算机 以其峰值性能能力的一小部分执行的情况下也可用地起作用。因此，OS图形性能常常保持 为远低于目前技术状态的可用计算能力。经常出售高端的计算上密集的应用程序(如Maya)，期望所述应用程序将用于高 性能PC上。此通常产生高得多的性能，及更昂贵且便携性较差、最少共同点的要求。因此， 所述应用程序具有比通用OS(或通用生产力应用程序，类似MicrosoftOffice)有限得多的 目标受众且通常以比通用OS软件或通用应用程序软件低得多的量出售。潜在的受众进一 步受限制，因为预期的用户时常难以提前试用所述计算上密集的应用程序。举例而言，假设 学生希望了解如何使用Maya或已经知道所述应用程序的潜在购买者在购买中希望在进行 投资之前试用Maya (此可能涉及也购买能够执行Maya的高端计算机)。当学生或潜在购 买者可下载Maya的演示版本或得到Maya演示版本的物理媒体复本时，若其缺乏能够执行 Maya的全部潜能(例如，处理复杂3D场景)的计算机，则其将不能够进行产品的全方位评 估。此实质上限制所述高端应用程序的受众。这也使出售价格变高，因为开发成本通常经 过比通用应用程序的购买次数小得多的购买次数而分摊。高价应用程序也对使用应用程序软件的盗版复本的个体及商业产生更多刺激。因 此，高端应用程序软件遭受猖獗盗版，尽管该软件的出版商进行了大量努力来通过各种技 术减轻该盗版。但是，甚至当使用盗版的高端应用程序时，用户也不可能排除投资昂贵的目 前技术状态的PC来执行盗版复本的需要。因此，尽管用户可以用软件应用程序的实际零 售价格的一小部分获得软件应用程序的使用，但盗版软件的用户仍需要购买或获得昂贵的 PC,以便完全利用该应用程序。此对于高性能盗版视频游戏的用户同样成立。尽管盗版者可以用游戏的实际价格 的一小部分得到游戏，但其仍需要购买适当地玩游戏所需的昂贵计算硬件(例如，GPU-增 强型PC，或类似XBox 360的高端视频游戏控制台)。假定视频游戏通常是消费者的娱乐， 则用于高端视频游戏系统的额外成本可能是过于昂贵的。该情形在当前工人的平均年收入 相当低(相对于美国的当前工人平均年收入)的国家(例如，中国)中更糟。这样，小得多 的百分比的人口拥有高端视频游戏系统或高端PC。在这些国家中，用户可支付费用以使用 连接到互联网的计算机的“网吧”相当普遍。经常地，所述网吧具有不具有高性能特征(诸 如，原本可使玩家能够玩计算上密集的视频游戏的GPU)的较旧型号或低端PC。这是在低端 PC上执行的游戏成功的关键因素(诸如，Vivendi的“魔兽世界”，其在中国高度成功，且通 常是在中国的网吧中玩)。相比之下，计算上密集的游戏(如“第二人生”)更不可能在安 装于中国网吧中的PC上玩。所述游戏实际上对于仅能够存取网吧中的低性能PC的用户来 说是不可访问的。对于考虑购买视频游戏且首先愿意通过经由互联网将演示下载到其家庭而试用 游戏的示范版本的用户也存在障碍。视频游戏演示常常为游戏的全能版本，其中一些特征 停用，或对游戏播放的量施加限制。此可能涉及在可将游戏安装于PC或控制台上且在PC或 控制台上执行之前下载数十亿字节的数据的长过程(可能几个小时)。在PC的状况下，其 也可能涉及算出游戏需要哪些特殊驱动器(例如，DirectX或OpenGL驱动器)，下载正确的 版本，安装正确的版本，及接着确定PC是否能够播放该游戏。后者步骤可能涉及确定PC是否具有足够的处理(CPU及GPU)能力、足够的RAM及相容的OS (例如，一些游戏在Windows XP上执行而不在Vista上执行)。因此，在试图执行视频游戏演示的长过程之后，用户可能 发现在给定用户的PC配置的情况下视频游戏演示不可能玩。更糟地，一旦用户已下载新驱 动器以用于尝试该演示，这些驱动器版本就可能与用户在PC上习惯使用的其他游戏或应 用程序不相容，因此，演示的安装可致使先前可操作的游戏或应用程序不能操作。这些障 碍不仅使用户沮丧，而且其也对视频游戏软件出版商及视频游戏开发商销售其游戏产生障 碍。导致不具经济效益的另一问题与以下事实有关给定PC或游戏控制台通常被设 计以适应对应用程序和/或游戏的特定程度的性能要求。举例而言，一些PC具有或多或少 的RAM、较慢或较快的CPU及较慢或较快的GPU (若其具有GPU)。一些游戏或应用程序利用 给定PC或控制台的全计算能力，而一些游戏或应用程序却不利用给定PC或控制台的全计 算能力。若用户的游戏或应用程序的选择未达到本地PC或控制台的峰值性能能力，则用户 可能由于未利用的特征而在PC或控制台上浪费了财力。在控制台的状况下，控制台制造商 可能支付比资助控制台成本所要的多的成本。存在于视频游戏的销售及享受中的另一问题涉及在用户实施购买游戏之前允许 用户观看他人玩游戏。存在用于记录视频游戏以在稍后时间重放的若干先前技术方法。举 例而言，美国专利第5，558，339号教导了在“游戏播放”期间将游戏状态信息(包括游戏控 制器动作)记录在视频游戏客户端计算机(由同一个或不同用户拥有)中。此状态信息可 在稍后时间使用以在视频游戏客户端计算机(例如，PC或控制台)上重放一些或所有游戏 动作。该方法的显著缺点在于对于观看已记录的游戏的用户，用户必须具有能够播放该游 戏的视频游戏客户端计算机且必须具有在该计算机上执行的视频游戏应用程序，以使得当 重放被记录的游戏状态时游戏播放是完全相同的。除此之外，视频游戏应用程序必须是以 在被记录的游戏与经回放的游戏之间不存在可能的执行差异的方式编写。举例而言，游戏图形大体在帧接帧基础上计算。对于许多游戏，取决于场景是否特 别复杂或是否存在减缓执行的其他延迟(例如，在PC上，另一过程可能正在执行，以致从游 戏应用程序夺走CPU周期)，游戏逻辑有时可能花费比一帧时间短或比一帧时间长的时间 来计算为下一个帧而显示的图形。在此种游戏中，以比一帧时间稍少的时间(例如，少几个 CPU时钟周期)计算的“临限值”巾贞最终可出现。当使用完全相同的游戏状态信息再次计算 该同一场景时，可能容易花费比一帧时间多几个CPU时钟周期的时间(例如，若内部CPU总 线稍微与外部DRAM总线不同相，且即使不存在来自从游戏处理夺走数毫秒CPU时间的另一 过程的大延迟，其也引入几个CPU周期时间的延迟)。因此，当回放游戏时，帧变成以两个 帧时间计算而非以单个帧时间计算。一些行为基于游戏计算新帧的频率(例如，当游戏取 样来自游戏控制器的输入时)。当播放游戏时，用于不同行为的时间参考中的该偏差不会 影响游戏播放，但其可导致所回放的游戏产生不同结果。举例而言，若篮球的轨道是以稳定 的60fps速率来计算，但游戏控制器输入是基于计算的帧的速率来取样，则当记录游戏时， 计算的帧的速率可能为53fps，而当重放游戏时，计算的帧的速率可能为52fps，此可使得 篮球是否被阻止进入篮中存在差异，从而导致不同结果。因此，使用游戏状态记录视频游戏 需要非常谨慎的游戏软件设计，以确保使用同一游戏状态信息重放产生完全相同的结果。用于记录视频游戏的另一先前技术方法是仅记录PC或视频游戏系统的视频输出
11(例如，到VCR、DVD记录器，或到PC上的视频捕获板)。接着可将视频回倒及重放，或替代 地，将记录的视频上传到互联网(通常在将视频压缩之后)。该方法的不利之处在于当回 放3D游戏序列时，用户限于仅从观看点(序列从该观看点被记录)来观看序列。换言之， 用户不可改变场景的观看点。另外，当经由互联网而使在家庭PC或游戏控制台上播放的记录的游戏序列的经 压缩的视频为其他用户可用时，即使视频是实时压缩，也不可能实时地将经压缩的视频上 传到互联网。其原因是因为世界上连接到互联网的许多家庭具有高度不对称的宽带连接 (例如，DSL及电缆调制解调器通常具有比上流带宽高得多的下流带宽)。被压缩的高分辨 率视频序列常常具有比网络的上传带宽容量高的带宽，使得其不可能实时上传。因此，在播 放游戏序列之后(可能几分钟或甚至几小时)，在互联网上的另一用户能够观看该游戏之 前，将存在显著延迟。尽管该延迟在特定情形下(例如，观看在先前时间出现的游戏玩家的 成果)可容忍，但其消除了观看游戏现场直播(例如，由优胜玩家玩的篮球锦标赛)的能力 或现场直播地播放游戏时的“即刻重放”能力。另一先前技术方法允许具有电视接收器的观看者观看视频游戏现场直播，但仅在 电视制作人员的控制下。美国与其他国家中的一些电视频道提供视频游戏观看频道，其中 电视观众能够在视频游戏频道上观看特定的视频游戏用户(例如，参加锦标赛烦人顶级玩 家)。这通过将视频游戏系统(PC和/或控制台)的视频输出馈送至用于电视频道的视频 分配及处理设备中来完成。这正如电视频道广播现场直播的篮球比赛时的情况，其中若干 个相机从篮球场周围的不同角度提供现场直播的馈送。电视频道接着能够利用其视频/音 频处理及效应设备来操作来自各种视频游戏系统的输出。举例而言，电视频道可在来自视 频游戏的视频之上叠加指示不同玩家的状态的文字(正如其可在现场直播的篮球比赛期 间叠加文字)，且电视频道可加录来自评论员(其可论述在比赛期间出现的动作)的音频。 另外，可将视频游戏输出与记录游戏的实际玩家的视频的相机(例如，显示玩家对游戏的 情绪反应)组合。该方法的一个问题在于必须实时地使所述现场直播的视频馈送为电视频道的视 频分配及处理设备可用，以便使其具有现场直播的广播的刺激性。然而，如先前所述，当视 频游戏系统从家庭执行时(尤其是当广播的一部分包括来自正捕获游戏玩家的真实世界 视频的相机的现场直播的视频时)，这常常不可能。另外，在锦标赛情形下，所关注的是家庭 中游戏者可修改游戏及作弊，如先前所述。由于这些原因，电视频道上的所述视频游戏广播 常常配置有聚集于公共位置处(例如，在电视演播室处或在竞技场中)的播放器及视频游 戏系统，其中电视制作设备可接受来自多个视频游戏系统及潜在的现场直播的相机的视频 馈送。尽管所述先前技术视频游戏电视频道可为电视观众提供非常刺激的演出(这是 与现场直播的运动事件同类(例如，与以“运动员”呈现的视频游戏玩家同类)的体验，不 仅根据其在视频游戏世界中的动作，而且根据其在真实世界中的动作)，但这些视频游戏系 统常常限于玩家彼此身体上极接近的情形。此外，因为电视频道被广播，所以每个被广播的 频道仅可显示由电视频道的制作人员选择的一个视频流。由于这些限制及广播时间、制作 设备及制作人员的高成本，所述电视频道通常仅显示参加顶级锦标赛的顶级玩家。另外，向全部电视观众广播视频游戏的全屏幕图像的给定电视频道每次仅显示一个视频游戏。这严重地限制电视观看者的选择。举例而言，电视观看者可能对给定时间显 示的游戏不感兴趣。另一观看者可能仅对观看并非由电视频道在给定时间放映的特定玩家 的游戏播放感兴趣。在其他状况下，观看者可能仅对观看内行玩家如何处理游戏中的特定 级别感兴趣。其他观看者可能希望控制观看点(视频游戏从该观看点来看)，该观看点不同 于由制作小组等选择的观看点。简言之，电视观看者在观看视频游戏中可能具有无数的偏 好(即使若干个不同电视频道可用，电视网络的特定广播也不适应所述偏好)。由于所有上 述原因，使得先前技术视频游戏电视频道在向电视观看者呈现视频游戏中具有显著限制。先前技术视频游戏系统及应用程序软件系统的另一缺点在于他们很复杂，且通 常遭受错误、崩溃和/或无意识且不需要的行为(统称“缺陷”)。尽管游戏及应用程序在 发行之前通常经历除错及调谐过程(经常称为“软件质量保证”或SQA)，但几乎不变的是 一旦游戏或应用程序被发行到领域中的广大受众，缺陷就会突然出现。遗憾的是，软件开发 商难以在发行之后识别及追踪到许多缺陷。软件开发商可能难以意识到缺陷。即使当其了 解缺陷时，也可能仅存在其可用于识别是什么引起该缺陷的有限量的信息。举例而言，用户 可打电话给游戏开发商的消费者服务热线且留下消息，该消息陈述当玩游戏时，屏幕开始 闪烁，接着变成固体蓝(solid blue)且PC冻结。其为SQA小组提供了在追踪缺陷中有用 的非常少的信息。在线连接的一些游戏或应用程序在特定状况下有时可提供更多信息。举 例而言，有时可使用”看门狗”过程来监视游戏或应用程序是否“崩溃”。看门狗过程可收 集游戏或应用程序崩溃时关于游戏或应用程序过程的状态(例如，存储器堆栈使用状态、 游戏或应用程序进展到的程度等)的统计，且接着经由互联网而将所述信息上传至SQA小 组。但在复杂游戏或应用程序中，该信息可花费非常长的时间来解密，以便准确地确定在崩 溃时用户正在进行什么。尽管如此，也不可能确定什么事件序列导致崩溃。与PC及游戏控制台相关联的又一问题在于其经受使消费者极不便利的服务问 题。服务问题也影响PC或游戏控制台的制造商，因为其通常需要发送特殊盒子以安全地装 运破损的PC或控制台，且因而招致修理的成本(若PC或控制台处于保修期内)。游戏或应 用程序软件出版商也可受处于修理状态中的PC和/或控制台引起的销售损失(或在线服 务使用)影响。图 1 说 明诸如 Sony Playstation 3、Microsoft Xbox 360 、
NintendoWii 、以Windows为基础的个人计算机或Apple Macintosh的先前技术视频游戏 系统。所述系统中的每一者包括用于执行程序码的中央处理单元(CPU)(通常为用于执行 高级图形操作的图形处理单元(GPU))，及用于与外部设备及用户通信的多个形式的输入/ 输出(1/0)。为简单起见，将所述组件显示为组合在一起为单个单元100。图1的先前技术 视频游戏系统也显示为包括光学媒体驱动器104(例如，DVD-ROM驱动器)；用于储存视频 游戏程序代码及数据的硬盘驱动器103 ；用于播放多人游戏、用于下载游戏、补丁、演示或 其他媒体的网络连接105 ；用于储存当前正由CPU/GPU 100执行的程序码的随机存取存储 器(RAM)IOl ；用于在游戏播放期间接收来自用户的输入命令的游戏控制器106 ；及显示设 备102 (例如，SDTV/HDTV或计算机监视器)。图1中所显示的先前技术系统受到若干限制。首先，与RAM 101的存取速度相比 较，光学驱动器104及硬碟机103往往具有慢得多的存取速度。当直接通过RAM 101工作 时，由于RAM 101通常具有高得多的带宽且不会受到磁盘机构相对长的搜寻延迟的事实，CPU/GPU 100在实践中可处理比直接从硬盘驱动器103或光学驱动器104读出程序代码及 数据时可能的每秒多边形数多得多的每秒多边形数。但仅有限量的RAM提供于这些先前技 术系统中(例如，256-512兆字节)。因此，常常需要“正在载入...”序列，其中RAM 101被 周期性地填充有用于视频游戏的下一个场景的数据。一些系统试图同时地重迭程序代码的载入与游戏播放，但这仅可在存在已知序列 的事件时进行(例如，若正沿道路驾驶车，则可在驾驶车的同时载入路旁的正接近的建筑 物的几何形状)。对于复杂和/或快速场景改变，此类型的重迭通常不起作用。举例而言， 在用户处于战役进行之中且在那时刻的视图内RAM 101完全被填满表示对象的数据的状 况下，若用户将视图快速地向左移动以观看当前未载入在RAM 101中的对象，则将导致动 作的不连续性，因为不存在足够的时间来将新对象自硬盘驱动器103或光学媒体104载入 到 RAM 101 中。图1的系统的另一问题是由于硬盘驱动器103及光学媒体104的储存容量的限制 引起。尽管磁盘储存设备可被制造成有相对较大的储存容量(例如，500亿字节或500亿字 节以上)，但其仍不提供用于在当前视频游戏中所遇到的特定情况的足够储存容量。举例而 言，如先前所述，英式足球视频游戏可允许用户在全世界的许多小组、玩家及运动场当中选 择。对于每个小组、每个玩家及每个运动场，需要大量纹理映射及环境映射来特征化世界上 的3D表面(例如，每个小组具有唯一运动衫，每一者需要唯一纹理映射)。用于解决上述后者问题的一个技术是对于游戏，一旦用户选择了纹理及环境映 射，就预先计算纹理及环境映射。此可涉及许多计算上密集的过程，包括解压缩图像、3D映 射、加阴影、组织数据结构等。因此，当视频游戏执行这些计算时，对于用户可能存在延迟。 减少此延迟的一个方法原则上为最初开发游戏时执行所有这些计算_包括小组、玩家名 册及运动场的每个排列。游戏的发行版本因而将包括储存在光学媒体104上或互联网上的 一个或多个服务器上的所有所述经预先处理的数据，当用户作出选择时，仅经由互联网将 用于给定小组、玩家名册、运动场选择的选定的预先处理的数据下载到硬盘驱动器103。然 而，作为实际问题，游戏播放中可能的每个排列的该预先载入的数据可能轻易地为几兆兆 字节(terabyte)的数据，其远超过现今的光学媒体设备的容量。此外，用于给定小组、玩家 名册、运动场选择的数据可能轻易地为几亿字节的数据或几亿字节以上的数据。在家庭网 络连接的情况下(例如，10Mbps)，经由网络连接105下载该数据将比在本地计算数据花费 更长时间。因此，图1中所显示的先前技术游戏架构使用户在复杂游戏的较大场景转变之间 经受显著延迟。诸如图1中所显示的先前技术方法的先前技术方法的另一问题在于这些年来， 视频游戏倾向于变得更高级且需要更多CPU/GPU处理能力。因此，即使采用无限量的RAM， 视频游戏硬件要求也超过所述系统中可用的处理能力的峰值水平。因此，需要用户每隔几 年升级游戏硬件以保持同步(或以较低质量水准玩较新游戏)。比以往更高级的视频游戏 的趋势的后果为用于家庭用途的玩视频游戏的机器通常不具经济效益，因为其成本通常 由其可支持的最高性能游戏的要求来确定。举例而言，可能使用XBox 360来玩类似“战争 机器(Gears of War) ”的游戏，该游戏要求高性能的CPU、GPU及几亿字节的RAM，或者可能 使用XBox 360来玩“吃豆(Pac Man) ”，其为来自20世纪70年代的游戏，其仅需要几千字节的RAM及非常低性能的CPU。实际上，XBox 360具有同时主机代管许多同时的“吃豆”游 戏的足够计算能力。在一周的大多数小时中，通常关闭视频游戏机。根据2006年7月Nielsen(尼尔 森)娱乐对13岁及13岁以上的活跃游戏者的研究，平均起来，活跃游戏者一周中花费十四 个小时或一周中的全部小时的仅12%来玩控制台视频游戏。这意味着平均视频游戏控制台 在88%的时间内闲置，这是昂贵资源的无效率使用。假定视频游戏控制台常常是由制造商 来资助以降低购买价格(期望该资助将通过来自未来视频游戏软件购买的版税来赚回)， 则这特别有意义。视频游戏控制台也造成与几乎任何消费者电子设备相关的成本。举例而言，需要 将系统的电子设备及机构容纳于外壳中。制造商需要提供服务保证。出售该系统的零售商 需要收取关于系统的销售和/或关于视频游戏软件的销售的利润。所有这些因素添加视频 游戏控制台的成本，该成本必须由制造商来资助、传递至消费者，或者由制造商与消费者两 者来资助。另外，盗版是视频游戏工业的较大问题。实际上每个较大视频游戏系统上所利用 的安全机构这些年来已“破裂”，导致视频游戏的未经授权的复制。举例而言，Xbox 360安 全系统在2006年7月破裂且用户现在能够在线下载非法复本。可下载的游戏(例如，用于 PC或Mac的游戏)特别容易经受盗版。在世界的特定区域(其中盗版管制不强)中，实质 上不存在独立视频游戏软件的可行市场，因为用户可与合法复本一般容易地以成本的非常 小一部分购买盗版复本。而且，在世界的许多地方，游戏控制台的成本占收入的高百分比， 以致即使盗版受控制，也很少有人可买得起目前技术状态的游戏系统。另外，已使用的游戏的市场减少了视频游戏业的收入。当用户变得对游戏厌倦时， 其可将游戏出售给将游戏转售给其他用户的店铺。这种未经授权但普遍的实践显著减少 了游戏出版商的收入。类似地，当每隔几年存在平台转变时，通常出现大约50%的销售减 少。这是因为当用户知道即将发行较新版本的平台时，用户停止购买用于较旧平台的游戏 (例如，当即将发行Playstation 3时，用户停止购买Playstation 2游戏)。组合起来，销 售的损失及与新平台相关的增加的开发成本可对游戏开发商的收益性有非常显著的不利 影响。新游戏控制台也非常昂贵。Xbox360、Nintendo Wii 及 Sony Playstation 3 均 以数百美元零售。高能力的个人计算机游戏系统可花费高达$8000。这表示用户的显著投 资，具体来说，考虑到硬件在几年后变陈旧及许多系统是为孩子而购买的事实。上述问题的一个方法是在线游戏，其中将游戏程序代码及数据主机代管于服务器 上且按要求将其传送至客户端机器，经压缩的视频及音频经由数字宽带网络而流动。一些 公司(诸如，芬兰的G-ClusteHG-群集公司)，其现在为日本的SOFTBANK Broadmedia(软 银宽媒)的子公司)当前在线提供所述服务。类似游戏服务变得在本地网络(诸如，旅馆 内及由DSL及电缆电视提供者提供的那些网络)中可用。这些系统的较大缺点是延时的问 题，也即，信号行进到游戏服务器及从游戏服务器行进所花费的时间，游戏服务器通常定位 在运营商的“前端”中。快速动作视频游戏(也称为“极速(twitch)”视频游戏)在用户 通过游戏控制器执行动作的时间与更新显示屏幕以显示用户动作的结果的时间之间需要 非常低的延时。需要低延时，以使得用户感觉到游戏“即刻地”响应。可视游戏的类型及用户的熟练程度而以不同延时间隔来满足用户。举例而言，对于缓慢的非正式游戏(类似西 洋双陆棋)或慢动作角色扮演游戏而言，100毫秒的延时可能是可容忍的，但在快动作游戏 中，超过70毫秒或80毫秒的延时可引起用户在游戏中更拙劣地表现，且因此不可接受。举 例而言，在需要快反应时间的游戏中，当延时自50毫秒增加至100毫秒时，存在准确度的锐 降。当游戏或应用服务器安装在附近的受控网络环境或至用户的网络路径可预测和/ 或可容忍带宽峰值的网络环境中时，在最大延时以及延时的一致性方面，控制延时容易得 多(例如，因此用户经由网络观察到来自数字视频流动的稳定运动)。该程度的控制可在以 下达成在电缆TV网络前端到电缆TV用户的家庭之间，或自DSL中央办公室至DSL用户的 家庭，或在来自服务器或用户的商业办公室区域网络(LAN)环境中。而且，有可能获得商业 之间的具有得到保证的带宽及延时的特定分级的点到点私用连接。但在将游戏主机代管于 连接到通用互联网的服务器中心中且接着经由宽带连接而使经压缩的视频流动(stream) 到用户的游戏或应用系统中，许多因素造成延时，导致先前技术系统的部署中的严重限制。在典型的连接宽带的家庭中，用户可具有用于宽带服务的DSL或电缆调制解调 器。所述宽带服务通常造成用户的家庭与通用互联网之间的多达25毫秒的来回行程延时 (且有时更多)。另外，存在由于经由互联网将数据路由到服务器中心而造成的来回行程延 时。经由互联网的延时基于给出数据的路线及数据被路由时数据所造成的延迟而改变。除 路由延迟之外，还由于光穿过使大多数互联网互连的光纤的速度而造成来回行程延时。举 例而言，对于每1000英里，由于光穿过光纤的速度及其他耗用而造成约22毫秒的来回行程 延时。额外延时可由于经由互联网流动的数据的数据速率而造成。举例而言，若用户具 有以“6Mbps DSL服务”出售的DSL服务，则在实践中，用户将很可能最多得到小于5Mbps 的下行输送量，且将可能周期性地看见由于各种因素(诸如，峰值载入时间期间在数字用 户线接入复用器(DSLAM)处的拥挤)产生的连接降级。若经由相邻者循环的本地共用同轴 电缆中存在拥挤或电缆调制解调器系统网络中的其他地方存在拥挤，则类似问题可出现， 从而将用于以“6Mbps电缆调制解调器服务”出售的连接的电缆调制解调器的数据速率减 小至远小于该数据速率。若使4Mbps的稳定速率下的数据分组以用户数据报协议(UDP)格 式单向地从服务器中心经由所述连接而流动，若一切都适当地工作，则数据分组将通过而 不造成额外延时，但若存在拥挤(或其他妨碍)且仅3. 5Mbps可用于使数据流动到用户，则 在典型情形下，包将被丢弃，导致丢失数据，或者分组将在拥挤点处排队直至它们可被发送 为止，从而引入了额外延时。不同拥挤点具有用于保存被延迟的分组的不同队列容量，因此 在一些状况下，立即将不可成功解决拥挤的分组丢弃。在其他状况下，将几百万比特的数据 排队且最终将其发送。但是，在几乎所有状况下，拥挤点处的排队具有容量限制，且一旦超 过该限制，队列将溢出且分组将被丢弃。因此，为了避免造成额外延时(或更糟地，分组丢 失)，必须避免超过从游戏或应用服务器到用户的数据速率容量。还由于在服务器中压缩视频及在客户端设备中解压缩视频所需的时间而造成延 时。当在服务器上执行的视频游戏正在计算待显示的下一个帧时，进一步造成延时。当前可 用的视频压缩算法受到高数据速率或高延时。举例而言，运动JPEG为仅帧内有损的压缩算 法，该压缩算法特征为低延时。视频的每个帧独立于视频的每个其他帧而压缩。当客户端设备接收经压缩的运动JPEG视频的一个帧时，其可立即解压缩该帧且显示该帧，从而导致 非常低的延时。但因为每个帧分开进行压缩，所以算法不能够利用连续帧之间的类似性，且 因此仅帧内视频压缩算法受到非常高的数据速率。举例而言，60fps (每秒帧数)640X480 运动JPEG视频可能需要40Mbps (每秒百万比特)或40Mbps (每秒百万比特)以上的数据。 用于所述低分辨率视频窗的所述高数据速率在许多宽带应用程序中将是过于昂贵的(且 对于大多数消费者的基于互联网的应用程序的确如此)。另外，因为每个帧经独立压缩，所 以可能由于有损压缩而产生的帧中的假影可能出现于连续帧中的不同位置处。这可导致当 解压缩视频时，在观看者看来为移动的视觉假影。其他压缩算法(诸如，来自Microsoft公司的MPEG2、H. 264或VC9)当用于先前技 术的配置中时，可实现高压缩比率，但以高延时为代价。所述算法利用帧间压缩以及帧内压 缩。周期性地，所述算法执行帧的仅帧内压缩。这种帧被称为关键帧(通常称作“I”帧)。 接着，该算法通常将I帧与先前帧与相继帧两者相比较。并非独立地压缩先前帧及相继帧， 而是算法确定图像从I帧到先前帧及相继帧有什么改变，且接着将该改变储存为“B”帧 (对于I帧之前的改变)及“P”帧(对于I帧之后的改变)。这导致比仅帧内压缩低得多 的数据速率。但是，其通常以较高延时为代价。I帧通常比B帧或P帧大得多(常常大10 倍)，且因此，以给定数据速率传输成比例地花费较长的时间。考虑(例如)一个i情形其中I帧为B帧及P帧的大小的10倍，且对于每个单 个I帧内，存在29个B帧+30个P帧=59个帧间，或对于每个“帧群”(GOP)总共60个帧。 因此，在60fps下，每秒存在1个60帧G0P。假设传输信道具有2Mbps的最大数据速率。为 了在信道中达成最高质量的视频，压缩算法将产生2Mbps数据流，且给定上述比率，这将产 生每帧内2百万比特(Mb)/(59+10) = 30，394个比特及每I帧303，935个比特。当通过解 压缩算法接收经压缩的视频流时，为了稳定地播放视频，需要以规则间隔(例如，60fps)解 压缩及显示每个帧。为了实现该结果，若任何帧受到传输延时，则需要将所有帧延迟至少该 延时，因此最糟状况的帧延时将限定用于每个视频帧的延时。因为I帧最大，所以I帧引入 最长传输延时，且整个I帧将必须在可解压缩及显示I帧(或取决于I帧的任何帧间)之 前接收。假定信道数据速率为2Mbps，则传输I帧将花费303，935/2Mb = 145毫秒。使用传输信道的带宽的大百分比的帧间视频压缩系统(如上所述)将由于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帧的高峰值数据速率导致高帧延时。当然，上述论述仅特征化由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帧延时，但仍招致上文所描述的由于峰值帧大小而引起的延时。问题恰恰由于许多视频游戏的性质而加重。利用上文所描述的GOP结构的视频压 缩算法很大程度上被最佳化以用于连同要用于被动观看的现场直播的视频或电影材料一 起使用。通常，相机(真实相机，或者计算机产生的动画的状况下的虚拟相机)及场景相对 稳定，仅因为若相机或场景太颠簸地来回移动，则视频或电影材料(a)通常观看起来令人 不愉快，且(b)若其正被观看，当相机突然来回颠簸时，观看者通常不能够紧密地跟随该动 作(例如，若相机在拍摄吹灭生日蛋糕上的蜡烛的孩子时被扰动且突然在蛋糕之间来回颠 簸，则观看者通常集中于孩子及蛋糕上，而不理会相机突然移动时的简短中断)。在视频会 谈或视频电话会议的状况下，可将相机固持于固定位置中且根本不移动，从而导致根本非 常少的数据峰值。但3D高动作视频游戏通过恒定运动来被特征化(例如，考虑3D竞赛，其 中整个帧在竞赛的持续时间中处于快速运动中，或者考虑第一人称射击游戏，其中虚拟相 机恒定地颠簸地来回移动)。所述视频游戏可产生具有大的及频繁的峰值的帧序列，其中用 户可能需要清楚地看见在该突然运动期间发生了什么。因此，在3D高动作视频游戏中，压 缩假影远不可容忍。因此，许多视频游戏的视频输出(由于其性质)产生具有非常高且频 繁的峰值的经压缩的视频流。假定快动作视频游戏的用户对于高延时具有小的容忍度，且给定所有上述延时原 因，至今存在对于使视频在互联网上流动的服务器主机代管的视频游戏的限制。另外，若需 要高度互动性的应用程序被主机代管于通用互联网上且使视频流动，则所述应用程序的用 户遭受类似限制。所述服务需要网络配置，其中主机代管服务器直接设置于前端(在电缆 宽带的状况下)或中央办公室(在数字用户线(DSL)的状况下)中，或商业背景中的LAN内 (或特别分级的私用连接上)，以便控制自客户端设备至服务器的路线及距离以最小化延 时且可适应峰值而不造成延时。LAN(通常额定在lOOMbps-lGbps)及具有足够带宽的租用 线路通常可支持峰值带宽要求(例如，18Mbps峰值带宽为100Mbps LAN容量的一小部分)。若进行特殊适应，则峰值带宽要求也可由住宅宽带基础架构来适应。举例而言，在 电缆TV系统上，可为数字视频通信给出专用带宽，该专用带宽可处理诸如大I帧的峰值。此 外，在DSL系统上，可供应较高速度的DSL调制解调器(考虑高峰值)，或可供应可处理较高 数据速率的特别分级的连接。但是，附接至通用互联网的传统电缆调制解调器及DSL基础 架构对于用于压缩的视频的峰值带宽要求而言远不能容忍。因此，在线服务(将视频游戏 或应用程序主机代管于距客户端设备长距离的服务器中心中，且接着经由传统的住宅宽带 连接经由互联网而使经压缩的视频输出流动)遭受显著的延时及峰值带宽要求-尤其对于 需要非常低的延时的游戏及应用程序(例如，第一人称射击游戏及其他多用户、互动式动 作游戏，或需要快响应时间的应用程序)。


根据下面的详细描述并根据附图可以更完整地理解本公开，然而，所述附图并不 用来将公开的主题限制到所示特定实施方式中，而只是用作解释和理解。图1示出了先前技术视频游戏系统的架构。图2a至图2b示出了根据一个实施例的高级系统架构。图3示出了用于客户端与服务器之间的通信的实际的、额定的及所需的数据速率。图4a示出了根据一个实施例而使用的主机服务及客户端。图4b示出了与客户端与主机服务之间的通信相关的例示性延时。图4c示出了根据一个实施例的客户端设备。图4d示出了根据另一个实施例的客户端设备。图4e示出了图4c中的客户端设备的实例方块图。图4f示出了图4d中的客户端设备的实例方块图。图5示出了可根据一个实施例而使用的视频压缩的一个实例。图6a示出了可在另一个实施例中使用的视频压缩的一个实例。图6b示出了与传输低复杂度、低动作视频序列相关的数据速率中的峰值。图6c示出了与传输高复杂度、高动作视频序列相关的数据速率中的峰值。图7a至图7b示出了在一个实施例中使用的实例视频压缩技术。图8示出了在一个实施例中使用的额外实例视频压缩技术。图9a至图9c示出了在一个实施例中使用以用于缓解数据速率峰值的实例技术。图IOa至图IOb示出了将图像图像块有效地封装于分组内的一个实施例。图Ila至图Ild示出了使用前向纠错技术的实施例。图12示出了使用多核心处理单元来进行压缩的一个实施例。图13a至图13b示出了根据各种实施例的主机服务之间的地理定位及通信。图14示出了与客户端与主机服务之间的通信相关的示例性延时。图15示出了实例主机服务服务器中心架构。图16示出了包括多个现场直播的视频窗的用户接口的一个实施例的实例屏幕拍摄。图17示出了在选择特定视频窗之后的图16的用户接口。图18示出了在将特定视频窗放大至全屏幕大小之后的图17的用户接口。图19示出了叠加在多人游戏的屏幕上的实例合作用户视频数据。图20示出了用于主机服务上的游戏玩家的实例用户页面。图21示出了实例3D互动式广告。图22示出了用于自现场直播的表演的表面捕获产生具有纹理表面的照片般逼真 的图像的实例步骤序列。图23示出了允许选择线性媒体内容的实例用户接口页面。图24为示出了在现场直播网页之前消逝的时间量与连接速度的曲线图。
具体实施例方式在以下描述中列举了特定细节(诸如，设备类型、系统配置、通信方法等)，以便提 供对本公开的彻底理解。然而，一般本领域的技术人员应了解，实践所描述的所述实施例可 能不需要这些特定细节。图2a至图2b提供两个实施例的高级架构，其中视频游戏及软件应用程序由主机 服务210主机代管且在订阅服务下由用户场所211 (注意，“用户场所”意思是用户所定位的 无论何处的位置，若使用移动设备则包括室外)处的客户端设备205经由互联网206 (或其 他公众网络或私用网络)来存取。客户端设备205可为具有至互联网的有线或无线连接、 具有内部或外部显示设备222的通用计算机(诸如，以Microsoft Windows或Linux为基 础的PC或Apple公司的Macintosh计算机)，或者其可为将视频及音频输出到监视器或电 视机222的诸如机顶盒的专用客户端设备(具有至互联网的有线或无线连接)，或者其可为 推测起来具有至互联网的无线连接的行动设备。所述设备中的任一者可具有其自身的用户输入设备(例如，键盘、按钮、触摸屏 幕、追踪板(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中所显示的先前技术视频游戏系统)。随着游戏及应用程序软件变得更复杂及更具照片般逼真感，其将需要较高性能的 CPU、GPU、较多RAM，及较大且较快的磁盘驱动器，且可使主机服务210处的计算能力不断地 升级，但终端用户将不需要使家庭或办公室客户端平台205升级，因为将通过给定视频解 压缩算法而使家庭或办公室客户端平台205的处理要求对于显示分辨率及帧速率保持恒 定。因此，图2a至图2b中所说明的系统中不存在现今所见的硬件限制及相容性问题。另外，因为游戏及应用程序软件仅在主机服务210中的服务器中执行，所以在用户的家庭或办公室(除非另外有条件，否则如本文中所使用的“办公室”将包括任何非住宅 背景，包括(例如)教室)中决不存在游戏或应用程序软件的复本(光学媒体的形式，或者 为下载的软件)。这显著减轻游戏或应用程序软件被非法复制(盗版)的可能性，以及减轻 可由游戏或应用程序软件使用的有价值的数据库被盗版的可能性。实际上，若需要专门化 的服务器(例如，需要非常昂贵的、大的或有噪音的设备)来播放对于家庭或办公室使用不 可行的游戏或应用程序软件，则即使获得游戏或应用程序软件的盗版复本，其也将不可在 家庭或办公室中操作。在一个实施例中，主机服务210向设计视频游戏的游戏或应用程序软件开发商 (其大体指代软件开发公司、游戏或电影工作室，或游戏或应用程序软件出版商)220提供 软件开发工具，以使得其可设计能够在主机服务210上执行的游戏。所述工具允许开发商 利用主机服务的特征(所述特征通常在独立PC或游戏控制台中将不可用)(例如，快速存 取复杂几何形状的非常大的数据库(除非另外有条件，否则“几何形状”将在本文中用于指 代限定3D数据集的多边形、纹理、索具、照明、行为及其他组件及参数))。在该架构下，不同商业模型是可能的。在一个模型下，主机服务210从终端用户 收取订阅费用且向开发商220支付版税，如图2a中所显示。在替代实施中(图2b中所显 示)，开发商220直接从用户收取订阅费用且向主机服务210支付用于主机代管游戏或应用 程序内容的费用。这些基本原理不限于用于提供在线游戏或应用程序主机代管的任何特定 商业模型。经压缩的视频特性如先前所论述，在线提供视频游戏服务或应用程序软件服务的一个显著问题在于 延时。70毫秒-80毫秒的延时(自输入设备被用户致动(actuate)的时刻到在显示设备上 显示响应时的时刻)为用于需要快响应时间的游戏及应用程序的上限。然而，由于大量实 际及物理约束而使得这在图2a及图2b中所显示的架构的情况下非常难以达成。如图3中所指示，当用户订阅互联网服务时，连接通常额定为到用户的家庭或办 公室的标定最大数据速率301。取决于提供者的策略及路由设备能力，该最大数据速率可或 多或少被严格地强制执行，但通常由于许多不同原因中的一者而使得实际可用数据速率较 低。举例而言，可能在DSL中央办公室处或在本地电缆调制解调器回路上存在过多网络通 信通信，或可能在电缆线上存在噪音，从而引起丢弃的分组，或提供者可能建立每用户每月 最大数目的比特。当前，用于电缆及DSL服务的最大下行数据速率通常在数百千比特/秒 (Kbps)到30Mbps的范围内。蜂窝式服务通常限于数百Kbps的下行数据。然而，宽带服务 的速度及订阅宽带服务的用户的数目将随着时间而急剧增加。当前，一些分析者估计33% 的美国宽带用户具有2Mbps或2Mbps以上的下行数据速率。举例而言，一些分析者预测至 2010年止，超过85%的美国宽带用户将具有2Mbps或2Mbps以上的数据速率。如图3中所指示，实际可用最大数据速率302可随着时间而波动。因此，在低延 时、在线游戏或应用程序软件情况下，有时难以预测用于特定视频流的实际可用数据速率。 若对于特定量的场景复杂度及运动在给定数目的每秒帧数(fps)下以给定分辨率(例如， 640X480i60fps)维持给定质量水平所需的数据速率303升高高于实际可用最大数据速率 302 (如通过图3中的峰值指示)，则可出现若干问题。举例而言，一些互联网服务将仅丢弃 分组，从而导致用户的视频屏幕上的丢失的数据及失真的/丢失的图像。其他服务将暂时缓冲(也即，排队)额外分组且以可用数据速率将所述分组提供到客户端，从而导致延时的 增加-对于许多视频游戏及应用程序而言为不可接受的结果。最后，一些互联网服务提供 者将数据速率的增加视为恶意攻击(诸如，否认服务攻击(由计算机黑客用以使网络连接 停用的公知技术))，且将在特定时间周期中切断用户的互联网连接。因此，本文中所描述的 实施例设法确保用于视频游戏的所需数据速率不会超过最大可用数据速率。主机服务架构图4a说明根据一个实施例的主机服务210的架构。主机服务210可位于单个服 务器中心中，或者可跨越多个服务器中心而分散(以为具有比其他者低延时的至特定服务 器中心的路径的用户提供低延时连接，以在用户之间提供负载平衡，且在一或多个服务器 中心出故障的状况下提供冗余)。主机服务210最终可包括成千上万个或甚至数百万个服 务器402，从而服务非常大的用户基础(user base)。主机服务控制系统401提供对主机服 务210的总体控制，且指引路由器、服务器、视频压缩系统、计费及帐务系统等。在一个实施 例中，主机服务控制系统401实施在基于Linux的分散式处理系统上，该处理系统绑定到用 于储存用于用户信息、服务器信息及系统统计数据的数据库的RAID阵列。在上述描述中， 除非归因于其他特定系统，否则由主机服务210实施的各种动作由主机服务控制系统401 来起始及控制。主机服务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可不同。在一个实施例中，服务器402无磁盘，也即，并非具有其自身的本地大容量储存器 (其为光学或磁性储存器，或者基于半导体的储存器，诸如闪存或服务类似功能的其他大 容量储存装置)，每一个服务器经由快速底板或网络连接而存取共用的大容量储存器。在 一个实施例中，该快速连接为连接到独立冗余磁盘阵列(RAID)405系列的储存区域网络 (SAN)403，在使用超高速以太网实施的设备之间具有连接。如本领域的技术人员已知的， SAN 403可用于将许多RAID阵列405组合在一起，从而导致极高的带宽_接近或可能超过 可自用于当前游戏控制台及PC中的RAM得到的带宽。此外，尽管基于诸如磁性媒体的旋转 媒体的RAID阵列经常具有显著的搜寻时间存取延时，但基于半导体储存器的RAID阵列可 实施为具有低得多的存取延时。在另一配置中，一些或所有服务器402在本地提供一些或 所有其自身的大容量储存器。举例而言，服务器402可将频繁存取的信息(诸如，其操作 系统及视频游戏或应用程序的复本)储存在基于低延时本地闪存的储存器上，但其可利用 SAN来存取基于旋转媒体的具有较高搜寻延时的RAID阵列405，以较不频繁地存取几何形 状或游戏状态信息的大数据库。
22
另外，在一个实施例中，主机服务210使用下文详细描述的低延时视频压缩逻辑 404。视频压缩逻辑404可以软件、硬件或其任何组合来实施(下文描述其特定实施例)。 视频压缩逻辑404包括用于压缩音频以及视觉材料的逻辑。在操作中，当经由键盘、鼠标、游戏控制器或其他输入设备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中显示为独 立式设备，但其可集成在诸如便携式计算机或行动设备的客户端设备内。家庭或办公室客户端415 (先前在图2a及图2b中描述为家庭或办公室客户端 205)可为非常低廉且低能力的设备，其具有非常有限的计算或图形性能且可能具有非常 有限的本地大容量储存器或不具有本地大容量储存器。相比之下，耦合至SAN 403及多个 RAID 405的每一个服务器402可为格外高性能的计算系统，且实际上，若多个服务器以并 列处理配置合作地使用，则几乎不存在对可承受的计算量及图形处理能力的限制。此外，由 于低延时视频压缩404及低延时视频解压缩412(由用户感知地)，所以将服务器402的计 算能力提供给用户。当用户按压输入设备421上的按钮时，显示器422上的图像被响应于 按钮按压而更新(在感知上无有意义的延迟)，好像游戏或应用程序软件在本地执行。因 此，对于为非常低性能的计算机或只是实施低延时视频解压缩及控制信号逻辑413的低廉 芯片的家庭或办公室客户端415，自看来在本地可用的远程位置有效地为用户提供任意计 算能力。此为用户给出用于玩最高级、处理器密集的(通常为新的)视频游戏及最高性能 的应用程序的能力。图4c显示非常基础且低廉的家庭或办公室客户端设备465。该设备为根据图4a 及图4b的家庭或办公室客户端415的一个实施例。其大约2英寸长。其具有与具有以太 网供电(PoE)的以太网电缆相接口的以太网插孔462，该设备从以太网插孔462得到其电 力及其到互联网的连接性。该设备能够在支持网络地址转换(NAT)的网络内执行NAT。在 办公室环境中，许多新的以太网交换器具有PoE且将PoE直接带到办公室中的以太网插孔。在此种情形下，所需的为从壁式插孔到客户端465的以太网电缆。若可用的以太网连接不 运输电力(例如，在具有DSL或电缆调制解调器但无PoE的家庭中)，则存在可用的低廉的 壁式“砖块(brick)，，(也即，电源)，其将接受无电力的以太网电缆且输出具有PoE的以太 网。客户端465含有耦合至蓝牙无线接口的控制信号逻辑413 (图4a)，该蓝牙无线接 口与诸如键盘、鼠标、游戏控制器和/或麦克风和/或耳机的蓝牙输入设备479相接口。而 且，客户端465的一个实施例在与显示设备468耦合的情况下能够以120fps输出视频，显 示设备468能够支持120fps视频且向一对遮光眼镜466发信号(通常经由红外)以对于 每个相继帧交替地遮蔽一只眼接着遮蔽另一只眼。用户所感觉的效果为“跳出”显示屏幕 的立体3D图像。支持该操作的一种该显示设备468为Samsung HL-T5076S。因为用于每一 只眼的视频流是单独的，所以在两个独立视频流由主机服务210压缩的一个实施例中，帧 在时间上交错，且帧在客户端465内以两个独立解压缩过程来解压缩。客户端465也含有低延时视频解压缩逻辑412，其解压缩传入的视频及音频且经 由HDMI (高清晰度多媒体接口 )、连接器463输出，HDMI (高清晰度多媒体接口 )、连接器463 插入到SDTV (标准清晰度电视)或HDTV (高清晰度电视)468中，从而向TV提供视频及音 频，或插入到支持HDMI的监视器468中。若用户的监视器468不支持HDMI，则可使用HDMI 至DVI (数字视觉接口)，但音频将丢失。在HDMI标准下，显示能力(例如，所支持的分辨 率，帧速率)464从显示设备468表达，且接着经由互联网连接462将该信息传回到主机服 务210，因此主机服务210可使经压缩的视频以适合于该显示设备的格式流动。图4d显示家庭或办公室客户端设备475，除了客户端设备475具有更多外部接口 之外，其与图4c中所显示的家庭或办公室客户端设备465相同。而且，客户端475可接受 PoE来供电，或者其可占用插入墙壁中的外部电源适配器(未图示)。视频相机477使用客 户端475USB输入将经压缩的视频提供到客户端475，经压缩的视频由客户端475上传到主 机服务210以用于下文所描述的用途。将利用下文所描述的压缩技术将低延时压缩器创建 到相机477中。除具有用于其互联网连接的以太网连接器之外，客户端475还具有到互联网的 802. Ilg无线接口。两种接口均能够在支持NAT的网络内使用NAT。而且，除具有用于输出视频及音频的HDMI连接器之外，客户端475还具有双链接 DVI-I连接器，双链接DVI-I连接器包括模拟输出端(且具有将提供VGA输出的标准适配器 电缆)。其还具有用于复合视频及S视频的模拟输出端。对于音频，客户端475具有左/右模拟立体RCA插孔，且对于数字音频输出，其具 有T0SLINK (光纤)输出端。除了到输入设备479的蓝牙无线接口之外，其还具有用于接口到输入设备的USB 插孔。图4e显示客户端465的内部架构的一个实施例。该图中所显示的所有设备或一 些设备可实施在场可程序化逻辑阵列、定制ASIC中或若干个离散设备(定制设计或者现成 的)中。具有PoE的以太网497附接到以太网接口 481。电力499才具有PoE的以太网497 得到且连接到客户端465中的其余设备。总线480为用于设备之间的通信的公同总线。
执行来自闪存476的小客户端控制应用程序的控制CPU 483 (几乎任何小CPU都 是适当的，诸如具有嵌入式RAM的IOOMHz下的MIPS R4000系列CPU)实施用于网络(也即， 以太网接口)的协议栈且还与主机服务210通信，并配置客户端465中的所有设备。其还 处理与输入设备469的接口并将分组(必要时，连同受前向纠错保护的用户控制器数据一 起)发送回至主机服务210。而且，控制CPU 483监视分组通信(例如，分组是丢失还是延 迟，以及其到达的时间戳)。将此信息发送回至主机服务210，以使得其可恒定地监视网络 连接且相应地调整其发送的内容。最初在制造时为闪存476载入用于控制CPU 483的控制 程序以及对于特定客户端465单元而言唯一的序号。此序号允许主机服务210唯一地识别 客户端465单元。蓝牙接口 484经由其天线(在客户端465内部)无线地通信至输入设备469。视频解压缩器486为经配置以实施本文中所描述的视频解压缩的低延时视频解 压缩器。大量视频解压缩设备存在，或者为现成产品，或者作为具有可整合在FPGA或定制 ASIC中的设计的知识产权(IP)。一个提供用于H. 264解码器的IP的公司为澳大利亚新南 威尔士州(NSW Australia)的Ocean LogicofManly0使用IP的优点在于本文中所使用 的压缩技术与压缩标准不相符。一些标准解压缩器足够灵活以经配置以适应本文中的压缩 技术，但一些标准解压缩器可能并非如此。但是，在IP的情况下，在视需要而重新设计解压 缩器中存在完全灵活性。视频解压缩器的输出端耦合至视频输出子系统487，视频输出子系统487将视频 耦合至HDMI接口 490的视频输出端。音频解压缩子系统488或者使用可用的标准音频解压缩器来实施，或者其可实施 为IP，或者可在可(例如)实施VorbiS音频解压缩器的控制处理器483内实施音频解压 缩。实施音频解压缩的设备耦合到音频输出子系统489，音频输出子系统489将音频 耦合至HDMI接口 490的音频输出端。图4f显示客户端475的内部架构的一个实施例。如可见，除额外接口及来自插入 墙壁中的电源适配器的可选外部DC电力(且若如此使用，则可选外部DC电力替换将来自 以太网PoE 497的电力)之外，该架构与客户端465的架构相同。下文中将不重复与客户 端465共同的功能性，但将额外功能性描述如下。CPU 483与额外设备通信且配置额外设备。WiFi子系统482经由其天线提供无线互联网存取，作为对以太网497的替代。WiFi 子系统可购自多家制造商，包括美国加州的圣克拉拉的AtherosCommunications (阿特赫 鲁斯通信公司)。USB子系统485提供对用于有线USB输入设备479的蓝牙通信的替代。USB子系 统相当标准且可容易地用于FPGA及ASIC，且经常创建到执行如视频解压缩的其他功能的 现成设备中。与客户端465内的视频输出相比较，视频输出子系统487产生较宽范围的视频输 出。除提供HDMI 490视频输出之外，其提供DVI-I 491、S-视频492及合成视频493。而 且，当DVI-I 491接口用于数字视频时，将显示能力464自显示设备传回至控制CPU 483，以 使得其可向主机服务210通知显示设备478的能力。由视频输出子系统487提供的所有接口均为相当标准的接口且容易以许多形式可用。音频输出子系统489经由数字接口 494(S/PDIF和/或Toslink)数字地输出音频 且经由立体模拟接口 495输出模拟形式的音频。来回行程延时分析当然，为了实现前一段的利益，用户使用输入设备421的动作与在显示设备420上 看见该动作的后果之间的来回行程延时应不大于70毫秒-80毫秒。此延时必须考虑在自用 户场所211中的输入设备421到主机服务210及再次返回到用户场所211至显示设备422 的路径中的所有因素。图4b说明各种组件及网络(信号必须经由该组件或网络行进)，且 该组件及网络上方的为时间线，该时间线列出实际实施中可预期的例示性延时。注意，图4b 经简化以便仅显示重要路径路由。下文描述用于系统的其他特征的数据的其他路由。双头 箭头(例如，箭头453)指示来回行程延时且单头箭头(例如，箭头457)指示单向延时，且 “ ”表示近似量测。应指出，将存在所列的延时不可达成的真实世界情形，但在大量状况 下，在美国，使用至用户场所211的DSL及电缆调制解调器连接，该延时可在下一段中所描 述的情形中达成。而且，注意，尽管至互联网的蜂窝式无线连接性的确将在所显示的系统中 工作，但大多数当前美国蜂窝式数据系统(诸如，EVD0)招致非常高的延时且将不能够达成 图4b中所显示的延时。然而，这些基本原理可在可能能够实施该水平的延时的未来蜂窝式 技术上实施。自用户场所211处的输入设备421开始，一旦用户致动输入设备421，就将用户控 制信号发送至客户端415 (其可为诸如机顶盒的独立设备，或其可为在诸如PC或行动设备 的另一设备中执行的软件或硬件)，且将其分组化(在一个实施例中以UDP格式)并为分组 给出目的地地址以到达主机服务210。分组将也含有用于指示控制信号来自哪个用户的信 息。接着经由防火墙/路由器/NAT(网络地址转换)设备443将控制信号分组转发到WAN 接口 442。WAN接口 442为由用户的ISP (互联网服务提供者)提供到用户场所211的接口 设备。WAN接口 442可以是电缆或DSL数据机、WiMax收发器、光纤收发器、蜂窝式数据接 □、电网十办i^din (InternetProtocol-over-powerline interface), ^ilJSKN 的许多接口中的任何其他接口。另外，可将防火墙/路由器/NAT设备443 (及(可能地) WAN接口 442)整合到客户端415中。该一个实例将为移动电话，其包括用于实施家庭或办 公室客户端415的功能性的软件，以及用于经由某标准(例如，802. Ilg)而无线地路由及连 接到互联网的装置。WAN接口 442接着将控制信号路由至本文中所称的用于用户的互联网服务提供者 (ISP)的“存在点”441，WAN接口 442为提供连接至用户场所211的WAN输送器与通用互联 网或私用网络之间的接口的设施。存在点的特性将视所提供的互联网服务的性质而改变。 对于DSL，其通常是DSLAM位于的电话公司中央办公室。对于电缆调制解调器，其通常是电 缆多系统运营商(MSO)前端。对于蜂窝式系统，其通常是与蜂窝式塔相关的控制室。但无 论存在点的性质怎样，其均将接着将控制信号分组路由至通用互联网410。接着经由将最 可能系光纤收发器接口的接口将控制信号分组路由至WAN接口 444至主机服务210。WAN 444将接着将控制信号分组路由至路由逻辑409 (其可以许多不同方式来实施，包括以太网 交换器及路由服务器)，路由逻辑409估计用户的地址且将控制信号路由至用于给定用户 的正确的服务器402。
26
服务器402接着将所述控制信号视为在服务器402上执行的游戏或应用程序软件 的输入且使用所述控制信号来处理游戏或应用程序的下一个帧。一旦产生下一个帧，就将 视频及音频自服务器402输出至视频压缩器404。可经由各种装置将视频及音频自服务器 402输出至压缩器404。首先，可将压缩器404创建到服务器402中，因此可在服务器402 内在本地实施压缩。或者，可经由到网络(其或者是服务器402与视频压缩器404之间的 私用网络，或者是经由诸如SAN 403的共用网络的网络)的网络连接(诸如，以太网连接) 以分组化的形式输出视频和/或音频。或者，可经由视频输出连接器(诸如，DVI或VGA连 接器)将视频自服务器402输出，且接着由视频压缩器404来捕获。而且，可将音频自服务 器402输出为数字音频(例如，经由T0SLINK或S/PDIF连接器)或模拟音频，模拟音频由 视频压缩器404内的音频压缩逻辑来数字化并编码。—旦视频压缩器404已捕获来自服务器402的视频帧及在该帧时间期间所产生的 音频，则视频压缩器将使用下文所描述的技术压缩视频及音频。一旦视频及音频被压缩，就 通过一地址将其分组化以将其发送回至用户的客户端415，且将其路由至WAN接口 444，WAN 接口 444接着经由通用互联网410路由视频及音频分组，通用互联网410接着将视频及音 频分组路由至用户的ISP的存在点441，存在点441将视频及音频分组路由至用户场所处的 WAN接口 442，WAN接口 442将视频及音频分组路由至防火墙/路由器/NAT设备443，防火 墙/路由器/NAT设备443接着将视频及音频分组路由至客户端415。客户端415解压缩视频及音频，且接着在显示设备422(或客户端的内置显示设 备)上显示视频并将音频发送到显示设备422或到单独的放大器/扬声器或到创建到客户 端中的放大器/扬声器。为使用户感觉到刚才所描述的整个过程在感知上没有滞后，来回行程延迟需要小 于70毫秒或80毫秒。所描述的来回行程路径中的一些延时延迟受主机服务210和/或用 户的控制，而其他的延时延迟不受主机服务210和/或用户的控制。尽管如此，基于大量真 实世界情况的分析及测试，以下为近似量测。用于发送控制信号的单向传输时间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毫秒之间的时间。因此，可通过将在实践中所见的所有最糟状况的延时加在一起来确定图4a中所显 示的系统的用户可预期将经历的最糟状况的来回行程延时。他们是1+1+25+22+1+16+6+8 =80毫秒。此外，实际上，在实践中(具有下文所论述的防止误解的说明)，此大致为使用 图4a中所显示的系统的原型版本(在美国使用现成的Windows PC作为客户端设备及家庭 DSL及电缆调制解调器连接)所见的来回行程延时。当然，优于最糟状况的情况可导致短得 多的延时，但不可依赖其来开发广泛使用的商业服务。为了经由通用互联网达成图4b中所列出的延时，需要客户端415中的视频压缩器 404及视频解压缩器412 (来自图4a)产生具有非常特定的特性的分组流，以使得经由自主 机服务210至显示设备422的整个路径所产生的分组序列不经受延迟或过多分组丢失，且 详言之，始终如一地落在经由用户的互联网连接(经由WAN接口 442及防火墙/路由器/ NAT 433)而可用于用户的带宽的约束内。另外，视频压缩器必须产生足够强健的分组流，以 使得其可容忍在正常互联网及网络传输中出现的不可避免的分组丢失及分组重排序。低延时视频压缩为了完成上述目标，一个实施例采用新的视频压缩方法，该方法降低用于传输视 频的延时及峰值带宽要求。在描述该实施例之前，将关于图5及图6a至图6b提供对当前 视频压缩技术的分析。当然，若用户具备足以处理所述技术所需的数据速率的带宽，则该技 术可根据基本原理来使用。注意，本文中不解决音频压缩，而是陈述音频压缩与视频压缩同 时且同步地来实施。满足用于该系统的要求的先前技术音频压缩技术存在。图5说明用于压缩视频的一个特定先前技术，其中由压缩逻辑520使用特定压缩 算法来压缩每个个别视频帧501-503以产生一系列经压缩的帧511-513。该技术的一个实 施例是“运动JPEG”，其中根据联合图像专家群(JPEG)压缩算法基于离散余弦变换(DCT) 来压缩每一帧。可使用各种不同类型的压缩算法，然而，仍遵守该基本原理(例如，以小波 为基础的压缩算法，诸如JPEG-2000)。此类型压缩的一个问题在于其减小了每个帧的数据速率，但其不利用连续帧之 间的类似性来减小总视频流的数据速率。举例而言，如图5中所说明，假定640 X 480 X 24比 特/像素=640*480*24/8/1024 = 900千字节/帧(KB/帧)的帧速率，则对于给定质量的 图像，运动JPEG可能仅将该流压缩1/10，从而产生90KB/帧的数据流。在60帧/秒下，此 将需要90KB*8比特*60帧/秒=42. 2Mbps的信道带宽，其对于美国现今几乎所有的家庭 互联网连接而言将为极高的带宽，且对于许多办公室互联网连接而言为过高的带宽。实际 上，假定其在此种高带宽的情况下要求恒定数据流，且其将仅服务一个用户，则即使在办公 室LAN环境中，其也将消耗IOOMbps以太网LAN的带宽的大百分比及支持LAN的负担沉重的 以太网交换器。因此，当与其他压缩技术(诸如下文所描述的那些技术)相比较时，用于运 动视频的压缩无效率。此外，使用有损压缩算法的单个帧压缩算法(如JPEG及JPEG-2000) 产生在静止图像中可能不引人注意的压缩假影(例如，场景中的密集树叶内的假影可能不呈现为假影，因为眼并不确切地知道密集树叶应如何呈现)。但是，一旦场景在运动中，假影 就可能突出，因为眼侦测到自帧至帧而改变的假影，尽管假影在场景的区域(在该区域中， 假影在静止图像中可能不引人注意)中。此导致帧序列中的“背景噪音”的感知，该“背景 噪音”的外观与边缘模拟TV接收期间可见的“雪花”杂音类似。当然，该类型的压缩仍可用 于本文中所描述的特定实施例中，但一般而言，为了避免场景中的背景噪音，对于给定感知 质量，需要高数据速率(也即，低压缩比率)。其他类型的压缩(诸如，H. 264，或Windows媒体VC9、MPEG2及MPEG4)在压缩视频 流中均更有效，因为其利用连续帧之间的类似性。这些技术均依赖于用于压缩视频的相同 的一般技术。因此，尽管将描述H. 264标准，但相同的一般原理适用于各种其他压缩算法。 大量H. 264压缩器及解压缩器可用，包括用于压缩H. 264的x264开放源软件库及用于解压 缩H. 264的FFmpeg (—种视频和音频流方案)开放源软件库。图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帧。对于以下论述，将假定所要的帧速率为60帧/秒，每个I帧为约160Kb，平均 P帧及B帧为16Kb且每隔一秒产生一新的I帧。在该组参数下，平均数据速率将为 160Kb+16Kb*59 = 1. 1Mbps。该数据速率适当地落在用于到家庭及办公室的许多当前宽带 互联网连接的最大数据速率内。该技术也倾向于避免来自仅帧内编码的背景噪音问题，因 为P帧及B帧追踪帧之间的差异，因此压缩假影倾向于不自帧至帧而呈现及消失，从而减少 上文所描述的背景噪音问题。上述类型的压缩的一个问题在于尽管平均数据速率相对低(例如，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毫秒的延时的快动作视频游戏而言其为极长的延时。若进行尝试来消除1秒视频缓冲，其仍将不会导致用于快动作视频游戏的足够延 时减少。举例而言，如先前所述，B帧的使用将需要接收I帧的前的所有B帧以及I帧。若 假定在P帧与B帧之间大致分裂59个非I帧，则将存在至少29个B帧且可显示任何B帧 之前所接收的I帧。因此，不管信道的可用带宽如何，均需要29+1 = 30个帧每一者1/60 秒持续时间的延迟，或500毫秒的延时。显而易见，该时间极长。
因此，另一方法将是消除B帧且仅使用I帧及P帧。(其中一个后果是对于给 定质量水平，数据速率将增加，但出于此实例中的一致性起见，继续假定每个I帧的大小为 160Kb且平均P帧的大小为16Kb，且因此数据速率仍为1. 1Mbps)。该方法消除了由B帧引 入的不可避免的延时，因为每个P帧的解码仅依赖于先前所接收的帧。该方法仍存在的问 题在于1帧比平均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，则延时将进一 步增加。还注意到，以远超过可用数据速率622的峰值数据速率623使ISP “堵塞”通常存 在严重后果。不同ISP中的设备将不同地表现，但当以比可用数据速率622高得多的数据 速率接收分组时，以下行为在DSL及电缆调制解调器ISP当中相当普遍(a)通过将分组排 入队列而使分组延迟(引入延时)，(b)丢弃一些或所有分组，(c)将连接停用一时间周期 (最可能因为ISP担忧其为恶意攻击，诸如“否认服务”攻击)。因此，以全数据速率传输分 组流(具有诸如图6b中所显示的所述特性的特性)并非为可行的选项。可在主机服务210 处将峰值623排入队列且以低于可用最大数据速率的数据速率进行发送，从而引入前一段 中所描述的不可接受的延时。另外，图6b中所显示的视频流数据速率序列624为非常“驯服的(tame) ”视频流数 据速率序列，且将是由于压缩来自视频序列的视频而预期产生的该种数据速率序列，该视 频序列并不改变很大且具有非常少的运动(例如，如在视频电话会议中将是普遍的，在视 频电话会议中，相机处于固定位置中且具有非常少的运动，且场景(例如，就座的人谈话) 中的对象显示较少运动)。图6c中所显示的视频流数据速率序列634为从具有多得多的动作的视频(诸如， 可能在电影或视频游戏中或在某应用程序软件中产生)预期可见的典型序列。注意，除I 帧峰值633之外，还存在相当大且在许多场合上超过可用最大数据速率的P帧峰值(诸如， 635及636)。尽管所述P帧峰值并不如I帧峰值一般相当大，但其仍极大以致不能由信道 以全数据速率来运输，且如同I帧峰值一样，P帧峰值必须缓慢地传输(借此增加延时)。在高带宽信道(例如，100Mbps LAN,或高带宽100Mbps私用连接)上，网络将能 够容忍诸如I帧峰值633或P帧峰值636的大峰值，但原则上，可维持低延时。但是，所述 网络经常在许多用户当中共用(例如，在办公室环境中)，且该“有峰”数据将影响LAN的 性能，尤其在网络通信经路由至私用共用连接(例如，从远程数据中心到办公室)的情况 下。首先，记住此实例是60fps下640X480像素的相对低分辨率的视频流的实例。60fps 下的1920X1080的HDTV流容易由现代计算机及显示器来处理，且60fps下的2560X1440分辨率显示器日益可用(例如，Apple公司的30"显示器)。使用H. 264压缩，60fps下的 1920X1080的高动作视频序列可能需要4. 5Mbps以获得合理质量水平。若假定I帧峰值为 标定数据速率的10倍，则其将产生45Mbps峰值，以及较小但仍相当大的P帧峰值。若若干 个用户正在同一 100Mbps网络(例如，办公室与数据中心之间的私用网络连接)上接收视 频流，则容易看见来自若干用户的视频流的峰值可如何碰巧对准，从而淹没网络的带宽，且 可能淹没网络上支持用户的交换器的底板的带宽。即使在超高速以太网的状况下，若足够 的用户具有同时对准的足够峰值，则其可淹没网络或网络交换器。此外，一旦2560X1440 分辨率视频变得更常见，平均视频流数据速率就可能为9. 5Mbps,从而或许产生95Mbps峰 值数据速率。不用说，数据中心与办公室之间的100Mbps连接(其在现今为格外快的连接) 将完全被来自单一用户的峰值通信击溃。因此，即使LAN及私用网络连接对有峰流动视频 可具有更高容忍度，具有高峰值的流动视频也是不需要的且可能需要办公室的IT部门的 特殊计划及适应。当然，对于标准线性视频应用程序，该问题并不是问题，因为数据速率在传输点 “经平滑化”且用于每一帧的数据低于最大可用数据速率622，且在解压缩I帧、P帧及B帧 序列之前，客户端中的缓冲器储存I帧、P帧及B帧序列。因此，网络上的数据速率保持接 近于视频流的平均数据速率。很遗憾地，这引入延时，即使不使用B帧，对于诸如需要快响 应时间的视频游戏及应用程序的低延时应用程序而言，这也是不可接受的。用于减轻具有高峰值的视频流的一个先前技术解决方法是使用常常被称作“恒定 比特速率”(CBR)编码的技术。尽管术语CBR看来似乎暗示将所有帧压缩以具有相同比特速 率(也即，大小)，但其经常提及的为压缩范例，在压缩范例中，允许跨越特定数目的帧(在 我们的状况下，1个帧)的最大比特速率。举例而言，在图6c的状况下，若对编码施加CBR 约束(其将比特速率限于(例如)额定最大数据速率621的70% )，则压缩算法将限制所 述帧中的每一者的压缩，以使得通常将使用额定最大数据速率621的70%以上来压缩的任 何帧将以较少比特来压缩。这个结果是将使通常将需要更多比特来维持给定质量水平的 帧“极度缺乏”比特且所述帧的图像质量将比不需要比额定最大数据速率621的70%多的 比特的其他帧的图像质量糟。此方法对于特定类型的经压缩视频(其中(a)预期较少运动 或场景改变且(b)用户可接受周期性的质量降级)可产生可接受的结果。适合CBR的应用 的良好实例为视频电话会议，因为存在较少峰值，且在质量暂时降级的情况下(例如，若使 相机扫视，从而导致显著场景运动及大峰值，则在扫视期间可能不存在足够的比特用于高 质量图像压缩，其将导致降级的图像质量)，大多数用户可接受。很遗憾地，CBR并非良好地 适合具有高复杂度的场景或大量运动和/或需要合理恒定的质量水平的许多其他应用。在一个实施例中所使用的低延时压缩逻辑404使用若干不同技术来解决流动低 延时经压缩视频同时维持高质量的许多问题。首先，低延时压缩逻辑404仅产生I帧及P 帧，从而缓解等待若干个帧时间来解码每个B帧的需要。另外，如图7a中所说明，在一个实 施例中，低延时压缩逻辑404将每个未经压缩的帧701-760再分成一系列“图像块(tile) ” 且将每个图像块个别地编码为I帧或P帧。在本文中将该群经压缩的I帧及P帧称作“R 帧”711-770。在图7a中所显示的特定实例中，将每个未经压缩的帧再分成4X4矩阵的16 个图像块。然而，所述基本原理不限于任何特定再分机制。在一实施例中，低延时压缩逻辑404将视频帧划分成许多图像块，且将来自每个帧的一个图像块编码(也即，压缩)为I帧(也即，将该图像块压缩，好像其为全图像的大 小的1/16的单独视频帧，且用于此“迷你型”巾贞的压缩为I帧压缩)并将剩余图像块编码为 P帧(也即，用于每个“迷你型” 1/16帧的压缩为P帧压缩)。经压缩为I帧的图像块及经 压缩为P帧的图像块将分别被称作“I图像块”及“P图像块”。随着每个相继视频帧而改变 待编码为I图像块的图像块。因此，在给定帧时间中，视频帧中的所述图像块中仅一个图像 块为I图像块，且所述图像块中的剩余者为P图像块。举例而言，在图7a中，未经压缩的帧 701的图像块0经编码为I图像块10且剩余的1-15图像块经编码为P图像块(P1至P15) 以产生R帧711。在下一个未经压缩的视频帧702中，未经压缩的帧701的图像块1经编码 为I图像块II且剩余的图像块0及2至15经编码为P图像块(P0，及P2至P15)以产生R 帧712。因此，用于图像块的I图像块及P图像块在相继帧上逐渐地在时间上交错。该过 程继续，直至产生R图像块770 (矩阵中最末图像块经编码为I图像块(也即，115))为止。 该过程接着重新开始，从而产生诸如帧711(也即，对于图像块0，编码I图像块)等的另一 个R帧。尽管图7a中未说明，但在一个实施例中，R帧的视频序列的第一 R帧仅含有I图 像块(也即，以使得随后的P帧具有参考图像数据(自其开始计算运动))。或者，在一实施 例中，启动序列使用与正常相同的I图像块型样，但不包括用于尚未连同I图像块一起编码 的所述图像块的P图像块。换言之，在第一I图像块到达之前不连同任何数据一起编码特 定图像块，从而避免图9a中的视频流数据速率934中的启动峰值，其在下文进一步详细说 明。此外，如下所述，各种不同大小及形状可用于所述图像块同时仍遵守所述基本原理。在客户端415上执行的视频解压缩逻辑412解压缩每个图像块，好像其为小I帧 及P帧的单独视频序列，且接着将每个图像块再现给驱动显示设备422的帧缓冲器。举例 而言，使用来自R帧711至770的10及P0来解压缩并再现视频图像的图像块0。类似地， 使用来自R帧711至770的II及P1来重建图像块1，等等。如上所述，I帧及P帧的解压 缩是这项技术中众所熟知的，且I图像块及P图像块的解压缩可通过使视频解压缩器的多 个执行个体在客户端415上执行来完成。尽管倍增过程看来似乎增加客户端415上的计算 负担，但实际上其不会增加客户端415上的计算负担，因为图像块本身成比例地较小(相对 于额外处理的数目而言)，因此所显示的像素的数目相同，好像存在一个处理且使用传统的 全大小的I帧及P帧。该R帧技术显著减轻通常与I帧相关联的带宽峰值(图6b及图6c中所说明)，因 为任何给定帧主要是由通常比I帧小的P帧构成。举例而言，再次假定典型I帧为160Kb， 则图7a中所说明的帧中的每一者的I图像块将为该量的大致1/16或10Kb。类似地，假定 典型P帧为16Kb，则用于图7a中所说明的图像块中的每一者的P帧可为大致1Kb。最终结 果为约10Kb+15*lKb = 25Kb的R帧。因此，每一 60帧序列将是25Kb*60 = 1. 5Mbps。因 此，在60帧/秒下，这将需要能够维持1. 5Mbps的带宽的信道，但由于I图像块是贯穿60 帧间隔而分散而使得具有低得多的峰值。注意，在先前实例中，在用于I帧及P帧的相同假定数据速率情况下，平均数据速 率为1. 1Mbps。这是因为在先前实例中，每隔60个帧时间仅引入新I帧，而在此实例中，构 成I帧的16个图像块在16个帧时间中循环，且因此，每隔16个帧时间引入I帧的均等物， 从而导致稍高的平均数据速率。尽管如此，但在实践中，引入更频繁的I帧并不会线性地增 加数据速率。这是由于以下事实P帧(或P图像块)主要编码自先前帧至下一个帧的差
32异。因此，若先前帧与下一个帧相当类似，则P帧将非常小，若先前帧与下一个帧相当不同， 则P帧将非常大。但因为P帧很大程度上是自先前帧导出，而非自实际帧导出，所以所得的 经编码帧可能含有比具有足够数目的比特的I帧多的错误(例如，视觉假影)。此外，当一 个P帧跟随另一 P帧时，可出现错误累加(当存在长P帧序列时，变得更糟)。现在，尖端的 视频压缩器将侦测到图像的质量在一序列P帧的后降级的事实，且必要时，其将更多比特 分配给随后的P帧以提高质量，或若其为最有效的动作过程，则用I帧替换P帧。因此，当 使用长P帧序列(例如，59个P帧，如上文先前实例中)时，特定言的当场景具有大量复杂 度和/或运动时，通常，对于P帧而言需要更多比特(因为其变得距I帧更远)。或者，自相对观看点看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帧急剧地减少峰值，这使视频序列在远小于1/ P帧序列的延时下可用。可视视频序列的性质、信道的可靠性及可用数据速率而以多种不同方式来配置R 帧。在替代实施例中，在4X4配置中使用不同于16的数目的图像块。举例而言，可在2X1 或1X2配置中使用2个图像块，可在2X2、4X1或1X4配置中使用4个图像块，可在3X2、 2X3、6X1或1X6配置中使用6个图像块或可在4X2(如图7b中所显示)、2X4、8X 1或 1 X 8配置中使用8个图像块。注意，图像块不需要为方形，视频帧也不必为方形，或甚至矩 形。可将图像块分解成最佳地适合所使用的视频流及应用程序的无论什么形状。在另一实施例中，I图像块及P图像块的循环不锁定到图像块的数目。举例而言， 在8图像块4X2配置中，仍可如图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图像块一起进行排序。此外，尽管在图
337a-图7b中说明每个帧具有单个I图像块，但可在单个帧中编码多个I图像块(取决于传 输信道的带宽)。相反地，特定帧或帧序列可在不具有I图像块(也即，仅P图像块)的情 况下传输。前一段的方法适当起作用的原因在于尽管不具有跨越每个单个帧而分散的I图 像块看来似乎导致较大峰值，但系统的行为并不如此简单。因为每个图像块是与其他图像 块分开进行压缩，所以当图像块变小时，每个图像块的编码可变得较不有效，因为给定图像 块的压缩器不能够利用来自其他图像块的类似图像特征及类似运动。因此，与将屏幕划分 成8个图像块相比较，将屏幕划分成16个图像块通常将导致较不有效的编码。但是，若将 屏幕划分成8个图像块且其引起每隔8个帧(而非每隔16个帧)引入一个完全I帧的数 据，则其导致总体上高得多的数据速率。因此，通过每隔16个帧(而非每隔8个帧)引入 一个完全I帧，减小了总数据速率。而且，通过使用8个较大图像块(而非16个较小图像 块)，减小了总数据速率，其也将由较大图像块引起的数据峰值减轻至某种程度。在另一实施例中，图7a及图7b中的低延时视频压缩逻辑404通过基于待压缩的 视频序列的已知特性而通过设定预先配置或者基于每个图像块中的图像质量的正在进行 的分析而自动地控制至R帧中的各图像块的比特的分配。举例而言，在一些竞赛视频游戏 中，玩家的汽车(其为场景中相对无运动的)的前方占据屏幕的下半部的大部分，而屏幕 的上半部完全被填满正接近的道路、建筑物及风景，其几乎总是在运动中。若压缩逻辑404 将相等数目的比特分配给每个图像块，则图7b中的未经压缩的帧721中的屏幕的下半部 上的图像块(图像块4-7)通常将以比图7b中的未经压缩的帧721中的屏幕的上半部中的 图像块(图像块0-3)高的质量而压缩。若已知该特定游戏或游戏的此特定场景具有所述 特性，则主机服务210的运营商可配置压缩逻辑404以将更多比特分配给屏幕的顶部的图 像块(与分配给屏幕的底部处的图像块的比特相比)。或者，压缩逻辑404可在压缩帧之 后估计图像块的压缩质量(使用许多压缩质量度量中的一者或多者，诸如峰值信号噪音比 (PSNR))，且若确定在特定时间窗上，特定图像块始终如一地产生较佳质量结果，则其逐渐 地将更多比特分配给产生较低质量结果的图像块，直至各种图像块达到类似水平的质量为 止。在替代实施例中，压缩器逻辑404分配比特以在特定图像块或图像块群中达成较高质 量。举例而言，其可提供较佳的总体感知外观，以在屏幕的中心具有比边缘处高的质量。在一个实施例中，为了改良视频流的特定区域的分辨率，视频压缩逻辑404使用 较小图像块来编码视频流的具有相对多的场景复杂度和/或运动的区域(与视频流的具 有相对少的场景复杂度和/或运动的区域相比)。举例而言，如图8中所说明，在一个R帧 811 (可能随后跟着具有相同图像块大小的一系列R帧(未图示))的一个区域中的移动人 物805的周围使用较小图像块。接着，当人物805移动至图像的新区域时，在另一 R帧812 内的此新区域的周围使用较小图像块，如所说明。如上所述，各种不同大小及形状可用作 “图像块”同时仍遵守所述基本原理。尽管上文所描述的循环I/P图像块实质上减小视频流的数据速率中的峰值，但其 并不完全消除峰值，尤其在快速改变或高度复杂的视频图像(诸如在电影、视频游戏及某 一应用程序软件下出现)的状况下。举例而言，在突然场景转变期间，复杂帧可能随后跟着 完全不同的另一复杂帧。即使若干个I图像块可领先于场景转变仅几个帧时间，其在该情 形下也没有帮助，因为新帧的材料与先前I图像块无关。在这种情形下(及在即使并非一切都改变，大量图像也改变的其他情形下)，视频压缩器404将确定将许多(若并非所有)P 图像块更有效地写码为I图像块，且所导致的是所述帧的数据速率中的非常大的峰值。如先前所论述，其仅为对于大多数消费者级互联网连接(及许多办公室连接)的 状况，其仅不可“堵塞”超过图6c中显示为622的可用最大数据速率以及额定最大数据速 率621的数据。注意，额定最大数据速率621 (例如，“6Mbps DSL”)实质上为对于考虑购买 互联网连接的用户的销售数字，但通常其不保证性能水平。出于该应用的目的，其是不相关 的，因为我们仅关注经由连接使视频流动时的可用最大数据速率622。因此，在图9a及图 9c中，当描述对峰值问题的解决方法时，自曲线图省略额定最大数据速率，且仅显示可用最 大数据速率922。视频流数据速率不得超过可用最大数据速率922。为了解决此问题，视频压缩器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所接收的统计数据(例如，峰值丢失、延时、最大数据速率等)而确定 峰值数据速率。图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的峰值难得出现。但是，当其确实出现时(例如，在场景转变期间)， 其所需的数据速率必须产生良好质量的视频图像。解决此问题的一个方式是简单地配置视频压缩器404以使得其最大数据速率输 出为峰值数据速率941。遗憾地，峰值帧期间的所得视频输出质量不良，因为压缩算法“极 度缺乏”比特。所导致的为当存在突然转变或快速运动时出现压缩假影，且及时地，用户开 始认识到当存在突然改变或快速运动时假影总是突然出现，且其可变得相当讨厌。尽管人的视觉系统对在突然改变或快速运动期间出现的视觉假影相当敏感，但对 在所述情形下侦测到帧速率的减小并不是非常敏感。事实上，当所述突然改变出现时，看来 似乎人的视觉系统专注于追踪所述改变，且若帧速率暂时从60fps下降到30fps且接着立 即返回到60fps，则人的视觉系统不会注意到。此外，在非常急剧的转变(如突然场景改变) 的状况下，若帧速率下降到20fps或甚至15fps且接着立即返回到60fps，则人的视觉系统 不会注意到。只要帧速率减小仅偶尔出现，对于人观察者而言，看来似乎视频以60fps不断 地执行。通过图9b中所说明的技术来利用人的视觉系统的此特性。服务器402 (来自图4a 及图4b)以稳定帧速率(在一个实施例中，在60fps下)产生未经压缩的视频输出流。时间 线显示每个1/60秒每个帧961-970输出。自帧961开始，将每个未经压缩的视频帧输出至 低延时视频压缩器404，低延时视频压缩器404在小于一帧时间的时间中压缩所述帧，产生 用于第一帧的经压缩的帧1981。经产生用于经压缩的帧1981的数据可视如先前所描述的 许多因素而较大或较小。若数据足够小以致可以峰值数据速率941在一帧时间(1/60秒) 或小于一帧时间内将其传输至客户端415，则在传输时间(xmit时间)991(指示传输时间的 持续时间的箭头的长度)期间将其传输。在下一个帧时间中，服务器402产生未经压缩的 帧2962，将其压缩成经压缩的帧2982，且在小于一帧时间的传输时间992期间以峰值数据 速率941将其传输至客户端415。接着，在下一个帧时间中，服务器402产生未经压缩的帧3963。当由视频压缩器 404来压缩未经压缩的帧3963时，所得的经压缩的帧3983为比可以峰值数据速率941在一 帧时间中传输的数据多的数据。因此，在传输时间(2倍峰值)993期间将其传输，其占据所 有帧时间及下一个帧时间的一部分。现在，在下一个帧时间期间，服务器402产生另一未经 压缩的帧4964且将其输出至视频压缩器404，但数据被忽略且通过974来说明。这是因为 视频压缩器404经配置以忽略在其仍传输先前经压缩的帧时到达的其他未经压缩的视频 帧。当然，客户端415的视频解压缩器将未能接收到帧4，但其简单地继续在显示设备422 上显示帧3历时2个帧时间(也即，暂时将帧速率自60fps减小至30fps)。对于下一个帧5，服务器402输出未经压缩的帧5965，将其压缩成经压缩的帧5985 且在传输时间995期间在1帧内将其传输。客户端415的视频解压缩器解压缩帧5并将其 显示于显示设备422上。接着，服务器402输出未经压缩的帧6966，视频压缩器404将其压 缩成经压缩的帧6986，但此时所得的数据非常大。在传输时间(4倍峰值)996期间以峰值 数据速率941传输经压缩的帧，但花费几乎4个帧时间来传输帧。在接下来的3个帧时间期 间，视频压缩器404忽略来自服务器402的3个帧，且客户端415的解压缩器将帧6稳定地 保持在显示设备422上历时4个帧时间(也即，暂时将帧速率自60fps减小至15fps)。接着最后，服务器402输出帧10970，视频压缩器404将其压缩成经压缩的帧10987，且在传输 时间997期间将其传输，且客户端415的解压缩器解压缩帧10并将其显示于显示设备422 上且再一次视频以60fps重新开始。注意，尽管视频压缩器404丢弃了来自由服务器402产生的视频流的视频帧，但其 不会丢弃音频数据(不管音频是以什么形式来的)，且当丢弃视频帧时视频压缩器404继 续压缩音频数据并将其传输至客户端415，客户端415继续解压缩音频数据并将音频提供 至由用户使用以回放音频的无论什么设备。因此在丢弃帧的周期期间，音频继续而不减弱。 与经压缩的视频相比，经压缩的音频消耗相对小百分比的带宽，且因此不会对总数据速率 有较大影响。尽管在数据速率图中的任一者中都未说明，但峰值数据速率941内总是存在 经保留用于经压缩音频流的数据速率容量。选择刚刚在图9b中所描述的实例来说明在数据速率峰值期间帧速率如何下降， 但未说明的是当使用先前所描述的循环I/P图像块技术时，所述数据速率峰值及随的发生 的丢弃的帧很少，即使在高场景复杂度/高动作序列(诸如在视频游戏、电影及某个应用程 序软件中出现的那些)期间也如此。因此，减小的帧速率罕有且暂时，且人的视觉系统不会 侦测到它们。若将刚刚所描述的帧速率减小机制应用于图9a中所说明的视频流数据速率，则 在图9c中说明所得的视频流数据速率。在此实例中，2倍峰值952已减小至平坦化的2倍 峰值953，且4倍峰值955已减小至平坦化的4倍峰值955，且整个视频流数据速率934保 持处于或低于峰值数据速率941。因此，使用上文所描述的技术，可经由通用互联网及消费者级互联网连接而以低 延时来传输高动作视频流。另外，在LAN(例如，lOOMbs以太网或802. llg无线网络)上或私 用网络(例如，数据中心与办公室之间的100Mbps连接)上的办公室环境中，可在无峰值情 况下传输高动作视频流，以使得多个用户(例如，以4. 5Mbps传输60fps下的1920X 1080) 可使用LAN或共用私用数据连接，而不使重迭峰值淹没(overwhelm)网络或网络交换器底 板。数据速率调整在一个实施例中，主机服务210最初评估信道的可用最大数据速率622及延时以 确定用于视频流的适当数据速率且接着响应于此而动态地调整数据速率。为了调整数据速 率，主机服务210可(例如)修改待发送至客户端415的视频流的图像分辨率和/或每秒 帧数。而且，主机服务可调整经压缩视频的质量水平。当改变视频流的分辨率时(例如，自 1280 X 720分辨率至640 X 360)，客户端415上的视频解压缩逻辑412可将图像按比例增加 以在显示屏幕上维持相同图像大小。在一个实施例中，在信道完全退出的情形下，主机服务210将游戏暂停。在多人游 戏的状况下，主机服务向其他用户报告该用户已退出游戏和/或将游戏暂停以用于其他用户。丢弃或延迟的分组在一个实施例中，若数据由于图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图像块导致小得多的视觉假影。一个实施例试图通过将经压缩的图像块智能地封装于TCP(传输控制协议)分组 或UDP(用户数据报协议)分组内而减少丢失分组的效应。举例而言，在一个实施例中，只 要可能，即将图像块与分组边界对准。图10a说明可如何在不实施此特征的情况下将图像 块封装于一系列分组1001-1005内。具体言之，在图10a中，图像块越过分组边界且经无效 率地封装以致单一分组的丢失导致多个帧的丢失。举例而言，若分组1003或1004丢失，则 丢失三个图像块，导致视觉假影。相比之下，图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个图像块)的丢失。图10b中所显示的实施例的一个额外益处在于图像块是以其在图像内被显示的 不同次序进行传输。若邻近分组由于干扰传输的同一事件(其将影响屏幕上彼此不接近的 区域)而丢失，则此方式在显示器上产生较不引人注意的假影。一个实施例使用前向纠错(FEC)技术来保护视频流的特定部分以使其免受信道 错误的影响。如此项技术中已知，诸如里德-所罗门及Viterbi (维特比)的FEC技术产生 纠错数据信息并将其附加至经由通信信道而传输的数据。若错误在基本数据(例如，I帧) 中出现，则FEC可用于校正该错误。FEC码增加传输的数据速率，因此理想地，其仅在最需要时使用。若数据正被发送， 且其将不导致非常引人注意的视觉假影，则可较佳不使用FEC码来保护数据。举例而言，紧接于丢失的I图像块之前的P图像块将仅在屏幕上产生1/60秒的视觉假影(也即，屏幕上 的图像块将不被更新)。此种视觉假影几乎不能被人眼侦测到。随着P图像块自I图像块 进一步向后，丢失P图像块越加变得更引人注意。举例而言，若图像块循环型样为在I图像 块再次可用之前I图像块随后跟着15个P图像块，则若紧接于I图像块之后的P图像块丢 失，则其导致该图像块显示不正确的图像历时15个帧时间(在60fps下，这将为250毫秒)。 人眼将容易侦测到250毫秒的流的中断。因此，P图像块距新的I图像块越向后(也即，P 图像块跟随I图像块越接近)，则假影越引人注意。如先前所论述，尽管如此，但一般而言， P图像块跟随I图像块越接近，用于该P图像块的数据越小。因此，跟随I图像块的P图像 块不仅对于保护以免丢失而言更关键，而且其大小较小。此外，一般而言，需要保护的数据 越小，保护其所需的FEC码越小。因此，如图11a中所说明，在一个实施例中，由于I图像块在视频流中的重要性，仅 I图像块具备FEC码。因此，FEC 1101含有用于I图像块1100的纠错码且FEC1104含有用 于I图像块1103的纠错码。在此实施例中，对于P图像块不产生FEC。在图lib中所说明的一个实施例中，对于在丢失时最可能引起视觉假影的P图像 块也产生FEC码。在此实施例中，FEC 1105提供用于前3个P图像块但不用于跟随的P图 像块的纠错码。在另一实施例中，对于数据大小最小的P图像块产生FEC码(其将倾向于 自选在I图像块的后最早出现的P图像块，其对于保护最为关键)。在另一实施例中，并非将FEC码连同图像块一起发送，而是将图像块传输两次，每 次在不同分组中传输。若一分组丢失/延迟，则使用另一分组。在图11c中所显示的一个实施例中，产生分别用于与视频同时自主机服务传输的 音频分组1110及1112的FEC码1111及1113。维持视频流中的音频的完整性特别重要，因 为失真的音频(例如，滴答声或嘶嘶声)将导致特别不合需要的用户体验。FEC码帮助确保 音频内容在客户端计算机415处无失真地再现。在另一实施例中，并非将FEC码连同音频数据一起发送，而是将音频数据传输两 次，每次在不同分组中传输。若一个分组丢失/延迟，则使用另一分组。另外，在图lid中所说明的一个实施例中，FEC码1121及1123分别用于自客户 端415上行传输到主机服务210的用户输入命令(例如，按钮按压)1120及1122。这是重 要的，因为在视频游戏或应用程序中漏掉按钮按压或鼠标运动可能导致不合需要的用户体 验。在另一实施例中，并非将FEC码连同用户输入命令数据一起发送，而是将用户输 入命令数据传输两次，每次在不同分组中传输。若一个分组丢失/延迟，则使用另一分组。在一个实施例中，主机服务210评估与客户端415的通信信道的质量，以确定是否 使用FEC，且若使用，则确定应对视频、音频及用户命令的何部分应用FEC。评估信道的“质 量”可包括如上所述的诸如估计分组丢失、延时等的功能。若信道特别不可靠，则主机服务 210可对所有I图像块、P图像块、音频及用户命令应用FEC。相比之下，若信道可靠，则主 机服务210可仅对音频及用户命令应用FEC，或可不对音频或视频应用FEC，或可根本不使 用FEC。可使用FEC的应用的各种其他排列，同时仍遵守所述基本原理。在一个实施例中， 主机服务210不断地监视信道的状况且相应地改变FEC策略。在另一实施例中，参看图4a及图4b，当分组丢失/延迟，从而导致图像块数据的丢
39失时，或若可能由于特别糟的分组丢失而使得FEC不能够校正丢失的图像块数据，客户端 415评估在将接收新的I图像块之前剩余多少个帧且将其与自客户端415至主机服务210 的来回行程延时相比较。若来回行程延时小于新的I图像块应到达之前的帧的数目，则客 户端415向主机服务210发送消息，请求新的I图像块。将此消息路由至视频压缩器404， 且其并非产生用于数据已丢失的图像块的P图像块，而是产生I图像块。假定图4a及图 4b中所显示的系统经设计以提供通常小于80毫秒的来回行程延时，则这导致图像块被校 正于80毫秒内(在60fps下，帧具有16. 67毫秒的持续时间，因此在全帧时间中，80毫秒 延时将导致83. 33毫秒内的经校正的图像块，83. 33毫秒为5个帧时间，其为引人注意的中 断，但远不及(例如)对于15个帧250毫秒中断引人注意)。当压缩器404脱离其通常的 循环次序而产生此种I图像块时，若I图像块将引起所述帧的带宽超过可用带宽，则压缩器 404将延迟其他图像块的循环，以使得其他图像块在所述帧时间期间接收P图像块(即使在 所述帧期间一个图像块通常将应为I图像块)，且接着通常的循环将自下一个帧开始继续， 且通常将已接收到先前帧中的I图像块的图像块将接收I图像块。尽管此动作暂时延迟R 帧循环的阶段，但其通常将在视觉上不引人注意。视频及音频压缩器/解压缩器实施图12说明一个特定实施例，其中使用多核和/或多处理器1200来并行地压缩8个 图像块。在一实施例中，使用在2. 66GHz或更高下执行的双核处理器、四核Xeon (至强)CPU 计算机系统，每个核心作为独立过程实施开源x264H. 264压缩器。然而，可使用各种其他硬 件/软件配置，同时仍遵守所述基本原理。举例而言，CPU核心中的每一者可通过以FPGA实 施的H. 264压缩器来替换。在图12中所显示的实例中，核心1201-1208用于作为八个独立 线绪来同时处理I图像块及P图像块。如此项技术中众所周知的，当前多核及多处理器计 算机系统与诸如Microsoft Windows XP专业版(64比特版或者32比特版)及Linux的多 线绪处理操作系统整合时，其固有地能够进行多线绪处理。在图12中所说明的实施例中，因为该8个核心中的每一者仅负责一个图像块， 所以其很大程度上独立于其他核心而操作，每一者执行x264的单独实例化。使用以PCI Express xl 为基础的 DVI 捕获卡(诸如，来自 Netherlands 的 Microtronix ofOosterhout 的Sendero视频成像IP开发板)来捕获640 X 480、800 X 600或1280X720分辨率下的未 经压缩的视频，且卡上的FPGA使用直接存储器存取(DMA)来将所捕获的视频经由DVI总线 传送至系统RAM中。将所述图像块配置成4X2配置1205(尽管其说明为方形图像块，但在 该实施例中，其具有160 X 240分辨率)。x264的每个实例化被配置成压缩该8个160 X 240 图像块中的一者，且其经同步化以使得在初始I图像块压缩的后每一核心进入一循环，每 一帧与另一帧不同相，以压缩一 I图像块继的以七个P图像块，如图12中所说明。在每一帧时间，使用先前所描述的技术将所得的经压缩图像块组合成分组流，且 接着将经压缩图像块传输至目的地客户端415。尽管图12中未说明，但若组合的8个图像块的数据速率超过指定峰值数据速率 941，则所有8个x264过程将暂时中止历时达必要的帧时间，直至已传输用于组合的8个图 像块的数据为止。在一个实施例中，将客户端415实施为执行FFmpeg的8个实例化的PC上的软件。 接收过程接收8个图像块，且将每一图像块路由至FFmpeg实例化，FFmpeg实例化解压缩图像块并将其再现至显示设备422上的适当图像块位置。客户端415接收来自PC的输入设备驱动器的键盘、鼠标或游戏控制器输入并将其 传输到服务器402。服务器402接着应用所接收的输入设备数据并将其应用于在服务器402 上执行的游戏或应用程序，服务器402为使用Intel 2. 16GHz双核CPU执行Windows的PC。 服务器402接着产生新帧并经由其DVI输出端将新帧自以主机板为基础的图形系统或者经 由NVIDIA8800GTX PCI卡的DVI输出端输出。同时，服务器402经由其数字音频输出端(例如，S/PDIF)输出由游戏或应用程序 产生的音频，该数字音频输出端耦合至实施视频压缩的以双四核Xeon为基础的PC上的数 字音频输入端。Vorbis开源音频压缩器用于使用可用于处理线绪的无论什么核心来与视频 同时地压缩音频。在一个实施例中，完成压缩其图像块的核心首先执行音频压缩。接着将 经压缩的音频连同经压缩的视频一起传输，并在客户端415上使用Vorbis音频解压缩器来 解压缩经压缩的音频。主机服务服务器中心分配经由玻璃(诸如，光纤)的光以光在真空中的速度的某一部分行进，且因此可确定 光在光纤中的确切传播速度。但是，在实践中，考虑用于路由延迟、传输无效率及其他耗用 的时间，我们观察到互联网上的最佳延时反映较接近光速的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的任何用户场所存取在中心定位的单个服务器中 心。在图13b中所说明的另一实施例中，主机服务210服务器中心HS1-HS6战略上定 位于美国(或其他地理区域)的周围，特定较大的主机服务服务器中心接近高人口中心而 定位(例如，HS2及HS5)。在一个实施例中，服务器中心HS1-HS6经由网络1301交换信息， 网络1301可为互联网或私用网络或两者的组合。在多个服务器中心的情况下，可以较低延 时向具有高用户ISP延时453的用户提供服务。尽管互联网上的距离的确为对经由互联网的来回行程延时有影响的因素，但有时 很大程度上与延时无关的其他因素也起作用。有时经由互联网将分组流路由至距离远的位 置且再次返回，从而导致来自长循环的延时。有时在路径上存在不适当操作的路由设备，从 而导致传输的延迟。有时存在使路径超载的通信，其引入延迟。此外，有时，根本是存在防 止用户的ISP路由至给定目的地的故障。因此，尽管通用互联网通常以相当可靠且最佳的路由及延时来提供从一点到另一点的连接，该相当可靠且最佳的路线及延时很大程度上是 通过距离来确定(尤其是在导致路由至用户的本地区域的外部的长距离连接的情况下)， 但该可靠性及延时得不到任何保证且常常不可自用户的场所至通用互联网上的给定目的 地而达成。在一个实施例中，当用户客户端415最初连接到主机服务210以玩视频游戏或使 用应用程序时，客户端在启动时与可用的主机服务服务器中心HS1-HS6中的每一者通信 (例如，使用上文所描述的技术)。若延时对于特定连接而言足够低，则使用该连接。在一 个实施例中，客户端与所有主机服务服务器中心或主机服务服务器中心的一个子集通信， 选择具有最低延时连接的主机服务服务器中心。客户端可选择具有最低延时连接的服务中 心，或服务器中心可识别具有最低延时连接的服务器中心并将此信息(例如，以互联网地 址的形式)提供给客户端。若特定主机服务服务器中心超载和/或用户的游戏或应用程序可容忍至另一、较 少载入的主机服务服务器中心的延时，则可将客户端415重定向至另一主机服务服务器中 心。在此种情形下，将使用户正执行的游戏或应用程序在用户的超载服务器中心处的服务 器402上暂停，且将游戏或应用程序状态数据传送至另一主机服务服务器中心处的服务器 402。接着将重新开始该游戏或应用程序。在一个实施例中，主机服务210将等待直至游戏 或应用程序达到自然暂停点(例如，游戏中的级别之间，或者在用户在应用程序中起始“保 存”操作之后)才进行传送。在又一实施例中，主机服务210将等待直至用户活动停止历时 指定时间周期(例如，1分钟)为止且接着将在这时起始传送。如上所述，在一个实施例中，主机服务210订阅图14的互联网旁路服务440以试 图将得到保证的延时提供给其客户端。如本文中所使用的互联网旁路服务是提供自互联网 上的一点至另一点的具有得到保证的特性(例如，延时、数据速率等)的私用网络路线的服 务。举例而言，若主机服务210正使用在圣弗朗西斯科提供的AT&T的DSL服务接收来自 用户的大量通信(而非路由至以AT&T的圣弗朗西斯科为基地的中央办公室)，则主机服务 210将在以圣弗朗西斯科为基地的中央办公室与用于主机服务210的服务器中心中的一或 多者之间租用来自服务提供者(可能为AT&T本身或另一提供者)的高容量私用数据连接。 接着，若自所有主机服务服务器中心HS1-HS6经由通用互联网至圣弗朗西斯科中使用AT&T DSL的用户的路线导致过高延时，则可改为使用私用数据连接。尽管私用数据连接通常比经 由通用互联网的路线更昂贵，但只要其保持主机服务210的一小百分比连接至用户，总成 本影响就低，且用户将体验到更一贯的服务体验。在电力故障的情况下，服务器中心常常具有两个备用电力层。第一层通常为来自 电池(或来自替代的立即可用的能量源，诸如保持运转且附接至发电机的飞轮)的备用电 力，其在电力干线出故障时立即提供电力且保持服务器中心运转。若电力故障为暂时的，且 电力干线迅速返回(例如，在一分钟内)，则电池所需的是保持服务器中心运转。但若电力 故障历时较长的时间周期，则通常启动发电机(例如，柴油机供电)来取代电池且发电机只 要具有燃料即可运转。所述发电机极昂贵，因为其必须能够产生多达服务器中心通常自电 力干线所得到的电力。在一个实施例中，主机服务HS1-HS5中的每一者彼此共用用户数据，以便在一个 服务器中心具有电力故障时，其可将在进行中的游戏及应用程序暂停，且接着将游戏或应用程序状态数据自每个服务器402传送至其他服务器中心处的服务器402，且接着将通知 每一用户的客户端415以指导其传达至新的服务器402。假定所述情形偶尔出现，则将用户 转移至不能够提供最佳延时的主机服务服务器中心(也即，用户将仅必须容忍较高延时历 时电力故障的持续时间)可为可接受的，其将允许用于转移用户的宽得多的范围的选项。 举例而言，给定跨越美国的时区差，则东海岸上的用户在11 30PM可能将要睡眠，而西海岸 上的用户在8:30PM正开始在视频游戏使用上达到峰值。若那时西海岸上的主机服务服务 器中心中存在电力故障，则其他主机服务服务器中心处可能不存在用于处理所有用户的足 够的西海岸服务器402。在此种情形下，可将一些用户转移至东海岸上具有可用服务器402 的主机服务服务器中心，且对于用户而言的唯一后果将是较高延时。一旦将用户自失去电 力的服务器中心转移，服务器中心接着就可开始其服务器及设备的有序切断，以便在电池 (或其他立即电力备用)耗尽之前切断所有设备。以此方式，可避免用于服务器中心的发电 机的成本。在一个实施例中，在主机服务210的严重载入的时间期间(或者由于峰值用户载 入，或者因为一个或多个服务器中心出故障)，基于用户正使用的游戏或应用程序的延时要 求将用户转移至其他服务器中心。因此，将为使用需要低延时的游戏或应用程序的用户给 出对存在有限供应的可用低延时服务器连接的优选。主机服务特征图15说明在以下特征描述中利用的用于主机服务210的服务器中心的组件的实 施例。如同图2a中所说明的主机服务210 —样，除非另外有条件，否则此服务器中心的组 件由主机服务210控制系统401来控制及协调。将来自用户客户端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的子网络的网络连接及至附接 至其他设备的子网络的另一网络连接。
43
应用程序/游戏服务器1521-1525可经相同地、有些不同地或全部不同地来配置， 如先前关于图4a中所说明的实施例中的服务器402所描述的。在一实施例中，每一用户当 使用主机服务时通常为至少一应用程序/游戏服务器1521-1525。出于说明的简单起见，将 假定给定用户正使用应用程序/游戏服务器1521，但多个服务器可由一用户使用，且多个 用户可共用单一应用程序/游戏服务器1521-1525。自客户端415 (如先前所描述)所发 送的用户的控制输入经接收为入埠互联网通信1501，且经由入埠路由1502而路由至应用 程序/游戏服务器1521。应用程序/游戏服务器1521使用用户的控制输入作为至在服务 器上执行的游戏或应用程序的控制输入，且计算视频及与其相关联的音频的下一个帧。应 用程序/游戏服务器1521接着将未经压缩的视频/音频1529输出至共用视频压缩1530。 应用程序/游戏服务器可经由任何装置(包括一或多个超高速以太网连接)而输出未经压 缩的视频，但在一实施例中，视频是经由DVI (交互式数字视频系统)连接而输出，且音频及 其他压缩及通信信道状态信息系经由通用串列总线(USB)连接而输出。共用视频压缩1530压缩来自应用程序/游戏服务器1521-1525的未经压缩的视 频及音频。该压缩可完全以硬件或以执行软件的硬件来实施。可存在用于每个应用程序/ 游戏服务器1521-1525的专用压缩器，或若压缩器足够快，则可使用给定压缩器来压缩来 自一个以上应用程序/游戏服务器1521-1525的视频/音频。举例而言，在60fps下，视频 帧时间为16. 67毫秒。若压缩器能够在1毫秒内压缩1帧，则该压缩器可用于通过取得来 自一个接一个的服务器的输入而压缩来自多达16个应用程序/游戏服务器1521-1525的 视频/音频，该压缩器保存每个视频/音频压缩过程的状态且当其在来自服务器的视频/ 音频流当中循环时切换背景。这导致压缩硬件的实质成本节省。因为不同服务器将在不同 时间完成帧，所以在一个实施例中，压缩器资源是处于具有用于储存每个压缩过程的状态 的共用储存装置(例如，RAM，闪存)的共用集区1530中，且当服务器1521-1525帧完整且 准备被压缩时，控制装置确定那时哪个压缩资源可用，为该压缩资源提供服务器的压缩过 程的状态及待压缩的未经压缩的视频/音频的帧。注意，用于每个服务器的压缩过程的状态的一部分包括关于压缩本身的信息，诸 如先前帧的经解压缩的帧缓冲数据(其可用作用于P图像块的参考)、视频输出的分辨率； 压缩的质量；图像块结构；每图像块的比特的分配；压缩质量、音频格式(例如，立体声、环 绕音效、Dolby AC-3 (杜比 ) AC-3)。但是压缩过程状态也包括关于以下的通信信 道状态信息峰值数据速率941，及先前帧(如图9b中所说明)当前是否正被输出(且因 此应忽略当前帧)，及潜在地是否存在应在压缩中考虑的(诸如，过多分组丢失)影响压缩 决策(例如，在I图像块的频率方面，等)的信道特性。因为峰值数据速率941或其他信道 特性随着时间而改变，如由支持每个用户监视从客户端415发送的数据的应用程序/游戏 服务器1521-1525所确定的，所以应用程序/游戏服务器1521-1525将相关信息发送至共 用硬件压缩1530。共用硬件压缩1530也使用诸如先前所描述的所述装置的装置将经压缩的视频/ 音频分组化，且在适当时，应用FEC码，复制特定数据，或采取其他步骤，以便充分地确保视 频/音频数据流由客户端415接收且以可行的高质量及可靠性解压缩的能力。—些应用程序(诸如，下文所描述的应用程序)需要给定应用程序/游戏服务器 1521-1525的视频/音频输出同时在多个分辨率下(或以其他多个格式)可用。若应用程序/游戏服务器1521-1525如此通知共用硬件压缩1530资源，则该应用程序/游戏服务 器1521-1525的未经压缩的视频音频1529将被以不同格式、不同分辨率和/或在不同分组 /纠错结构中同时压缩。在一些状况下，一些压缩资源可在压缩同一视频/音频的多个压 缩过程当中共用(例如，在许多压缩算法中，存在借以在应用压缩的前将图像按比例调整 成多个大小的步骤。若需要输出不同大小的图像，则该步骤可用于同时服务若干个压缩过 程)。在其他状况下，对于每个格式将需要单独的压缩资源。在任何状况下，将用于给定应 用程序/游戏服务器1521-1525 ( 一或多个)所需的所有各种分辨率及格式的经压缩的视 频/音频1539同时输出到出埠路由1540。在一个实施例中，经压缩的视频/音频1539的 输出是处于UDP格式，因此其为单向分组流。出埠路由网络1540包含一系列路由服务器及交换器，该系列路由服务器及交换 器将每个经压缩的视频/音频流经由出埠互联网通信1599接口(其通常将连接到至互联 网的光纤接口)而指引到有意的用户或其他目的地和/或返回至延迟缓冲器1515，和/或 返回至入埠路由1502，和/或经由私用网络(未图示)而输出以供进行视频分配。注意(如 下所述)出埠路由1540可将给定视频/音频流同时输出至多个目的地。在一实施例中， 这是使用互联网协议(IP)多播来实施，其中广播意欲同时流动到多个目的地的给定UDP 流，且该广播由出埠路由1540中的路由服务器及交换器来重复。广播的该多个目的地可经 由互联网而至多个用户的客户端415、经由入埠路由1502而到多个应用程序/游戏服务器 1521-1525，和/或到一个或多个延迟缓冲器1515。因此，将给定服务器1521-1522的输出 压缩成一个或多个格式，且将每个经压缩的流指引到一个或多个目的地。另外，在另一实施例中，若多个应用程序/游戏服务器1521-1525同时由一个用户 使用(例如，在用于产生具有复杂场景的3D输出的并行处理配置中)且每个服务器产生 所得图像的部分，则可由共用硬件压缩1530将多个服务器1521-1525的视频输出组合成 一组合帧，且自该点向前如上所述处理该组合帧，好像其来自单个应用程序/游戏服务器 1521-1525。注意，在一个实施例中，将由应用程序/游戏服务器1521-1525产生的所有视频的 复本(至少以由用户观看的视频的分辨率或更高分辨率)记录于延迟缓冲器1515中历时 至少某一数目的分钟(在一个实施例中为15分钟)。这允许每个用户“回放”来自每个会 话的视频，以便核查先前工作或业绩(在游戏的状况下)。因此，在一个实施例中，将路由至 用户客户端415的每个经压缩视频/音频输出1539流也多播至延迟缓冲器1515。当将视 频/音频储存于延迟缓冲器1515上时，延迟缓冲器1515上的目录提供应用程序/游戏服 务器1521-1525 (其为延迟的视频/音频的来源)的网络地址与延迟缓冲器1515上可发现 延迟的视频/音频的位置之间的交叉参考。 现场直播的、可即刻观看的、可即刻播放的游戏 应用程序/游戏服务器1521-1525不仅可用于执行用户的给定应用程序或视频 游戏，而且其可用于建立用于支持经由主机服务210的导航及其他特征的主机服务210的 用户接口应用程序。一种该用户接口应用程序的屏幕拍摄显示在图16中(“游戏取景器 (Game Finder) ”屏幕)。该特定用户接口屏幕允许用户观看由其他用户现场玩的(或延迟 的)15个游戏。“缩略图”视频窗中的每一者(诸如，1600)为在运动中的现场直播的视频 窗，其显示来自一个用户的游戏的一个视频。缩略图中所显示的视图可为用户正看的同一视图，或其可为延迟的视图(例如，若用户正玩搏斗游戏，则用户可能不希望其他用户看见 其隐藏在哪里且其可选择将其游戏播放的任何视图延迟一时间周期(例如，10分钟))。视 图也可为不同于任何用户的视图的游戏的相机视图。通过菜单选择(此说明中未图示)，用 户可基于多种标准来选择要同时观看的游戏的选择。作为例示性选择的小取样，用户可选 择游戏的随机选择(诸如图16中所显示的游戏)、所有一个类别的游戏(均由不同玩家来 玩)、仅游戏的顶级玩家、游戏中的给定级别的玩家，或较低级玩家(例如，若玩家正学习基 础)、是“搭档”(或为竞争者)的玩家、具有最多数目观看者的游戏等。注意，通常，每个用户将决定来自其游戏或应用程序的视频是否可由他人观看，且 若如此，则决定该视频可由哪些他人观看及何时可由他人观看，决定该视频是否只可在具 有延迟的情况下观看。产生图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。此外，在一个实施例中，可能不需要请求，因为缩略图被“推送”至允许其的那 些用户的客户端。来自15个游戏的所有同时混合的音频可能产生刺耳的声音。用户可选择以此方 式将所有声音混合在一起(可能就为得到由被观看的所有动作产生的“喧嚣”的感觉)，或 者用户可选择每次仅收听来自一个游戏的音频。单个游戏的选择是通过将黄色选择帧1601 移动到给定游戏来完成(黄色帧移动可通过使用键盘上的箭头键、通过移动鼠标、通过移 动操纵杆或通过推动诸如移动电话的另一设备上的方向按钮来完成)。一旦选择了单个游 戏，则只有来自该游戏的音频播放。而且，显示游戏信息1602。在该游戏的状况下，例如， 出版商标志(“EA”)及游戏标志“极品飞车卡本峡谷”及橙色横条在相对条件下指示在该
46特定时刻玩游戏或观看游戏的人的数目(在此状况下，许多，因此游戏为“热门”)。另外提 供“状态”，指示存在145个玩家正积极地玩极品飞车游戏的80个不同具体实例(也即，该 游戏可通过个别玩家游戏或多人游戏来玩)，且存在680个观看者(此用户是其中之一)。 注意，该统计数据(及其他统计数据)由主机服务控制系统401来收集并储存于RAID阵列 1511-1512上，以用于保持主机服务210操作的日志且用于适当地向用户计费并向提供内 容的出版商支付费用。一些统计数据是由于由服务控制系统401进行的动作而记录，且一 些统计数据是由个别应用程序/游戏服务器1521-1525报告给服务控制系统401。举例而 言，当游戏正被观看时(及当游戏被停止观看时)，执行此游戏取景器应用程序的应用程序 /游戏服务器1521-1525向主机服务控制系统401发送消息，以使得主机服务控制系统401 可更新多少个游戏处于观看中的统计数据。一些统计数据可为用户接口应用程序(诸如， 此游戏取景器应用程序)所用。若用户单击其输入设备上的启动按钮，则其将看见黄色帧中的缩略图视频放大同 时缩略图视频保持现场直播为全屏幕大小。该效果显示在图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。现在接收选定视频的全屏幕版本 的该服务器将解压缩该全屏幕版本并将其逐渐地按比例放大至全大小。图18说明在将游戏完全放大至全屏幕且以用户的显示设备422的全分辨率显示 游戏之后屏幕看起来如何(如通过箭头1800指向的图像所指示的)。执行游戏取景器应 用程序的应用程序/游戏服务器1521-1525向提供缩略图的其他应用程序/游戏服务器 1521-1525发送消息以指示所述缩略图不再需要且向主机服务控制服务器401发送消息以 指示不再观看其他游戏。此时，产生的唯一显示为屏幕顶部的叠加层(overlay) 1801，其将 信息及菜单控制提供给用户。注意，随着该游戏进展，观众增长至2，503个观看者。在如此 多的观看者的情况下，必然存在具有显示设备422的许多观看者，所述显示设备422具有相 同或接近的分辨率(每个应用程序/游戏服务器1521-1525具有按比例调整视频以用于调 整配合度的能力)。因为所显示的游戏为多人游戏，所以用户可决定在某时刻加入该游戏。由于多种 原因，主机服务210可或可不允许用户加入该游戏。举例而言，用户可能必须支付玩游戏的费用而选择不支付，用户可能不具有足以加入所述特定游戏的足够等级(例如，对于其他 玩家而言，其将不有竞争性)，或者用户的互联网连接可能不具有足以允许用户玩的足够低 的延时(例如，不存在用于观看游戏的延时约束，因此可在无延时关注的情况下观看被远 距离地(实际上，在另一大陆上)玩的游戏，但对于待玩的游戏而言，延时必须足够低以使 用户(a)享受该游戏，且(b)处于与可能具有较低延时连接的其他玩家相等的地位)。若 准许用户玩，则为用户提供游戏取景器用户接口的应用程序/游戏服务器1521-1525将请 求主机服务控制服务器401初始化(也即，定位并启动)被合适地配置以用于播放特定游 戏的应用程序/游戏服务器1521-1525从而从RAID阵列1511-1512载入该游戏，且接着主 机服务控制服务器401将指导入埠路由1502将来自用户的控制信号传送至现在对游戏进 行主机代管的应用程序/游戏服务器且现在对游戏进行主机代管的应用程序/游戏服务器 将指导共用硬件压缩1530自压缩来从主机代管游戏取景器应用程序的应用程序/游戏服 务器的视频/音频切换至压缩来自现在对游戏进行主机代管的应用程序/游戏服务器的视 频/音频。游戏取景器应用程序/游戏服务与对游戏进行主机代管的新的应用程序/游戏 服务器的垂直同步并不同步，且因此在该两个同步之间可能存在时间差。因为共用视频压 缩硬件1530将在应用程序/游戏服务器1521-1525完成视频帧之后即开始压缩视频，所以 来自新服务器的第一帧可比旧服务器的全帧时间完成得早，来自新服务器的第一帧可能在 先前经压缩的帧完成其传输之前(例如，考虑图9b的传输时间992 若未经压缩的帧3963 早一帧时间的一半地完成，则其将影响(impinge)传输时间992)。在这种情形下，共用视 频压缩硬件1530将忽略来自新服务器的第一帧(例如，如忽略(974)帧4964)，且客户端 415将来自旧服务器的最末帧保持额外一帧时间，且共用视频压缩硬件1530将开始压缩来 自对游戏进行主机代管的新应用程序/游戏服务器的下一帧时间视频。对于用户而言，在 视觉上，从一个应用程序/游戏服务器至另一应用程序/游戏服务器的转变将是无缝的。 主机服务控制服务器401接着将通知对游戏取景器进行主机代管的应用程序/游戏服务器 1521-1525切换至闲置状态，直至再次需要其为止。用户接着能够玩该游戏。此外，例外的是游戏将在感知上即刻地播放(因为游戏 已被以十亿比特/秒速度从Raid阵列1511-1512载入到应用程序/游戏服务器1521-1525 上)，且将通过理想的驱动器、暂存器配置(在Windows的状况下)将游戏连同被正确配置 以用于该游戏的操作系统一起载入到准确适合于该游戏的服务器上，且没有可能与该游戏 的操作竞争的其他应用程序在该服务器上执行。而且，随着用户在游戏中进展，游戏的片段中的每一者将以十亿比特/秒的速度 (也即，在8秒内载入十亿字节)从RAID阵列1511-1512载入服务器中，且由于RAID阵 列1511-1512的巨大储存容量(因为其为许多用户的共用资源，所以其可能非常大，但仍 具成本效益)，使得可预先计算几何形状设置或其他游戏片段设置并将其储存于RAID阵列 1511-1512上且极快速地进行载入。此外，因为每个应用程序/游戏服务器1521-1525的硬 件配置及计算能力是已知的，所以可预先计算像素及顶点着色。因此，游戏可几乎即刻启动，其将在理想环境中执行，且随后的片段将几乎即刻载 入。但是，除这些优点之外，用户将能够观看他人玩游戏(经由先前所描述的游戏取 景器，及其他装置)，且两者均决定游戏是否有趣，如果这样，则自观看他人来学习技巧。此外，用户将能够即刻地演示该游戏，而不必等待大的下载和/或安装，且用户将能够即刻玩 该游戏(可能在较小费用的试用基础上，或在较长期的基础上)。此外，用户将能够通过足 够低延时的无线连接而在Windows PC、MaCint0Sh上、在电视机上、在家里、在行进时且甚至 在移动电话上玩该游戏。此外，这均可在并非曾经实体拥有游戏复本的情况下完成。如先前所叙述，用户可决定不允许其游戏播放可被他人观看，允许其游戏可在延 迟之后观看，允许其游戏可被选定用户观看，或允许其游戏可被所有用户观看。不管怎样， 在一个实施例中，将视频/音频储存于延迟缓冲器1515中历时15分钟，且用户将能够“回 倒”并观看其先前的游戏播放，且将游戏暂停，将游戏缓慢地回放，将游戏快进等，正如其在 观看具有数字视频记录器(DVR)的TV时所能够进行的。尽管在该实例中，用户在玩游戏， 但若用户正使用应用程序，则相同“DVR”能力是可用的。这在核查先前工作中及在如下详 述的其他应用中可是有用的。另外，若游戏经设计为具有基于利用游戏状态信息而回倒的 能力，以便可改变相机视图等，则也将支持此“3D DVR”能力，但其将需要将游戏设计为支持 “3D DVR”能力。使用延迟缓冲器1515的“DVR”能力将连同任何游戏或应用程序(当然，限 于在使用游戏或应用程序时所产生的视频)一起起作用，但在具有3D DVR能力的游戏的状 况下，用户可控制先前所播放的片段的3D “飞越(fly-through) ”，且使延迟缓冲器1515记 录所得视频并记录游戏片段的游戏状态。因此，将特定“飞越”记录为经压缩的视频，但因 为也将记录游戏状态，所以不同的飞越将可能在游戏的同一片段的稍后日期。如下所述，主机服务210上的用户将各自具有一个用户页面，在该用户页面中，用 户可公布关于其本身的信息及其他数据。用户将能够公布的事情之一为来自其已保存的游 戏播放的视频片段。举例而言，若用户已克服游戏中的特别困难的挑战，则用户可刚好“回 倒”到其在游戏中获得其大成果的地点之前，且接着指导主机服务210将某一持续时间(例 如，30秒)的视频片段保存在用户的用户页面上以供其他用户观看。为了实施这些，用户正 使用的应用程序/游戏服务器1521-1525仅要做的事情是将储存于延迟缓冲器1515中的 视频回放至RAID阵列1511-1512且接着在用户的用户页面上给所述视频片段编索引。若游戏具有3D DVR的能力，如上所述，则也可由用户来记录3D DVR所需的游戏状 态信息且使其为用户的用户页面可用。在游戏经设计为除具有活跃玩家外还具有“旁观者”(也即，能够在不参与的情况 下在3D世界行进并观察到动作的用户)的情况下，则游戏取景器应用程序将使用户能够作 为旁观者以及玩家加入游戏。从观看的实施点看，对于主机系统210而言，用户是旁观者而 不是活跃玩家是不存在差异的。将游戏载入应用程序/游戏服务器1521-1525上且用户将 控制该游戏(例如，控制观看世界的虚拟相机)。唯一的差异是用户的游戏体验。多个用户合作主机服务210的另一特征是多个用户在观看现场直播的视频的同时合作的能力 (即使使用迥然不同的设备来观看也如此)。当玩游戏时及当使用应用程序时，这都有用。许多PC及移动电话装备有视频相机且具有进行实时视频压缩的能力(尤其当图 像小时)。而且，小相机是可用的，可附接到电视，且以软件或使用用于压缩视频的许多硬件 压缩设备中的一者来实施实时压缩并不困难。而且，许多PC及所有移动电话具有麦克风， 且耳机在具有麦克风情况下可用。组合有本地视频/音频压缩能力(具体来说，使用本文中所描述的低延时视频压缩技术)的所述相机和/或麦克风将使用户能够将视频和/或音频连同输入设备控制数据 一起从用户场所211传输到主机服务210。当使用所述技术时，则可实现图19中所说明的 能力用户可使其视频及音频1900出现在另一用户的游戏或应用程序内的屏幕上。该实例 为多人游戏，其中队友在赛车中合作。用户的视频/音频仅可被其队友选择性地观看/听 到。此外，因为使用上文所描述的技术将有效地不存在延时，所以玩家将能够实时地彼此谈 话或进行运动而没有可感知的延迟。该视频/音频整合是通过使来自用户的相机/麦克风的经压缩视频和/或音频作 为入埠互联网通信1501到达而完成。接着，入埠路由1502将该视频和/或音频路由到被 准许观看/听到视频和/或音频的应用程序/游戏服务器1521-1525。接着，选择使用视频 和/或音频的各别应用程序/游戏服务器1521-1525的用户解压缩视频和/或音频且视需 要而将其整合以出现于游戏或应用程序内，诸如通过1900所说明的。图19的实例显示如何在游戏中使用该合作，但该合作可为用于应用程序的极其 强大的工具。考虑一各情形其中一大建筑物正由在芝加哥的建筑师为以纽约为基地的房 地产开发商为纽约市设计，但该决策涉及在旅游中且碰巧在迈阿密机场的财务投资者，且 需要进行关于建筑物的特定设计要素(在其如何搭配其附近的建筑物方面)的决策，以满 足投资者与房地产开发商两者。假定建筑公司在芝加哥具有具有附接到PC的相机的高分 辨率监视器，房地产开发商在纽约具有带相机的笔记本计算机，且投资者在迈阿密具有带 相机的移动电话。建筑公司可使用主机服务210来对能够进行高度逼真3D再现的强大的 建筑设计应用程序进行主机代管，且其可利用纽约市的建筑物的大数据库，以及正设计的 建筑物的数据库。建筑设计应用程序将在应用程序/游戏服务器1521-1525中的一者上 (或若其需要大量计算能力，则在若干者上)执行。处于全异(disparate)位置处的3个用 户中的每一者将连接至主机服务210，且每一者将具有对建筑设计应用程序的视频输出的 同时观看，但其将被针对每个用户具有的给定设备及网络连接特性而由共用硬件压缩1530 适当地设定大小(例如，建筑公司可经由20Mbps商用互联网连接看见2560X 144060fps显 示，纽约的房地产开发商可经由其笔记本计算机上的6Mbps DSL连接看见1280X72060fps 图像，且投资者可经由其移动电话上的250Kbps蜂窝式数据连接看见320X 18060fps图 像)。每一方将听到其他方的语音(将通过应用程序/游戏服务器1521-1525中的许多 广泛可用的会议呼叫套装软件中的任一者来处理会议呼叫)，且经由用户输入设备上的按 钮的致动，用户将能够使用其本地相机使视频出现。随着会议进行，建筑师将能够通过极 具照片般逼真感的3D再现显示当其使建筑物旋转且使其邻接该区域中的另一建筑物飞越 (fly-by)时建筑物看起来像什么，且所有方均将在各方的显示设备的分辨率下可见到相同 视频。由任何方使用的本地设备中的任一者均能够以该真实感处理3D动画不是问题，更不 用说下载或甚至储存再现纽约市的周围建筑物所需的巨大数据库。自用户中的每一者的观 点看，尽管距离很远，且尽管是全异本地设备，但其将简单地在难以置信的真实感程度下具 有无缝体验。此外，当一方希望其面部被看来较佳地传达其情绪状态时，其可如此进行。另 外，若房地产开发商或投资者希望控制建筑程序且使用其自身的输入设备(其为键盘、鼠 标、小键盘或触摸屏幕)，则其可如此，且其可以用无感知的延时来响应(假定其网络连接 不具有不合理的延时)。举例而言，在移动电话的状况下，若移动电话连接至机场的WiFi网 络，则其将具有非常低的延时。但若其使用美国现今可用的蜂窝式数据网络，则其很可能将遭受引人注意的滞后。但是，对于会议的大多数目的(其中投资者正观看建筑师控制建筑 物飞越或正谈论视频电话会议)，甚至蜂窝式延时也应是可接受的。最后，在合作性会议呼叫结束时，房地产开发商及投资者将进行其评论且从主机 服务停播，建筑公司将能够“回倒”已记录在延迟缓冲器1515上的会议的视频且核查在会 议期间进行的应用于建筑物的3D模型的评论、面部表情和/或动作。若存在其希望保存的 特定片段，则可将视频/音频的所述片段自延迟缓冲器1515移动至RAID阵列1511-1512 以用于档案储存及稍后回放。而且，从成本观点看，若建筑师仅需要使用纽约市的计算能力及大数据库历时15 分钟的会议呼叫，则其仅需要支付所述资源被使用的时间的费用，而不必拥有高能力的工 作台且不必购买大数据库的昂贵复本。视频丰富的社区服务主机服务210使得有空前机会来在互联网上建立视频丰富的社区服务。图20显 示用于主机服务210上的游戏玩家的例示性用户页面。如同游戏取景器应用程序一样，用 户页面为在应用程序/游戏服务器1521-1525中的一者上执行的应用程序。该页面上的所 有缩略图及视频窗显示恒定地移动的视频(若片段短，则其循环)。使用视频相机或通过上传视频，用户(其用户名为“KILLHAZARD”)能够公布其本 身的视频2000 (其他用户可观看该视频)。该视频储存于RAID阵列1511-1512上。而且， 当其他用户来到KILLHAZARD的用户页面时，若KILLHAZARD此时正使用主机服务210，则将 显示其正进行的无论什么的现场直播的视频2001 (假定KILLHAZARD准许观看其用户页面 的用户观看该视频)。这将由对用户页面应用程序进行主机代管的应用程序/游戏服务器 1521-1525从服务控制系统401请求KILLHAZARD是否为活跃的(且若如此，则请求其正使 用的应用程序/游戏服务器1521-1525)来完成。接着，使用由游戏取景器应用程序使用的 相同方法，将合适分辨率及格式的经压缩的视频流发送至执行用户页面应用程序的应用程 序/游戏服务器1521-1525且将其显示。若用户选择具有KILLHAZARD的现场直播的游戏 播放的窗口且接着适当地单击其输入设备，则该窗口将放大(再次使用与游戏取景器应用 程序相同的方法)，且现场直播的视频将以观看用户的显示设备422的分辨率(适合于观看 用户的互联网连接的特性)填充屏幕。这优于先前技术方法的关键优点是观看用户页面的用户能够看见用户不拥有的 现场直播地播放的游戏，且可不具有能够玩该游戏的本地计算机或游戏控制台。其为用户 提供看用户页面中显示为“活动中”的用户玩游戏的极好机会，且这是了解观看用户可能希 望尝试或较擅长的游戏的机会。来自KILLHAZARD的搭档2002的相机记录的或上传的视频剪辑也显示于用户页面 上，且每个视频剪辑的下方为指示该搭档是否在线玩游戏的文字(例如，six shot正玩游 戏“龙骑士(Eragon)”且MrSnUggleS99离线等)。通过单击菜单项(未图示)，搭档视频 剪辑自显示已记录的或上传的视频切换至当前正玩主机服务210上的游戏的搭档在所述 时刻在其游戏中正在进行的内容的现场直播的视频。因此，其变成为搭档分群的游戏取景 器。若选择搭档的游戏且用户单击该游戏，则该游戏将放大至全屏幕，且用户将能够观看全 屏幕现场直播地播放的游戏。再次，观看搭档的游戏的用户不拥有游戏的复本，也不拥有用于玩该游戏的本地
51计算/游戏控制台资源。游戏观看是有效瞬时的。如上文先前所描述，当用户玩主机服务210上的游戏时，用户能够“回倒”游戏且 发现其希望保存的视频片段，且接着将该视频片段保存到其用户页面。这被称为“自赏剪 辑(Brag Clip)”。视频片段2003都是由KILLHAZARD从其所玩的先前游戏保存的自赏剪 辑2003。数字2004显示自赏剪辑已被观看多少次，及自赏剪辑何时被观看，用户具有对其 评定等级的机会，且橙色钥匙孔形状的图示2005的数目指示等级是多高。当用户观看用户 页面时，自赏剪辑2003连同页面上的其余视频一起恒定地循环。若用户选择并单击自赏剪 辑2003中的一者，则其放大以呈现自赏剪辑2003，以及允许播放、暂停、回倒、快进、步进等 该剪辑的DVR控制。自赏剪辑2003回放是通过应用程序/游戏服务器1521-1525载入用户记录自赏 剪辑时储存于RAID阵列1511-1512上的经压缩视频片段且将其解压缩并将其回放来实施。自赏剪辑2003也可为来自支持3D DVR能力的游戏的“3D DVR”视频片段(也即， 来自可被重放且允许用户改变相机观看点的游戏的游戏状态序列)。在此状况下，除用户 在记录游戏片段时进行的特定“飞越”的经压缩视频记录之外，也储存游戏状态信息。当用 户页面正被观看且所有缩略图及视频窗均恒定地循环时，3D DVR自赏剪辑2003将使在用 户记录游戏片段的“飞越”时记录为经压缩视频的自赏剪辑2003恒定地循环。但是，当用 户选择3D DVR自赏剪辑2003并单击3D DVR自赏剪辑2003时，除允许播放经压缩视频自 赏剪辑的DVR控制之外，用户将能够单击给出其用于游戏片段的3D DVR能力的按钮。其将 能够独立地控制游戏片段期间的相机“飞越”，且若其希望(且拥有用户页面的用户允许如 此)，则其将能够以经压缩的视频的形式记录替代性自赏剪辑“飞越”，替代性自赏剪辑“飞 越”将接着可为用户页面的其他观看者所用(立即地，或者在用户页面的拥有者具有核查自 赏剪辑的机会之后)。该3D DVR自赏剪辑2003能力是通过启动将要在另一应用程序/游戏服务器 1521-1525上重放已记录的游戏状态信息的游戏来启用。因为游戏可被几乎瞬时地启动 (如先前所描述)，所以启动其(其播放限于由自赏剪辑片段记录的游戏状态)且接着允许 用户在将经压缩视频记录到延迟缓冲器1515的同时用相机进行“飞越”并不困难。一旦用 户完成进行“飞越”，则将游戏撤销启动。从用户的观点看，启动具有3D DVR自赏剪辑2003的“飞越”并不比控制线性自赏 剪辑2003的DVR控制难。用户可不知道该游戏或甚至不知道如何玩该游戏。用户指示盯 着看另一操作者记录的游戏片段期间的3D世界的虚拟相机操作者。用户将也能够将其自身的音频加录于自赏剪辑上(或者自麦克风记录或者上 传)。以这种方式，可使用自赏剪辑来使用来自游戏的人物及动作产生定制动画。此动画制 作技术通常被称为“游戏电影(machinima) ”。随着用户在游戏中进展，其将达成不同技能级别。所播放的游戏将成果报告给服 务控制系统401，且所述技能级别也将显示于用户页面上。互动式动画广告在线广告已自文字转变至静态图像、视频，且现在转变至互动式片段，通常使用如 Adobe Flash的动画精简型客户端来实施。使用动画精简型客户端的原因在于用户通常 对于因向其推销产品或服务的特权而被延迟较无耐心。而且，精简型客户端在非常低性能的PC上执行，且因此广告商可具有高度信心互动式广告将适当地工作。很遗憾地，诸如 Adobe Flash的动画精简型客户端在互动性的程度及体验(以减少下载时间)的持续时间 上受限制。图21说明一个互动式广告，其中用户将在汽车在陈列室中旋转时选择汽车的外 部及内部色彩，同时实时射线追踪显示汽车看起来如何。接着用户选择角色来驾驶汽车，且 接着用户可采用该汽车来用于在竞赛轨道上或者穿过诸如摩纳哥的外国场所驾驶。用户 可选择较大引擎或较佳轮胎，且接着可看见改变的配置如何影响汽车加速或保持稳定的能 力。当然，广告有效地的为尖端的3D视频游戏。但对于可在PC或视频游戏控制台上播 放的这种广告，其将需要可能100MB下载，且在PC的状况下，其可能需要安装特殊驱动器， 且可能在PC缺乏足够CPU或GPU计算能力时根本不执行。因此，所述广告在先前技术配置 中不切实际。在主机服务210中，所述广告几乎即刻地投放，且较佳地执行，无论用户的客户端 415能力如何。因此，其比精简型客户端互动式广告更迅速地投放，体验上更加丰富，且高度可靠。实时动画期间流动的几何形状RAID阵列1511-1512及入埠路由1502可提供如此快的数据速率且具有如此低的 延时，以致有可能设计依赖于RAID阵列1511-1512及入埠路由1502来在实时动画(例如， 具有复杂数据库的飞越)期间于游戏播放的中间或应用程序中可靠地直接传送几何形状 的视频游戏及应用程序。在先前技术的系统(诸如，图1中所显示的视频游戏系统)下，可用的大量储存设 备(尤其是在实用的家庭设备中)极缓慢以致不能在游戏播放期间流动几何形状(除了所 需的几何形状稍微可预测的情形之外)。举例而言，在存在指定道路的驾驶游戏中，可合理 地适当预测用于进入视野内的建筑物的几何形状且大量储存设备可提前搜寻即将到来的 几何形状所定位的位置。但在具有不可预测的改变的复杂场景中(例如，在周围具有复杂人物的战役场景 中)，若PC或视频游戏系统上的RAM完全被填满用于当前在视图中的对象的几何形状，且接 着用户突然将其人物转向以观看其人物之后是什么，若未将几何形状预先载入RAM中，则 可能在可显示几何形状之前存在延迟。在主机服务210中，RAID阵列1511-1512可以超过超高速以太网速度的速度使数 据流动，且在SAN网络下，有可能达到优于10个十亿比特以太网或优于其他网络技术的100 亿比特/秒的速度。100亿比特/秒将在小于一秒内载入十亿字节的数据。在60fps帧时 间(16. 67毫秒)内，可载入约170百万比特(21MB)的数据。当然，甚至在RAID配置中，旋 转媒体也仍将导致大于一帧时间的延时，但以闪存为基础的RAID储存器最终将与旋转媒 体RAID阵列一般大且将不会招致该高延时。在一各实施例中，使用经由大量RAM写入的高 速缓存来提供非常低延时的存取。因此，在足够高的网络速度，以及足够低延时的大量储存器下，可与CPU和/或GPU 可处理3D数据一般快地将几何形状流动到应用程序/游戏服务器1521-1525中。因此，在 先前所给出的实例中，其中用户突然将其人物转向且向后看，可在人物完成旋转之前载入其身后的所有人物的几何形状，且因此，对于用户而言，将看来似乎其处于与现场直播的动 作一般真实的照片般逼真的世界中。如先前所论述，照片般逼真的计算机动画中的最后的边界中的一者是人脸，且由 于人眼对于不完全性的敏感性，来自照片般逼真的面部的最轻微错误可导致来自观看者的 负面反应。图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 theexpression of a performer，，；2005 年 2 月 25 日申请的第 11/066，954 号“Apparatusand method for improving marker identification within a motion capturesystem，，;2005年 3 月 10 日申请的第 11/077，628 号"Apparatus and method forperforming motion capture using shutter synchronization，，；2005 年 10 月 20 El 串 i青白勺第 11/255, 854 ^ "Apparatus and method for performing motion captureusing a random pattern on capture surfaces，，;2006 年 6 月 7 日申请的第 11/449，131 号“System and method for performing motion capture usingphosphor application techniques"； 2006 ^ 6 7 H ^itWH 11/449, 043 ^-"System and method for performing motion capture by strobing a f luorescentlamp" ；2006 年6 月 7 日申请的第 11/449，127 号"System and method for threedimensional capture of stop-motion animated characters”，上述申请中的每一者都被转让给本CIP申请的受让人)捕获的现场直播的表 演如何导致非常平滑的捕获表面，既而达成高多边形计数的追踪表面(也即，多边形运动 精确地追随面部的运动)。最后，当将现场直播的表演的视频映射于追踪表面上以产生纹理 表面时，产生照片般逼真的结果。尽管当前GPU技术能够再现追踪表面及纹理中的许多多边形且实时地照明该表 面，但若多边形及纹理每一帧时间改变(其将产生最具照片般逼真感的结果)，则其将迅速 地消耗现代PC或视频游戏控制台的所有可用RAM。使用上文所描述的流动几何形状技术，将几何形状不断地馈送至应用程序/游戏 服务器1521-1525中以使得其可不断地动画制作照片般逼真的面部从而允许产生具有几 乎不能区别于现场直播的动作面部的面部的视频游戏变得实际。线性内容与互动式特征的整合电影、电视节目及音频材料(统称“线性内容”)广泛地以许多形式可用于家庭及 办公室用户。线性内容可在如⑶、DVD、HD-DVD及蓝光媒体的实体媒体上获取。其也可通过 来自卫星及电缆TV广播的DVR来记录。此外，其可以经由卫星及电缆TV的即付即看(PPV) 内容及以电缆TV上的视频点播(VOD)可用。日益增加的线性内容可经由互联网以下载的内容及流动内容可用。现今，确实不 存在一个能体验与线性媒体相关的所有特征的位置。举例而言，DVD及其他视频光学媒体 通常具有在其他位置处不可用的互动式特征(如导演的评论、“花絮”短片等)。在线音乐 站点具有通常在CD上不可用的封面艺术及歌曲信息，但并非所有CD在线可用。且与电视 节目相关联的网站常常具有额外特征、博客及有时来自演员或创作人员的评论。另外，在许多电影或运动事件的情况下，通常有经常连同线性媒体一起发行(在 电影的状况下)或(在运动的状况下)可以被紧密地联系到真实世界事件(例如，玩家的
54交易)的视频游戏。主机服务210非常适合于在将全异形式的相关内容连结在一起时传送线性内容。 的确，传送电影不如传送高度互动式视频游戏有挑战，且主机服务210能够将线性内容传 送至家庭或办公室中的多种设备，或传送至移动设备。图23显示用于主机服务210的例示 性用户接口页面，其显示线性内容的选择。但是，不同于大多数线性内容传送系统，主机服务210还能够传送相关的互动式 成份(例如，DVD上的菜单及特征、HD-DVD上的互动式叠加层，及网站上的Adobe Flash动 画(如下文所述))。因此，客户端设备415限制不再引入哪些特征可用的限制。另外，主机代管系统210能够动态且实时地将线性内容与视频游戏内容连结在一 起。举例而言，若用户正观看哈利波特电影中的Quidditch(魁地奇)比赛，且决定其愿意 尝试玩Quidditch，则其可仅仅单击按钮且电影将暂停且其将被立即输送到哈利波特视频 游戏的Quidditch片段。在玩Quidditch比赛的后，另一次单击按钮，且电影将即刻重新开 始。在照片般逼真的图形及制作技术的情况下，其中摄影捕获的视频不能区别于现场 直播的动作人物，当用户进行自现场直播的动作电影中的Quidditch游戏至主机服务上的 视频游戏中的Quidditch游戏的转变时(如本文中所述)，该两个场景实际上不能区别。此 为线性内容与互动式(例如，视频游戏)内容两者的导演提供全新的创作选项，因为该两个 世界之间的线变得不能区别。利用图14中所显示的主机服务架构，可将3D电影中的虚拟相机的控制提供给观 看者。举例而言，在发生于列车内的场景中，将有可能允许观看者在故事进展时控制虚拟相 机且环顾列车。此假定列车中的所有3D对象(“资产”)以及能够实时地再现所述场景以 及原始电影的足够计算能力水平可用。且甚至对于非计算机产生的娱乐，存在可提供的非常刺激的互动式特征。举例而 言，2005电影“傲慢与偏见”具有装饰华丽的旧英国大厦中的许多场景。对于特定大厦场景， 用户可将视频暂停且接着控制相机以巡视大厦，或可能的周围区域。为了实施这些，可携 带具有鱼眼镜头的相机穿过大厦，当其追踪其位置时，非常类似于实施先前技术Apple (苹 果)公司的QuickTimeVR。各种帧接着将被转换，因此图像不失真，且接着其连同电影一起 被储存于RAID阵列1511-1512上，且在用户选择继续虚拟巡视时被回放。在运动事件的情况下，可经由主机服务210来使现场直播的运动事件(诸如，篮球 比赛)流动以供用户观看(如同其对于常见TV所想要的那样)。在用户观看特定播放之 后，游戏的视频游戏(最终篮球玩家看起来与真实玩家一般照片般逼真)可赶上在同一位 置中开始的玩家，且用户(可能各自控制一玩家)可重新玩以观看其是否可比所述玩家做 得更佳。本文中所描述的主机服务210极其适合于支持此未来世界，因为其能够承受不切 实际以致不能安装于家庭中或大多数办公室背景中的计算能力及大容量储存资源，而且其 计算资源总是最新的(在可用的最新的计算硬件的情况下)，但是在家庭背景中，将总是存 在具有较旧代的PC及视频游戏的家庭。此外，在主机服务210中，用户被隐瞒所有此计算 复杂度，因此，即使用户可能正使用非常尖端的系统，自用户的观点看，也如改变电视上的 信道一般简单。另外，用户将能够存取所有计算能力及计算能力将自任何客户端415带来的体验。多人游戏对于游戏为多人游戏的程度，则游戏将能够不仅经由入埠路由1502网络传达到 应用程序/游戏服务器1521-1525，而且通过网络桥接器传达至具有不在主机服务210中 执行的服务器或游戏机器的互联网(未图示)。当通过通用互联网上的计算机玩多人游戏 时，则应用程序/游戏服务器1521-1525将具有极快访问互联网的益处(与游戏在家庭中 的服务器上执行的情况相比)，但其将受在较缓慢连接上玩游戏的其他计算机的能力限制， 且也潜在地受互联网上的游戏服务器被设计以适应最少共同点(common denominator)(所 述游戏服务器是相对较慢的消费者互联网连接上的家庭计算机)的事实限制。但当完全在主机服务210服务器中心内玩多人游戏时，则可达到极大差异。对用 于用户的游戏进行主机代管的每个应用程序/游戏服务器1521-1525将与其他应用程序/ 游戏服务器1521-1525以及用极高速度、极低延时连接性及巨大、非常快的储存阵列对针 对多人游戏的中央控制进行主机代管的任何服务器互连。举例而言，若超高速以太网用于 入埠路由1502网络，则应用程序/游戏服务器1521-1525将在彼此当中传达，且传达到以 十亿比特/秒速度在潜在的仅1毫秒或1毫秒以下的延时下对针对多人游戏的中央控制进 行主机代管的任何服务器。另外，RAID阵列1511-1512将能够非常快速地响应且接着以十 亿比特/秒速度传送数据。作为一个实例，若用户在外表及服装方面定制人物，以使得人物 具有对于人物而言唯一的大量几何形状及行为，在限于在家庭中在PC或游戏控制台上执 行的游戏客户端的先前技术系统下，若所述人物将进入另一用户的视野中，则用户将必须 等待直到长的缓慢下载完成为止，以便将所有几何形状及行为数据载入其计算机中。在主 机服务210内，所述相同下载可优于以十亿比特/秒速度从RAID阵列1511-1512服务的超 高速以太网。即使家庭用户具有8Mbps互联网连接(其根据现今的标准来看极快)，超高速 以太网也快100倍。因此，在快的互联网连接上花费一分钟进行的工作在超高速以太网上 将花费小于一秒。顶级玩家分群及锦标赛主机服务210极其适合于锦标赛。因为无游戏在本地客户端中执行，所以不存在 用户作弊的机会。而且，由于输出路由1540多播UDP流的能力，使得主机服务210能够同 时向观众中的数千人广播较大锦标赛。事实上，当存在如此风行以致数千名用户正接收相同流的特定视频流时(例 如，显示较大锦标赛的视图)，可以更有效的将视频流发送到内容传送网络(⑶N)(诸如， Akamai (阿卡迈公司)或Limelight (聚光灯公司))以用于大量分配到许多客户端设备 415。当使用CDN来显示顶级玩家分群的游戏取景器页面时，可获得类似水平的效率。对于较大锦标赛，可使用现场直播的名人解说员来在特定比赛期间提供评论。尽 管大量用户将是在观看较大锦标赛，且相对小数目将是在锦标赛中玩。可将来自名人解说 员的音频路由到对在锦标赛中玩的用户进行主机代管且对锦标赛中的游戏的任何旁观者 模式复本进行主机代管的应用程序/游戏服务器1521-1525，且可将音频加录于游戏音频 之上。可在游戏上(也可能刚好在旁观者视图上)叠加名人解说员的视频。网页载入的加速
全球信息网的主要传送协议、超文本传输协议(HTTP)是被构想并被限定在其中 仅商业具有高速互联网连接，且在线的消费者使用拨号数据机或ISDN的时代中。此时，用 于快速连接的“黄金标准”是Tl线，其对称地提供1. 5Mbps数据速率(也即，两个方向中具 有相等数据速率)。现今，情形完全不同。大量发达世界中经由DSL或电缆调制解调器连接的平均家 庭连接速度具有比Tl线高得多的下行数据速率。事实上，在世界的一些地方中，光纤到路 边(fiber-to-the-curb)正将高达50Mbps至IOOMbps的数据速率带入家庭。遗憾地，HTTP没有被架构(也没有被实施)成有效地利用该急剧的速度改善。网 站为远程服务器上的档案的集合。非常简单地说，HTTP请求第一档案，等待下载该档案，且 接着请求第二档案，等待下载该档案等。事实上，HTTP允许一个以上“开放连接”(也即，每 次请求一个以上档案)，但由于商定的标准(及防止网络服务器被超载的愿望)而使得仅准 许非常少的开放连接。此外，由于网页被构造的方式，浏览器常常未意识到可用于立即下载 的多个同时页面(也即，仅在剖析一个页面之后才变得显而易见需要下载如图像的新档 案)。因此，网站上的档案实质上是逐个地载入。此外，由于由HTTP使用的请求及响应协 议，存在与所载入的每个档案相关的大致(访问美国的典型网络服务器)100毫秒的延时。在相对低速连接的情况下，这不会引入大量问题，因为用于档案本身的下载时间 决定网页的等待时间。但是，随着连接速度增大(尤其是复杂网页情况下)，开始引起问题。在图24中所显示的实例中，显示了典型商业网站(该特定网站来自较大的运动鞋 商标)。网站上具有54个档案。档案包括HTML、CSS、JPEG、PHP、JavaScript及Flash档 案，且包括视频内容。在现场直播网页(也即，用户可单击该网页并开始使用该网页)之 前，必须载入总共1.5M字节。对于大量档案存在许多原因。首先，该网页为复杂且尖端的 网页，且其次，该网页为基于关于存取该页面的用户的信息动态地组合的网页(例如，用户 来自哪个国家，何种语言，用户之前是否进行购买等)，且视所有这些因素而下载不同档案。 但是，其仍为非常典型的商业网页。图24显示随着连接速度增大在现场直播网页之前经过的时间量。在1. 5Mbps连接 速度2401下，使用具有传统网络浏览器的传统网络服务器，在现场直播网页之前花费13. 5 秒。在12Mbps连接速度2402下，载入时间减少至6. 5秒，或约快一倍。但在96Mbps连接 速度2403下，载入时间仅减少至约5. 5秒。这个原因是因为在这种高下载速度下，下载档 案本身的时间最小，但每个档案各自大致100毫秒的延时仍保持，从而导致54个档案*100 毫秒=5. 4秒的延时。因此，无论到家庭的连接多快，该网站在现场直播之前将总是花费至 少5. 4秒。另一因素是服务器侧排队；每个HTTP请求是在队列的后部添加，因此在忙碌的 服务器上这将具有显著影响，因为对于要从网络服务器得到的每个小项目，HTTP请求需要 等待其返回。解决这些问题的一个方式是废弃或重新限定HTTP。或者，可能使网站拥有者较佳 地将其档案合并成单一档案(例如，以Adobe Flash格式)。但是，作为一个实际问题，该 公司以及许多他人在其网站架构中具有大量投资。另外，尽管一些家庭具有12-lOOMbps连 接，但大多数家庭仍具有较缓慢的速度，且HTTP在缓慢速度下确实工作良好。一个替代方法是在应用程序/游戏服务器1521-1525上对网络浏览器进行主机 代管，且在RAID阵列1511-1512上(或潜在地在对网络浏览器进行主机代管的应用程序/游戏服务器1521-1525上的RAM中或本地储存器上)对用于网络服务器的档案进行主机代 管。由于经由入埠路由1502 (或至本地储存器)的非常快的互连，并非在使用HTTP下每档 案具有100毫秒的延时，而是在使用HTTP下将存在每档案最小延时。接着，并非使家庭中 的用户经由HTTP存取网页，而是用户可经由客户端415存取网页。接着，甚至在1.5Mbps 连接下(因为此网页不需要大量带宽来用于其视频)，网页也将在每个线2400小于1秒的 时间内处于现场直播。实质上，在应用程序/游戏服务器1521-1525上执行的网络浏览器 显示现场直播的页面之前将不存在延时，且在客户端415显示来自网络浏览器的视频输出 之前将不存在可侦测到的延时。当用户使用鼠标搜寻网页和/或在网页上键入字时，将用 户的输入信息发送至在应用程序/游戏服务器1521-1525上执行的网络浏览器，且网络浏 览器将相应地作出响应。此方法的一个不利之处是若压缩器正恒定地传输视频数据，则使用带宽，即使网 页变成静态也如此。这可通过配置压缩器以仅在(并且如果)网页改变时才传输数据且接 着仅将数据传输到发生改变的页面部分来补救。当存在具有恒定地改变的闪烁标语等的一 些网页时，所述网页往往令人讨厌，且除非存在要移动某物(例如，视频剪辑)的原因，否 则通常网页为静态的。对于所述网页，可能为以下状况使用主机服务210将传输较少数 据(与传统网络服务器相比)，因为将仅传输实际显示的图像，没有精简型客户端可执行代 码，且没有可能从不被观看的大对象(诸如，滚动翻转图像)。因此，使用主机服务210来对旧版网页进行主机代管，可将网页载入时间减少到 打开网页是类似改变电视上的频道的程度有效地即刻地现场直播该网页。便于游戏及应用程序的除错如先前所述，具有实时图形的视频游戏及应用程序为非常复杂的应用程序且通常 当其被发行到该领域中时，其含有缺陷。尽管软件开发商将自用户得到关于缺陷的反馈，且 其可能具有用于在崩溃之后将机器状态传回的一些方式，但确切地识别是什么引起游戏或 实时应用程序崩溃或不适当地执行非常困难。当游戏或应用程序在主机服务210中执行时，将游戏或应用程序的视频/音频输 出恒定地记录在延迟缓冲器1515上。另外，看门狗进程执行每个应用程序/游戏服务器 1521-1525，该看门狗进程将向主机服务控制系统401定期地报告应用程序/游戏服务器 1521-1525正平稳地执行。若看门狗进程未能报告，则服务器控制系统401将试图与应用程 序/游戏服务器1521-1525通信，且若成功，则将收集可用的无论什么机器状态。将无论什 么可用的信息连同由延迟缓冲器1515记录的视频/音频一起发送到软件开发商。因此，当游戏或应用程序软件开发商自主机服务210得到崩溃的通知时，其得到 导致崩溃的原因的帧接帧的纪录。该信息在追踪到缺陷并将缺陷修复中可能是极具价值 的。还应该注意，当应用程序/游戏服务器1521-1525崩溃时，在最近的可重新启动的 时刻重新启动服务器，且将消息提供给用户，从而就技术困难道歉。资源共用及成本节省图4a及图4b中所显示的系统为终端用户与游戏及应用程序开发商两者提供多种 益处。举例而言，通常，家庭及办公室客户端系统(例如，PC或游戏控制台)仅在一周中的 小百分比的小时中处于使用中。根据由Nielsen(尼尔森)娱乐“Active Gamer BenchmarkStudy (活跃游戏者基准点研究)” (http://www. prnewswire. com/cgi-bin/stories, pi ？ ACCT = 104&ST0RY = /www/story/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及视频游戏控制台仅在一周的小部 分小时中被利用。值得注意地，因为许多人在非假日的周一至周五的日间小时期间在商业或在学校 工作，所以这些人通常在这些小时期间不玩视频游戏，且因此当其确实玩视频游戏时，其通 常是在其他小时期间(诸如，晚上、周末及假日)。给定图4a中所显示的主机服务的配置，则上述两段中所描述的使用模式导致资 源的非常有效的利用。显而易见，存在对于可在给定时间由主机服务210来服务的用户的 数目的限制，尤其在用户需要用于复杂应用程序(如尖端3D视频游戏)的实时响应性的情 况下。但是，不同于家庭中的视频游戏控制台或由商业使用的PC(其通常在大多数时间闲 置放置)，服务器402可由不同用户在不同时间重新利用。举例而言，具有高性能双CPU及 双GPU及大量RAM的高性能服务器402可由商业及学校在非假日的9AM至5PM利用，但由 玩尖端视频游戏的游戏者在晚上、周末及假日利用。类似地，低性能应用程序可由商业及学 校在商业小时期间在具有Celeron (赛扬)CPU、无GPU (或非常低端的GPU)及有限RAM的低 性能服务器402上利用且低性能游戏可在非商业小时期间利用低性能服务器402。另外，在本文中所描述的主机服务配置的情况下，资源是在数千名(若非数百万 名)用户当中有效地共用。一般而言，在线服务仅具有其总用户基础的小百分比在给定 时间使用服务。若考虑先前所列出的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%的硬件成本来支持给定用户玩性能游戏的给定级别。此外，假定一些游戏及应用程序需要比其他者多的计算能力，则可基于被用户玩 的游戏或由用户执行的应用程序来动态地分配资源。因此，选择低性能游戏或应用程序的 用户将被分配低性能(较低廉)服务器402，且选择高性能游戏或应用程序的用户将被分配 高性能(较昂贵)服务器402。实际上，给定游戏或应用程序可能具有游戏或应用程序的 较低性能及较高性能区，且可在游戏或应用程序的区之间将用户从一个服务器402切换到 另一服务器402，以保持用户在满足游戏或应用程序的需要的最低成本服务器402上执行。 注意，比单个磁盘快得多的RAID阵列405将可以被甚至低性能服务器402所用，这具有较 快磁盘传送速率的益处。因此，跨越所有所玩游戏或所使用的应用程序的每服务器402平 均成本比玩最高性能游戏或应用程序的大多数昂贵服务器402的成本小得多，然而，即使 低性能服务器402也会从RAID阵列405得到磁盘性能益处。另外，主机服务210中的服务器402可能只是不具有磁盘或周边接口(不同于网 络接口)的PC主机板，且恰好，可向下整合成刚好具有到SAN 403的快速网络接口的单个 芯片。而且，RAID阵列405可能将在比存在磁盘的情况多得多的用户当中共用，因此每个活 跃的用户的磁盘成本将远小于一个磁盘驱动器。所有该设备将可能驻留于环境上受控制的 服务器室环境中的支架中。若服务器402出故障，则其可容易地在主机服务210处进行修 理或替换。相比之下，家庭或办公室中的PC或游戏控制台必须坚固，必须能够幸免于合理 的磨损及撕裂以防被重击或降落的独立器具需要外壳，具有至少一个磁盘驱动器，必须幸 免于不利的环境条件(例如，被勉强塞入具有其他用具的过热AV橱柜中)，需要服务保证， 必须被封装及装运，且由可能收取零售利润的零售商来出售。另外，PC或游戏控制台必须 被配置以满足将在未来某一时刻使用的计算上最密集的预期游戏或应用程序的峰值性能， 即使较低性能游戏或应用程序(或游戏或应用程序的区)也可能在大多数时间玩。此外， 若PC或控制台出故障，则使其得到修理是昂贵且耗时的过程(不利地影响制造商、用户及 软件开发商)。因此，假定图4a中所显示的系统将相当于本地计算资源的体验的体验提供给用 户，以供用户在家庭、办公室或学校中体验给定水平的计算能力，则通过图4a中所显示的 架构提供所述计算能力要低廉得多。消除对升级的需要另外，用户不必再担忧将PC和/或控制台升级以玩新游戏或处理较高性能的新 应用程序。主机服务210上的任何游戏或应用程序(不管所述游戏或应用程序需要何类 型的服务器402)均可为用户所用，且所有游戏及应用程序接近即刻地执行(也即，快速地 从RAID阵列405或服务器402上的本地储存器载入)且适当地具有最新更新及缺陷修复 (也即，软件开发商将能够选择用于执行给定游戏或应用程序的服务器402的理想服务器 配置，且接着将服务器402配置有最佳驱动器，且接着随着时间的推移，开发商将能够同时 将更新、缺陷修复等提供给主机服务210中的游戏或应用程序的所有复本)。实际上，在用
60户开始使用主机服务210之后，用户可能发现游戏及应用程序继续提供较佳体验(例如，经 由更新和/或缺陷修复)且可能是以下状况用户一年后发现新游戏或应用程序可用于利 用计算技术(例如，较高性能的GPU)(其在一年前甚至不存在)的服务210上，因此对于用 户而言，将不可能购买将在一年后玩游戏或执行应用程序的一年前的技术。因为玩游戏或 执行应用程序的计算资源对于用户而言不可见(也即，自用户的观点看，用户仅选择开始 接近即刻地执行的游戏或应用程序_更像用户改变电视上的信道)，所以用户的硬件将在 用户甚至未意识到升级的情况下已被“升级”。消除对于备份的需要对于商业、学校及家庭中的用户的另一较大问题是备份。若磁盘出故障，或若存在 无意擦除，则储存在本地PC或视频游戏控制台中的信息(例如，在控制台的状况下，用户的 游戏成果及等级)可能丢失。存在提供用于PC的手动或自动备份的许多可用的应用程序， 且可将游戏控制台状态上传至在线服务器以供备份，但通常将本地备份复制至必须储存于 安全且有组织的某处的另一本地磁盘(或其他非挥发性储存设备)，且由于经由典型低成 本互联网连接可用的缓慢上行速度而使得对于在线服务的备份常常有限。在图4a的主机 服务210下，储存于RAID阵列405中的数据可使用为本领域技术人员所熟知的先前技术 RAID配置技术来配置，以使得当磁盘出故障时，将不丢失数据，且将通知在容纳出故障的磁 盘的服务器中心处的技术员，且接着技术员将替换该磁盘，该磁盘接着将被自动地更新以 使得RAID阵列再一次容忍故障。另外，因为所有磁盘驱动器彼此接近且其间具有经由SAN 403的快速本地网络，所以在服务器中心中将所有磁盘系统配置定期地备份到次级储存器 (其可储存于服务器中心处或者经易地重新定位)并不困难。从主机服务210的用户的观 点看，其数据始终完全安全，且其从不必考虑备份。对演示的存取用户经常希望在购买游戏或应用程序的前试用游戏或应用程序。如先前所述，存 在先前技术装置，通过该先前技术装置来演示(“演示”的动词形式意思是试用演示版本，演 示版本也被称为“演示”，但作为名词)游戏及应用程序，但其中的每一者遭受限制和/或不 便利。使用主机服务210，对于用户而言，容易且便于试用演示。实际上，用户所进行的系经 由用户接口(诸如，下文所描述的用户接口)选择演示且试用该演示。演示将几乎即刻地 载入适合于该演示的服务器402上，且其将完全类似任何其他游戏或应用程序而执行。无 论演示需要非常高性能的服务器402还是低性能的服务器402，且无论用户使用的家庭或 办公室客户端415是何类型，自用户的观点看，演示均将工作。游戏演示或应用程序演示的 软件出版商将能够确切地控制准许用户试用何演示及试用多长时间，且当然，演示可包括 为用户提供获得对所演示的游戏或应用程序的全版本的存取机会的用户接口要素。因为演示可能是低于成本价或免费提供，所以一些用户可能试图使用重复的演示 (尤其是重复地玩可能有趣的游戏演示)。主机服务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用户不值得费神去滥用演示系统，且相反，其在其意欲试用新游戏及应用程序时使用 演示。对学校、商业及其他机构的益处显著益处尤其出现在利用图4a中所显示的系统的商业、学校及其他机构。商业及 学校具有与安装、维护及升级PC相关联的实质成本，尤其当谈及执行诸如Maya的高性能应 用程序的PC时。如先前所陈述，PC通常仅在一周的小时的一部分中被利用，且如在家庭中， 具有给定水平的性能能力的PC在办公室或学校环境中的成本远高于在服务器中心环境中 的成本。在较大商业或学校(例如，大的大学)的状况下，所述实体的IT部门设置服务 器中心且维护经由LAN级连接而远程地存取的计算机可以是实际的。存在用于经由LAN 或经由办公室之间的私用高带宽连接而远程存取计算机的许多解决方法。举例而言， 通过Microsoft的Windows终端机服务器，或者通过虚拟网络计算应用程序(如来自 RealVNC (远程控制)有限公司的VNC或者通过来自Sun Microsystems (太阳计算机系统公 司)的精简型客户端装置，用户可获得对PC或服务器的远程存取，在图形响应时间及用户 体验中具有一定范围的质量。另外，所述自行管理的服务器中心通常专用于单个商业或学 校，且因此不能够利用在全异应用程序(例如，娱乐及商业应用程序)在一周的不同时间利 用同一计算资源时所可能的使用的重叠。因此，许多商业及学校缺乏独立设置具有至每一 用户的LAN速度的网络连接的服务器中心的规模、资源或专门技能。实际上，大百分比的学 校及商业具有与家庭相同的互联网连接(例如，DSL、电缆调制解调器)。然而，所述组织仍可能具有对于非常高性能的计算的需要(或者定期地或者周期 性地)。举例而言，小建筑公司可能仅具有小数目的建筑师，当进行设计工作时，具有相对适 度的计算需要，但其可能周期性地需要非常高性能的3D计算(例如，当建立用于客户端的 新建筑设计的3D飞越时)。图4a中所显示的系统极其适合于所述组织。所述组织仅需要 为提供至家庭的同一种类的网络连接(例如，DSL、电缆调制解调器)且通常非常低廉。其 可利用低廉的PC作为客户端415，或者完全没有PC也可以，而利用简单实施控制信号逻辑 413及低延时视频解压缩412的低廉的专用设备。该特征对于可能具有PC的偷窃或对PC 内的专用组件的损坏的问题的学校特别有吸引力。
这种配置解决了用于所述组织的许多问题(且许多这种优点也为进行通用计算 的家庭用户共用)。举例而言，操作成本(其最终必须以某种形式传递回至用户以便具有 可行的商业)可能低得多，因为(a)计算资源是与在一周中具有不同峰值使用时间的其他 应用程序共用，(b)所述组织可仅在需要时获得(且招致成本)对高性能计算资源的存取， (c)所述组织不必提供用于备份或以其他方式维护高性能计算资源的资源。盗版的消除另外，游戏、应用程序、互动式电影等可能不再如现今这样被盗版。因为游戏是在 服务器中心处执行，所以用户不具备对于基本程序码的存取，因此不存在盗版。即使用户将 要复制原始码，用户也不能够在标准游戏控制台或家庭计算机上执行该码。此打开了标准 视频游戏不可用的世界各地(诸如，中国)的市场。已使用的游戏的重新销售也是不可能 的。对于游戏开发商而言，如同现今的状况，存在较少市场不连续性。与全新的一代技 术迫使用户及开发商升级且游戏开发商取决于硬件平台的及时传送的当前情形对比，可随 着时间随着游戏要求改变而逐渐地更新主机服务210。流动互动式视频以上描述提供由以通用互联网为基础的低延时流动互动式视频(其隐含地也包 括连同视频一起的音频，如本文中所使用)的新颖基本概念致能的多种应用。经由互联网 而提供流动视频的先前技术系统仅具有可通过高延时互动实施的所致能的应用。举例而 言，用于线性视频的基本回放控制(例如，暂停、回倒、快进)在高延时下适当地工作，且有 可能在线性视频馈送当中进行选择。此外，如先前所陈述，一些视频游戏的性质允许其以高 延时来播放。但是，用于流动视频的先前技术方法的高延时(或低压缩比率)严重限制流 动视频的潜在应用或使其部署变窄到专门化的网络环境，且甚至在所述环境中，先前技术 也引入网络上的实质负担。本文中所描述的技术打开了在经由互联网的低延时流动互动式 视频下可能的多种应用的大门，尤其是经由消费者级互联网连接而致能的所述应用。实际上，在与图4c的客户端465 —般小的客户端设备下，足以通过有效的任意量 的计算能力、任意量的快速储存及强大服务器之间的极快网络连接而提供增强的用户体 验，其使新的计算时代成为可能。另外，因为带宽要求并不随着系统的计算能力增长而增长 (也即，因为带宽要求仅关于显示分辨率、质量及帧速率)，所以一旦宽带互联网连接性是 普遍存在的(例如，经由分布广的低延时无线涵盖)、可靠的且具有足以满足所有用户的显 示设备422的需要的足够高的带宽，则问题将是典型消费者及商业应用所必要的是厚重客 户端(诸如，执行Windows、Linux、OSX等的PC或移动电话)还是甚至精简型客户端(诸 如，Adobe Flash 或 Java)。流动互动式视频的出现导致关于计算架构的结构的假定的重新考虑。该一个实例 是图15中所显示的主机服务210服务器中心实施例。用于延迟缓冲G器和/或分群视频 1550的视频路径是反馈回路，其中应用程序/游戏服务器1521-1525的经多播的流动互动 式视频输出经由路径1552而实时地或者经由路径1551在可选择的延迟之后被反馈回到应 用程序/游戏服务器1521-1525中。这使得通过先前技术服务器或本地计算架构将是不可 能或不可行的多种实际应用(例如，诸如图16、图17及图20中所说明的应用)成为可能。 但是，作为更一般的架构特征，反馈回路1550所提供的是流动互动式视频水平下的递归，
63因为可在应用程序需要视频时将视频无限地循环。这使得之前从未可用的多种应用可能性 成为可能。另一关键架构特征在于视频流是单向UDP流。这有效地实现流动互动式视频的 任意程度的多播(相比之下，诸如TCP/IP流的双向流将随着用户的数目增加而在来自来回 通信的网络上产生越来越多的通信停滞)。多播是服务器中心内的重要能力，因为其允许系 统对互联网用户(且实际上，世界的人口)的增长的需要作出响应以在一对多或甚至多对 多基础上通信。再次，本文中所论述的说明流动互动式视频递归与多播两者的使用的实例 (诸如，图16)仅为具有可能性的非常大的冰山的尖端。在一个实施例中，本文中所说明的各种功能模组及相关联的步骤可由含有用于执 行所述步骤的固线式逻辑的特定硬件组件(诸如，特殊用途集成电路(“ASIC”))或由被编 程的计算机组件与定制硬件组件的任何组合来执行。在一个实施例中，可将所述模组实施于诸如Texas仪器的TMS320x架构(例如， TMS320C6000, TMS320C5000,...等)的可编程数字信号处理器(“DSP”)上。可使用各种 不同的DSP，同时仍遵守所述基本原理。实施例可包括如上文所阐述的各种步骤。所述步骤可体现于引起通用或专用处理 器执行特定步骤的机器可执行指令中。已将与这些基本原理无关的各种元件(诸如，计算 机存储器、硬碟机、输入设备)从图中省去以避免混淆相关方面。所公开的标的物的要素也可作为用于储存机器可执行指令的机器可读媒体来提 供。机器可读媒体可包括(但不限于)闪存、光碟、CD-ROM、DVDROM、RAM、EPR0M、EEPR0M、磁 卡或光卡、传播媒体或适合于储存电子指令的其他类型的机器可读媒体。举例而言，本发明 可作为计算机程序来下载，该计算机程序可经由通信链路(例如，数据机或网络连接)借助 于体现在载波或其他传播媒体中的数据信号而从远程计算机(例如，服务器)传送到请求 计算机(例如，客户端)。还应理解，所公开的标的物的要素也可作为计算机程序产品来提供，该计算机程 序产品可包括在上面储存有指令的机器可读媒体，所述指令可用于程序化计算机(例如， 处理器或其他电子设备)以执行一序列操作。或者，所述操作可通过硬件与软件的组合来 执行。机器可读媒体可包括(但不限于)软盘、光盘、CD-ROM，及磁光盘、ROM、RAM、EPROM、 EEPR0M、磁卡或光卡、传播媒体或适合于储存电子指令的其他类型的媒体/机器可读媒体。 举例而言，所公开的标的物的要素可作为计算机程序产品来下载，其中程序可经由通信链 路(例如，数据机或网络连接)借助于体现于载波或其他传播媒体中的数据信号而自远程 计算机或电子设备传送至请求过程。另外，尽管已结合特定实施例描述所公开的标的物，但众多修改及变更将适当地 处于本公开的范畴内。因此，说明书及图式应视为说明性的而非限制性的意义。
6权利要求
一种方法，该方法包括将互联网线性视频与交互式视频内容一起组合成单个视频流；对所述单个视频流进行压缩；将压缩后的单个视频流以流动互动式视频的形式通过互联网发送至用户客户端设备。
全文摘要
一种方法，该方法包括将互联网线性视频与交互式视频内容一起组合成单个视频流，该单个视频流被压缩，并被以流动互动式视频的形式通过互联网发送至用户客户端设备。
文档编号H04N7/173GK101897183SQ200880119271
公开日2010年11月24日 申请日期2008年12月4日 优先权日2007年12月5日
发明者R·范德拉安, S·G·珀尔曼 申请人:生命力有限公司