技术领域
[0001] 本
发明是交互式图形流传输领域。更具体地但并非排他性地，本发明涉及来自
服务器上的应用的用于在远程客户端上由GPU显示的交互式图形流传输。
背景技术
[0002] 在交互式图形应用(如电脑游戏)领域中，用户通常下载或通过物理介质获得这些应用并且在他们的设备上本地执行这些应用。
[0003] 然而，交互式图形应用的一些提供商期望在服务器处执行图形应用并跨网络将经
渲染的图形从应用流传输至用户用于在用户设备上显示的灵活性和控制
力。
[0004] 采用这种对图形内容进行流传输的形式的
现有技术的当前状态为在专业服务器上执行应用，该专
门服务器提供了CPU、
存储器、后备存储器和
图形处理单元(GPU)，该图形处理单元用于将该应用的输出渲染到
像素的
帧缓冲区中。然后，所产生的像素被检索并被编码成传统的
视频流(例如h.264)，并且被发送至客户端。
[0005] 这种方法存在许多缺点。首先，服务器必须极其强大，足以同时为许多用户运行计算和图形密集型应用；这导致高电力使用(并因此还导致高冷却成本)，这是决定商业可行性的重大问题。
[0006] 其次，现有的视频标准(如h.264)是固有地‘有损’，意味着它们在编码过程中会丢失图像保真度。可以通过增加流的带宽需求来减少压缩假象，但是存在对进入用户住处的带宽的硬限制以及对从服务器共同
定位的
数据中心出来的带宽量的软限制。这意味着这些系统必须接受将压缩假象引入将可行的内容流中。
[0007] 第三，实时视频压缩是巨大的计算密集型过程，其中，所产生的流的带宽需求是已经分配的压缩处理量的函数。这增加了服务器负载和系统等待时间。
[0008] 第四，成千上万的消费者设备(例如，平板计算机、移动设备和智能电视)越来越多地包含强大的GPU，当所有的应用图形处理发生在服务器上时，这些GPU是远远没有被充分利用的资源。
[0009] 第五，随着现在许多设备提供2560*1600像素并且“4k智能电视”(4096像素宽显示器)即将到来，显示
分辨率正在快速地增长。基于像素的压缩系统(如h.264)意味着：要得到这些显示所需要的保真度意味着要增加经编码的视频流的带宽。
[0010] 因此，如果可以开发这样一种交互式图形流系统则将是所期望的：在该系统中，在服务器上执行应用并且在客户端设备上由本地GPU渲染图形。
[0011] 在P·
艾泽特(P Eisert)与P·费希特勒(P Fechteler)的以下文章中描述了一个这样的系统：“计算机图形的低时延流传输(Low Delay Streaming of Computer Graphics)”，第十五届IEEE
图像处理国际会议(IEEE International Conference on Image Processing)，ICIP 2008。然而，在这篇文章中描述的方法包括在客户端处消隐服务器存储器。这种消隐是带宽密集型的，并且甚至可以不必消隐整个图形数据(例如，特定客户端设备的分辨率限制可能不支持高分辨率纹理)。
[0012] MPEG-4标准描述了将压缩的几何网格和纹理传输到远程设备并且可以被适配成提供一种交互式图形流传输系统。然而，要针对单独的交互式应用实现MPEG-4将需要对该应用进行
修改。此外，MPEG-4标准将导致针对每个新流潜在地将图形数据从服务器重传到客户端，导致服务器与客户端之间的带宽的低效率使用。
[0013] 因此，期望一种交互式图形流传输系统，该系统提供了对服务器与客户端之间的带宽的改善的使用，可适应不同的客户端设备能力，并且极少需要或者不需要对交互式图形应用进行重新编程。
[0014] 本发明的目的是提供一种满足以上期望同时克服现有技术的缺点或至少提供有用的替代方案的用于交互式图形流传输的方法和系统。
发明内容
[0015] 根据本发明的第一方面，提供了一种将交互式计算机图形从服务器流传输至客户端设备的方法，该方法包括：
[0016] a)拦截从应用传输去往在该服务器处的图形处理单元(GPU)的多条图形指令；
[0017] b)在该服务器处对这些图形指令进行处理以生成图形数据；
[0018] c)在该服务器处至少针对该图形数据中的部分图形数据生成索引信息；
[0019] d)代替该图形数据将该索引信息传输至客户端设备；
[0020] e)利用该索引信息提取存储在该客户端设备处的相应图形数据；并且[0021] f)使用该相应图形数据在该客户端设备处的图形处理单元(GPU)处渲染计算机图形。
[0022] 该图形数据可以包括图形状态、静态资源和动态资源的集合中的一者或多者。
[0023] 可以对在该图形数据内的多个对象进行散列以生成该索引信息。
[0024] 该动态资源可以包括
顶点缓冲区，并且可以针对该顶点缓冲区的多个经修改的部分生成索引信息。该顶点缓冲区可以被划分成多个
块，并且针对多个经修改的块的运行生成索引信息。可以针对多个经修改的块的修正运行生成索引信息，从而使得该运行从在该运行中的第一个块内的第一个经修改的位延伸到在该运行中的最后一个块内的最后一个经修改的位。该顶点缓冲区可以被划分成对应于多个顶点字段的多个条带，并且针对多个经修改的条带可以生成索引信息。
[0025] 该第一方面的方法可以进一步包括在该服务器与该客户端之间同步该图形数据的步骤。当该图形数据包括纹理时，可以仅同步所使用的这些纹理的数据。该客户端设备的配置文件可以确定图形数据同步。该客户端设备的该配置文件可以通过在该客户端设备处为多个较高分辨率图形分配多个较低分辨率图形来确定图形数据同步。
[0026] 可以在该客户端设备处的显示器上显示这些经渲染的图形。该客户端设备可以响应于这些显示的图形接收用户输入，并且该用户输入可以被传输回至在该服务器上正执行的应用。可以使用UDP至少部分地传输该用户输入。可以在该服务器上合成状态转换事件。
[0027] 该应用可以是由用户从多个应用中选择出来用于在该服务器上执行的。
[0028] 根据本发明的进一步的方面，提供了一种用于对交互式计算机图形流传输的系统，包括：
[0029] 服务器，该服务器被配置成用于拦截从应用传输去往在该服务器处的图形处理单元(GPU)的多条图形指令、处理这些图形指令以生成图形数据、至少针对该图形数据中的部分图形数据生成索引信息、代替该图形数据将该索引信息传输至客户端设备；以及[0030] 客户端设备，该客户端设备被配置成用于利用该索引信息提取存储在该客户端设备处的相应图形数据并且使用该相应图形数据在该客户端设备处的图形处理单元(GPU)处渲染多个计算机图形。
附图说明
[0031] 现在将仅通过举例并且参考附图描述本发明的
实施例，在附图中：
[0032] 图1：示出了展示根据本发明的实施例的系统的
硬件图；
[0033] 图2：示出了展示根据本发明的实施例的处理流
水线的
框图；
[0034] 图3：示出了展示根据本发明的实施例的方法的
流程图；
[0035] 图4：示出了展示根据本发明的实施例的在客户端播放器与服务器之间的交互的框图；
[0036] 图5：示出了展示根据本发明的实施例的拦截图形指令的流程图；
[0037] 图6：示出了展示根据本发明的实施例创建散列键集合的流程图；
[0038] 图7：示出了展示根据本发明的实施例的图形命令压缩的流程图；并且[0039] 图8：示出了展示根据本发明的实施例的顶点缓冲区块的散列法的框图。
具体实施方式
[0040] 本发明提供了一种用于将交互式图形从服务器流传输至客户端设备的方法和系统。
[0041] 该系统采集在服务器上执行的应用的输出并且使用语义驱动的压缩来使能在客户端上使用其自身的图形处理单元(GPU)实时地本地渲染该输出。客户端设备上的用户输入被反馈至服务器以使能与正执行的应用进行交互。
[0042] 驱动应用的数据以及对该数据的处理在服务器上保持安全，同时图形结果被流传输用于在客户端设备上进行渲染。
[0043] 这使得客户端设备能够利用其GPU来将处理成本从服务器上转移，同时保留客户端-服务器架构的安全性优势。
[0044] 在图1中，示出了根据本发明的实施例的交互式图形流传输系统100。
[0045] 系统100包括服务器101和至少一个客户端设备102。服务器101和客户端设备102可以经由通信网络103进行通信。
[0046] 服务器101可以包括中央处理单元104，该中央处理单元被配置成用于执行应用模块、拦截器模块、处理模块和通信模块。
[0047] 客户端设备102可以包括中央处理单元105，该中央处理单元被配置成用于执行第二处理模块、被配置成用于存储索引图形数据的本地存储器106和被配置成渲染图形的图形处理单元(GPU)107。客户端设备102还可以包括用户输入108和显示设备109。显示设备109可以被配置成用于向用户显示经渲染的图形。客户端设备102可以被进一步配置成用于响应于显示的图形接收来自用户的输入并且将该输入传输至服务器101。
[0048] 在图2中，将描述根据本发明的实施例的图形处理流水线200。
[0049] 示出了应用模块201。应用模块201可以是应用的标准
软件部署，该应用响应于用户输入而生成图像，如计算机游戏应用。
[0050] 应用模块201生成用于预期传输至本地图形处理单元(GPU)的图形指令。
[0051] 这些指令可以被拦截器模块202拦截，并且，因此有用地，应用模块201不必被修改成在本发明的图形处理系统的实施例中发挥作用。
[0052] 拦截器模块202可以将所有这些指令转向至处理模块203。因此，执行应用模块201的装置不需要图形处理单元(GPU)或不需要使用图形处理单元。
[0053] 处理模块203可以处理图形指令以生成图形数据，例如图形状态、静态资源或动态资源。
[0054] 然后，处理模块203可以利用此图形数据来生成索引信息。
[0055] 索引信息可以经由通信模块204被传输至远程设备。
[0056] 在远程设备上的第二处理模块205可以接收此索引信息并且可以在远程设备处从本地存储器中检索对应于索引信息的图形数据。
[0057] 此图形数据可以在远程设备处在图形处理单元(GPU)处被渲染器206利用以渲染图形。
[0058] 在图3中，将描述将交互式图形从服务器流传输至客户端设备的方法300。
[0059] 在步骤301中，在服务器上执行的交互式图形应用生成用于图形处理单元(GPU)的图形指令。
[0060] 在步骤302中，这些指令例如被拦截器模块拦截。
[0061] 在步骤303中，这些被拦截的指令例如被处理模块处理以生成图形数据。图形数据可以包括图形状态、静态资源和/或动态资源。
[0062] 在步骤304中，生成针对图形数据的索引信息。例如，在图形数据中的对象可以被散列以生成散列码。
[0063] 在一个实施例中，当动态资源是顶点缓冲区时，该顶点缓冲区可以被分区并且被散列以减少变化之后的对于整个顶点缓冲区的不必要的重传。例如，顶点缓冲区可以被划分成多个块，并且可以针对多个经修改的块的每个运行生成散列。块的运行可以是块的修正运行，从而使得生成从该运行的第一个块的第一改变到该运行的最后一个块的最后改变的散列。
[0064] 在步骤305中，代替图形数据将此索引信息传输至客户端设备。
[0065] 在步骤306中，索引信息用于在客户端设备处检索相应的图形数据。
[0066] 在步骤307中，此图形数据被传输至在客户端设备处的图形处理单元(GPU)以对图形进行渲染。
[0067] 在步骤308中，可以向用户显示图形。
[0068] 在步骤309中，用户可以提供输入，该输入被反馈至在服务器上正执行的交互式图形应用。
[0069] 在一个实施例中，该方法进一步包括在服务器与客户端之间同步图形数据的步骤。在同步过程中，只有一部分图形数据可以被传输。例如，mipmap可以在传输之前被从图形数据中删除并且在客户端处重新生成，可以基于客户端设备的分辨率能力代替高分辨率纹理发送降低分辨率的纹理，并且可以将实际利用的纹理数据传输至客户端设备。
[0070] 将参照图4至图8描述本发明的一个实施例。
[0071] 此实施例准许服务器提供可以从客户端设备远程调用的多个应用。在服务器上运行的应用逻辑以及该应用的图形输出通过互联网被流传输至客户端设备进行本地渲染。
[0072] 将理解的是，所描述的与此实施例有关的各种特征可以被全部实现以呈现该系统或者可以被部分地实现以呈现潜在的不太有效的系统。
[0073] 如图4所示，
进程开始于正在客户端设备(PC、平板计算机、智能电视机、移动设备)上运行的客户端播放器应用程序。此播放器应用程序使用TCP/IP连接到在服务器上运行提供当前可用应用的“转盘(Carousel)”。选择应用并且利用切换至该启动的应用的TCP连接发起针对客户端的会话，因此该应用可以继续与客户端进行通信。
[0074] 这个实施例需要无损下行通信。因此，TCP或无损UDP协议可以有利地用于下行通信，并且(有损但是低时延的)UDP协议可以用于上行客户端输入通信。上行客户端输入(如定位器设备、
键盘、操纵杆)可以全部以一种“绝对形式”与正在服务器上合成的实际“状态转换事件”一起被发送以用于正运行的应用。这种方法可以准许丢掉UDP数据包而不漏掉改变应用行为的潜在重要的状态转换事件。例如，
鼠标随着按钮被按压移动，而不是鼠标在按钮没有被按压的情况下移动。
[0075] 在正常操作中，应用调用3D图形驱动程序的边际效应(side effect)将会是对写入帧缓存中并且被显示的像素的计算。如图5所示，这个实施例的过程通过利用代理对在服务器上运行的现有应用进行干预来运作，该代理将图形命令流以及所有相关联的资源引导到本发明的系统中。
[0076] 该代理管理将数据传输到对数据进行渲染并创建当前图像所在的远程客户端设备。
[0077] 从应用流到3d图形系统的数据量通常很大，并且如果不借助以下描述的语义驱动的压缩处理则难以传递至远程客户端。
[0078] 本发明的这个实施例通过利用从应用流至图形系统的数据表示什么以及怎样以一种有效的方式处理该数据的知识来运作。这个数据流可以被视为用于在远程设备上的扩展状态、演变状态和边际效应(通常是GPU命令)。
[0079] 这个实施例使得观察到：当以30Hz生成帧时，图形资产的工作集以更加适度的速度演变，因为通常存在几何帧间相干。
发明人还观察到：因为该数据流是由在某种粒度程度上具有固定的调度序列的应用所生成的，这可以用于避免传输之前发送至客户端设备的数据。
[0080] 当客户端连接到服务时，作为握手协议的一部分，其为服务器给出：
[0081] ·客户端配置文件，该客户端配置文件详细描述其图形能力和所
请求分辨率。这些图形能力用于确保代理仿效客户端能够执行的。
[0082] ·散列键集合，其中，每个键唯一地标识客户端已本地缓存的数据的blob。这个缓存可以不确定地从CDN(内容传递网络)或从可移除介质(如USB闪盘)由之前的会话填充。
[0083] 散列键集合确保服务器将总是使用散列键(也被称为数据
摘要)而不是重发数据，从而减小了带宽需求。图6示出了通用技术。
[0084] 散列键通常比其所表示的数据要小得多，通常是64位或128位键。然而，通过保持到最近使用的数据blob的散列键的索引的较小附加缓存(例如，256个条目)，可以进一步减小带宽。这允许减小“发送资源更新”命令的大小。
[0085] 图形命令
[0086] 如图7所示，图形命令随着其由应用下发而被采集并且被延迟直到尽可能晚才使用无损
熵编码(如霍夫曼编码)被编码、相对于客户端历史图形命令被去重并且使用滑窗字典被压缩。
[0087] 用于发射命令流的触发器是边际效应命令(如绘制命令或帧结束命令)的表现，在该点处已经被应用改变的所有相关状态被分辨以确保其在远程设备上被同步。
[0088] 应用图形命令帧所需要的数据量(当明显地是应用依赖型时)通常很低，因为在当前帧中所使用的图形命令(但不必是图形参数)与前一帧的图形命令非常相似。
[0089] 分辨改变的状态
[0090] 存在多种类型的用于实时图形中的状态，并且每个状态可以被区别处理：
[0091] ·图形状态
[0092] ·静态资源
[0093] ·动态资源
[0094] 图形状态
[0095] 图形状态包括控制客户端图形系统操作的所有状态。其包括渲染状态(RenderState)和杂项固定功能控制(例如，视口大小(Viewport size)、帧缓冲区清除
颜色)以及
着色器和着色器常量。通过逐渐消隐服务器-客户端状态来处理这些状态，以减少不必要的传输以及由图形应用使用的进入自定义代码中的
包装公共渲染状态突发传送——例如，当创建新的待使用纹理时，几乎所有图形程序还设定缩小倍数过滤和放大倍数过滤以及包装模式。所有这些可以被压缩到单个低开销命令中。
[0096] 着色器常量(也称为均匀性)是由图形应用使用以对其着色器代码进行参数的方法。其作为具有N个4元组的线性寄存器文件呈现给该应用，其中，N通常大于128。这个寄存器文件以任何该应用觉得合适的方式被使用，意味着本发明的这个实施例需要仔细处理这个文件以确保例如并非每次使用着色器时都传输整个寄存器文件。许多过程可以被用于减小带宽：
[0097] ·标识常用值，如0.0和1.0
[0098] ·有损重编码至更低的
精度(例如半浮点数和有范围整数)
[0099] ·每个着色器地消隐寄存器文件以减少抖动
[0100] ·游程长度编码变化
[0101] 静态资源
[0102] 静态资源的生命周期为使得：一旦被创建，这些静态资源就被简单地引用作为图形处理的一部分，直到这些静态资源不再被需要时对其进行处置。
[0103] 针对静态资产，这是以直接的方式运作的，因为应用对于资产做出的任何读/写都可以被干预并且散列的内容可以对照散列键集合被检查。
[0104] 作为标准3d图形API(应用程序编程
接口)的一部分，当应用与图形资源进行交互时，该应用必须提供指示其意图的标志。这些标志被规则的图形
驱动器用来优化本地机器的性能。
[0105] 在这个实施例中，可以重新改变标志的用途以帮助标识可能不变的资源。在当前实施例中，如果资源被标记为“WRITE_ONLY”并且已经涉及这个资源的所有存储器，则可以猜测这是静态资源——例如，静态几何网格。此静态资源可以被散列、进行散列键集合检查并且被可选择地传递至客户端设备。
[0106] 如上所述，着色器代码永远是静态的并且进行散列键集合探测。客户端设备使用不同的着色器语言，因此可以在服务器上使用自动的着色器译码功能以在散列之前将用HLSL写的着色器转换成用GLSL写的着色器。
[0107] 同样地，顶点
声明描述了顶点缓冲区的布局是静态的。
[0108] 大多数的纹理也是静态资产，但是造成其是大型资源的问题。当前实施例通过以下方式减轻这个问题：
[0109] ·只传输实际使用的纹理。进一步细化可以是通过检查几何纹理坐标来标识实际使用的纹理部分，该坐标将纹理图集的区域
指定在地图上。
[0110] ·控制代理图形驱动器的能力以减小将被从应用接受的表观最小纹理尺寸。这利用了以下事实：在应用可以基于用户的图形驱动器的特征和性能改变保真度的一般要求下，图形应用被设计成用于在广泛的性能配置文件上运行。通过改变代理驱动器能力，应用可被间接地控制。
[0111] ·将在其中可以在客户端上生成mipmap的纹理从顶层纹理中标识出来从而减少33％的发送数据量。进一步细化可以是：从确定实际使用纹理的哪个mipmap的之前的游戏会话中收集数据。对于3d内容而言，具有比运行时需要的分辨率高得多的分辨率的纹理并不少见。
[0112] ·使用散列键集合来替代更低分辨率资产更好地匹配于客户端设备能力。这可以被驱除出客户端配置文件并且在每个应用上执行。
[0113] 动态资源
[0114] 和静态资源一样，3d应用经常具有随时间演变的资源，并且这些3d应用造成了针对带宽受限制的客户端设备的挑战。最常见的动态资源编辑是使用被称为顶点缓冲区的包含几何信息的特殊缓冲区。这个顶点缓冲区的格式灵活并且由之前声明的顶点声明定义，该顶点声明描述了顶点缓冲区的不同字段和偏移，使得图形硬件可以解释数据。
[0115] 由应用动态地更新的资源使用
锁定/解锁范式以确保数据、图形硬件的消费者以及数据、应用的生产者不发生冲突。
[0116] 对于3d应用而言，锁定包含几何结构的顶点缓冲区、做出改变并且然后使用那个数据来绘制显示的某个元素很常见。锁定API一般提供用于指示顶点缓冲区的哪个部分将被编辑的参数，然而，这些参数经常由应用为整个缓冲区设定，因为该应用与锁定操作达成的“协定”仅仅是保证不改变由图形硬件正在使用的数据。
[0117] 这个问题可以通过在应用与顶点缓冲区之间引入散列的锁定缓冲区来解决。正如本发明的其他部分，可以利用关于如何从已经被声明的先前结构中处理顶点缓冲区的信息以及关于如何在实践中使用顶点缓冲区的经验知识。
[0118] 散列的锁定缓冲区将顶点缓冲区分割成固定长度的块。在当前实施例中，使用1024字节块，但是这可以出于性能原因被调节。每个块追踪其是否是“污染的”(已经被改变并因此将需要与客户端设备同步)、其是否可以是“干净的”(已经被同步、应用是否曾经可以重写该数据)以及在该污染块中改变是从哪里开始的。
[0119] 随着应用执行锁定-编辑-解锁操作，每个块的此元数据被累积。在因为数据将要被绘制命令使用而必须对其进行解析时，客户端设备必须与服务器同步。
[0120] 为了确保在散列键集合中获得匹配，必须精确地标识出变化的数据的相同运行。标识包括在内的运行将产生不同的散列并因此不允许避免发送大量数据。当前实施例使用污染块的运行来识别需要更新的区域。
[0121] 通过使用第一个块的开始以及最后一个块的结束进一步细化这些区域，其中，数据不同于产生的“污染块的修正运行”。此外，使用确保以正确的粒度处理数据的当前有效的顶点声明，也就是说，因为前几个字节恰好没有不同，所以散列并非开始于顶点结构的中间。通过使用顶点声明，此实施例回退到完整顶点的开始并且在完整顶点的末尾完成。
[0122] 下一个问题是，对于图形应用而言，在顶点缓冲区中交叉存储不同的顶点数据类型是常见且被鼓励的。然而，并非更新顶点的所有字段也是常见的。例如，顶点颜色和顶点纹理坐标可以是常量，但是顶点的
位置是变化的。
[0123] (伪码)顶点声明可能看起来如此：
[0124]
[0125] 当污染块的修正运行可以被散列并且该系统的这种实施例将运行时，可以在每个条带的
基础上在用于处理污染块的修正运行的操作中通过使用顶点声明来进一步减小带宽。
[0126]
[0127] 也就是说，该系统可以跨过顶点缓冲区(选择性地压缩)并且将相似类型的数据散列到一起，使得在此示例中该系统为每个顶点具有的3个字段生成3个散列。结果是该系统将在键集合中找到颜色条带以及纹理坐标条带并且不需要将这些条带发送至客户端设备。当且仅当该系统还未看到顶点位置之前，将需要发送变化的顶点位置。例如，对于循环动画而言，这将用匹配的散列快速地填充键集合。
[0128] 缓冲区重用
[0129] 在当前实施例中，该系统对微软DirectX 3d图形API进行干预并且利用从标志参数中得获得的附加语义洞悉，该标志参数是当该应用锁定顶点缓冲区以及由微软支持的“最佳实践”调用序列时提供的。
[0130] 顶点缓冲区锁定的常见
用例是用动态生成的几何结构逐渐填充缓冲区，直到该缓冲区被填满并且然后从头再次开始。为了确保图形硬件可以继续全速运作，图形API引进针对该应用的2个附加标志：NO_OVERWRITE和DISCARD。
[0131] NO_OVERWRITE意味着该应用承诺永不重写其之前已经写入缓冲区中的任何数据。这个承诺的原因在于图形硬件可以在使用存储器映像、直接存储器存取(DMA)或存取此数据的任何其他手段时保持自信并且保证不过时。
[0132] DISCARD意味着该应用指示缓冲区是“一次性写入”并且随后将不再从中读取。这个承诺的原因在于其允许当应用填充新的缓冲区时并且当缓冲区是解锁时图形硬件继续在现有缓冲区上运作、安静地交换驱动器内部的缓冲区并且处置已知其将永远不再被需要的其他缓冲区。
[0133] 鼓励应用开发人员通过用图形数据逐渐填充NO_OVERWRITE缓冲区、提取其一些部分来一起使用这两个标志。当达到不能再将数据装入缓冲区中的点时，开发人员用DISCARD标志锁定该缓冲区并且从该缓冲区的开始再次开始填充。这个系统允许图形硬件以最高的效率运作。
[0134] 如图8所示，本发明的这个实施例利用这个知识来在针对OVERWRITE锁定的相同缓冲区极有可能被关联之后在DISCARD缓冲区的开始处标识该系统何时检测到块的短污染运行。在DISCARD缓冲区中的块的此短污染运行将很可能不与散列键集合匹配并且需要进行发送。
[0135] 因此，新的DISCARD缓冲区运行可以被当做在缓冲区结尾处的前一运行的继续从而确保散列键集合匹配。
[0136] 本发明的一些实施例的潜在优点在于：
[0137] a)服务器上不需要专业高耗电GPU并且因此可以使用一般的服务器。这进而意味着每个服务器的用户数量可以更高，从而减小运行成本。
[0138] b)本发明可以是分辨率无关的，并且不像基于像素的视频压缩，本发明可以在不增加流带宽需求的情况下以高分辨率进行播放。
[0139] c)对于以高分辨率运行的一些应用，带宽需求可以极低(＜1Mbs)，因为依靠了压缩，该压缩利用了对关于什么被压缩了的知晓。
[0140] d)本发明可以不需要对现有可执行应用的改变，并且因此不需要
访问用于修改的源代码，因此可以在现有的和遗留的软件上被使用。
[0141] e)可以将任意的新内容实时注入流中以将其重新用于新的设备和平台。例如，针对虚拟按钮的
覆盖当在平板计算机上运行时可以被创建、围绕内容的标语广告可以被引入、并且用于将广告插入视频游戏的虚拟世界内部的图像可以被替换。
[0142] f)可以收集来自用户的细粒度资源使用信息以帮助细化哪里的资产被保持在CDN(内容传递网络)上并且为了未来的用户将冗余数据从流中去除。
[0143] 虽然已经通过其实施例的描述说明了本发明，并且虽然已经相当详细地描述了实施例，但是
申请人并不意在将所附
权利要求书的范围限定或者以任何方式限制于这些细节。本领域技术人员将易于想到附加优势和修改。因此，本发明在其较宽的方面并不限于示出和描述的特定细节、代表性装置和方法以及说明性示例。因此，可以在不偏离申请人的总体发明概念的精神或范围的情况下偏离这些细节。
