用于使用选定的图像块和图像块旋转模式来编码视频的系统和方法.pdf

用于使用选定的图像块和图像块旋转模式来编码视频的系 统和方法
    相关申请 本申请要求 2009 年 3 月 23 日提交的题为 “System And Method For Compressing Video Using Feedback”美 国 临 时 专 利 申 请 No.61/210,888 的 优 先 权， 该 申 请 为 2009 年 1 月 23 日 提 交 的 题 为 “System And Method for Protecting Certain Types of Multimedia Data Transmitted Over A Communication Channel” 的共同待决的美国申 请 No.12/359,150 的 部 分 继 续 申 请， 并 为 2007 年 12 月 5 日 提 交 的 题 为 “Hosting And Broadcasting Virtual Events Using Streaming Interactive Video” 的共同待决的美 国申请 No.11/999,475 的继续申请， 该美国申请 No.11/999,475 为 2002 年 12 月 10 日提交 的、 题为 “Apparatus and Method for Wireless Video Gaming” 的、 第 10/315,460 号的部 分继续 (CIP) 申请， 该申请已转让给本 CIP 申请的受让人。
     技术领域
     本公开总体上涉及改善用户操作及存取音频和视频媒体的能力的数据处理系统 的领域。 背景技术 自从托马斯·爱迪生 (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)。同样地， 类似 TM TM Slingbox ( 视灵宝 ) 娱乐播放器的设备记录视频且使其经由家庭网络流动或经由互联网 流动而出， 其中可在 PC 上远程观看该视频。且互联网协议电视 (IPTV) 服务经由数字用户 线 (DSL) 或其他家庭互联网连接而提供类似电缆 TV 的服务。 近来还努力将多个媒体功能整 合到单个设备 ( 诸如， Moxi( 摩西 ) 媒体中心及执行 Windows XP 媒体中心版本的 PC) 中。 尽管所述设备中的每个设备对其执行的功能提供一点便利， 但每个设备缺乏对大多数媒体的普遍且简单的存取。另外， 常常由于昂贵的处理和 / 或本地储存的需要而使得所述设备 经常花费数百美元来制造。 另外， 所述现代的消费者电子设备通常消耗大量电力， 甚至当闲 置时也消耗大量电力， 这意谓着其随着时间而更加昂贵且浪费能源。 举例而言， 若消费者忘 记将设备切断或将其切换到不同视频输入端， 则该设备可能继续操作。 此外， 因为所述设备 当中没有一个设备为完全的解决方案， 所以必须将其与家庭中的其他设备的堆栈整合在一 起， 这仍对用户留下鼠窝式线及许多远程控制。
     此外， 当许多较新的以互联网为基础的设备适当地工作时， 其通常提供更一般形 式 ( 与其原本可能可用的形式相比 ) 的媒体。举例而言， 使视频经由互联网流动的设备常 常仅使视频材料流动， 而不能使常常伴随 DVD 的互动式 “额外项目” 流动， 如视频的 “制作” 、 游戏或导演评论。这是由于以下事实 ： 互动式材料经常是以特定格式制作， 该特定格式意 欲用于在本地处理互动性的特定设备。举例而言， DVD、 HD-DVD 及蓝光光碟中每一者具有其 自身的特定互动格式。任何家庭媒体设备或本地计算机 ( 其可能经开发以支持所有流行格 式 ) 将需要一定程度的尖端性 (sophistication) 及灵活性， 其将可能对于消费者操作而言 过于昂贵及复杂。
     使该问题加重， 若稍后在将来引入新格式， 则本地设备可能不具有支持新格式的 硬件能力， 这将意味着消费者将必须购买升级的本地媒体设备。 举例而言， 若在稍后的日期 引入较高分辨率的视频或立体视频 ( 例如， 每一只眼一个视频流 )， 则本地设备可能不具有 解码该视频的计算能力， 或其可能不具有用于以新格式输出该视频的硬件 ( 例如， 假定通 过与遮光眼镜 (shuttered glassess) 同步的 120fps 视频来实现立体视觉， 其中将 60fps 传送到每一只眼， 若消费者的视频硬件仅可支持 60fps 视频， 则该选项在缺乏升级的硬件 购买的情况下将不可用 )。
     当谈及尖端的互动式媒体 ( 尤其是视频游戏 ) 时， 媒体设备废弃及复杂度的问题 为严重问题。
     现代视频游戏应用基本上划分成四个主要非便携式式硬件平台： Sony PlayStation 1、 2 及 3(PS1、 PS2，及 PS3) ； Microsoft Xbox 及 Xbox360 ； 及 Nintendo TM Gamecube( 任天堂方糖 ) 及 Wii ； 以及以 PC 为基础的游戏。所述平台中的每一者不同于 其他者， 使得被编写以在一个平台上执行的游戏通常不会在另一平台上执行。也可能存在 一代设备与下一代设备的相容性问题。 即使大多数软件游戏开发者建立独立于特定平台而 设计的软件游戏， 为了在特定平台上执行特定游戏， 也需要专有软件层 ( 其经常被称为 “游 戏开发引擎」 ” ) 来调适游戏以在特定平台上使用。每一个平台以 “控制台” ( 也即， 附接到 TV 或监视器 / 扬声器的脱机盒 (standalone box)) 的形式出售给消费者或其本身为 PC。 通 常， 视频游戏在诸如蓝光 DVD、 DVD-ROM 或 CD-ROM 的光学媒体上出售， 该光学媒体含有体现 为尖端的实时软件应用程序的视频游戏。随着家庭宽带速度增加， 视频游戏正日益变得可 用于下载。
     由于高级视频游戏的实时性及高计算要求而使得实现与视频游戏软件的平台相 容性的特殊性要求极端苛刻。举例而言， 一个人可能期望从一代视频游戏到下一代视频游 戏 ( 例如， 自 XBox 至 XBox 360， 或自 Playstation 2(“PS2” ) 至 Playstation 3(“PS3” )) 的完全游戏相容性， 正如存在从一个 PC 到具有较快处理单元或核心的另一 PC 的生产力应 用程序 ( 例如， Microsoft Word( 微软文字处理软件 )) 的普遍相容性。然而， 对于视频游戏并非是这种状况。因为当发行一代视频游戏时， 视频游戏制造商通常寻求对于给定价格 点的最高可能性能， 所以经常对系统进行动态架构改变， 以使得被编写以用于前代系统的 许多游戏在稍后一代系统上不能工作。举例而言， XBox 基于 x86 系列处理器， 而 XBox 360 基于 PowerPC 系列。
     可利用技术来模仿先前架构， 但假定视频游戏为实时应用程序， 则在模仿中达成 完全相同的行为常常不切实际。这是对消费者、 视频游戏控制台制造商及视频游戏软件出 版商的损失。对于消费者而言， 这意味着将旧的一代视频游戏控制台与新的一代视频游戏 控制台两者保持接通到 TV 以便能够玩所有游戏的必要性。对于控制台制造商而言， 这意味 着与新控制台的模仿及较慢采用相关的成本。且对于出版商而言， 这意味着可能必须发行 新游戏的多个版本以便涵盖所有潜在的消费者 - 不仅发行用于视频游戏的每个商标 ( 例 如， XBox、 Playstation) 的版本， 而且常常发行用于给定商标的每个版本 ( 例如， PS2 及 PS3) 的版本。举例而言， 开发艺电有限公司 (Electronic Arts) 的 “疯狂橄榄球 08” 的单独版本 以用于 XBox、 XBox 360、 PS2、 PS3、 Gamecube、 Wii 及 PC 平台以及其他平台。
     便携式设备 ( 诸如， 移动电话及便携式媒体播放器 ) 也对游戏开发商提出挑战。 日 益增加地， 所述设备连接到无线数据网络且能够下载视频游戏。 但是， 市场中存在具有多种 不同显示分辨率及计算能力的多种移动电话及媒体设备。而且， 因为所述设备通常具有电 力消耗、 成本及重量约束， 所以其通常缺乏类似于图形处理单元 (“GPU” ) 的高级图形加速 硬件 ( 诸如， 由美国加州的圣克拉拉的 NVIDIA( 英伟达公司 ) 制造的设备 )。因此， 游戏软 件开发商通常开发同时用于许多不同类型的便携式设备的给定游戏标题。用户可发现 ： 给 定游戏标题不可用于其特定移动电话或便携式媒体播放器。 在家庭游戏控制台的状况下， 硬件平台制造商通常向软件游戏开发商收取用于在 其平台上发布游戏的能力的版税。 移动电话无线通信公司通常也向游戏出版商收取用于将 游戏下载到移动电话中的版税。在 PC 游戏的状况下， 不存在用于发布游戏所支付的版税， 但由于用于支持多种 PC 配置及可能引起的安装问题的较高消费者服务负担而使得游戏开 发商通常面临高成本。而且， PC 通常较少阻碍游戏软件的盗版， 因为其可很容易地由精通 技术的用户重新编程且游戏可更容易地被盗版且更容易地被分配 ( 例如， 经由互联网 )。 因 此， 对于软件游戏开发商而言， 在游戏控制台、 移动电话及 PC 上发行具有成本及不利之处。
     对于控制台及 PC 软件的游戏出版商而言， 成本不止于此。为了经由零售通道分配 游戏， 出版商向零售商收取低于出售价格的批发价格以使零售商具有利润率。出版商通常 也必须支付制造及分配保存游戏的物理媒体的成本。零售商经常也向出版商收取 “价格保 护费” 以涵盖可能的意外费用 ( 诸如， 游戏售不出， 或游戏的价格降低， 或零售商必须退还部 分或所有批发价格和 / 或从购买者收回游戏 )。 另外， 零售商通常也向出版商收取用于帮助 在广告传单中销售游戏的费用。 此外， 零售商日益增加地从已玩完游戏的用户购买回游戏， 且接着将所述游戏以使用过的游戏出售， 通常不与游戏出版商分享使用过的游戏的收入。 以下事实增加了施加给游戏出版商的成本负担 ： 游戏常常被经由互联网盗版及分配以供用 户下载及进行免费复制。
     随着互联网宽带速度增加且宽带连接性在美国及全世界变得更广泛 ( 更具体地， 到家庭和到租赁连接互联网的 PC 的 “网吧” )， 游戏被更多地经由下载而分配到 PC 或控制 台。而且， 宽带连接更多地用于玩多人及大型多人在线游戏 ( 该两者在本公开中由首字母
     缩写词 “MMOG” 来指代 )。这些改变减轻了与零售分配相关的一些成本及问题。下载在线游 戏解决了游戏出版商的一些不利之处， 因为分配成本通常较小且存在较少或不存在未出售 媒体的成本。但已下载的游戏仍被盗版， 且由于其大小 ( 大小常常为几十亿字节 ) 而使得 其可能花费非常长的时间来下载。 另外， 多个游戏可装满小磁盘驱动器， 例如连同便携式计 算机一起或连同视频游戏控制台一起出售的那些磁盘驱动器。然而， 就游戏或 MMOG 需要在 线连接以使得游戏可玩的程度而言， 盗版问题得以减轻， 因为通常需要用户具有有效的用 户帐户。 不同于可由相机拍摄显示屏幕的视频或由麦克风记录来自扬声器的音频来复制的 线性媒体 ( 例如， 视频及音乐 )， 每个视频游戏体验是唯一的， 且不可使用简单的视频 / 音 频记录来复制。因此， 甚至在未强力执行版权法且盗版猖獗的区域中， 也可保护 MMOG 免于 被盗版， 从而可支持商业。举例而言， 已成功地部署 Vivendi SA( 维旺迪公司 ) 的 “魔兽世 界” MMOG， 而在全世界未遭受盗版。且许多在线或 MMOG 游戏 ( 诸如， Linden Lab( 林登实验 室)的 “第二人生” MMOG) 通过建在游戏中的经济模型而产生游戏运营商的收入， 其中资产 可使用在线工具而带来、 出售且甚至建立。 因此， 可使用除传统游戏软件购买或订阅之外的 机制来为在线游戏的使用付费。
     尽管由于在线或 MMOG 的性质而使得常常可减轻盗版， 但在线游戏运营商仍面临 其余挑战。许多游戏需要大量的本地 ( 也即， 家庭内 ) 处理资源以供在线或 MMOG 适当地工 作。若用户具有低性能的本地计算机 ( 例如， 不具有 GPU 的计算机， 诸如低端笔记本计算 机 )， 则其可能不能够玩该游戏。另外， 随着游戏控制台老化， 其远落后于目前技术状态且 可能不能够处理更高级的游戏。即使假定用户的本地 PC 能够处理游戏的计算要求， 常常也 存在安装复杂度。可能存在驱动器不相容性 ( 例如， 若下载新游戏， 则可能安装新版本的图 形驱动器， 其致使依赖于旧版本图形驱动器的先前已安装的游戏不可操作 )。随着下载更 多游戏， 控制台可能用完本地磁盘空间。当发现缺陷并修复时或若对游戏进行了修改 ( 例 如， 若游戏开发商发现游戏的级别太难玩或太容易玩 )， 复杂游戏通常随着时间推移而从游 戏开发商接收下载的补丁 (patch)。该补丁需要新的下载。但有时并非所有用户完成所有 补丁的下载。在其他时候， 下载的补丁引入其他相容性或磁盘空间消耗问题。
     而且， 在游戏播放期间， 可能需要大数据下载以将图形或行为信息提供到本地 PC 或控制台。举例而言， 若用户进入 MMOG 中的一个房间中， 且遇到由图形数据组成或具有在 用户的本地机器上不可用的行为的场景或人物， 则必须下载那个场景或人物的数据。若互 联网连接不够快， 则此可导致玩游戏期间的实质延迟。 此外， 若所遇到的场景或人物需要超 过本地 PC 或控制台的储存空间或计算能力的储存空间或计算能力， 则其可产生下述情形 ： 其中用户不能在游戏中继续， 或必须以质量降低的图形继续。因此， 在线或 MMOG 游戏常常 限制其储存和 / 或计算复杂度要求。另外， 其常常限制游戏期间的数据传送的量。在线或 MMOG 游戏也可使可玩游戏的用户的市场变窄。
     此外， 精通技术的用户越来越多地对游戏的本地复本进行反向工程且修改游戏以 使得他们可以作弊。作弊可能与进行比用人力可能的速度快的重复按钮按压 ( 例如， 为了 非常快速地射击 ) 一样简单。在支持游戏中资产交易的游戏中， 作弊可达到导致欺骗性交 易涉及具有实际经济价值的资产的欺诈程度。当在线或 MMOG 经济模型基于所述资产交易 时， 这可导致对游戏运营商的实质有害后果。
     开发新游戏的成本随着 PC 及控制台能够制作越来越尖端的游戏 ( 例如， 具有更逼真的图形 ( 诸如， 实时光线追踪 )， 及更逼真的行为 ( 诸如， 实时物理学仿真 )) 而增长。在 视频游戏业的早期， 视频游戏开发是应用程序软件开发非常类似的过程 ； 也即， 大多数开发 成本在软件的开发中 ( 与图形、 音频及行为要素或 “资产” 的开发相对比 )， 诸如可被开发以 用于具有广泛特殊效果的电影的那些软件开发。现今， 许多尖端的视频游戏开发成果比软 件开发更类似于富有特效的电影开发。举例而言， 许多视频游戏提供 3-D 世界的仿真， 且产 生更加真实 ( 也即， 看似与摄影拍摄的实景 (live action) 图像一样逼真的计算机图形 ) 的人物、 道具及环境。照片一样逼真的游戏开发的最具挑战方面中的一者为创建不能区别 于实景人脸的计算机产生的人脸。面部捕获技术 ( 诸如， 由加州的圣弗朗西斯科的 Mova 开 TM TM 发的 Contour ( 轮廓 ) 真实性捕获系统 ) 捕获表演者的面部的精确几何形状并在表演者 处于运动中时以高分辨率追踪表演者的面部的精确几何形状。此技术允许在 PC 或游戏控 制台上再现 (render)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、 Sony Playstation 3 及 Nintendo Wii 计划在大约相同的大体时段引进。但在所述引进之前的数年中， 游戏开发商 实质上必须 “压注 (place bets)” 哪些控制台平台将比其他者更成功， 且相应地投入其开 发资源。电影制作公司也必须在电影发行之前很长时间基于其估计可能成功的电影而分 摊其有限的制作资源。给定视频游戏所需的投资的增长程度， 则游戏制作越加变得类似电 影制作， 且游戏制作公司常规上基于其对特定视频游戏的将来成功的估计而投入其制作资 源。 但是， 不同于电影公司， 此压注并非仅基于制作本身的成功 ； 而是， 其依据于游戏要在其 上执行的游戏控制台的成功。同时在多个控制台上发行游戏可减轻风险， 但此额外努力增 加成本， 且经常延迟游戏的实际发行。
     PC 上的应用程序软件及用户环境正变得更为计算上密集、 动态及互动， 不仅使其 在视觉上更吸引用户， 而且使其更有用及直观。举例而言， 新 Windows Vista( 视窗远景 )TM 操作系统与 Macintosh 操作系统的后续版本两者并入了视觉动画效应。 高级图形工具 ( 诸 TM TM 如， 来自 Autodesk( 欧特克 ) 公司的 Maya ( 玛雅 )) 提供非常尖端的 3D 再现及动画制作 能力 ( 其推动了目前技术状态的 CPU 及 GPU 的限制 )。然而， 这些新工具的计算要求对于所 述产品的用户及软件开发商而言产生了许多实际问题。
     因为操作系统 (OS) 的视觉显示必须在多种计算机 ( 包括不再出售但仍可随着新OS 而升级的前代计算机 ) 上工作， OS 图形要求在很大程度上受 OS 要用于的计算机 ( 其通 常包括不包括 GPU 的计算机 ) 的最少共同点限制。这严重地限制 OS 的图形能力。此外， 电 池供电的便携式计算机 ( 例如， 笔记本计算机 ) 限制视觉显示能力， 因为 CPU 或 GPU 中的高 计算活动通常导致较高电力消耗及较短电池寿命。便携式计算机通常包括在不利用处理 器时自动地减低处理器活动性以降低电力消耗的软件。在一些计算机型号中， 用户可手动 地减低处理器活动性。举例而言， Sony 的 VGN-SZ280P 笔记本计算机包括在一侧上标记为 “Stamina( 持久性 )” ( 用于低性能， 更长电池寿命 ) 且另一侧上标记为 “Speed( 速度 )” (用 于高性能， 较短电池寿命 ) 的交换器。在便携式计算机上执行的 OS 必须能够即使在计算机 以其峰值性能能力的一小部分执行的情况下也可用地起作用。因此， OS 图形性能常常保持 为远低于目前技术状态的可用计算能力。
     经常出售高端的计算上密集的应用程序 ( 如 Maya)， 期望所述应用程序将用于高 性能 PC 上。此通常产生高得多的性能， 及更昂贵且便携性较差、 最少共同点的要求。因此， 所述应用程序具有比通用 OS( 或通用生产力应用程序， 类似 Microsoft Office) 有限得多 的目标受众且通常以比通用 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 或视频游戏系统的视频输出 ( 例如， 到 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 、 Nintendo WiiTM、 以 Windows 为基础的个人计算机或 Apple Macintosh 的先前技术视频游戏系统。所述系统中 的每一者包括用于执行程序码的中央处理单元 (CPU)( 通常为用于执行高级图形操作的图 形处理单元 (GPU))， 及用于与外部设备及用户通信的多个形式的输入 / 输出 (I/O)。为简 单起见， 将所述组件显示为组合在一起为单个单元 100。 图 1 的先前技术视频游戏系统也显 示为包括光学媒体驱动器 104( 例如， DVD-ROM 驱动器 ) ； 用于储存视频游戏程序代码及数据 的硬盘驱动器 103 ； 用于播放多人游戏、 用于下载游戏、 补丁、 演示或其他媒体的网络连接105 ； 用于储存当前正由 CPU/GPU 100 执行的程序码的随机存取存储器 (RAM)101 ； 用于在游 戏播放期间接收来自用户的输入命令的游戏控制器 106 ； 及显示设备 102( 例如， SDTV/HDTV 或计算机监视器 )。
     图 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 游戏 )。组合起来， 销 售的损失及与新平台相关的增加的开发成本可对游戏开发商的收益性有非常显著的不利 影响。
     新游戏控制台也非常昂贵。Xbox 360、 Nintendo Wii 及 Sony Playstation 3 均 以数百美元零售。高能力的个人计算机游戏系统可花费高达 $8000。这表示用户的显著投 资， 具体来说， 考虑到硬件在几年后变陈旧及许多系统是为孩子而购买的事实。
     上述问题的一个方法是在线游戏， 其中将游戏程序代码及数据主机代管于服务器 上且按要求将其传送至客户端机器， 经压缩的视频及音频经由数字宽带网络而流动。一些 公司 ( 诸如， 芬兰的 G-Cluster(G- 群集公司 )， 其现在为日本的 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( 每秒帧数 )640×480 运动 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 帧 GOP。假设传输信道具有 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( 通常额定在 100Mbps-1Gbps) 及具有足够带宽的租用 线路通常可支持峰值带宽要求 ( 例如， 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 示出了在本发明一个实施例中使用的帧速率处理技术。
     图 10a 至图 10b 示出了将图像图像块有效地封装于分组内的一个实施例。
     图 11a 至图 11d 示出了使用前向纠错技术的实施例。
     图 12 示出了使用多核心处理单元来进行压缩的一个实施例。
     图 13a 至图 13b 示出了根据各种实施例的主机服务之间的地理定位及通信。
     图 14 示出了与客户端与主机服务之间的通信相关的示例性延时。
     图 15 示出了实例主机服务服务器中心架构。
     图 16 示出了包括多个现场直播的视频窗的用户接口的一个实施例的实例屏幕拍 摄。
     图 17 示出了在选择特定视频窗之后的图 16 的用户接口。
     图 18 示出了在将特定视频窗放大至全屏幕大小之后的图 17 的用户接口。
     图 19 示出了叠加在多人游戏的屏幕上的实例合作用户视频数据。
     图 20 示出了用于主机服务上的游戏玩家的实例用户页面。
     图 21 示出了实例 3D 互动式广告。
     图 22 示出了用于自现场直播的表演的表面捕获产生具有纹理表面的照片般逼真 的图像的实例步骤序列。
     图 23 示出了允许选择线性媒体内容的实例用户接口页面。
     图 24 为示出了在现场直播网页之前消逝的时间量与连接速度的曲线图。
     图 25a-b 示出了本发明的采用从客户端设备至主机服务的反馈信道的实施方式。
     图 26a-b 示出了一实施例， 其中基于最后已知的已成功接收的图像块 / 帧来对图 像块 / 帧进行编码。
     图 27a-b 示出了一实施例， 其中游戏或应用程序的状态被从第一主机服务或服务 器运送 (ported) 至第二主机服务或服务器。
     图 28 示出了一实施例， 其中通过使用差异数据来运送游戏或应用程序的状态。
     图 29 示出了本发明一实施例， 该实施例在客户端设备上采用临时解码器。
     图 30 示出了根据本发明一实施例的如何在 “R 帧” 之间散布 “I 图像块” 。
     图 31a-h 示出了本发明的生成直播流和 / 或一个或多个 HQ 流的实施例。 具体实施方式
     在以下描述中列举了特定细节 ( 诸如， 设备类型、 系统配置、 通信方法等 )， 以便提 供对本公开的彻底理解。 然而， 一般本领域的技术人员应了解， 实践所描述的所述实施例可 能不需要这些特定细节。
     图 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) 下以给定分辨率 ( 例如， 640×480@60fps) 维持给定质量水平所需的数据速率 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， 以较不频繁地存取几何形 状或游戏状态信息的大数据库。
     另外， 在一个实施例中， 主机服务 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.11g 无线接口。两种接口均能够在支持 NAT 的网络内使用 NAT。
     而且， 除具有用于输出视频及音频的 HDMI 连接器之外， 客户端 475 还具有双链接 DVI-I 连接器， 双链接 DVI-I 连接器包括模拟输出端 ( 且具有将提供 VGA 输出的标准适配器 电缆 )。其还具有用于复合视频及 S 视频的模拟输出端。
     对于音频， 客户端 475 具有左 / 右模拟立体 RCA 插孔， 且对于数字音频输出， 其具 有 TOSLINK( 光纤 ) 输出端。
     除了到输入设备 479 的蓝牙无线接口之外， 其还具有用于接口到输入设备的 USB 插孔。
     图 4e 显示客户端 465 的内部架构的一个实施例。该图中所显示的所有设备或一 些设备可实施在场可程序化逻辑阵列、 定制 ASIC 中或若干个离散设备 ( 定制设计或者现成 的 ) 中。
     具有 PoE 的以太网 497 附接到以太网接口 481。 电力 499 才具有 PoE 的以太网 497 得到且连接到客户端 465 中的其余设备。总线 480 为用于设备之间的通信的公同总线。
     执行来自闪存 476 的小客户端控制应用程序的控制 CPU 483( 几乎任何小 CPU 都 是适当的， 诸如具有嵌入式 RAM 的 100MHz 下的 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 Logic of Manly。使用 IP 的优点在于 ： 本文中所使 用的压缩技术与压缩标准不相符。 一些标准解压缩器足够灵活以经配置以适应本文中的压 缩技术， 但一些标准解压缩器可能并非如此。但是， 在 IP 的情况下， 在视需要而重新设计解 压缩器中存在完全灵活性。
     视频解压缩器的输出端耦合至视频输出子系统 487， 视频输出子系统 487 将视频 耦合至 HDMI 接口 490 的视频输出端。
     音频解压缩子系统 488 或者使用可用的标准音频解压缩器来实施， 或者其可实施 为 IP， 或者可在可 ( 例如 ) 实施 Vorbis 音频解压缩器 ( 可在 Vorbis.com 上找到 ) 的控制 处理器 483 内实施音频解压缩。
     实施音频解压缩的设备耦合到音频输出子系统 489， 音频输出子系统 489 将音频 耦合至 HDMI 接口 490 的音频输出端。图 4f 显示客户端 475 的内部架构的一个实施例。如可见， 除额外接口及来自插入 墙壁中的电源适配器的可选外部 DC 电力 ( 且若如此使用， 则可选外部 DC 电力替换将来自 以太网 PoE 497 的电力 ) 之外， 该架构与客户端 465 的架构相同。下文中将不重复与客户 端 465 共同的功能性， 但将额外功能性描述如下。
     CPU 483 与额外设备通信且配置额外设备。
     WiFi 子系统 482 经由其天线提供无线互联网存取， 作为对以太网 497 的替代。 WiFi 子系统可购自多家制造商， 包括美国加州的圣克拉拉的 Atheros Communications( 阿特赫 鲁斯通信公司 )。
     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 及电缆调制解调器连接， 该延时可在下一段中所描 述的情形中达成。 而且， 注意， 尽管至互联网的蜂窝式无线连接性的确将在所显示的系统中 工作， 但大多数当前美国蜂窝式数据系统 ( 诸如， EVDO) 招致非常高的延时且将不能够达成 图 4b 中所显示的延时。然而， 这些基本原理可在可能能够实施该水平的延时的未来蜂窝式 技术上实施。进一步地， 存在这样的游戏及应用程序实例 ( 例如， 不要求快速用户反应时间 的游戏， 诸如象棋 )， 其中通过当前 US 蜂窝数据系统所产生的延时虽然对于用户而言是显 而易见的， 但对于该游戏及应用程序而言是可接受的。
     自用户场所 211 处的输入设备 421 开始， 一旦用户致动输入设备 421， 就将用户控 制信号发送至客户端 415( 其可为诸如机顶盒的独立设备， 或其可为在诸如 PC 或行动设备 的另一设备中执行的软件或硬件 )， 且将其分组化 ( 在一个实施例中以 UDP 格式 ) 并为分组 给出目的地地址以到达主机服务 210。分组将也含有用于指示控制信号来自哪个用户的信 息。接着经由防火墙 / 路由器 /NAT( 网络地址转换 ) 设备 443 将控制信号分组转发到 WAN接口 442。WAN 接口 442 为由用户的 ISP( 互联网服务提供者 ) 提供到用户场所 211 的接口 设备。 WAN 接口 442 可以是电缆或 DSL 数据机、 WiMax 收发器、 光纤收发器、 蜂窝式数据接口、 电力线互联网协议接口 (Internet Protocol-over-powerline interface)， 或到互联网的 许多接口中的任何其他接口。另外， 可将防火墙 / 路由器 /NAT 设备 443( 及 ( 可能地 )WAN 接口 442) 整合到客户端 415 中。该一个实例将为移动电话， 其包括用于实施家庭或办公室 客户端 415 的功能性的软件， 以及用于经由某标准 ( 例如， 802.11g) 而无线地路由及连接到 互联网的装置。
     WAN 接口 442 接着将控制信号路由至本文中所称的用于用户的互联网服务提供者 (ISP) 的 “存在点” 441， WAN 接口 442 为提供连接至用户场所 211 的 WAN 输送器与通用互联 网或私用网络之间的接口的设施。存在点的特性将视所提供的互联网服务的性质而改变。 对于 DSL， 其通常是 DSLAM 位于的电话公司中央办公室。对于电缆调制解调器， 其通常是电 缆多系统运营商 (MSO) 前端。对于蜂窝式系统， 其通常是与蜂窝式塔相关的控制室。但无 论存在点的性质怎样， 其均将接着将控制信号分组路由至通用互联网 410。接着经由将最 可能系光纤收发器接口的接口将控制信号分组路由至 WAN 接口 444 至主机服务 210。WAN 444 将接着将控制信号分组路由至路由逻辑 409( 其可以许多不同方式来实施， 包括以太网 交换器及路由服务器 )， 路由逻辑 409 估计用户的地址且将控制信号路由至用于给定用户 的正确的服务器 402。 服务器 402 接着将所述控制信号视为在服务器 402 上执行的游戏或应用程序软件 的输入且使用所述控制信号来处理游戏或应用程序的下一个帧。一旦产生下一个帧， 就将 视频及音频自服务器 402 输出至视频压缩器 404。可经由各种装置将视频及音频自服务器 402 输出至压缩器 404。首先， 可将压缩器 404 创建到服务器 402 中， 因此可在服务器 402 内在本地实施压缩。或者， 可经由到网络 ( 其或者是服务器 402 与视频压缩器 404 之间的 私用网络， 或者是经由诸如 SAN 403 的共用网络的网络 ) 的网络连接 ( 诸如， 以太网连接 ) 以分组化的形式输出视频和 / 或音频。或者， 可经由视频输出连接器 ( 诸如， DVI 或 VGA 连 接器 ) 将视频自服务器 402 输出， 且接着由视频压缩器 404 来捕获。而且， 可将音频自服务 器 402 输出为数字音频 ( 例如， 经由 TOSLINK 或 S/PDIF 连接器 ) 或模拟音频， 模拟音频由 视频压缩器 404 内的音频压缩逻辑来数字化并编码。
     一旦视频压缩器 404 已捕获来自服务器 402 的视频帧及在该帧时间期间所产生的 音频， 则视频压缩器将使用下文所描述的技术压缩视频及音频。 一旦视频及音频被压缩， 就 且将其路由至 WAN 接口 444， WAN 通过一地址将其分组化以将其发送回至用户的客户端 415， 接口 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×480×24 比 特 / 像素＝ 640*480*24/8/1024 ＝ 900 千字节 / 帧 (KB/ 帧 ) 的帧速率， 则对于给定质量的 图像， 运动 JPEG 可能仅将该流压缩 1/10， 从而产生 90KB/ 帧的数据流。在 60 帧 / 秒下， 此 将需要 90KB*8 比特 *60 帧 / 秒＝ 42.2Mbps 的信道带宽， 其对于美国现今几乎所有的家庭 互联网连接而言将为极高的带宽， 且对于许多办公室互联网连接而言为过高的带宽。实际 上， 假定其在此种高带宽的情况下要求恒定数据流， 且其将仅服务一个用户， 则即使在办公 室 LAN 环境中， 其也将消耗 100Mbps 以太网 LAN 的带宽的大百分比及支持 LAN 的负担沉重的 以太网交换器。因此， 当与其他压缩技术 ( 诸如下文所描述的那些技术 ) 相比较时， 用于运 动视频的压缩无效率。 此外， 使用有损压缩算法的单个帧压缩算法 ( 如 JPEG 及 JPEG-2000) 产生在静止图像中可能不引人注意的压缩假影 ( 例如， 场景中的密集树叶内的假影可能不 呈现为假影， 因为眼并不确切地知道密集树叶应如何呈现 )。 但是， 一旦场景在运动中， 假影 就可能突出， 因为眼侦测到自帧至帧而改变的假影， 尽管假影在场景的区域 ( 在该区域中， 假影在静止图像中可能不引人注意 ) 中。此导致帧序列中的 “背景噪音” 的感知， 该 “背景 噪音” 的外观与边缘模拟 TV 接收期间可见的 “雪花” 杂音类似。当然， 该类型的压缩仍可用 于本文中所描述的特定实施例中， 但一般而言， 为了避免场景中的背景噪音， 对于给定感知 质量， 需要高数据速率 ( 也即， 低压缩比率 )。
     其他类型的压缩 ( 诸如， 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 帧的解码仅依赖于先前所接收的帧。该方法仍存在的问 题在于 ： I 帧比平均 P 帧大得多， 以致在低带宽信道上 ( 如大多数家庭中及许多办公室中典 型的 )， I 帧的传输添加实质延时。此在图 6b 中加以说明。视频流数据速率 624 低于可用 最大数据速率 621( 除对于 I 帧之外 )， 其中 I 帧所需的峰值数据速率 623 远超过可用最大 数据速率 622( 且甚至超过额定最大数据速率 621)。 P 帧所需的数据速率小于可用最大数据 速率。 即使在 2.2Mbps 的可用最大数据速率峰值稳定地保持在其 2.2Mbps 峰值速率， 也将花 费 160Kb/2.2Mb ＝ 71 毫秒来传输 I 帧， 且若可用最大数据速率 622 下降 50％ (1.1Mbps)， 则 将花费 142 毫秒来传输 I 帧。因此， 传输 I 帧中的延时将落在 71 毫秒与 142 毫秒之间的某 处。该延时添加到图 4b 中所识别的延时 ( 所述延时在最糟状况下总计达 70 毫秒 )， 因此， 这将导致从用户致动输入设备 421 的时刻直到图像呈现于显示设备 422 上的为 141-222 毫 秒的总来回行程延时， 其极高。且若可用最大数据速率下降至低于 2.2Mbps， 则延时将进一 步增加。
     还注意到， 以远超过可用数据速率 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 下 640×480 像素的相对低分辨率的视频流的实例。60fps 下的 1920×1080 的 HDTV 流容易由现代计算机及显示器来处理， 且 60fps 下的 2560×1440 分辨率显示器日益可用 ( 例如， Apple 公司的 30″显示器 )。使用 H.264 压缩， 60fps 下的 1920×1080 的高动作视频序列可能需要 4.5Mbps 以获得合理质量水平。 若假定 I 帧峰值为 标定数据速率的 10 倍， 则其将产生 45Mbps 峰值， 以及较小但仍相当大的 P 帧峰值。若若干 个用户正在同一 100Mbps 网络 ( 例如， 办公室与数据中心之间的私用网络连接 ) 上接收视 频流， 则容易看见来自若干用户的视频流的峰值可如何碰巧对准， 从而淹没网络的带宽， 且 可能淹没网络上支持用户的交换器的底板的带宽。即使在超高速以太网的状况下， 若足够 的用户具有同时对准的足够峰值， 则其可淹没网络或网络交换器。此外， 一旦 2560×1440 分辨率视频变得更常见， 平均视频流数据速率就可能为 9.5Mbps， 从而或许产生 95Mbps 峰 值数据速率。 不用说， 数据中心与办公室之间的 100Mbps 连接 ( 其在现今为格外快的连接 ) 将完全被来自单一用户的峰值通信击溃。因此， 即使 LAN 及私用网络连接对有峰流动视频 可具有更高容忍度， 具有高峰值的流动视频也是不需要的且可能需要办公室的 IT 部门的 特殊计划及适应。
     当然， 对于标准线性视频应用程序， 该问题并不是问题， 因为数据速率在传输点 “经平滑化” 且用于每一帧的数据低于最大可用数据速率 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 中所显示的特定实例中， 将每个未经压缩的帧再分成 4×4 矩阵的 16 个图像块。然而， 所述基本原理不限于任何特定再分机制。 在一实施例中， 低延时压缩逻辑 404 将视频帧划分成许多图像块， 且将来自每个 帧的一个图像块编码 ( 也即， 压缩 ) 为 I 帧 ( 也即， 将该图像块压缩， 好像其为全图像的大 小的 1/16 的单独视频帧， 且用于此 “迷你型” 帧的压缩为 I 帧压缩 ) 并将剩余图像块编码为 P 帧 ( 也即， 用于每个 “迷你型” 1/16 帧的压缩为 P 帧压缩 )。经压缩为 I 帧的图像块及经 压缩为 P 帧的图像块将分别被称作 “I 图像块” 及 “P 图像块” 。随着每个相继视频帧而改变 待编码为 I 图像块的图像块。因此， 在给定帧时间中， 视频帧中的所述图像块中仅一个图像 块为 I 图像块， 且所述图像块中的剩余者为 P 图像块。举例而言， 在图 7a 中， 未经压缩的帧 701 的图像块 0 经编码为 I 图像块 I0 且剩余的 1-15 图像块经编码为 P 图像块 (P1 至 P15) 以产生 R 帧 711。在下一个未经压缩的视频帧 702 中， 未经压缩的帧 701 的图像块 1 经编码 为 I 图像块 I1 且剩余的图像块 0 及 2 至 15 经编码为 P 图像块 (P0， 及 P2 至 P15) 以产生 R 帧 712。因此， 用于图像块的 I 图像块及 P 图像块在相继帧上逐渐地在时间上交错。该过 程继续， 直至产生 R 图像块 770( 矩阵中最末图像块经编码为 I 图像块 ( 也即， I15)) 为止。 该过程接着重新开始， 从而产生诸如帧 711( 也即， 对于图像块 0， 编码 I 图像块 ) 等的另一 个 R 帧。尽管图 7a 中未说明， 但在一个实施例中， R 帧的视频序列的第一 R 帧仅含有 I 图 像块 ( 也即， 以使得随后的 P 帧具有参考图像数据 ( 自其开始计算运动 ))。或者， 在一实施 例中， 启动序列使用与正常相同的 I 图像块型样， 但不包括用于尚未连同 I 图像块一起编码 的所述图像块的 P 图像块。换言之， 在第一 I 图像块到达之前不连同任何数据一起编码特 定图像块， 从而避免图 9a 中的视频流数据速率 934 中的启动峰值， 其在下文进一步详细说 明。此外， 如下所述， 各种不同大小及形状可用于所述图像块同时仍遵守所述基本原理。
     在客户端 415 上执行的视频解压缩逻辑 412 解压缩每个图像块， 好像其为小 I 帧 及 P 帧的单独视频序列， 且接着将每个图像块再现给驱动显示设备 422 的帧缓冲器。举例 而言， 使用来自 R 帧 711 至 770 的 I0 及 P0 来解压缩并再现视频图像的图像块 0。类似地， 使用来自 R 帧 711 至 770 的 I1 及 P1 来重建图像块 1， 等等。如上所述， I 帧及 P 帧的解压
     缩是这项技术中众所熟知的， 且 I 图像块及 P 图像块的解压缩可通过使视频解压缩器的多 个执行个体在客户端 415 上执行来完成。尽管倍增过程看来似乎增加客户端 415 上的计算 负担， 但实际上其不会增加客户端 415 上的计算负担， 因为图像块本身成比例地较小 ( 相对 于额外处理的数目而言 )， 因此所显示的像素的数目相同， 好像存在一个处理且使用传统的 全大小的 I 帧及 P 帧。
     该 R 帧技术显著减轻通常与 I 帧相关联的带宽峰值 ( 图 6b 及图 6c 中所说明 )， 因 为任何给定帧主要是由通常比 I 帧小的 P 帧构成。举例而言， 再次假定典型 I 帧为 160Kb， 则图 7a 中所说明的帧中的每一者的 I 图像块将为该量的大致 1/16 或 10Kb。类似地， 假定 典型 P 帧为 16Kb， 则用于图 7a 中所说明的图像块中的每一者的 P 帧可为大致 1Kb。最终结 果为约 10Kb+15*1Kb ＝ 25Kb 的 R 帧。因此， 每一 60 帧序列将是 25Kb*60 ＝ 1.5Mbps。因 此， 在 60 帧 / 秒下， 这将需要能够维持 1.5Mbps 的带宽的信道， 但由于 I 图像块是贯穿 60 帧间隔而分散而使得具有低得多的峰值。
     注意， 在先前实例中， 在用于 I 帧及 P 帧的相同假定数据速率情况下， 平均数据速 率为 1.1Mbps。这是因为在先前实例中， 每隔 60 个帧时间仅引入新 I 帧， 而在此实例中， 构 成 I 帧的 16 个图像块在 16 个帧时间中循环， 且因此， 每隔 16 个帧时间引入 I 帧的均等物， 从而导致稍高的平均数据速率。尽管如此， 但在实践中， 引入更频繁的 I 帧并不会线性地增 加数据速率。这是由于以下事实 ： P 帧 ( 或 P 图像块 ) 主要编码自先前帧至下一个帧的差 异。因此， 若先前帧与下一个帧相当类似， 则 P 帧将非常小， 若先前帧与下一个帧相当不同， 则 P 帧将非常大。但因为 P 帧很大程度上是自先前帧导出， 而非自实际帧导出， 所以所得的 经编码帧可能含有比具有足够数目的比特的 I 帧多的错误 ( 例如， 视觉假影 )。此外， 当一 个 P 帧跟随另一 P 帧时， 可出现错误累加 ( 当存在长 P 帧序列时， 变得更糟 )。现在， 尖端的 视频压缩器将侦测到图像的质量在一序列 P 帧的后降级的事实， 且必要时， 其将更多比特 分配给随后的 P 帧以提高质量， 或若其为最有效的动作过程， 则用 I 帧替换 P 帧。因此， 当 使用长 P 帧序列 ( 例如， 59 个 P 帧， 如上文先前实例中 ) 时， 特定言的当场景具有大量复杂 度和 / 或运动时， 通常， 对于 P 帧而言需要更多比特 ( 因为其变得距 I 帧更远 )。
     或者， 自相对观看点看 P 帧， 紧密地跟随 I 帧的 P 帧倾向于需要比距 I 帧更远的 P 帧少的比特。因此， 在图 7a 中所显示的实例中， 没有 P 帧比距 I 帧隔开 15 个帧更远 ( 在 I 帧之前 )， 而在先前实例中， P 帧可能从 I 帧隔开 59 个帧。因此， 在更频繁的 I 帧情况下， P 帧较小。当然， 确切相对大小将基于视频流的性质而改变， 但在图 7a 的实例中， 若 I 图像块 或在 为 10Kb， 则 P 图像块的大小平均可为仅 0.75kb， 从而导致 10Kb+15*0.75Kb ＝ 21.25Kb， 60 帧 / 秒下， 数据速率将为 21.25Kb*60 ＝ 1.3Mbps， 或比 1.1Mbps 下的具有 I 帧随后跟着 59 个 P 帧的流的数据速率高约 16％。再一次， 用于视频压缩的所述两种方法之间的相对结 果将视视频序列而改变， 但通常， 我们凭经验发现， 对于给定质量水平， 使用 R 帧比使用 I/P 帧序列需要多约 20％的比特。但是， 当然， R 帧急剧地减少峰值， 这使视频序列在远小于 I/ P 帧序列的延时下可用。
     可视视频序列的性质、 信道的可靠性及可用数据速率而以多种不同方式来配置 R 帧。在替代实施例中， 在 4×4 配置中使用不同于 16 的数目的图像块。举例而言， 可在 2×1 或 1×2 配置中使用 2 个图像块， 可在 2×2、 4×1 或 1×4 配置中使用 4 个图像块， 可在 3×2、 2×3、 6×1 或 1×6 配置中使用 6 个图像块或可在 4×2( 如图 7b 中所显示 )、 2×4、 8×1 或1×8 配置中使用 8 个图像块。注意， 图像块不需要为方形， 视频帧也不必为方形， 或甚至矩 形。可将图像块分解成最佳地适合所使用的视频流及应用程序的无论什么形状。
     在另一实施例中， I 图像块及 P 图像块的循环不锁定到图像块的数目。举例而言， 在 8 图像块 4×2 配置中， 仍可如图 7b 中所说明而使用 16 循环序列。顺序的未经压缩的帧 721、 722、 723 各自经划分成 8 个图像块 0-7， 且每个图像块被个别压缩。自 R 帧 731， 仅图 像块 0 被压缩为 I 图像块， 且剩余图像块被压缩为 P 图像块。对于随后的 R 帧 732， 所有 8 个图像块被压缩为 P 图像块， 且接着对于随后的 R 帧 733， 图像块 1 被压缩为 I 图像块且其 他图像块均被压缩为 P 图像块。此外， 如此对于 16 个帧继续进行排序， 仅每隔一帧产生一 个 I 图像块， 因此在第 15 个帧时间期间 ( 图 7b 中未图示 ) 及在第 16 个帧时间期间产生用 于图像块 7 的最末 I 图像块 ( 使用所有的 P 图像块压缩 R 帧 780)。接着， 序列再次以图像 块 0 被压缩为 I 图像块且其他图像块被压缩为 P 图像块开始。如在先前实施例中， 整个视 频序列的第一帧通常将均为 I 图像块， 以提供用于从该点向前的 P 图像块的参考。I 图像 块及 P 图像块的循环甚至不需要为图像块的数目的偶倍数。举例而言， 在 8 个图像块的情 况下， 在使用另一 I 图像块之前， 具有一个 I 图像块的每一帧之后可为所有都为 P 图像块的 2 个帧。在又一实施例中， 若 ( 例如 ) 已知屏幕的特定区域具有更多运动 ( 需要更频繁的 I 图像块 )， 而其他区域更为静态 ( 例如， 显示游戏的分数 )( 需要较不频繁的 I 图像块 )， 则 与其他图像块相比， 可更经常地将特定图像块连同 I 图像块一起进行排序。此外， 尽管在图 7a- 图 7b 中说明每个帧具有单个 I 图像块， 但可在单个帧中编码多个 I 图像块 ( 取决于传 输信道的带宽 )。相反地， 特定帧或帧序列可在不具有 I 图像块 ( 也即， 仅 P 图像块 ) 的情 况下传输。
     前一段的方法适当起作用的原因在于 ： 尽管不具有跨越每个单个帧而分散的 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 产生未经压缩的帧 2 962， 将其压缩成经压缩的帧 2 982， 且在小于一帧时间的传输时间 992 期间以峰值数 据速率 941 将其传输至客户端 415。
     接着， 在下一个帧时间中， 服务器 402 产生未经压缩的帧 3 963。当由视频压缩器 404 来压缩未经压缩的帧 3 963 时， 所得的经压缩的帧 3 983 为比可以峰值数据速率 941 在一帧时间中传输的数据多的数据。因此， 在传输时间 (2 倍峰值 )993 期间将其传输， 其占 据所有帧时间及下一个帧时间的一部分。现在， 在下一个帧时间期间， 服务器 402 产生另一 未经压缩的帧 4964 且将其输出至视频压缩器 404， 但数据被忽略且通过 974 来说明。这是 因为视频压缩器 404 经配置以忽略在其仍传输先前经压缩的帧时到达的其他未经压缩的 视频帧。当然， 客户端 415 的视频解压缩器将未能接收到帧 4， 但其简单地继续在显示设备 422 上显示帧 3 历时 2 个帧时间 ( 也即， 暂时将帧速率自 60fps 减小至 30fps)。
     对于下一个帧 5， 服务器 402 输出未经压缩的帧 5 965， 将其压缩成经压缩的帧 5 985 且在传输时间 995 期间在 1 帧内将其传输。客户端 415 的视频解压缩器解压缩帧 5 并 将其显示于显示设备 422 上。接着， 服务器 402 输出未经压缩的帧 6 966， 视频压缩器 404 将其压缩成经压缩的帧 6 986， 但此时所得的数据非常大。在传输时间 (4 倍峰值 )996 期 间以峰值数据速率 941 传输经压缩的帧， 但花费几乎 4 个帧时间来传输帧。在接下来的 3 个帧时间期间， 视频压缩器 404 忽略来自服务器 402 的 3 个帧， 且客户端 415 的解压缩器将 帧 6 稳定地保持在显示设备 422 上历时 4 个帧时间 ( 也即， 暂时将帧速率自 60fps 减小至 15fps)。接着最后， 服务器 402 输出帧 10 970， 视频压缩器 404 将其压缩成经压缩的帧 10 987， 且在传输时间 997 期间将其传输， 且客户端 415 的解压缩器解压缩帧 10 并将其显示于 显示设备 422 上且再一次视频以 60fps 重新开始。
     注意， 尽管视频压缩器 404 丢弃了来自由服务器 402 产生的视频流的视频帧， 但其 不会丢弃音频数据 ( 不管音频是以什么形式来的 )， 且当丢弃视频帧时视频压缩器 404 继 续压缩音频数据并将其传输至客户端 415， 客户端 415 继续解压缩音频数据并将音频提供 至由用户使用以回放音频的无论什么设备。 因此在丢弃帧的周期期间， 音频继续而不减弱。 与经压缩的视频相比， 经压缩的音频消耗相对小百分比的带宽， 且因此不会对总数据速率 有较大影响。尽管在数据速率图中的任一者中都未说明， 但峰值数据速率 941 内总是存在 经保留用于经压缩音频流的数据速率容量。
     选择刚刚在图 9b 中所描述的实例来说明在数据速率峰值期间帧速率如何下降， 但未说明的是当使用先前所描述的循环 I/P 图像块技术时， 所述数据速率峰值及随的发生 的丢弃的帧很少， 即使在高场景复杂度 / 高动作序列 ( 诸如在视频游戏、 电影及某个应用程 序软件中出现的那些 ) 期间也如此。因此， 减小的帧速率罕有且暂时， 且人的视觉系统不会 侦测到它们。
     若将刚刚所描述的帧速率减小机制应用于图 9a 中所说明的视频流数据速率， 则 在图 9c 中说明所得的视频流数据速率。在此实例中， 2 倍峰值 952 已减小至平坦化的 2 倍 峰值 953， 且 4 倍峰值 955 已减小至平坦化的 4 倍峰值 955， 且整个视频流数据速率 934 保 持处于或低于峰值数据速率 941。
     因此， 使用上文所描述的技术， 可经由通用互联网及消费者级互联网连接而以低 延时来传输高动作视频流。 另外， 在 LAN( 例如， 100Mbs 以太网或 802.11g 无线网络 ) 上或私 用网络 ( 例如， 数据中心与办公室之间的 100Mbps 连接 ) 上的办公室环境中， 可在无峰值情况下传输高动作视频流， 以使得多个用户 ( 例如， 以 4.5Mbps 传输 60fps 下的 1920×1080) 可使用 LAN 或共用私用数据连接， 而不使重迭峰值淹没 (overwhelm) 网络或网络交换器底 板。
     数据速率调整
     在一个实施例中， 主机服务 210 最初评估信道的可用最大数据速率 622 及延时以 确定用于视频流的适当数据速率且接着响应于此而动态地调整数据速率。 为了调整数据速 率， 主机服务 210 可 ( 例如 ) 修改待发送至客户端 415 的视频流的图像分辨率和 / 或每秒 帧数。而且， 主机服务可调整经压缩视频的质量水平。当改变视频流的分辨率时 ( 例如， 自 1280×720 分辨率至 640×360)， 客户端 415 上的视频解压缩逻辑 412 可将图像按比例增加 以在显示屏幕上维持相同图像大小。
     在一个实施例中， 在信道完全掉线 (drop out) 的情形下， 主机服务 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 的纠错码且 FEC 1104 含有 用于 I 图像块 1103 的纠错码。在此实施例中， 对于 P 图像块不产生 FEC。
     在图 11b 中所说明的一个实施例中， 对于在丢失时最可能引起视觉假影的 P 图像 块也产生 FEC 码。在此实施例中， FEC 1105 提供用于前 3 个 P 图像块但不用于跟随的 P 图 像块的纠错码。在另一实施例中， 对于数据大小最小的 P 图像块产生 FEC 码 ( 其将倾向于 自选在 I 图像块的后最早出现的 P 图像块， 其对于保护最为关键 )。
     在另一实施例中， 并非将 FEC 码连同图像块一起发送， 而是将图像块传输两次， 每 次在不同分组中传输。若一分组丢失 / 延迟， 则使用另一分组。
     在图 11c 中所显示的一个实施例中， 产生分别用于与视频同时自主机服务传输的 音频分组 1110 及 1112 的 FEC 码 1111 及 1113。维持视频流中的音频的完整性特别重要， 因 为失真的音频 ( 例如， 滴答声或嘶嘶声 ) 将导致特别不合需要的用户体验。 FEC 码帮助确保音频内容在客户端计算机 415 处无失真地再现。
     在另一实施例中， 并非将 FEC 码连同音频数据一起发送， 而是将音频数据传输两 次， 每次在不同分组中传输。若一个分组丢失 / 延迟， 则使用另一分组。
     另外， 在图 11d 中所说明的一个实施例中， 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， 当分组丢失 / 延迟， 从而导致图像块数据的丢 失时， 或若可能由于特别糟的分组丢失而使得 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 计算机系统， 每个核心作为独立过程实施开源 x264 H.264 压缩器。然而， 可使用各种其他 硬件 / 软件配置， 同时仍遵守所述基本原理。举例而言， CPU 核心中的每一者可通过以 FPGA 实施的 H.264 压缩器来替换。在图 12 中所显示的实例中， 核心 1201-1208 用于作为八个独 立线绪来同时处理 I 图像块及 P 图像块。如此项技术中众所周知的， 当前多核及多处理器 计算机系统与诸如 Microsoft Windows XP 专业版 (64 比特版或者 32 比特版 ) 及 Linux 的多线绪处理操作系统整合时， 其固有地能够进行多线绪处理。
     在图 12 中所说明的实施例中， 因为该 8 个核心中的每一者仅负责一个图像块， 所以其很大程度上独立于其他核心而操作， 每一者执行 x264 的单独实例化。使用以 PCI Express x1 为基础的 DVI 捕获卡 ( 诸如， 来自 Netherlands 的 Microtronix of Oosterhout 的 Sendero 视频成像 IP 开发板 ) 来捕获 640×480、 800×600 或 1280×720 分辨率下的未 经压缩的视频， 且卡上的 FPGA 使用直接存储器存取 (DMA) 来将所捕获的视频经由 DVI 总线 传送至系统 RAM 中。将所述图像块配置成 4×2 配置 1205( 尽管其说明为方形图像块， 但在 该实施例中， 其具有 160×240 分辨率 )。x264 的每个实例化被配置成压缩该 8 个 160×240 图像块中的一者， 且其经同步化以使得在初始 I 图像块压缩的后每一核心进入一循环， 每 一帧与另一帧不同相， 以压缩一 I 图像块继的以七个 P 图像块， 如图 12 中所说明。
     在每一帧时间， 使用先前所描述的技术将所得的经压缩图像块组合成分组流， 且 接着将经压缩图像块传输至目的地客户端 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 输出端将新帧自以主机板为基础的图形系统或者经 由 NVIDIA 8800GTX PCI Express 卡的 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 的子网络的网络连接及至附接 至其他设备的子网络的另一网络连接。
     应用程序 / 游戏服务器 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( 显示为图 16 的黑白再现中的黑色矩形轮廓线 ) 移动到给定游戏来完成 ( 黄色帧移 动可通过使用键盘上的箭头键、 通过移动鼠标、 通过移动操纵杆或通过推动诸如移动电话 的另一设备上的方向按钮来完成 )。一旦选择了单个游戏， 则只有来自该游戏的音频播放。 而且， 显示游戏信息 1602。在该游戏的状况下， 例如， 出版商标志 ( 例如， “电子艺界公司 (Electronic Arts)” 的 “EA” ) 及游戏标志例如 “极品飞车卡本峡谷” 及橙色横条 ( 在图 16 中被再现为具有垂直条纹的横条 ) 在相对条件下指示在该特定时刻玩游戏或观看游戏的 人的数目 ( 在此状况下， 许多， 因此游戏为 “热门” )。另外提供 “状态” ( 即， 统计 )， 指示存 在 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、 Macintosh 上、 在电视机上、 在家里、 在行进时且甚至在移动电话上玩该游戏。此外， 这均可 在并非曾经实体拥有游戏复本的情况下完成。
     如先前所叙述， 用户可决定不允许其游戏播放可被他人观看， 允许其游戏可在延 迟之后观看， 允许其游戏可被选定用户观看， 或允许其游戏可被所有用户观看。不管怎样， 在一个实施例中， 将视频 / 音频储存于延迟缓冲器 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 商用互联网连接看见 2560×1440 60fps 显示， 纽约的房地产开发商可经由其笔记本计算机上的 6Mbps DSL 连接看见 1280×720 60fps 图像， 且投资者可经由其移动电话上的 250Kbps 蜂窝式数据连接看见 320×180 60fps 图像 )。每一方将听到其他方的语音 ( 将通过应用程序 / 游戏服务器 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)” ( 在此显示为 Game4) 且 MrSnuggles99 离线等 )。通过单击菜单项 ( 未图示 )， 搭档视频剪辑自显示已记录的或上传的视频切换至当前正玩主机服务 210 上的 游戏的搭档在所述时刻在其游戏中正在进行的内容的现场直播的视频。因此， 其变成为搭 档分群的游戏取景器。 若选择搭档的游戏且用户单击该游戏， 则该游戏将放大至全屏幕， 且 用户将能够观看全屏幕现场直播地播放的游戏。
     再次， 观看搭档的游戏的用户不拥有游戏的复本， 也不拥有用于玩该游戏的本地 计算 / 游戏控制台资源。游戏观看是有效瞬时的。
     如上文先前所描述， 当用户玩主机服务 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 的动画精简型客户端在互动性的程度及体验 ( 以减少下载时间， 且可用于几 乎所有的用户设备， 包括不具有 GPU 或高性能 CPU 的低性能 PC 及苹果电脑 ) 的持续时间上 受限制。
     图 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 显示使用 ContourTM 真实性捕获技术 ( 以下共同待审申请中的申请的主 题： 2004 年 9 月 15 日申请的第 10/942,609 号 “Apparatus and method for capturing the motion of a performer” ； 2004 年 9 月 15 日申请的第 10/942,413 号 “Apparatus and method for capturing the expression of a performer” ； 2005 年 2 月 25 日申请的第 11/066,954 号 “Apparatus and method for improving marker identification within a motion capture system” ； 2005 年 3 月 10 日申请的第 11/077,628 号 “Apparatus and method for performing motion capture using shutter synchronization” ； 2005 年 10 月 20 日 申 请 的 第 11/255,854 号 “Apparatus and method for performing motion capture using a random pattern on capture surfaces” ； 2006 年 6 月 7 日申请的第 11/449,131 号 “System and method for performing motion capture using phosphor application techniques” ； 2006 年 6 月 7 日申请的第 11/449,043 号 “System and method for performing motion capture by strobing a fluorescent lamp” ； 2006 年 6 月 7 日申请的第 11/449,127 号 “System and method for three dimensional capture of stop-motion animated characters” ， 上述申请中的每一者都被转让给本 CIP 申请的受让人 ) 捕获的现场直播的表演如何导致非常平滑的捕获表面， 既而达成高多边形计数的追踪 表面 ( 也即， 多边形运动精确地追随面部的运动 )。最后， 当将现场直播的表演的视频映射 于追踪表面上以产生纹理表面时， 产生照片般逼真的结果。
     尽管当前 GPU 技术能够再现追踪表面及纹理中的许多多边形且实时地照明该表 面， 但若多边形及纹理每一帧时间改变 ( 其将产生最具照片般逼真感的结果 )， 则其将迅速 地消耗现代 PC 或视频游戏控制台的所有可用 RAM。
     使用上文所描述的流动几何形状技术， 将几何形状不断地馈送至应用程序 / 游戏 服务器 1521-1525 中以使得其可不断地动画制作照片般逼真的面部从而允许产生具有几 乎不能区别于现场直播的动作面部的面部的视频游戏变得实际。
     线性内容与互动式特征的整合
     电影、 电视节目及音频材料 ( 统称 “线性内容” ) 广泛地以许多形式可用于家庭及 办公室用户。线性内容可在如 CD、 DVD、 及蓝光媒体的实体媒体上获取。其也可通过来自卫 星及电缆 TV 广播的 DVR 来记录。此外， 其可以经由卫星及电缆 TV 的即付即看 (PPV) 内容 及以电缆 TV 上的视频点播 (VOD) 可用。
     日益增加的线性内容可经由互联网以下载的内容及流动内容可用。现今， 确实不 存在一个能体验与线性媒体相关的所有特征的位置。举例而言， DVD 及其他视频光学媒体 通常具有在其他位置处不可用的互动式特征 ( 如导演的评论、 “花絮” 短片等 )。在线音乐 站点具有通常在 CD 上不可用的封面艺术及歌曲信息， 但并非所有 CD 在线可用。且与电视 节目相关联的网站常常具有额外特征、 博客及有时来自演员或创作人员的评论。
     另外， 在许多电影或运动事件的情况下， 通常有经常连同线性媒体一起发行 ( 在 电影的状况下 ) 或 ( 在运动的状况下 ) 可以被紧密地联系到真实世界事件 ( 例如， 玩家的 交易 ) 的视频游戏。
     主机服务 210 非常适合于在将全异形式的相关内容连结在一起时传送线性内容。 的确， 传送电影不如传送高度互动式视频游戏有挑战， 且主机服务 210 能够将线性内容传 送至家庭或办公室中的多种设备， 或传送至移动设备。图 23 显示用于主机服务 210 的例示 性用户接口页面， 其显示线性内容的选择。
     但是， 不同于大多数线性内容传送系统， 主机服务 210 还能够传送相关的互动式 成份 ( 例如， DVD 上的菜单及特征、 HD-DVD 上的互动式叠加层， 及网站上的 Adobe Flash 动 画 ( 如下文所述 ))。因此， 客户端设备 415 限制不再引入哪些特征可用的限制。
     另外， 主机代管系统 210 能够动态且实时地将线性内容与视频游戏内容连结在一 起。举例而言， 若用户正观看哈利波特电影中的 Quidditch( 魁地奇 ) 比赛， 且决定其愿意 尝试玩 Quidditch， 则其可仅仅单击按钮且电影将暂停且其将被立即输送到哈利波特视频 游戏的 Quidditch 片段。在玩 Quidditch 比赛的后， 另一次单击按钮， 且电影将即刻重新开 始。
     在照片般逼真的图形及制作技术的情况下， 其中摄影捕获的视频不能区别于现场 直播的动作人物， 当用户进行自现场直播的动作电影中的 Quidditch 游戏至主机服务上的 视频游戏中的 Quidditch 游戏的转变时 ( 如本文中所述 )， 该两个场景实际上不能区别。 此 为线性内容与互动式 ( 例如， 视频游戏 ) 内容两者的导演提供全新的创作选项， 因为该两个 世界之间的线变得不能区别。利用图 14 中所显示的主机服务架构， 可将 3D 电影中的虚拟相机的控制提供给观 看者。 举例而言， 在发生于列车内的场景中， 将有可能允许观看者在故事进展时控制虚拟相 机且环顾列车。此假定列车中的所有 3D 对象 (“资产” ) 以及能够实时地再现所述场景以 及原始电影的足够计算能力水平可用。
     且甚至对于非计算机产生的娱乐， 存在可提供的非常刺激的互动式特征。举例而 言， 2005 电影 “傲慢与偏见” 具有装饰华丽的旧英国大厦中的许多场景。 对于特定大厦场景， 用户可将视频暂停且接着控制相机以巡视大厦， 或可能的周围区域。为了实施这些， 可携 带具有鱼眼镜头的相机穿过大厦， 当其追踪其位置时， 非常类似于实施先前技术 Apple( 苹 果 ) 公司的 QuickTime VR。 各种帧接着将被转换， 因此图像不失真， 且接着其连同电影一起 被储存于 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 极其适合于锦标赛。因为无游戏在本地客户端中执行， 所以不存在 用户作弊的机会 ( 例如， 在现有技术的锦标赛中， 他们可能通过修改运行于他们本地 PC 上 的游戏副本来给予他们不公平的好处 )。 而且， 由于输出路由 1540 多播 UDP 流的能力， 使得 主机服务 210 能够同时向观众中的数千人或更多广播较大锦标赛。
     事实上， 当存在如此风行以致数千名用户正接收相同流的特定视频流时 ( 例 如， 显示较大锦标赛的视图 )， 可以更有效的将视频流发送到内容传送网络 (CDN)( 诸如， Akamai( 阿卡迈公司 ) 或 Limelight( 聚光灯公司 )) 以用于大量分配到许多客户端设备 415。
     当使用 CDN 来显示顶级玩家分群的游戏取景器页面时， 可获得类似水平的效率。
     对于较大锦标赛， 可使用现场直播的名人解说员来在特定比赛期间提供评论。尽 管大量用户将是在观看较大锦标赛， 且相对小数目将是在锦标赛中玩。可将来自名人解说 员的音频路由到对在锦标赛中玩的用户进行主机代管且对锦标赛中的游戏的任何旁观者 模式复本进行主机代管的应用程序 / 游戏服务器 1521-1525， 且可将音频加录于游戏音频 之上。可在游戏上 ( 也可能刚好在旁观者视图上 ) 叠加名人解说员的视频。
     网页载入的加速
     全球信息网及其主要传送协议、 超文本传输协议 (HTTP) 是被构想并被限定在其 中仅商业具有高速互联网连接， 且在线的消费者使用拨号数据机或 ISDN 的时代中。此时， 用于快速连接的 “黄金标准” 是 T1 线， 其对称地提供 1.5Mbps 数据速率 ( 也即， 两个方向中 具有相等数据速率 )。
     现今， 情形完全不同。大量发达世界中经由 DSL 或电缆调制解调器连接的平均家 庭连接速度具有比 T1 线高得多的下行数据速率。事实上， 在世界的一些地方中， 光纤到路 边 (fiber-to-the-curb) 正将高达 50Mbps 至 100Mbps 的数据速率带入家庭。
     遗憾地， 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-100Mbps 连 接， 但大多数家庭仍具有较缓慢的速度， 且 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 Benchmark Study( 活跃游戏者基准点研究 )” (http://www.prnewswire.com/cgi-bin/stories.pl ？ ACCT ＝ 104&STORY ＝ /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 中的游戏或应用程序的所有复本 )。实际上， 在用 户开始使用主机服务 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 处被存储及执行， 所以用户不具备对于基本程序码的存取， 因此不存在 盗版。即使用户将要复制原始码， 用户也不能够在标准游戏控制台或家庭计算机上执行该 码。此打开了标准视频游戏不可用的世界各地 ( 诸如， 中国 ) 的市场。已使用的游戏的重 新销售也是不可能的， 因为没有游戏副本分发给用户。
     对于游戏开发商而言， 如同现今的状况， 新一代的游戏控制台或 PC 被引入市场， 存在较少市场不连续性。与全新的一代控制台或 PC 技术迫使用户及开发商升级且游戏开 发商取决于硬件平台的及时传送给用户 ( 例如， 在游戏机 3 的情况下， 引入被推迟了超过一 年， 且开发者必须等待直至其可得到并且大量单元被购买 ) 的当前情形对比， 可随着时间 随着游戏要求改变而利用更先进的计算技术逐渐地更新主机服务 210。
     流动互动式视频以上描述提供由以通用互联网为基础的低延时流动互动式视频 ( 其隐含地也包 括连同视频一起的音频， 如本文中所使用 ) 的新颖基本概念致能的多种应用。经由互联网 而提供流动视频的先前技术系统仅具有可通过高延时互动实施的所致能的应用。举例而 言， 用于线性视频的基本回放控制 ( 例如， 暂停、 回倒、 快进 ) 在高延时下适当地工作， 且有 可能在线性视频馈送当中进行选择。 此外， 如先前所陈述， 一些视频游戏的性质允许其以高 延时来播放。但是， 用于流动视频的先前技术方法的高延时 ( 或低压缩比率 ) 严重限制流 动视频的潜在应用或使其部署变窄到专门化的网络环境， 且甚至在所述环境中， 先前技术 也引入网络上的实质负担。 本文中所描述的技术打开了在经由互联网的低延时流动互动式 视频下可能的多种应用的大门， 尤其是经由消费者级互联网连接而致能的所述应用。
     实际上， 在与图 4c 的客户端 465 一般小的客户端设备下， 足以通过有效的任意量 的计算能力、 任意量的快速储存及强大服务器之间的极快网络连接而提供增强的用户体 验， 其使新的计算时代成为可能。 另外， 因为带宽要求并不随着系统的计算能力增长而增长 ( 也即， 因为带宽要求仅关于显示分辨率、 质量及帧速率 )， 所以一旦宽带互联网连接性是 普遍存在的 ( 例如， 经由分布广的低延时无线涵盖 )、 可靠的且具有足以满足所有用户的显 示设备 422 的需要的足够高的带宽， 则问题将是典型消费者及商业应用所必要的是厚重客 户端 ( 诸如， 执行 Windows、 Linux、 OSX 等的 PC 或移动电话 ) 还是甚至精简型客户端 ( 诸 如， Adobe Flash 或 Java)。
     流动互动式视频的出现导致关于计算架构的结构的假定的重新考虑。该一个实 例是图 15 中所显示的主机服务 210 服务器中心实施例。用于延迟缓冲器和 / 或分群视频 1550 的视频路径是反馈回路， 其中应用程序 / 游戏服务器 1521-1525 的经多播的流动互动 式视频输出经由路径 1552 而实时地或者经由路径 1551 在可选择的延迟之后被反馈回到应 用程序 / 游戏服务器 1521-1525 中。这使得通过先前技术服务器或本地计算架构将是不可 能或不可行的多种实际应用 ( 例如， 诸如图 16、 图 17 及图 20 中所说明的应用 ) 成为可能。 但是， 作为更一般的架构特征， 反馈回路 1550 所提供的是流动互动式视频水平下的递归， 因为可在应用程序需要视频时将视频无限地循环。 这使得之前从未可用的多种应用可能性 成为可能。
     另一关键架构特征在于 ： 视频流是单向 UDP 流。这有效地实现流动互动式视频的 任意程度的多播 ( 相比之下， 诸如 TCP/IP 流的双向流将随着用户的数目增加而在来自来回 通信的网络上产生越来越多的通信停滞 )。 多播是服务器中心内的重要能力， 因为其允许系 统对互联网用户 ( 且实际上， 世界的人口 ) 的增长的需要作出响应以在一对多或甚至多对 多基础上通信。再次， 本文中所论述的说明流动互动式视频递归与多播两者的使用的实例 ( 诸如， 图 16) 仅为具有可能性的非常大的冰山的尖端。
     非转接对等 (NON-TRANSIT PEERING)
     在一实施例中， 主机服务 210 具有至一个或多个互联网服务提供商 (ISP) 的一个 或多个对等连接， 该互联网服务提供商 (ISP) 也向用户提供互联网服务， 这样主机服务 210 可通过保持在 ISP 网络内的非转接路由而与用户通信。 例如， 如果主机服务 210WAN 接口 441 直接连接到康卡斯特电缆通信有限公司的网络， 为用户场所 211 通过康卡斯特电缆调制解 调器而被提供宽带服务， 主机服务 210 和客户端 415 之间的路由可全部在康卡斯特的网络 内建立。其潜在的优点将包括 ： 较低的通信费用 ( 因为可避免两个或多个 ISP 网络之间的IP 转接费用 )， 潜在的更可靠的连接 ( 可防止 ISP 网络之间存在拥塞或其他转接中断 ) 和 较低延时 ( 可防止 ISP 网络之间存在拥塞、 低效路由或其他延迟 )。
     该实施例中， 在通话初期， 当客户端 415 开始联系主机服务 210 时， 主机服务 210 接收用户场所 211 的 IP 地址。 之后其使用例如来自 ARIN( 美国网络地址注册管理组织 ) 的 有效 IP 地址表， 查看该 IP 地址是否是分配给连接到主机服务 210 的特定 ISP 的 IP 地址， 该主机服务 210 能够路由到用户场所 211 而无需通过另外的 ISP 来 IP 转接。例如， 如果 IP 地址位于 76.21.0.0 和 76.21.127.255 之间， 则 IP 地址被分配给康卡斯特电缆通信有限公 司。在该示例中， 如果主机服务 210 保持至康卡斯特、 AT&T 和 Cox ISP 的连接， 则其选择康 卡斯特作为最可能向该特定用户提供最佳路由的 ISP。
     使用反馈的视频压缩
     在一实施例中， 从客户端设备向主机服务提供反馈以表明成功的 ( 或不成功的 ) 图像块和 / 或帧传送。从客户端提供的反馈信息之后被用于调节主机服务处的视频压缩操 作。
     例如， 图 25a-b 示出了本发明的一个实施例， 其中在客户端设备 205 和主机服务 210 之间建立反馈信道 2501。客户端设备 205 使用该反馈信道 2501 发送成功接收的图像 块 / 帧的分组化确认和 / 或不成功接收的图像块 / 帧的指示。
     在一实施例中， 成功接收每个图像块 / 帧之后， 客户将确认信息发送到主机服务 210。该实施例中， 如果在指定时段后没有接收到确认和 / 或如果接收到客户端设备 205 所 接收的比已发送的图像块 / 帧靠后的图像块 / 帧的确认， 则主机服务 210 检测分组丢失。 可 选地， 或另外地， 客户端设备 205 可检测分组丢失并将分组丢失的指示连同受该分组丢失 影响的图像块 / 帧的指示一起发送给主机服务 210。 该实施例中， 并不需要成功传送的图像 块 / 帧的连续确认。
     不管如何检测分组丢失， 在图 25a-b 所例示的实施例中， 生成用于图像的 I- 图像 块的初始组 ( 图 25a 中未示出 ) 后， 编码器随后仅生成图像的 P- 图像块， 直到检测到分组 丢失。注意在图 25a 中， 诸如 2510 的每一个帧被示为 4 个纵向的图像块。该帧可以按不同 的配置被铺放， 例如 2×2， 2×4， 4×4 等， 或者该帧可以在没有图像块的情况下整个被编码 ( 例如作为 1 个大的图像块 )。为了示例本发明的该实施例而提供了帧铺放配置的上述实 例。本发明下面的原理并不限于任何特定的帧铺放配置。
     只传送 P- 图像块降低了因为上面提出的所有原因的信道带宽需求 ( 例如， p- 图 像块通常比 I- 图像块小 )。当经由反馈信道 2501 检测到分组丢失时， 如图 25b 所示， 由编 码器 2500 生成新的 I- 图像块， 以重新初始化客户端设备 205 上解码器 2502 的状态。如图 所示， 在一实施例中， I- 图像块分布于多个编码帧上， 以限制由每个单独的编码帧消耗的带 宽。例如图 25 中， 其中每个帧包括 4 个图像块， 在 4 个连续的编码帧内的不同位置处传送 单个 I- 图像块。
     编码器 2500 可将所描述的和该此实施例相关的技术与此处描述的其他编码技术 组合。例如， 除了响应于所检测的分组丢失而生成 I- 图像块外， 编码器 2500 可在其他情况 中生成 I- 图像块， 在该情况中， I- 图像块可能有益于正确地再现图像序列 ( 例如， 响应于 突然的场景转换 )。
     图 26a 示出了本发明的另一个实施例， 其依赖于客户端设备 205 和主机服务 210之间的反馈信道 2601。并非响应于所检测的分组丢失而生成新的 I- 图像块 / 帧， 此实施 例的编码器 2600 调整 P- 图像块 / 帧的相依性。作为初始问题， 需要注意的是 ： 此实例中所 提出的具体细节无需符合本发明的基本原理。例如， 虽然通过使用 P- 图像块 / 帧描述本实 例， 但本发明的基本原理并不限于任何特定的编码格式。
     图 26a 中， 编码器 2600 将多个未压缩的图像块 / 帧 2605 编码为多个 P- 图像块 / 帧 2606， 并通过通信信道 ( 例如互联网 ) 将该 P- 图像块 / 帧传送给客户端设备 205。客户 端设备 205 上的解码器 2602 解码 P- 图像块 / 帧 2606， 生成多个解压缩的图像块 / 帧 2607。 编码器 2600 过去的状态 2611 存储于主机服务 210 上的存储设备 2610 内， 而解码器 2602 过去的状态 2621 存储于客户端设备 205 上的存储设备 2620 内。解码器的 “状态” 是诸如 MPEG-2 和 MPEG-4 的视频编码系统领域中公知的术语。 在一实施例中， 存储器内所存储的过 去 “状态” 包含来自在先 P- 图像块 / 帧的组合数据。存储器 2611 和 2621 可分别集成到编 码器 2600 和解码器 2602 中， 而非与编码器 2600 和解码器 2602 分离， 正如图 26a 所示。此 外， 可以使用各种类型的存储器， 包括 ( 以示例而非限制的方式 ) 随机存取存储器。
     在一实施例中， 当没有分组丢失发生时， 编码器 2600 将每个 P- 图像块 / 帧编码为 依赖于之前的 P- 图像块 / 帧。因此， 正如图 26a 使用的符号所指示， P- 图像块 / 帧 4 依赖 于 P- 图像块 / 帧 3( 使用符号 43 标识 ) ； P- 图像块 / 帧 5 依赖于 P- 图像块 / 帧 4( 使用符 号 54 标识 ) ； 而 P- 图像块 / 帧 6 依赖于 P- 图像块 / 帧 5( 使用符号 65 标识 )。在该实例 中， P- 图像块 / 帧 43 在编码器 2600 和解码器 2602 之间的传送期间已被丢失。可以各种方 式将该丢失传送到编码器 2600， 包括但不限于上述的那些方式。例如， 每次解码器 2606 成 功地接收和 / 或解码图像块 / 帧时， 可将此信息从解码器 2602 传送到编码器 2600。如果 编码器 2600 并未在一时段之后接收到特定图像块 / 帧已被接收和 / 或解码的指示， 则编码 器 2600 将假定所述图像块 / 帧未被成功接收。可选地， 或者另外地， 当特定图像块 / 帧未 被成功接收时， 解码器 2602 可通知编码器 2600。
     在一实施例中， 不管如何检测丢失的图像块 / 帧， 一旦出现该情况， 则编码器 2600 通过使用已知的由解码器 2602 成功接收的上一个图像块 / 帧， 编码下一个图像块 / 帧。在 图 26a 所示的实例中， 图像块 / 帧 5 和 6 不认为是 “成功接收” ， 由于图像块 / 帧 4 的丢失， 其不能由解码器 2602 正确地解码 ( 即， 图像块 / 帧 5 的解码依赖于图像块 / 帧 4 而图像块 / 帧 6 的解码依赖于图像块 / 帧 5)。因此在图 26a 所示的实例中， 编码器 2600 将图像块 / 帧 7 编码为依赖图像块 / 帧 3( 上一个成功接收的图像块 / 帧 ) 而非解码器 2602 不能正确 解码的图像块 / 帧 6。虽然图 26a 中没有示出， 随后将图像块 / 帧 8 编码为依赖于图像块 / 帧 7 而将图像块 / 帧 9 编码为依赖于图像块 / 帧 8， 假定未检测到另外的分组丢失。
     如上所提及， 编码器 2600 和解码器 2602 将过去的解码器和编码器状态 2611 和 2621， 分别保持于存储器 2610 和 2620 内。因此当编码图像块 / 帧 7 时， 编码器 2600 从存 储器 2610 中获取与图像块 / 帧 3 相关的先前编码器状态。同样地， 和解码器 2602 相关的 存储器 2620 至少存储上一个已知的好解码器状态 ( 实例中与图像块 / 帧 3 相关的状态 )。 因此， 解码器 2602 获取与图像块 / 帧 3 相关的过去状态信息以使得图像块 / 帧 7 可被解码。
     由于上述技术， 可使用相对小的带宽来对实时、 低延时、 交互的视频进行编码和并 使其流动， 因为不曾需要 I- 图像块 / 帧 ( 除了在流开始处初始化解码器和编码器 )。此外， 虽然解码器产生的视频图像可能临时包括因丢失的图像块 / 帧 4 和图像块 / 帧 5 以及 6 而产生的不想要的失真 ( 由于图像块 / 帧 4 的丢失， 其不能被正确解码 )， 但该失真仅在非常 短的持续时间可见。此外， 如果使用图像块 ( 而非全视频帧 )， 此失真将被限定到所再现的 视频图像的特定区域。
     图 26b 示出了根据本发明一个实施例的方法。在 2650 处， 基于之前生成的图像块 / 帧而生成图像块 / 帧。在 2651 处， 检测到丢失的图像块 / 帧。在一实施例中， 基于从编码 器传送到解码器的信息来检测丢失的图像块 / 帧， 如上所述。在 2652 处， 基于已知的在解 码器处已被成功接收和 / 或解码的图像块 / 帧， 生成下一个图像块 / 帧。在一实施例中， 通 过从存储器加载与成功接收和 / 或解码的图像块 / 帧有关的状态， 该编码器生成下一个图 像块 / 帧。同样地， 当解码器接收到新的图像块 / 帧时， 其通过从存储器加载与成功接收和 / 或解码的图像块 / 帧有关的状态而解码该图像块 / 帧。
     在一实施例中， 基于编码器处成功接收和 / 或解码的上一个图像块 / 帧而生成下 一个图像块 / 帧。在另一实施例中， 生成的下一个图像块 / 帧是 I 图像块 / 帧。再一个实 施例中， 选择基于先前成功接收的图像块 / 帧生成下一个图像块 / 帧还是生成为 I 帧是基 于： 丢失了多少图像块 / 帧和 / 或信道的延时。在丢失了相对小数量 ( 例如 1 或 2) 的图像 块 / 帧以及来回行程延时相对低 ( 例如 1 或 2 帧时间 ) 的情况下， 生成 P 图像块 / 帧可能 是最佳的， 因为上一次成功接收的图像块 / 帧和新生成的图像块 / 帧之间的差异可能相对 小。如果丢失了若干个图像块 / 帧且来回行程延时高， 则生成 I 图像块 / 帧可能是最佳的， 因为上一次成功接收的图像块 / 帧和新生成的图像块 / 帧之间的差异可能大。在一实施例 中， 设定图像块 / 帧丢失阈值和 / 或延时阈值以确定是传送 I 图像块 / 帧还是 P 图像块 / 帧。如果丢失的图像块 / 帧的数量低于图像块 / 帧丢失阈值和 / 或如果来回行程延时低于 延时阈值， 则生成新的 I 图像块 / 帧 ； 否则生成新的 P 图像块 / 帧。
     在一实施例中， 编码器总是尝试生成与上次成功接收的图像块 / 帧有关的 P 图像 块 / 帧， 而若编码过程中编码器确定 P 图像块 / 帧将可能大于 I 图像块 / 帧时 ( 例如， 如果 其已压缩 1/8 的图像块 / 帧且压缩的大小大于先前压缩的 I 图像块 / 帧平均大小的 1/8)， 则编码器将放弃压缩 P 图像块 / 帧且将改为压缩 I 图像块 / 帧。
     如果丢失的分组很少发生， 则上述使用反馈来报告丢弃的 (dropped) 图像块 / 帧 的系统会典型地导致至用户的视频流中出现非常微小的中断， 因为由丢失分组所中断的图 像块 / 帧在客户端设备 205 和主机服务 210 之间大概一个来回行程的时间内被替换， 假定 编码器 2600 在短时间内压缩该图像块 / 帧。而且因为被压缩的新图像块 / 帧是基于未压 缩视频流中稍后的帧， 所以视频流并没有落后于未压缩视频流。但是如果含有新图像块 / 帧的包也被丢失， 则这将导致至少两个来回行程的延迟以再次请求和发送另一个新图像块 / 帧， 在许多实际情况下其将导致视频流的显著中断。因而， 从主机服务 210 向客户端设备 205 成功发送在丢失的图像块 / 帧之后发送的新编码的图像块 / 帧是非常重要的。
     在一实施例中， 前向纠错 (FEC) 技术， 例如先前在图 11a、 11b、 11c 和 11d 中所描述 和示出的那些技术， 被用于减轻丢失新编码的图像块 / 帧的可能性。如果传送图像块 / 帧 时 FEC 编码已被使用， 则更强的 FEC 码用于新编码的图像块 / 帧。
     丢失分组的一个潜在原因是信道带宽的突然损耗， 例如， 如果用户场所 211 处宽 带连接的其他某些用户开始使用大量的带宽。如果新生成的图像块 / 帧也因丢弃分组 ( 即 使使用了 FEC) 而丢失， 则在一实施例中 ： 当客户端 415 通知主机服务 210 第二个新编码的图像块 / 帧丢失， 视频压缩器 404 在其编码随后新编码的图像块 / 帧时， 降低数据速率。不 同的实施例使用不同的技术降低数据速率。 例如在一实施例中， 通过增加压缩比， 降低编码 图像块 / 帧的品质， 从而达到此数据速率的降低。在另一实施例中， 通过降低视频的帧速率 ( 例如从 60fps 到 30fps) 并相应地减慢数据传输的速率而降低数据速率。在一实施例中， 用于降低数据速率的技术都被使用 ( 例如既降低帧速率又增加压缩比 )。如果数据传输的 较低速率对减轻丢弃分组是成功的， 则依照先前所述的信道数据速率检测和调节方法， 主 机服务 210 将继续以较低的数据速率编码， 之后随着信道所允许而逐渐地向上或向下调节 数据速率。与丢弃分组和 / 或延时有关的反馈数据的连续接收允许主机服务 210 基于当前 信道条件动态调节数据速率。
     在线游戏系统中的状态管理
     该发明的一个实施例使用技术来有效地存储和运送服务器间活跃游戏的当前状 态。虽然此处描述的实施例是关于在线游戏的， 但该发明的基本原理可用于其他各种类 型的应用程序 ( 例如设计应用程序、 文字处理软件、 诸如电邮或即使消息接发的通信软件 等 )。图 27a 示出了用于实施该实施例的示例性系统架构而图 27b 示出了示例性的方法。 虽然将同时描述该方法和系统架构， 但图 27b 所示的方法并不限于任何特定的系统架构。
     图 27b 中的 2751 处， 用户从客户端设备 205 上启动主机服务 210a 上的新在线游 戏。作为响应， 在 2752 处， 将游戏的 “洁净 (clean)” 图像 2702a 从存储器 ( 例如硬盘驱动 器， 无论是直接连接到执行游戏的服务器， 还是通过网络连接到服务器 ) 加载至主机服务 210a 上的存储器 ( 例如 RAM)。 “洁净” 图像包括在任何游戏播放启动之前， 游戏的运行时 间程序代码和数据 ( 例如， 就像当首次执行游戏时那样 )。之后在 2753 处， 用户玩游戏， 使 得 “洁净” 图像变为非洁净图像 ( 例如， 由图 27a 中 “状态 A” 所表示的正执行的游戏 )。在 2754 处， 游戏由用户或主机服务 210a 中的任一个暂停或终止。在 2755 处， 主机服务 210a 上的状态管理逻辑电路 2700a 确定游戏的 “洁净” 图像和当前游戏状态 (“状态 A” ) 之间 的差异。各种已知的技术可用于计算两个二值图像之间的差异， 该技术例如包括 UNIX 操作 系统上的公知 “diff” 工具所使用的那些技术。当然， 本发明的基本原理并不限于任何用于 差异计算的特定技术。
     不管如何计算该差异， 一旦使用它们， 则差异数据会被本地存储于存储设备 2705a 内和 / 或被传送给不同主机服务 210b。如果被传送到不同的主机服务 210b， 该差异数据可 能被存储到新主机服务 210b 的存储设备 ( 未示出 ) 上。在任一种情况中， 差异数据与主机 服务上的用户帐号相关， 以使得其可在下一次用户登陆主机服务并启动该游戏时被识别。 在一实施例中， 并非立刻传送， 该差异数据不被传送到新的主机服务， 直到下一次用户尝试 玩该游戏 ( 而不同的主机服务被确定为作为该游戏的主机的最佳选择 )。
     返回到图 27b 所示的方法， 在 2757 处， 用户从客户端设备重启游戏， 所述客户端设 备可以是用户最初玩该游戏使用客户端设备 205 或不同的客户端设备 ( 未示出 )。作为响 应， 在 2758 处， 主机服务 210b 上的状态管理逻辑 2700b 从存储设备获取游戏的 “洁净” 图像 和差异数据。在 2759 处， 状态管理逻辑路 2700b 将洁净图像和差异数据组合以重新构建游 戏在原始主机服务 210a 上的状态 ( “状态 A” )。可以使用各种已知的技术来使用所述差异 数据， 重新创建二值图像的状态， 该技术例如包括 UNIX 操作系统上公知的 “修补 (patch)” 工具中所使用的那些技术。也可使用在诸如 PC 备份的公知备份程序中使用差异计算技术。本发明的基本原理不限于任意使用差异数据重建二值图像的特定技术。
     此外， 在 2760 处， 平台相关 (platform-dependent) 数据 2710 被合并到最终的游 戏图像 2701b 中。 平台相关数据 2710 可包括唯一对应于目标服务器平台的任意数据。 以示 例而非限制的方式， 平台相关数据 2710 可包括新平台的媒体访问控制 (MAC) 地址、 TCP/IP 地址、 时刻、 硬件序列号 ( 例如用于硬盘驱动器和 CPU)、 网络服务器地址 ( 例如 DHCP/Wins 服务器 ) 以及软件序列号 / 激活码 ( 包括操作系统序列号 / 激活码 )。
     其他与客户 / 用户有关的平台相关数据可包括 ( 但不限于 ) 下列各项 ：
     1. 用户的屏幕分辨率。当用户恢复游戏时， 用户可使用具有不同分辨率的不同设 备。
     2. 用户的控制器配置。当游戏恢复时， 用户可能已从游戏控制器切换到键盘 / 鼠 标。
     3. 用户权限， 例如是否折扣率已经期满 ( 例如 ： 如果用户曾在促销期间玩游戏， 且 现在正在较高消费的普通时段玩 )， 或者用户或设备是否有某些年龄限制 ( 例如， 用户的父 母可能已经改变用于孩子的设置， 这样孩子不允许看成人资料， 或者如果正在播放游戏的 设备 ( 例如公共图书馆的计算机 ) 在是否显示成人资料方面具有某些限制 )。
     4. 用户的等级。用户可能已被允许在某一联盟中玩多人游戏， 但是因为其他某些 用户已经超过该用户的等级， 所以用户可能已被降级到较小的联盟中。
     为了解释本发明该实施例而提供了平台相关数据 2710 的前述实例。本发明的基 本原理并不限于平台相关数据的任意特定集合。
     图 28 图形化地示出了第一主机服务处的状态管理逻辑 2700a 如何从正执行的游 戏 2701a 中提取差异数据 2800。之后， 第二主机服务处的状态管理逻辑 2700b 将洁净图像 2702b 和差异数据 2800 以及平台相关数据 2710 组合， 以重新生成正执行的游戏 2701b 的状 态。大体如图 28 所示， 差异数据的大小显著地小于整个游戏图像 2701a 的大小， 因此通过 仅仅存储 / 传输差异数据而节省了大量的存储空间和带宽。虽然图 28 中未示出， 但是平台 相关数据 2700 在其被合并到最终的游戏图像 2701b 时， 可改写某些差异数据。
     虽然上面描述了在线视频游戏的实施， 但本发明的基本原理并不限于视频游戏。 例如可在任意类型的在线主机应用程序的环境中实现前述状态管理技术。
     用于保持客户端解码器的技术
     在本发明一实施例中， 每当用户请求连接主机服务 210 时， 主机服务 210 便将新的 解码器传送到客户端设备 205。因而， 在该实施例中， 客户端设备所使用的解码器总是最新 的 (up-to-date) 且为客户端设备上实施的软件 / 硬件特别量身定做的。
     如图 29 所示， 该实施例中， 永久地安装于客户端设备 205 上的应用程序并不包括 解码器。相反地， 是客户端下载器应用程序 2903 来在每次客户端设备 205 连接主机服务 210 时， 管理临时解码器 2900 的下载和安装。该下载器应用程序 2903 可被实施为硬件、 软 件、 固件或其任意组合。响应于新的在线会话的用户请求， 下载器应用程序 2903 通过网络 ( 例如互联网 ) 传送与客户端设备 205 相关的信息。该信息可包括识别客户端设备和 / 或 客户端设备硬件 / 软件配置 ( 例如， 处理器、 操作系统等 ) 的识别数据。
     基于此信息， 主机服务 210 上的下载器应用程序 2901 选择合适的临时解码器 2900 以用于客户端设备 205 上。 主机服务上的下载器应用程序 2901 之后传送临时解码器 2900，之后客户端设备上的下载器应用程序 2903 在客户端设备 205 上验证和 / 或安装解码器。 编 码器 2902 之后使用此处所述的任意技术来编码音频 / 视频内容， 并将内容 2910 传送到解 码器 2900。一旦安装了新的解码器 2900， 其解码用于当前在线会话的内容 ( 即， 使用此处 所述的一个或多个音频 / 视频解压缩技术 )。 在一实施例中， 当会话终止时， 解码器 2900 被 从客户端设备 205 上移除 ( 例如卸载 )。
     在一实施例中， 随着临时解码器 2900 正被下载， 下载器应用程序 2903 通过做出信 道评估 ( 例如， 信道上可达到的数据速率 ( 例如， 通过确定其花多长时间下载数据 )、 信道 上的分组丢失率以及信道的延时 ) 来描绘信道特性。下载器应用程序 2903 生成描述所述 信道评估的信道特征化数据。之后将该信道特征化数据从客户端设备 205 传送到主机服务 下载器 2901， 其使用信道特征化数据来确定如何最好地利用信道将媒体传送到客户端设备 205。
     在下载临时解码器 2900 期间， 客户端设备 205 一般会发送消息回主机服务 205。 这些消息可包括指示无误还是有误地接收到分组的确认信息。此外， 该消息提供反馈至下 载器 2901， 该反馈针对关于数据速率 ( 基于接收分组的速率进行计算 )、 分组错误率 ( 基于 所报告的有误接收的分组的百分比 ) 和信道来回行程延时 ( 基于下载器 2901 接收反馈之 前所花的时间量， 所述反馈关于已被传输的给定分组 )。
     以 示 例 的 方 式， 如 果 数 据 速 率 被 确 定 为 2Mbps， 则和若数据速率被确定为 5Mbps( 例 如 1280×720， 60fps) 相 比， 下载器选择较小的视频窗口分辨率用于编码器 2902( 例如 640×480， 60fps)。可依赖于分组丢失率， 选择不同的向前纠错 (FEC) 或分组结 构。
     如果分组丢失非常低， 则可无纠错地传送压缩的音频和视频。如果是分组丢失适 中， 则可用纠错编码技术 ( 例如， 像之前图 11a、 11b、 11c 和 11d 中描述和示出的那些 ) 传送 压缩的音频和视频。 如果分组丢失非常高， 则可确定不能传送优等质量的视听流， 而客户端 设备 205 可通知用户无法通过通信信道 ( 例如， “链路 (link)” ) 获得主机服务， 或者其可 能尝试建立至具有较低分组丢失的主机服务的不同路由 ( 如下所述 )。
     如果延时短， 则可以以低延时传输压缩的音频和视频并建立会话。如果延时太高 ( 例如高于 80ms)， 则对于需要短延时的游戏来说， 客户端设备 205 可通知用户无法通过链 路获得主机服务 ( 该链路可用但对用户输入的响应时间将是迟缓的或 “滞后的” )， 或者用 户可以尝试建立至具有较低延时的主机服务的不同路由 ( 如下所述 )。
     客户端设备 205 可尝试通过网络 ( 例如互联网 ) 经由另一条路由连接至主机服务 210， 查看是否降低了减损 ( 例如， 分组丢失更小、 延时更短、 或者甚至数据速率更高 )。例 如， 主机服务 210 可从多个地理位置 ( 例如， 主机中心在洛杉矶而一个在丹佛 ) 连接到互联 网， 由于洛杉矶拥挤所以可能有更高的分组丢失， 但是在丹佛没有拥挤。 此外， 主机服务 210 可通过多个互联网服务提供商 ( 例如 AT&T 和康卡斯特 ) 连接到互联网。
     因为主机设备 205 和服务提供商之一 ( 例如 AT&T) 之间的拥挤或其他问题， 分组 丢失和 / 或高延时和 / 或受约束的数据速率可能发生。然而， 如果客户端设备 205 通过另 一个服务提供商 ( 例如康卡斯特 ) 连接到主机服务 210， 其可能可以连接而无拥挤问题和 / 或较低的分组丢失和 / 或较短延时和 / 或更高的数据速率。因此， 当下载临时解码器 2900 时， 如果客户端设备 205 经历了高于指定阈值 ( 例如， 指定持续时间上， 指定数量的分组丢弃 ) 的分组丢失、 高于指定阈值的延时和 / 或低于指定阈值的数据速率， 在一实施例中， 其 尝试通过可选的路由重新连接到主机服务 210( 一般通过连接到不同的 IP 地址或不同的域 名 )， 以确定是否可获得更好的连接。
     可选连接选项耗尽后， 如果连接依旧经历不可接受的减损， 则其可能是 ： 客户端设 备 205 到互联网的本地连接遭受减损， 或者是 ： 离主机服务 210 太远而不能获得适当的延 时。在此情况下， 客户端设备 205 可能通知用户无法通过链路获得主机服务或者主机服务 仅仅是有损可用的、 和 / 或只有某些类型的低延时游戏 / 应用程序是可用的。
     因为主机服务 210 和客户端设备 205 之间的链路特征的评估和潜在的改进是在临 时解码器正被下载时进行的， 所以其降低了客户端设备 205 分别下载临时解码器 2900 和评 估链路特征所需的花费的时间量。但是在另一实施例中， 客户端设备 205 将下载临时解码 器 2900 与链路特征的评估和潜在改进 ( 例如， 通过使用虚构的测试数据而非解码器程序代 码 ) 分开执行。为什么这可能是较佳实施有很多原因。例如在某些实施例中， 客户端设备 205 部分或全部实施为硬件。因此， 对于这些实施例， 本身没有必要下载软件解码器。
     使用基于标准的图像块大小的压缩
     如上所提及， 当使用基于图像块的压缩时， 本发明的基本原理并不限于任何特定 的图像块大小、 形状或方向。例如在诸如 MPEG-2 和 MPEG-4 的基于 DCT 的压缩系统中， 图像 块可能是宏块 (macroblock)( 数据压缩中使用的部件， 其一般表示 16×16 像素的块 ) 的大 小。此实施例提供了用于与图像块一起工作的非常精细的粒度等级。
     此外， 不管图像块大小如何， 可以使用各种类型的铺放模式。例如， 图 30 示出了一 实施例， 其中 R 帧 3001-3004 的每一个中都使用了多个 I- 图像块。使用了旋转模式， 其中 在每个 R 帧散布 I- 图像块， 使得每四个 R 帧生成一个完整的 I- 帧。以这种方式散布 I- 图 像块将降低分组丢失的影响 ( 将丢失限制到显示器的小区域内 )。
     图像块的大小还可为基本压缩算法的整体自然结构。例如， 如果在一个实施例中 使用 H.264 压缩算法， 图像块被设定为 H.264“片 (slice)” 的大小。这允许此处所述的技 术易于集成到各种不同标准压缩算法的环境中， 该算法例如是 H.264 和 MPEG-4。一旦图像 块大小被设定为自然压缩结构， 可实施如上所述的那些技术同样的技术。
     用于流倒回 (REWIND) 和回放操作的技术
     如之前连同图 15 所描述的， 由应用程序 / 游戏服务器 1521-1525 生成的未经压缩 的视频 / 音频流 1529 可由共用硬件压缩 1530 以多种分辨率压缩， 同时生成多个经压缩的 视频 / 音频流 1539。例如， 由应用程序 / 游戏服务器 1521 生成的视频 / 音频流可由共用硬 件压缩 1530 以 1280×720×60fps 压缩， 并作为出埠互联网通信 1599 经由出埠路由 1540 传送给用户。同样的那种视频 / 音频流同时可由共用硬件压缩 1530 按比例缩小到缩略图 尺寸 ( 例如 200×113)， 并经由路径 1552( 或通过延迟缓冲器 1515) 发送到应用程序 / 游戏 服务器 1522， 以显示为图 16 中缩略图集合的一个缩略图 1600。当缩略图 1600 经过图 17 中级尺寸 1700 而被放大到图 18 中的尺寸 1800(1280×720×60fps) 时， 并非对缩略图流 进行解压缩， 应用程序 / 游戏服务器 1522 可解压缩发送到应用程序 / 游戏服务器 1521 的 用户的 1280×720×60fps 流的复本， 并且缩放到较高分辨率的视频， 便如同其被从缩略图 尺寸而缩放到 1280×720 尺寸那样。该方法具有两次重用 1280×720 压缩流的优点。但其 具有若干缺点 ： (a) 发送到用户的经压缩的视频流可能在图像质量上变化， 如果用户互联网连接的数据吞吐量变化导致由应用程序 / 游戏服务器 1522 的 “出席观看 (spectating)” 的用户观看的图像质量变化， 即使用户的互联网连接并未变化， (b) 应用程序 / 游戏服务器 1522 将不得不使用处理资源来解压缩整个 1280×720 图像， 而且之后缩放此图像 ( 可能应 用重采样滤波器 ) 以在缩放期间显示小得多的尺寸 ( 例如 640×360)， (c) 如果由于有限的 互联网连接带宽和 / 或丢失的 / 损坏的分组而丢帧， 出席观看的用户 “倒回” 并 “暂停” 延 迟缓冲器 1515 中记录的视频， 出席观看的用户将发现延迟缓冲器中的丢帧丢失 ( 如果用户 逐帧 “步进” ， 这将会格外明显 )， 以及 (d) 如果出席观看的用户倒回以延迟缓冲器中所记录 的视频中寻找特定帧， 则应用程序 / 游戏服务器 1522 将不得不在延迟缓冲器中所记录的视 频流中寻找先于所寻帧的 I 帧或 I 图像块， 之后解压缩所有的 P 帧 / 图像块， 直到达到想要 的帧。同样的限制将不仅存在于 “出席观看” 视频 / 音频流直播的用户， 而且还存在于观看 视频 / 音频流的存档复本 ( 例如 “精彩剪辑 (Brag Clip)” ) 复本的用户 ( 包括生成视频 / 音频流的用户 )。
     本发明的可选实施例通过用不止一种的尺寸和 / 或结构来压缩视频流来解决这 些问题。如此处所描述的， 一个流 (“直播” 流 ) 基于网络连接的特征 ( 例如数据带宽、 分 组可靠性 ) 和用户的本地客户端能力 ( 例如解压缩能力、 显示器分辨率 ) 而被最佳地压缩 并流向终端用户。 其他流以高质量、 一个或更多分辨率、 以及可经受视频回放检验的结构来 压缩 ( 此处被称为 “HQ” 流 )， 这种 HQ 流被路由和存储到服务器中心 210 中。例如在一实施 例中， 所述 HQ 压缩流存储于 RAID 磁盘阵列 1515 并用于提供诸如暂停、 倒回的功能以及其 他回放功能 ( 例如 “精彩剪辑” ， 其可发布给其他用户进行观看 )。
     如图 31a 所示， 本发明的一个实施例包括解码器 3100， 其至少能够以至少两种格 式压缩视频流 ： 一种格式 3110 为周期性包括 I- 图像块或 I- 帧， 一种格式 3111 不包括 I- 图 像块和 I- 帧， 除非由于流的中断或因为 I- 图像块或 I- 帧被确定为可能小于 I- 图像块或 I- 帧 ( 如上所述 ) 而有必要包括 I- 图像块和 I- 帧。例如， 当播放视频游戏时传送到用户 的 “直播 “流 3111 可仅仅使用 P- 帧 ( 除非 I- 图像块或 I- 帧是必要的或者更小， 如上所 述 ) 压缩。此外， 此发明的编码器 3100 同时以第二种格式压缩直播视频流 3111， 在一实施 例中， 所述第二种格式周期性地包括 I- 图像块或 I- 帧 ( 或者相似类型的图像格式 )。
     虽然上述实施例使用 I- 图像块、 I- 帧、 P- 图像块和 P- 帧， 但本发明的基本原理并 不限于任何特定的压缩算法。例如， 可使用任意类型的图像格式取代 P- 图像块或 P- 帧， 在 该图像格式中， 帧依赖于先前或随后的帧。 同样地， 可使用任意类型的图像格式代替上述的 I- 图像块或 I 帧， 该图像格式并不依赖先前或随后帧。
     如上所提及的， HQ 流 3110 包括周期性的 I- 帧 ( 例如在一实施例中， 大约每 12 个 帧 )。 这是很重要的， 因为如果用户总是想将所存储视频流快速倒回到特定点， 则需要 I- 图 像块或 I- 帧。在只有 P- 帧 ( 例如， 序列的第一帧不是 I- 帧 ) 的压缩流的情况下， 解码器 必须回到序列的第一帧 ( 其可能有数小时长 )， 之后将 P 帧解压缩， 直至到达用户想倒回的 点。 通过 HQ 流 3110 内每 12 帧存储的 I- 帧， 用户可决定倒回到特定点， 且 HQ 流的最接近的 前一 I- 帧仅比想要的帧靠前不超过 12 帧。即使解码器最大解码率是实时的 ( 例如 ： 对于 60 帧 / 秒的流来说是一秒的 1/60)， 则离 I- 帧为 12( 帧 )/60( 帧 / 秒 ) ＝ 1/5 秒远。而在 许多情况下， 解码器能够比实时操作得更快， 所以例如以 2× 实时的解码率， 解码器能够在 6 帧的时间中解码 12 帧， 用于 “倒回 “的延迟仅为一秒延迟的 1/10。不用说， 如果最接近的前一 I- 帧先于倒回点大量帧， 即使快速解码器 ( 例如 10× 实时 ) 亦将具有不可接受的延 迟 ( 例如， 它将花 1 小时 /10 ＝ 6 分钟来做一次倒回 )。在另一实施例中， 使用周期性 I- 图 像块， 在此情况下， 当用户寻求倒回时， 解码器将会寻找先于倒回点的最接近的前一 I- 图 像块， 之后着手从那点开始该图像块的解码， 直到解码所有图像块到该倒回点。 虽然周期性 I- 图像块或 I- 帧与完全没有 I- 帧相比会导致更低效的压缩， 但是主机服务 210 一般具有 足够多的本地可用带宽和存储能力来管理 HQ 流。
     在另一实施例中， 编码器 3100 编码具有周期性 I- 图像块或 I- 帧的 HQ 流， 该 I- 图 像块或 I- 帧跟随有 P- 图像块或 P- 帧， 如前所述， 且之前还存在 B- 图像块或 B- 帧。如之 前所述， B- 帧是先前于 I- 帧的帧， 且基于在时间上往回 (backward) 工作时与 I- 帧的帧 差异。B- 图像块是图像块副本， 先前于 I- 图像块且基于时间上往回 (backward) 工作时与 I- 图像块的帧差异。此该实施例中， 如果想要的倒回点是 B- 帧 ( 或包含 B- 图像块 )， 则解 码器会寻找最接近的下一 I- 帧或 I- 图像块， 并在时间上往回解码， 直到想要的倒回点被解 码， 之后视频回放从该点向前进行， 解码器将逐帧向前解码 B- 帧、 I- 帧和 P- 帧 ( 或它们的 图像块副本 )。除了 I 和 P 类型之外， 使用 B- 帧或 B 图像块的优点在于 ： 在给定压缩比下， 通常能够达到更高的质量。
     在再一个实施例中， 编码器 3100 将 HQ 流编码为全部的 I- 帧。此方法的优点在 于： 每个倒回点都是 I- 帧， 从而为了达到该倒回点， 不需要解码其他帧。缺点在于 ： 和 I、 P 或 I、 P、 B 流编码相比， 经压缩的数据速率将会非常高。
     其他视频流回放操作 ( 例如 ： 快速或慢速倒回， 快速或慢速前向等 )， 一般由周期 I- 帧或 I- 图像块 ( 单独或组合使用 P 和 / 或 B 副本 ) 更加实际地完成， 因为在每种情况 下， 与在时间上逐帧前向相比， 流均以不同的帧顺序被回放， 从而解码器需要寻找和解码序 列中特定的 ( 通常是任意的 ) 帧。例如， 在非常快速的快进 ( 例如 100× 速度 ) 情况下， 所 播放的每下一帧均在先前帧 100 帧之后。 即使利用具有以 10× 实时运行且在 1 个帧时间内 解码 10 帧的解码器， 它将仍然是 10×， 太慢而不能获得 100× 的快进。 然而， 利用如前所述 的周期 I- 帧或 I- 图像块， 解码器能寻找最接近下一次播放所需的帧的适用 I- 帧和 I- 图 像块， 且仅解码至目标帧的点的中间帧或图像块。
     在另一实施例中， I 帧以一致的周期数 ( 例如总是每 8 个帧 ) 被编码入 HQ 流中， 用户可用于快进和倒回的倍速就是 I- 帧周期数的精确倍数， 所述快进和倒回比 I- 帧速率 更快。例如， 如果 I- 帧周期数是 8 帧， 则使得用户可用的快进或倒回速度可能是 1×， 2×， 3×， 4×， 8×， 16×， 64× 和 128× 以及 256×。对于比 I- 帧周期数更快的速度， 解码器将 首先以该速度向前跳转到一定数量的帧之前的最接近的 I- 帧 ( 例如， 如果当前所显示的帧 比 I- 帧领先 3 帧， 则以 128×， 解码器将跳到靠前 128+3 帧的帧 )， 之后对于每个后续的帧来 说， 解码器将随着所选速度 ( 例如以 128× 的所选速度， 解码器将跳转 128 帧 ) 跳转精确数 量的帧， 每次它将精确地落在 I- 帧上。因此假定比 I- 帧周期数快的所有速度是 I- 帧周期 数的精确倍数， 解码器将永不需要解码任何先前或后继帧来寻找想要的帧， 且仅需要针对 每一显示的帧， 解码一个 I- 帧。 对于比 I- 帧周期数更慢的速度 ( 例如 ： 1×， 2×， 3×， 4×)， 或者对于作为 I- 帧周期数的非倍数的更快速度， 对于所显示的每个帧， 解码器寻求一帧， 该帧使得显示想要的帧所需要的额外新解码的帧的数量最少， 该帧可为未解码的 I- 帧或 且仍为解码形式的已解码的帧 ( 在 RAM 或其他快速存储器中 )， 之后， 如果必要， 可解码中间帧， 直到想要的帧被解码和显示。例如以 4× 的速度快进， 在具有 8×I- 帧周期数的 I、 P 编码序列中， 如果当前帧是靠后 I- 帧 1 帧的 P- 帧， 而将被显示的想要的帧为 4 帧之后帧， 其为之前的 I- 帧之后的第 5 个 P- 帧。如果当前显示的帧 ( 其刚被解码 ) 被用作起始点， 该解码器将需要再解码 4 个 P- 帧来显示想要的帧。如果使用之前的 I- 帧， 为了显示想要 的帧， 解码器将需要解码 6 帧 (I- 帧和随后的 5 个 P- 帧 )。( 明显地， 在这种情况下， 使用 当前显示的帧来最小化需额外解码的帧是有利的 )。之后， 下一个将被解码的靠前 4 帧， 为 I- 帧之后的第一个 P- 帧。这种情况下， 如果当前解码的帧被用作起始点， 解码器还需解码 4 个帧 (2 个 P- 帧、 一个 I- 帧和一个 P- 帧 )。但是， 如果使用下一个 I- 帧来替代， 解码器 将仅需要解码 I- 帧和后续的 P- 帧。( 明显地， 在这种情况下， 使用下一个 I- 帧作为起始点 来最小化需额外解码的帧是有利的。) 因此， 在此实例中， 解码器可在使用当前解码的帧作 为起始点与使用随后的 I- 帧作为起始点之间交替。作为一主要原则， 不管 HQ 视频流回放 模式 ( 快进、 倒回或步进 ) 和速度如何， 对于该回放模式和速度下所显示的每个后续帧， 解 码器将从一使得显示想要的帧所需要的新解码的帧的数量最少的帧开始， 即 I- 帧或之前 解码的帧。
     如图 31b 所示， 主机服务 210 的一个实施例包括用于管理重放 HQ 流 3110 的用户 请求的流重放逻辑 3112。流重放逻辑 3112 接收客户请求 ( 该请求含有视频回放命令 ( 例 如： 暂停、 倒回、 从一指定点回放等 ))、 翻译该命令并从指定点解码 HQ 流 3110( 开始于 I- 帧 或之前解码的帧， 视情况而定， 之后向前或向后进行到指定点 )。在一实施例中， 向编码器 3100 提供经解码的 HQ 流 ( 可能是同一个编码器 3100， 如果其一次能够编码不止一个流， 或 者是单独的编码器 3100)， 以便其可被重新压缩 ( 使用此处所述的技术 ) 并被传送给客户端 设备 205。客户端设备上的解码器 3102 之后如上所述地解码并再现该流。
     在一实施例中， 流重放逻辑 3112 并不解码 HQ 流并在之后使编码器 3100 重新编码 该流。相反地， 其简单地从指定点将 HQ 流 3110 直接流向客户端设备 205。客户端设备 205 上的解码器 3102 之后解码 HQ 流。因为此处所述的回放功能一般不具有像播放实时视频游 戏那样的低延时需求 ( 例如 ： 如果玩家只是简单地查看先前的游戏播放， 而不是主动玩该 游戏 )， 所增加的普通高质量 HQ 流一般固有的延时可导致可接受的终端用户体验 ( 例如， 具 有更长延时但是高质量的视频 )。
     以示例而非限制的方式， 如果用户正在玩视频游戏， 则编码器 3100 提供具有本 质上所有 P- 帧的直播流， 所述 P- 帧针对用户的连接和本地客户端而被优化 ( 例如， 大约 1.4Mbps， 640×360 的分辨率 )。同时， 编码器 3100 还在主机服务 310 内将视频流压缩为 HQ 流 3100， 并将该 HQ 流存储在本地数码视频解码器 RAID 阵列上， 例如以 1280×720、 10Mbps， 每 12 帧具有 I- 帧。如果用户击 “暂停” 按钮， 则游戏将暂停在客户最后解码的帧上， 且屏幕 将冻结。之后如果用户击 “倒回” 按钮， 流重放逻辑 3112 将从 DVR RAID 中读取开始于最近 的 I- 帧或可用的已被解码的帧的 HQ 流 3110， 如上所述。若有需要的话， 流重放逻辑 3112 将解压缩中间的 P 或 B 帧， 若有需要的话并对帧进行重新排序， 以便以想要的倒回速度倒退 (backward) 回放序列， 之后调整 ( 使用本领域公知的现有技术的图像缩放技术 ) 想要解码 的、 打算从以 1280×720 进行显示变为以 640×360 进行显示的流， 之后直播流编码器 3100 将以 640×360 的分辨率重新压缩重排序的流并将其传送给用户。如果用户再次暂停， 并单 步浏览视频以近距离地观看序列， DVR RAID 上的 HQ 流 3110 可具有可用于单步执行的每个帧 ( 即使原始直播流可能由于此处所述众多原因中的任何原因而丢帧 )。此外， HQ 流中每 一点上的视频回放的质量将非常高， 而在直播流中可能存在某些点因带宽受损而导致经压 缩的图像的质量的临时降低。当受损图像质量持续一简短时段或在运动图像中时， 其是可 被用户接受的， 如果用户在特定的帧处停止 ( 或者缓慢地单步执行 ) 并仔细近距离地研究 帧， 受损质量可能不被接受。通过指定 HQ 流内的点 ( 例如， 前 2 分钟 )， 还向用户提供快进 或跳特定点的能力。在直播视频流仅是 P- 帧或者很少 ( 或者不可预测的 ) 有 I- 帧的情况 下， 所有这些操作都是无法以其完全通用性及高质量执行的。
     在一实施例中， 向用户提供视频窗口 ( 未示出， 诸如 Apple QuickTime 或 Adobe Flash 视频窗口 )， 该视频窗口具有 “刷子 (scrubber)” ( 即， 左 - 右滑动块控制 )， 其早在 HQ 流存储视频之前， 就允许用户向前或向后扫描浏览视频流。虽然对用户来说便好像是他或 她正 “刷” 过直播流， 事实上他或她正 “刷” 过所存储的 HQ 流 3110， 该 HQ 流 3110 之后被调 整大小并被重新压缩为直播流。 此外， 如前所述， 如果同一时刻的其他任何人或不同时刻的 用户观看 HQ 流， 该 HQ 流可以以比当同时编码 HQ 流时的直播流的分辨率更高的 ( 或更低 ) 的分辨率被观看， 而质量将和观看者的直播流的质量一样高， 潜在地可达到 HQ 流的质量。
     因此， 通过同时编码直播流 ( 如此处所述， 以针对其低延时、 带宽和分组容错要求 的合适方式 ) 和具有其高质量、 流回放操作需求的 HQ 流， 从而向用户提供这两种场景的想 要的配置。而事实上， 对用户来说高效透明的是 ： 存在两种被不同编码的不同流。从用户的 角度看， 该体验高度响应的， 具有很低的延时， 尽管运行于高度可变的且相对低带宽的互联 网连接上， 但数码视频记录 (DVR) 功能是非常高质量的， 具有灵活的操作和灵活的速度。
     因为上述技术， 用户在在线游戏游玩或其他在线交互期间受益于直播和 HQ 视频 流， 不受直播流或 HQ 流中任一个的限制。
     图 31c 示出了执行上述操作的系统架构的一个实施例。如图所示， 在此实施例中， 编码器 3100 分别编码一系列的 “直播” 流 3121L、 3122L 和 3125L 以及对应系列的 “HQ” 流 3121H1-H3、 3122H1-H3 和 3125H1-H3。每个 HQ 流 H1 被全分辨率编码， 而每个编码器 H2 和 H3 在编码之前将视频流缩放到的更小尺寸。例如， 如果视频流是 1280×720 的分辨率， H1 将以 1280×720 的分辨率编码， 而 H2 可缩放到 640×320 且以该分辨率编码， 而 H3 可缩放 到 320×180 并以该分辨率编码。可使用任意数量的同时的 Hn 缩放器 / 编码器， 提供各种 分辨率的多个同时 HQ 编码。
     每个直播流响应于经由入埠互联网连接 3101 接收的信道反馈信号 3161、 3162 和 3165 而工作， 如上所述 ( 例如参见图 25-26 中反馈信号 2501 和 2601 的论述 )。直播流经 由出埠路由逻辑 3140 在互联网 ( 或其他的网络 ) 上向外传送。直播压缩器 3121L-3125L 包括基于信道反馈 ( 包括缩放、 丢帧等 ) 而调节 (adapting) 压缩视频流的逻辑。
     入埠路由逻辑 3141 和 1502 经由信号路径 3151 将 HQ 流路由到内部延迟缓冲 器 ( 例如 RAID 阵列 3115) 或其他数据存储设备， 和 / 或经由信号路径 3152 将 HQ 流反 馈给用于额外处理的应用程序 / 游戏服务器和编码器 3100。如上所述， 一旦请求， HQ 流 3121Hn-3125Hn 随后被流入到终端用户 ( 例如参见图 31b 和关联内容 )。
     在一实施例中， 编码器 3100 被实施为图 15 中所示的共用硬件压缩逻辑 1530。在 另一实施例中， 某些或所有编码器和缩放器是单独的子系统。本发明的基本原理不限于任
     何特定的缩放或压缩资源的共用或硬件 / 软件配置。
     图 31c 配置的优点在于 ： 需要小于全尺寸视频窗口的视频窗口的应用程序 / 游戏 服务器 3121-3125 将无需处理和解压缩全尺寸的窗口。此外， 需要介于中间的窗口尺寸的 应用程序 / 游戏服务器 3121-3125 可接收接近于所要窗口尺寸的经压缩的流， 之后按比例 增大或缩小至想要的窗口尺寸。此外， 如果多个应用程序 / 游戏服务器 3121-3125 向另一 个应用程序 / 游戏服务器 3121-3125 请求同样尺寸的视频流， 入埠路由 3141 可执行 IP 多 播技术， 例如本领域公知的那些技术， 并将所请求的流一次性广播到多个应用程序 / 游戏 服务器 3121-3125 上， 无需将单独的流广播到做出请求的每个应用程序 / 游戏服务器。如 果接收广播的应用程序 / 游戏服务器改变视频窗口的尺寸， 其可切换至不同视频尺寸的广 播上。因此任意大数量的用户能够同时观看应用程序 / 游戏服务器视频流， 每一用户可灵 活缩放其视频窗口， 并总是获得缩放到接近想要窗口尺寸的视频流的好处。
     图 31c 所示方法的一个缺点在于 ： 在主机服务 210 的许多实际实施中， 从未有出 现过所有的压缩 HQ 流被一起观看的情况， 更不用说所有压缩 HQ 流的所有尺寸。当编码器 3100 被实现为共用资源 ( 例如 ： 缩放器 / 压缩器， 可实现为软件或硬件 ) 时， 减轻了此浪费。 但是， 由于涉及带宽， 将大量的未压缩流连接到公共的共用资源时可能会存在实际的问题。 例如， 每个 1080p60 流几乎是 3Gbps， 其甚至远远超过千兆位以太网。下面的可选实施例解 决了该问题。
     图 31d 示出了主机服务 210 的可选实施例， 其中每个应用程序 / 游戏服务器 3121-3125 具有两个分配给它的压缩器 ： (1) 直播流压缩器 3121L-3125L， 其基于信道反馈 3161-3165 调节经压缩的视频流， 以及 (2) 输出全分辨率的 HQ 流的 HQ 流压缩器， 如上所述。 值得注意的是， 直播压缩器是动态和自适应的， 与客户端 205 使用双向通信， 而 HQ 流是非自 适应性的和单向的。流之间的其他差异为 ： 直播流质量可以动态地变化， 依赖于信道条件 和视频资料的特性。一些帧可能是低质量的， 可能存在丢帧。此外， 直播流可能几乎全部是 P- 帧或 P- 图像块， 少有 I- 帧和 I- 图像块出现。HQ 流和直播流相比一般具有更高的数据 速率， 其将提供一致的高质量， 不会丢弃任何帧。 HQ 流可能全是 I- 帧， 或者可具有频繁的和 / 或规律的 I- 帧或 I- 图像块。HQ 流还可包括 B- 帧或 B- 图像块。
     在一实施例中， 共用视频缩放和重新压缩 3142( 下面详述 ) 只选择某些 HQ 视频 流 3121H1-3125H1， 在发送到如前所述的用于路由的入埠路由 3141 之前， 其将以一个或多 个不同的分辨率而被缩放和重新压缩。其他 HQ 视频流或者以全尺寸通过之前所述的用于 路由的入埠路由 3141， 或者根本不通过。在一实施例中， 基于是否有请求特定分辨率 ( 或 者接近于缩放的分辨率或全分辨率 ) 的特定 HQ 流的应用程序 / 游戏服务器 3121-3125 来 做出该决定 ： 哪些 HQ 流被缩放和重新压缩， 和 / 或哪些 HQ 流完全通过。通过该方法， 只 有被缩放和重新压缩的 HQ 流 ( 或者潜在地完全通过 ) 是实际需要的 HQ 流。在主机服务 210 的众多应用中， 这导致缩放和压缩资源的显著减少。此外， 假定每个 HQ 流至少由压缩 器 3121H1-3125H1 以全分辨率压缩， 和若其是接受的未经压缩的视频相比， 被路由所需的 带宽以及共用视频缩放和重新压缩 3142 中的带宽会显著地降低。例如， 3Gbps 未经压缩的 1080p60 流将被压缩到 10Mbps， 且仍然保留非常高的质量。因此， 利用千兆位以太网连接， 虽然不能传送 (carry) 一个未压缩的 3Gbps 视频流， 但可传送许多的 10Mbps 视频流， 在质 量上并不会具有明显的减少。图 31f 示 出 了 共 用 视 频 缩 放 和 重 新 压 缩 3142 以 及 大 量 HQ 视 频 压 缩 器 HQ 3121H1-3131H1 的细节。内部路由 3192 根据来自应用程序 / 游戏服务器 3121-3125 的将特 定视频流缩放到特定尺寸的请求， 一般从 HQ 视频压缩器 HQ 3121H1-3131H1 中选择一个子 集的经压缩 HQ 流。如果所请求的流要被缩放， 则通过解压缩器 3161-3164 路由该所选流子 集中的流， 或者如果所请求的流是全分辨率， 则在未经缩放的视频路径 3196 上路由该所选 流子集中的流。要被缩放的流由解压缩器 3161-3164 解压缩为未经压缩的视频， 之后由缩 放器 3171-3174 将每一个缩放到所请求的尺寸， 之后由压缩器 3181-3184 将每一个压缩。 注 意： 如果以不止一种分辨率请求特定的 HQ 流， 则内部路由 3192 将该流多播 ( 使用本领域从 业者公知的 IP 多播技术 ) 到一个或多个解压缩器 3161-3164 上和 ( 如果所请求的尺寸之 一是全分辨率 ) 出埠路由 3193 上。所有所请求的流， 无论其被缩放 ( 从压缩器 3181-3184) 与否 ( 从内部路由 3192)， 之后被发送到出埠路由 3193。路由 3193 之后将每个所请求的流 发送到请求它的应用程序 / 游戏服务器 3121-3125 上。在一实施例中， 如果不止一个应用 程序 / 游戏服务器请求同样分辨率的同一流， 则出埠路由 3193 将该流多播到做出该请求的 所有应用程序 / 游戏服务器 3121-3125 上。
     在共用视频缩放和重新压缩 3142 的当前优选实施例中， 所述路由通过使用千兆 位以太网开关来实施， 所述解压缩、 缩放以及压缩通过执行每一功能的离散的专门的半导 体器件来实施。同样的功能可以以更高集成度实施在硬件中或由非常快的处理器实施。
     图 31e 显示了主机服务 210 的另一个实施例， 其中之前所述的延迟缓冲器 3115 的 功能在共用视频延迟缓冲、 缩放和解压缩子系统 3143 中实现。 图 31g 示出了子系统 3143 的 细节。子系统 3143 的操作类似于图 31f 中所示的子系统 3142 的操作， 除了 3191 首先根据 来自应用程序 / 游戏服务器 3121-3125 的请求， 选择哪些 HQ 视频流将被路由， 之后请求延 迟的 HQ 流通过延迟缓冲器 3194( 在本实施例被实施为 RAID 阵列 ( 但其可被实施为具有足 够带宽和能力的任何存储媒体 )) 被路由， 未被请求延迟的流通过未经延迟视频路径 3195 被路由。 之后， 延迟缓冲器 3194 和未经延迟视频 3195 的输出基于所请求的流将被缩放或不 被缩放而由内部路由 3192 路由。经缩放的流通过解压缩器 3161-3164、 缩放器 3171-3174 和压缩器 3181-3184 而被路由至出埠路由 3193。未经缩放的视频 3196 也被发送至出埠路 由 3193， 之后， 以之前图 31f 的子系统 3142 中所述的同样方式， 出埠路由 3193 以单播或多 播模式将视频发送到应用程序 / 游戏服务器。
     视频延迟缓冲、 缩放和解压缩子系统 3143 的另一个实施例示于图 31h 中。在该实 施例中， 针对每个 HQ 流提供单独的延迟缓冲器 HQ3121D-HQ 3131D。假定 RAM 和闪存 ROM 的 成本快速下降， 其可用于延迟单独的经压缩的视频流， 与具有共用延迟缓冲器 3194 相比， 这将最终使得成本更低和 / 或更灵活。或者， 在再一实施例中， 单个延迟缓冲器 3197( 以虚 线示出 ) 可以以高性能集合资源 ( 例如， 非常快的 RAM、 闪存或磁盘 ) 单独为所有 HQ 流提供 延迟。在任何一种情况中， 每个延迟缓冲器 HQ 3121D-3131D 能够对来自 HQ 视频源的进行 可变地延迟， 或者无延迟地通过该流。 在另一实施例中， 每个延迟缓冲器能够提供具有不同 延迟量的多个流。所有的延迟或未经延迟均由应用程序 / 游戏服务器 3121-3125 来请求。 在所有这些情况中， 延迟和未经延迟的视频流 3198 被发送到内部路由 3192， 并通过之前所 述的与图 31g 有关的子系统 3143 的其他部分继续下去。
     与各种图 31n 相关的前述实施例中， 注意 ： 直播流使用双向连接， 且是为特定用户量身定做的， 具有最小的延时。HQ 流使用单向连接， 且为单播和多播。注意 ： 虽然多播功能 在这些图中被示为单个单元， 例如可被实施为千兆位以太网开关， 但在大规模系统中， 多播 功能可能通过由多个开关构成的树结构来实施。实际上， 对于来自高等级视频游戏玩家的 视频流， 即为这一情况， 该玩家的 HQ 流被上百万用户同时观看。在这种情况下， 在广播被多 播的 HQ 流的连续阶段， 有可能有大量的单独开关。
     出于诊断的目的， 且为了向用户提供反馈 ( 例如， 让用户知道他的游戏玩法 表演是多么的流行 )， 在一实施例中， 主机服务 210 将明了每个应用程序 / 游戏服务器 3121-3125 的视频流同时有多少观众。这可由用于特定视频流的应用程序 / 游戏服务器通 过保持计算有效请求的数量来实现。因此， 同时具有 100000 名观众的玩家将知道他或她的 游戏玩法是非常流行的， 它将为游戏玩家造成激励， 以做出更好的成绩并吸引观众。当 ( 例 如视频游戏锦标赛比赛的 ) 视频流具有非常高度收视率时， 可能需要讲解员来在电视游戏 比赛期间进行讲解， 这样观看该多播的某些用户或所有用户能够听到他们的解说词。
     应用程序 / 游戏服务器上运行的应用程序和游戏将被提供应用程序编程接口 (API)， 其中应用程序和 / 或游戏可提交对具有特定特征 ( 例如， 分辨率和延迟量 ) 的特定 视频流的请求。此外， 服从于应用程序 / 游戏服务器上运行的操作环境或者图 4a 的主机服 务控制系统 401 的这些 API 可以因为各种原因拒绝这些请求。例如， 所请求的视频流可能 具有某些许可权限限制 ( 例如， 使得它仅可由单个观众观看， 而不会被广播给其他人 )， 可 能有订阅限制 ( 例如， 观众可能必须付费才有权观看该流 )， 可能有年龄限制 ( 例如， 观众可 能必须有 18 岁才能观看该流 )， 可能有保密限制 ( 例如， 使用该应用程序或玩该游戏的人可 能仅限定所选数量或类别的观众可以观看 ( 例如他或她的 “朋友” )， 或者可能根本不允许 观看 )， 可能有需要资料被延迟的限制 ( 例如， 如果用户正在玩隐蔽类游戏， 其中他或她的 位置可被暴露 )。 有任意数量的可能限制流的观看的其他限制。 在任意的这些情况中， 应用 程序 / 游戏服务器的请求将被拒绝， 出具该拒绝的原因， 在一实施例中， 出具可选方案 ( 例 如， 申明须交什么费用来进行订阅 )， 通过该可选方案， 所述请求可被接受。
     之前任意实施例中存储于延迟缓冲器中的 HQ 视频流可被导出到主机服务 210 外 的其他目的中。例如， 特定的感兴趣的视频流可由应用程序 / 游戏服务器请求 ( 一般由用 户请求 ) 导出到 YouTube 上。这种情况下， 视频流和合适的描述信息 ( 例如， 玩家的姓名、 游戏、 时间、 得分等 ) 一起以与 YouTube 格式一致的格式通过互联网而被传送。这可通过通 过在单独流中将解说音频多播到请求这种解说的所有游戏 / 应用程序服务器 3121-3125 上 来实现。通过使用本领域从业者公知的音频混合技术， 游戏 / 应用程序服务器将解说的音 频与发送到用户场所 211 的音频流相合并。很可能存在多个讲解员 ( 例如， 具有不同观点， 或者用不同语言 )， 而用户能够在其中间选择。
     以相似的方式， 分离的音频流可被混合， 或者起作为主机服务 210 中特定视频流 ( 或单独的流 ) 的音频轨的替换， 混合或替换实时的或来自延迟缓冲器的视频流中的音频。 这种音频可以是解说词或叙述， 或者其能够为视频流中角色提供声音。这将使引擎电影 (Machinima)( 来自视频游戏视频流的用户生成动画 ) 很容易被用户创建。
     全篇文档描述的视频流被示为 ： 从应用程序 / 游戏服务器的视频输出中被捕捉的 视频流， 之后该视频流被流出和 / 或延迟并以各种方式而被再使用或发布。同样的延迟缓 冲器可用于保留来自非应用程序 / 游戏服务器源的视频资料并提供用于回放和发布的相同灵活度， 具有适当的限制。这种源包括来自电视台的直播馈送 ( 或者无线电通信， 或者非 无线电通信， 例如 CNN， 或者付费的， 例如 HBO， 或者免费的 )。 这种资源还包括预录制的电影 或电视节目、 家庭电影、 广告以及直播视频电视会议馈送。直播馈送可像游戏 / 应用服务器 的直播输出那样被处理。预录制的资料可像延迟缓冲器的输出那样被处理。
     在一个实施例中， 本文中所说明的各种功能模组及相关联的步骤可由含有用于执 行所述步骤的固线式逻辑的特定硬件组件 ( 诸如， 特殊用途集成电路 ( “ASIC” )) 或由被编 程的计算机组件与定制硬件组件的任何组合来执行。
     在一个实施例中， 可将所述模组实施于诸如 Texas 仪器的 TMS320x 架构 ( 例如， TMS320C6000、 TMS320C5000，…等 ) 的可编程数字信号处理器 (“DSP” ) 上。可使用各种 不同的 DSP， 同时仍遵守所述基本原理。
     实施例可包括如上文所阐述的各种步骤。 所述步骤可体现于引起通用或专用处理 器执行特定步骤的机器可执行指令中。已将与这些基本原理无关的各种元件 ( 诸如， 计算 机存储器、 硬碟机、 输入设备 ) 从图中省去以避免混淆相关方面。
     所公开的标的物的要素也可作为用于储存机器可执行指令的机器介质来提供。 机 器可读介质可包括 ( 但不限于 ) 闪存、 光碟、 CD-ROM、 DVD ROM、 RAM、 EPROM、 EEPROM、 磁卡或 光卡、 传播媒体或适合于储存电子指令的其他类型的机器可读介质。 举例而言， 本发明可作 为计算机程序来下载， 该计算机程序可经由通信链路 ( 例如， 数据机或网络连接 ) 借助于体 现在载波或其他传播媒体中的数据信号而从远程计算机 ( 例如， 服务器 ) 传送到请求计算 机 ( 例如， 客户端 )。
     还应理解， 所公开的标的物的要素也可作为计算机程序产品来提供， 该计算机程 序产品可包括在上面储存有指令的机器可读介质， 所述指令可用于程序化计算机 ( 例如， 处理器或其他电子设备 ) 以执行一序列操作。或者， 所述操作可通过硬件与软件的组合来 执行。机器可读介质可包括 ( 但不限于 ) 软盘、 光盘、 CD-ROM， 及磁光盘、 ROM、 RAM、 EPROM、 EEPROM、 磁卡或光卡、 传播媒体或适合于储存电子指令的其他类型的媒体 / 机器可读介质。 举例而言， 所公开的标的物的要素可作为计算机程序产品来下载， 其中程序可经由通信链 路 ( 例如， 数据机或网络连接 ) 借助于体现于载波或其他传播媒体中的数据信号而自远程 计算机或电子设备传送至请求过程。
     另外， 尽管已结合特定实施例描述所公开的标的物， 但众多修改及变更将适当地 处于本公开的范畴内。因此， 说明书及图式应视为说明性的而非限制性的意义。