CN102668495A

CN102668495A - 低延时传输协议的方法和系统

Info

Publication number: CN102668495A
Application number: CN2010800526939A
Authority: CN
Inventors: 斯坦尼斯拉夫·沃纳戈; 尼古拉·苏林; 瓦迪姆·斯塔尤拉
Original assignee: Musigy USA Inc
Current assignee: Net Power and Light Inc; Musigy USA Inc
Priority date: 2009-09-29
Filing date: 2010-09-24
Publication date: 2012-09-12
Also published as: US20110078532A1; AU2010300823A1; JP2013506348A; EP2484091A4; US20120084456A1; CA2774014A1; WO2011041229A3; KR101443070B1; WO2011041229A2; EP2484091A2; US8234398B2; KR20140024478A; US8527654B2; US8171154B2; US20120246227A1; KR20120082434A; US20140164484A1

Abstract

本发明公开了提供计算机生成输出，尤其是图形输出的方法和系统。该系统包含被配置为传送数字信息的网络。该系统包含与网络进行通信的服务器，该服务器被配置为执行应用程序和云引擎模块。该应用程序提供图形输出。输出捕获和编码引擎模块被进一步配置为从服务器的应用程序处拦截图形输出。该输出捕获和编码引擎模块被进一步配置为将图形输出转换成至少图形指令和视频编解码器数据其中之一。该输出捕获和编码引擎模块被进一步配置为通过网络传输转换后的输出。该系统包含通过网络与服务器进行通信的客户端，该客户端被配置为执行图形和视频编码及呈现引擎模块。该图形和视频编码及呈现引擎模块被配置为，响应所接收的被传输转换后输出，和呈现图形输出。该图形和视频编码及呈现引擎模块被进一步配置为在客户端拦截图形和视频解码及呈现输入。该图形和视频编码及呈现引擎模块被配置为将拦截的用户输入，传输至输出捕获和编码引擎模块。

Description

低延时传输协议的方法和系统

对相关申请的交互使用

本申请要求优先权，优先权申请为2009年9月29日提出的申请号：12/569,876的美国专利申请；本申请参考引用并入了如上所述申请的全部内容。

背景技术

虚拟桌面基础架构(VDI)是一个服务器为中心的计算模式，在数据中心主持和管理桌面虚拟机，同时在网络上通过瘦客户机向终端用户提供完整的PC桌面体验。

一些现有的解决方案增加了将引入的客户会话传入传统的共享桌面系统的能力，如微软的终端服务或Citrix的应用服务器、刀片服务器，甚至个人闲置的实体桌上型计算机。

VDI解决方案涉及服务器端窗口实例的远程执行，通过网络，利用如RDP或ICA等协议将屏幕更新发送至客户端显示设备。然而，先前之协议仅约每100毫秒将视频帧缓冲至客户端，因而不适用于如今图形密集型和要求音视频同步的应用程序。

现行有几种能提供VDI解决方案的方法。

“屏幕刮”方法包括利用协议“刮”图形元素，绘制主机的“屏幕”，并传送至客户端。例一，客户端能够联系服务器，并从帧缓冲区拉出一张新的屏幕“快照”。例二，服务器能连续将其屏幕活动推送至客户端。所推送活动可能是帧缓冲级、GDI/窗口管理级，或两者兼有。上述示例能使用缓存在客户端的常用图形元素。

屏幕刮法能与“多媒体重定向”相结合，其中服务器端的多媒体元素以其原生格式发送至客户端设备。客户端可以本地播放多媒体流，并将其动态地插入屏幕上适当位置。

这种方法适用于：(1)客户端具备呈现多媒体的技术能力和硬件，和(2)客户端已安装合适的编解码器，以正确呈现多媒体内容。实际上，这意味着客户端不能“太瘦”。

服务器图形系统虚拟化“虚拟”主机的图形系统。主机上的软件捕获所有可能的图形层(GDI，WPF，DirectX等)，并将其呈现为远程协议流(如远程桌面协议RDP)，尽快发送至客户端。这能给客户端一种体验，该体验很接近局部特性，而与客户端设备无关(低阶或瘦客户端同样适用)。

服务器和客户端的硬件加速使用主机上特殊的芯片组，该芯片组捕捉通过网络传输的屏幕。客户端设备具备相匹配的，用于呈现的特殊芯片组。

上述方法解决了通过网络实时远程显示图形信息的问题，但不能提供低延时和高质量和互动性的动态图形和全动态视频传输。仍存在下列问题：

·对全动态视频的支持有限。

·即使近距离工作(WAN，广域网)，固有延时仍很明显。

·不可信赖网络环境的性能和质量低下，数据包丢失、抖动和延时的可能性较高(如互联网)。

·当网络中出现重大数据流时，不能出于延时和用户体验质量的考虑，优先化流量。

·音视频流量的同步不一致。

·无法处理各种输入和输出，如全身感应、视频、声音、传感器和动作-所有此类都归属于背景信息。

导致上述问题的原因，部分在于，如Microsoft RDP，Citrix ICA，AT&T的VNC等现行方法在设计之时，视频和高度互动性的图形用户接口还未在用户计算机上普及。

因此，需要为远程计算提供改进的传输协议。

附图说明

当参考如下描述，以及各附图，本申请所公开的特征和对象则更显而易见，其中类似参考序号代表类似元素：

图1系为远程计算提供改进传输协议的示例系统。

图2系为远程计算提供改进传输协议的示例服务器。

图3系为远程计算提供改进传输协议的示例客户端。

图4系为远程计算提供改进传输协议的客户端上执行的捕获输出和编码引擎的示例。

图5系为远程计算提供改进传输协议的客户端上执行的解码和呈现引擎的示例。

图6系服务器所执行的示例步骤，依据改进的传输协议进行捕获、编码和发送。

图7系客户端所执行的示例步骤，依据改进的传输协议进行接收、解码和呈现。

图8系为远程计算提供改进传输协议的示例网络堆栈。

图9系服务器所执行的示例步骤，用于提供区域检测模块。

图10系服务器所执行的示例步骤，用于提供简单运动检测模块。

图11A系第一运动检测器的示例屏幕截图。

图11B系第二运动检测器的示例屏幕截图。

图11C系第三运动检测器的示例屏幕截图。

图12系为远程计算提供改进传输协议的示例视频编码器。

图13系预处理图形输出的示例步骤。

图14系提供顺序图像编码器的示例步骤。

发明详述

本申请提供了通过不可信赖的封包交换通信网络实现低延时、实时传输计算机所产生信息至多重互动显示设备的方法和系统。计算机输出信息可以由服务器上执行的应用程序所产生，例如图形输出、音频信号、数据、USB接口信号、打印排队等。系统能将应用程序产生的计算机输出信息通过网络互动式传输至多个终端使用设备。系统能支持各种终端使用设备，如低成本的“瘦”客户机和高性能的工作站，其中每个终端用户设备的可用带宽均不相同。多用户能同时与终端使用设备上同一图像信息进行互动。

该系统在终端使用设备上将捕获的互动数据传输回服务器，并使输入同步，方便应用程序的处理。系统则捕获服务器的图像和其他类型的服务器输入，应用各种编码方法进行编码，并将输出信息传输至终端使用设备。

本系统使用设计假定和目标(低延时、全动态视频、不可信赖网络、网络带宽相对较大等)，能显著区别于其他现行系统。分布式多媒体实时干扰系统中使用了类似方法，要求通过互联网最低延时(低于50毫秒)传输高质量的音频流，同时能精确同步上述流。该方法在各参考材料中予以讨论，包括：

申请于2007年3月13日的美国专利申请：11/717,606，名称：“Methodand System for Low Latency High Quality Music Conferencing”，该申请要求优先权，优先权申请为2006年3月22日提出，申请号：60/785,145，名称：“Method and system for low latency high quality music conferencing”的美国临时专利申请。

″Virtual Jamming.Four Fixes for the Major Problem Facing MusiciansWho Play Together on the Web：Lag″

http://www.spectrum.ieee.org/computing/software/virtual-jamming(最后更新于2009年9月10日)；以及

申请于2008年1月31日的美国专利申请：12/024,089，名称：“Methodand System for Precise Synchronization of Audio and Video Streams During aDistributed Communication Session With Multiple Participants”，该申请要求优先权，优先权申请为2007年1月31日提出，申请号：60/887,555，名称：“Method and System for Low Latency High Quality Music Conferencing”的美国临时专利申请。

本申请参考引用并入了如上所述参考材料的全部内容。

图1系为远程计算提供改进传输协议的示例系统。该系统能在地理上分布，并通过宽带网络进行通信，如互联网。

系统包含一台实体或虚拟服务器112，在操作系统上执行软件程序113的实例。例如，操作系统可以是Windows，Mac OS X，UNIX，Linux等。

应用程序的输出113被捕获和编码引擎114所捕获，下文将进行探讨。例如，上述输出可以为执行中应用程序113所提供用户接口的图形输出。

引擎114同样能捕获其他类型的输出。例如，音频输出能通过系统被捕获，用于编码和传输。

引擎114在服务器112上执行，通过宽带网络111，利用低延时混合网络堆栈传输对应用程序进行捕获和编码，下文将探讨。例如，上述网络可以是基于IP的网络、蜂窝网络、3G或4G无线网络、电缆线等。

该传输能在网络111上通过多个流109和110同时转播至多个接收器，利用多点传送(如果可用)来降低网络的负载。应该能够理解，依据网络111的可用带宽，本系统能适用任意数量的接收器。系统被配置使延时最小化，从而提升用户体验。例如，如果接收器的带宽不足(或网络发生拥塞)，系统则动态地降低图形质量，或减少流量带宽，从而维持低延时。

示例系统包括两个接收器：笔记本电脑103和灵活显示设备(电子纸)104。例如，笔记本电脑103可以是低成本的计算设备，如ASUS′Eee PC，基于Intel Atom CPU和Intel GMA 945图形加速芯片。类似的笔记本电脑也同样适用。

每个接收器包含图形、视频解码和呈现引擎(GVDR引擎)。笔记本电脑103包含基于软件的GVDR引擎和在笔记本电脑103上执行的操作系统。灵活显示设备包含硬件GVDR引擎107，以集成电路或数据信号处理器(DSP)，处理单元，存储单元的芯片组实现。应该能够理解，依据用户需求和可用资源，GVDR也能通过其他方式实现。或者，该视频解码和呈现引擎可能是外部硬件设备，如USB。实施例之一可能是具有网络输入和HDMI输出的小型电视盒。网络输入能连接到有线网络(电缆、以太网等)或无线网络(Wi-Fi等)。

应该可以理解的是，GVDR引擎易于实施，能在多种计算平台或消费性电子设备以各种方式适用。这能允许各种设备在本系统中起到接收器的作用。

GVDR引擎107和108在各自的接收器系统103和104上呈现应用程序113的图形105和106。此外，GVDR引擎107和108能呈现视频数据、音频数据以及所捕获的从应用程序输出的其他数据。

必要时，图形105和106能被刷新，刷新速率能从每秒15帧到每秒60帧刷新图片特定区域不等，或更频繁地如使用现时的显示设备。应该能够理解的是，依据系统资源和性能要求，更高的帧率也能实现。高帧率能提供更优化的用户体验。一个实施例中，图像的不同区域能以不同的速率刷新，以提升用户体验，下文将进行探讨。

一个实施例中，图形105和106能进行互动。用户101和102的各种输入数据能与设备104和105进行互动，被捕获并发回至应用程序113。输入数据包括：键盘连笔、鼠标移动、触碰和多点触碰事件、动作感应数据、加速度数据、传感器数据，如温度或空气情况、人体生物传感器，如心率传感器或血糖传感器、语音指令、眼球运动，或由电脑解释的神经脉冲等等。

输入数据能传输至引擎114，该引擎集合并传输输入数据至应用程序113。应用程序113能出于处理解释上述输入数据，并将其输出以响应输入数据。该输出又被引擎114捕获，通过网络111传输至接收器103和104，如上所述。

或者，引擎114能解释上述输入数据，以供处理。例如，引擎114能根据应用程序113单独提供的映射方案，将多点触碰事件映射到应用程序的特定指令。应该能够理解的是，输入数据能被应用程序113和引擎114的结合所解释。

在操作中，用户101和102能在同一应用程序113上共同工作。这种协作是系统特征之一，与应用程序是否包含多用户支持无关。

此外，如防火墙和网络地址转换(NAT)的安全和隐私问题被消除。用户101和102启动向信任源服务器112的连接。因此，示例系统中用户101和102从不接收未知和不信任的网络连接。

图2系为远程计算提供改进传输协议的示例服务器。如前所述，服务器201能执行应用程序和GVDR引擎。

服务器201可以是实体或虚拟的，且包含CPU202，以及可选用GPU203。服务器201能包含其他处理硬件单元，例如声卡(图中未显示)。例如，CPU可以是Intel Core i7。例如，GPU可以是Nvidia GeForce 9400。

应用程序204在管理程序中或无管理程序的常规操作系统中执行(操作系统和管理程序在图中未显示)。示例操作系统包含Windows XP，Windows Vista，Windows 7，Windows Server，Windows Mobile，Mac OS X，Mac OS X Server，UNIX，Linux，Symbian，Android等等。

输出捕获组件205从应用程序捕获输出数据，该数据以指令或原始数据的形式。捕获过程的详细情况将在下文进行探讨。例如，元件205可捕捉图像AIP指令(例如GDI或OPEN GL指令等)，从具有高频(20-60Hz)之视频存储器之影像，或是多媒体API指令(例如展示视频等)。

输出编码器206通过低延时混合网络堆栈208对传输的捕获输出数据进行编码。输出多点传送单元207管理通过网络至多个接收器的传输，并确保上述传输在多个接收器之间同步进行。此外，输出多点传送单元207确保适当的输出数据被传输至每个接收器。例如，不同质量的输出数据能用于不同带宽的接收器。此外，由于设备的呈现能力不同，如max fps，OpenGL硬件支援等，接收器亦不相同。

多点传送单元207维持接收器加入和退出广播会话，定义最佳的传输拓扑和路径，维护和重新安排多播覆盖网络。多点传送单元207也附加相应的同步数据，如传至外送数据包的时间戳，确保各接收器的时钟同步，并在需要时，调整比特率、编码数据、可用网络带宽，以及参与通信会话中每个接收器的处理能力和延时。

多点传送单元207与混合网络堆栈208和输出编码器206进行通信，高效地执行如上所述功能。该多点传送单元207能使用基于交互质量和接收器设备上用户体验的优化标准。网络堆栈208与实体网络接口相连接，该实体网络接口发送数据包至实体通信网络。网络堆栈208通常以用户模式或内核模式的软件组件来实现。或者也能以硬件集成电路来实现。

输入队列209负责从多个用户处接收输入指令，缓冲指令，并适时地提出指令(因此同步多个用户的输入数据)。输入解码器210确保应用程序204能理解不同类型的输入数据。输入解码器210删除所有不能由应用程序204解释的输入指令。

应该能够理解的是，输出捕获单元205，输出编码器206，输出多点传送单元207，网络堆栈208，输入队列209和输入解码器210能以应用程序204在本机操作系统的内置和用户模式上执行的软件程序而实现。上述特征将在下文进行探讨。

图3系为远程计算提供改进传输协议的示例客户端。客户端显示设备305可以是接收器设备，如上所述。

客户端305包含低延时混和网络堆栈307，输出解码器306和输出呈现器307，显示在设备上。该输出解码器能包含音频/视频编解码器，图像编解码器和图形指令库，对所接收的输出数据进行解码。

上述组件能以常规操作系统上执行的用户模式软件程序而实现，该程序能在包含CPU 302和GPU 303的低成本计算硬件平台上执行。例如，CPU 302可能是Intel Atom处理器。例如，GPU 303可能是Intel GMA 945。

上述组件还能以硬件实现。一个实施例中，客户端301未要求通用CPU和GPU，也未要求常规的操作系统，如Windows XP，Windows Vista，Windows 7，Windows Server，Windows Mobile，Mac OS X，Mac OS X Server，UNIX，Linux，Symbian，Android等。

客户端305能支持含输入编码器301的输入功能。输入编码器301和输出解码器306与网络堆栈307相连接，接收图形、编码视频流或来自远程服务器中间格式的图形指令形式的图像输出数据，并以编码输入数据为回应。输出解码器306可能接收和解释其他类型的输出，如音频或通用数据流(例如文件或数据流)。输入数据能在设备和操作系统中由输入编码器301的独立格式进行编码。

图4系为远程计算提供改进传输协议的客户端上执行的示例捕获输出和编码引擎。图形输出和编码引擎能捕获服务器上所执行应用程序的输出图形，如上所述。该引擎还能对其他形式的输出进行编码(图形应用程序接口指令、图片或视频)，接着依据数据类型和紧迫性，利用混合多信道网络协议堆栈传输编码后输出。该引擎还能更新缓存，使其与接收器上其他缓存(若存在)保持同步。

图形应用程序接口指令拦截器401，帧捕获单元402和视频通透拦截器403捕获由应用程序产生的图形信息(或可选为应用程序所执行的操作系统)。例如，帧捕获单元402能以20-30帧/秒的帧率捕获图形输出。若提供足够的处理功能和带宽，高帧率也能实现。

其他拦截器组件403a可能展示拦截其他类型的输出。示例输出类型包括音频、3D全息图、3D物体、打印机输出，以及数据文件和数据流形式的通用数据输出。

例如，高质量音频流的低延时拦截在“Method and System for LowLatency High Quality Music Conferencing”中予以描述，如上所述，本申请参考引入该内容。

通过各种机制能实现各输出类型的同步。一种机制通过发送器的时间标记(在多点传送单元413中执行，下文将进行探讨)，记录发送器的时间，使接收端同步。另一种机制在接收器实施抖动缓冲，下文将进行探讨，通过改变缓冲区大小、适时摒弃部分数据，从而管理网络延迟。又一种机制通过改变数据阐释(例如回放中音频采样率)得到期望的同步。

拦截器401，402，403的实施和相似拦截器403a可能不相同。它们能以内核模式或用户模式软件组件方式，在操作系统中执行。它们还可能以软件组件在管理程序的顶端执行，并在客户操作系统的虚拟实例中以软件组件的方式出现。如果图形捕获器和编码引擎以硬件芯片实现，它们也能以硬件实现。

图形应用程序接口(API)指令拦截器401捕获由应用程序产生的图形指令和API指令。上述指令可能包括，如Microsoft’s GDI，Direct 3D，OpenGL，Desktop Window Manager，and Apple’s QuickDraw，Quartz 2D，PostScript，Core Image，Core Animation，Quartz Compositor等。拦截器401与用户模式组建相结合，按虚拟显示驱动程序实现。上述虚拟显示驱动程序以实体显示驱动程序的方式向应用程序展示自己，但复制任何所接收的指令。一份复制的指令通过网络416被发送至接收器，而另一份复制指令被传输至实体图形处理单元或虚拟图形处理单元，用于创建图像，该图像能被帧捕获单元402所捕获。

图形指令筛选器404与发送器通用高速缓冲存储器406及区域检测器405进行通信，在通过网络416将上述指令传输至接收器之前，以确定哪些图形指令能用于进一步处理。

一个实例中，若图形API指令及相关参数(位图、纹理、电刷等)已展示给全部或部分接收器，则无法传输。此类指令被图形指令筛选器404过滤，并被杂凑数(hash number)所取代，上述杂凑数能识别高速缓冲存储器406的缓存位置。通用高速缓冲存储器406利用缓存过程同步412，使介于发送器和接收器的系统间同步。

若区域检测器405决定使用图形API指令所影响区域的视频或图形编码器(下文将进行探讨)，图形API指令也无法传输。区域检测器405执行下文所探讨的流程。

图形指令筛选器404还传输统计信息，如图形指令的数量、指令类型、未缓存大小和区域检测器405的边界区域。区域检测器405将统计信息与其自身运动检测数据和区域分类相对比，以确定是否使用图形API指令拦截器401或视频/图形编码器。

一个实例中，区域检测器405偏向在使用的图形指令。然而，应该能够理解，若应用程序使用多个GDI指令，以支持极富动感的图形，视频编解码器能更有效。

一旦指令证明能被进一步处理，该指令则被图形指令翻译器408转化为通用格式。上述通用格式在各图形API中非常普遍。该通用格式可能在如PostScript现有格式的基础上进行补充和修正。出于简化、便于理解和便于接收设备呈现的目的，上述格式能被优化。出于解释和简单小功率硬件实施或软件实施呈现的目的，该格式能被优化。

所翻译指令由图形指令压缩器409进行压缩。上述压缩器可能是游程编码，其中重复项被替换为该项目及其在序列中出现的次数。更高级的压缩算法能将指令转化为一组等效指令，然后由ZIP或RLE算法进行压缩。该方法能减少传输至接收器所需的带宽和延时。

产生的比特流(bit stream)被发送至多点传送单元413，下文将进行探讨，并利用混合多信道网络协议堆栈414通过网络416传输上述比特流。

上述堆栈414使用UDP进行传输，使用网路通讯协定(IP)进行路由选择。上述堆栈将在下文探讨。应该能够理解，其它类型的网络协议也同样适用。例如，能使用TCP/IP，但存在高延迟，使用户体验并非最佳。

帧捕获单元402从服务器的视频存储器捕获应用程序的帧数据，例如，频率每秒30-50帧。应该能够理解，若有必要，也能使用更高的捕获率。客户操作系统的内核模式软件组件可能用于提升从图形采集数据的速度。或者，帧捕获单元402能在用户模式中实现。

帧捕获单元402能捕获应用程序所显示的部分或全部屏幕。一个实施例中，捕获单元402捕获全部屏幕，并操作所捕获的图形，仅处理关联区域，下文将进行探讨。另一实施例中，捕获单元402仅捕获应用程序所显示的一或多个特定区域。

帧捕获单元402每20-30毫秒或更频繁地，每5-10毫秒向区域检测器vp5提供一个新的图像帧。帧捕获率的确定，部分取决于输出的帧率。该速率(毫秒计)等于1000除以每秒钟输出的帧。区域检测器405因而从帧拦截器402处接收上述图像，从拦截器401处接收一连串被截的图形API指令，以及从拦截器403处接收一连串被截的视频API指令。

区域检测器405则确定，对于图形中每个区域，是否使用基于指令的方法、视频或图形编解码器。上述区域可以为非矩形，下文将进行探讨。

区域检测器405则将上述图形帧，连同将进行视频编码的区域掩码馈给视频编码器407，下文将进行探讨。区域检测器405在各种情况下，能与多种图形编码器410相配合。

例如，可能存在两种类型的图形编码器410：适用于大像素的顺序图形编码器和适用于小图像的简单、无损或有损图像压缩器。顺序图型编码器偏向于处理器密集型的使用，但能大大压缩图像大小。相反地，小图像要求带宽较小，因此适用快速编码器优势更大。顺序图形编码器能有效低压缩大像素的图像，而小图像则使用快速编码器进行处理。

如上所述，区域检测器405向图形编码器410提供用于编码的图像元素。视频编码器407和图形编码器410对数据编码，从而压缩数据，并将压缩后数据传送至多点传送单元413。

多点传送单元413为一或多个接收器维持通信会话，定义最优化路径，为同步管理必要的时间标记，并根据从网络堆栈414所接收的网络反馈数据，通过改变视频编码器407和图形编码器410的参数，适应比特率。

多点传送单元413使用网络堆栈414，根据负载和延时要求来创建各类型的通信信道。多点传送单元413管理多信道的优先级关系，并与接收器创建连接。多点传送单元413也传输数据至接收器。

如下所述，网络堆栈414具有三种类型的信道：保证送达、非保证送达和非保证送达兼前向纠错。

一个实施例中，当网络情况良好时，多点传送单元413为API指令创建保证送达的信道，为视频编解码器的编码数据创建非保证送达的信道；当网络情况不稳定时，为视频创建非保证送达兼前向纠错信道，同样为音频流和图形编解码器的编码数据创建非保证送达兼前向纠错信道。多点传送单元413能通过低优先级的保证送达信道传输应用程序数据。音频数据以高优先级传输，因为由于数据包丢失或抖动使音频质量下降，导致所接收的音频质量与视频相比要差得多。

视频播放指令(例如DirectShow，Core Video，QuickTime)和与上述指令相关的媒体数据流能由视频拦截器为通透403而拦截。该拦截器403适用不同类型媒体，以多个具体指令软件组件而实现。

一个实例中，微软的DirectShow视频拦截器能以最高优先级的DirectShow过滤器实现，确保此为DirectShow处理管线的第一要务。该过滤器能筛选出相关指令和API兴趣要求指令(如播放视频文件的请求)，并将其传送至多点传送单元413和网络堆栈414。

拦截器403将捕获的媒体数据，直接传送至接收器，无需在发送系统上重新播放或由视频编码器407重新编码。例如，根据数据包丢失和可用带宽等网络情况，上述数据能通过非保证送达或非保证送达兼前向纠错信道被传输。

视频通透拦截器403与区域检测器405就一组媒体呈现指令(如视频呈现)所占区域进行通信。区域检测器405能利用上述信息以确定是否在该区域使用视频编码器407。上述决定能被下列因素所影响：如必要编解码器的可用性，以对接收器上原始媒体数据进行解码，或视频编码器是否基于其他原因而更可取(如接收器的CPU性能有限)。

相应数据(如网络摄像机的视频文件或视频流)能被发送至音频/视频包装器411。该包装器411能新增关于媒体类型、帧描述数据等信息。包装器411也能在需要时将媒体文件转码成另一种格式。该包装器411确保接收器上媒体数据的兼容性，并向接收器提供足够的元数据，供回放上述媒体数据。

图5系为远程计算提供改进传输协议的客户端上执行的示例解码和呈现引擎。客户端能在接收设备上执行，并被配置为接收编码数据。客户端能进一步以图形输出呈现编码数据给用户。客户端还能对其他类型的输出进行解码和呈现，包括但不限于：音频、数据文件、数据流、打印机数据流等。

一个实施例中，接收器包含网络传输协议堆栈504，视频抖动缓冲区506，视频解码器512和视频呈现器518。该接收器仅通过视频解码器512使用视频解码。若帧率很低，则不需要抖动缓冲区506。所接收的编码数据能通过发送器进行适当编码，无需图形编码器、通透编码或GDI指令。

接收器可以是以硬件中的解码芯片实现的简单、节能设计。

另一实施例中，简单的操作系统能加载和执行组件504，506，512，518，如上所述的系统服务。该实施例包含必要的附加组件，以支持504，512和518。

又一实施例中，上述组件能以软件组件实现，在Mac OS X或Windows 7等操作系统内执行。

另一实施例中，接收器支持附加的输出类型，如音频，如上所述。接收器能被延展，包含附加的抖动缓冲区519，输出解码器520和输出呈现器521。

又一实施例中，利用混合方法对应用程序的图形输出进行编码，如上所述。上述图形输出被编码成四类数据，包括：图形指令、视频帧、图像元素和通透视频。如图所示，此四类数据由四根管线处理，并实时合并成单一图形以供显示。

图形指令管线包括图形指令的抖动缓冲区505、图形指令解压器509、图形指令翻译器511、图形指令呈现器515和分布式同步缓存510。

视频解码管线包含视频解码器的抖动缓冲区506和视频解码器512。

基于图像的解码管线包含图像元素的抖动缓冲区507，图形解码器(可为多类型)513，和分布式同步缓存510。

通透视频管线包含图像元素的抖动缓冲区508和通透视频展开和呈现器507。

帧合成器516将管线输出结合成单一图形。平滑变换模块517处理上述图形，平滑该图形的边界区域。然后上述图形以图形输出在518中显示。

平滑变换能消除不同地区编程的不同方法所导致的人为结果。平滑变换的示例之一为模糊变换。应该能够理解，根据具体情况，使用不同的变换方案。

一个实施例中，抖动缓冲区505，506，507，508，519有不同的实现方案和算法。抖动缓冲区处理不同类型的数据，因此具有不同的需求。例如，若网络存在高延迟，即使帧率很低，抖动缓冲区仍能提高性能。因此，为保证流畅的用户体验(如音频/视频同步)，必须具有多个抖动缓冲区，以管理各种输出类型的同步。抖动缓冲区能动态改变其大小，验证所接收数据的时间标记，并在必要时删除、延迟或重新安排所接收数据。上述方法能管理延时，并保持高质量的输出，尤其适用于不可信赖网络。

例如，图形指令的抖动缓冲区能确保接收器按正确顺序处理图形的GDI指令。

高速缓冲存储器510用于为所接收的图形指令检索图形元素和参数，如位图和材质。如上所述，高速缓冲存储器510能根据从发送器所接收的哈希数存储上述实体。高速缓冲存储器510通过单独的数据通信信道从服务器缓存处接收数据，并维持其与发送器缓存的同步状态。

图6系服务器所执行的示例步骤，依据改进的传输协议进行捕获、编码和发送。如上所述，上述步骤能在服务器上执行，并与一或多个客户端进行通信。

步骤601中，服务器拦截执行中应用程序的图形输出。例如，该应用程序可以为现有的应用程序，被配置为单一用户提供交互式用户接口。通过拦截图形输出和用户输入(下文将进行探讨)，上述应用程序能被提供给多个用户。

或者上述图形输出能被拦截，并传播给多个客户端。该方法能用于，例如，传播多媒体演示给分布在广大地域范围内的多个客户端。

步骤602中，服务器执行区域检测步骤。上述区域检测步骤被配置为将图形输出分成一或多个区域，其中每个区域具有影响最优化数据转换的显著特性，下文将进行探讨。

例如，如上所述模块能提供该区域检测器。一个实施例中，上述模块可以是在服务器上执行的软件模块。另一实施例中，上述模块也可以是专用硬件和通用硬件的组合，且执行能访问服务器的软件。

步骤603中，服务器过滤上述所检测的区域。例如，在上述视频、图形或通透区域中不发送图形API指令；在通透区域中不发送视频和图形数据。

步骤604中，服务器将每个区域的图形输出转换成合适的转换输出。下文将探讨四个示例区域及其相关的特性。

图形API指令是用于呈现图形输出的操作系统或其它指令。例如，微软Windows提供了一系列图形指令，用于绘窗口、圆圈和其他图形。这类区域能利用标准的Microsoft APIs检测。其他操作系统具有相同的操作原则，也有标准的API，能用类似方法进行区域检测。上述区域能被最优地编码在原图形指令中，与传输屏幕快照相比，能极大地减少所需带宽。

应该能够理解的是，上述指令必须以保证送达的方式传输。若客户端丢失一或多个图形API指令，很难重建原图形输出。

视频数据能利用视频编解码器进行编码。视频数据在连续运动，能在尽量不影响用户体验时被压缩。各种优化编解码器均能使用，例如，当视频中的动作很少时，切换到高质量的编解码器；而当视频中动作很多时，切换到低质量的编解码器。应该能够理解，运动精度高的视频能以高速率被压缩，因为相较于细节，人眼更能感知视频中的动作。

应该能够理解，上述视频数据能以非保证送达的方式传输，因为单个丢失的数据包对整个视频输出的影响很小。若网络情况非常不可信赖(网络堆栈能检测，下文将进行探讨)，上述视频数据能以非保证送达兼前向纠错的方式传输，应该能够理解。

图形能利用图形编解码器进行编码。例如，图形编解码器的质量能高于上述所用视频编解码器，并对图形进行优化。因为缺乏动作，人眼将关注图形细节，为提升用户体验，必须高质量的呈现上述图形。

上述图形数据能以非保证送达兼前向纠错的方式传输，应该能够理解。编码图形数据中的错误能导致所显示图形输出中的瑕疵，利用前向纠错能最小化上述瑕疵，下文将进行探讨。通过保证送达也可行，以保证送达方式传输编码图形数据要求大量的带宽，其效率很低。

图形输出中的图形数据和视频数据能利用运动检测模块进行区分，下文将进行探讨。

通透数据能，例如，编码视频数据由客户端进行解压。若客户端具有足够的资源(硬件、编解码器等)对编码的视频数据进行解码，并且编码视频数据满足带宽和质量要求，服务器能直接将该编码视频数据传输给客户端，以供呈现。

应该能够理解的是，根据编码视频数据的大小及其对丢失数据包的阻抗力，保证、非保证和非保证兼前向纠错的三种送达方式均能使用，下文将进行探讨。

步骤605中，服务器传输转换后输出。如上所述，该转换后输出通过网络进行传输，该网络被配置为传送数字信息。上述转换后输出能被传输至一或多个客户端，以供呈现。

步骤606中，服务器通过合适的队列传输转换后输出。各队列均可使用，且每个队列被配置具有不同的传输和可靠性特征。示例队列包括：

可信赖队列，能保证基础包的送达和顺序。可信赖队列取决于接收器通过控制信道所发回的确认信息。可信赖信道的数据包组集含序列号。接收器定期地向发送器发回已接收数据包的序列号(“确认向量(ACKvector)”组集)。当发送器一段时间内未接收到数据包的确认信息(ACK)，发送器则认为数据包丢失，从可信赖信道重新发送数据包组集。发送器并不会等接收到确认信息，才发送下一部分数据包。

不可信赖队列，其不能保证基础包的送达和顺序。不可信赖队列将各数据包信道中序列号加为前缀，以恢复其顺序，并在接收器删除重复的数据包。该队列不进行其他检查，从而尽可能减少延时和CPU使用率。明显的数据包丢失等于或略高于(由交叉存取所致)网络数据包的丢失率。

兼前向纠错(FEC)的不可信赖队列，能发送冗余信息，将其分布在各待传输的数据包，帮助恢复丢失的数据包。一个实施例中，基于修正的Luby变换源码(LT源码)的前向纠错实施方案与传统的译码算法相比更快捷，更简便。上述方法能允许单一数据包丢失和封包遗失的恢复。一个实施例中，前向纠错使用NxM矩阵选择数据包子集至XOR(原LT源码使用伪随机子集)。耗损比特率等于(N+M)/(N*M)。模拟测试已显示：若网络数据包丢失率为15％，新增前向纠错能将明显的数据包丢失率降低至0.5％；若网络数据包丢失率为5％，明显的数据包丢失率将降至0.01％。

另一实施例中，前向纠错在少数案例(带宽非常低，数据丢失率非常高)中牺牲其稳健性，以减少常规案例(网络带宽＞＞数据比特率，网络丢失率＜20％)的延时。上述结果能通过交叉用户数据报协议数据包中的信道集实现，该方法能保证任一信道都不会给其它信道产生附加延时。此方法几乎能消除与数据包丢失相关的延时。

步骤607中，服务器退出上述步骤。

图7系客户端所执行的示例步骤，依据改进的传输协议进行接收、解码和呈现。如上所述，上述步骤能在客户端上执行。如图6中所述，上述步骤能从服务器端接收数据。

步骤701中，客户端能从可信赖队列中接收数据。可信赖队列已在步骤606中予以探讨。

步骤702中，客户端能从不可信赖队列中接收数据。不可信赖队列已在步骤606中予以探讨。

步骤703中，客户端能从兼前向纠错的可信赖队列中接收数据。兼前向纠错的可信赖队列已在步骤606中予以探讨。

应该能够理解，每个队列能与一或多个抖动缓冲区相联系，如上所述，该抖动缓冲区能进行动态调整。

步骤704中，客户端能从一或多个上述队列，或其组合中接收转换输出。每个队列均能根据所接收的数据和队列协议，产生输出。抖动缓存算法在步骤704被用于各信道，传送各类型数据。抖动缓冲区有益于降低呈现后所接收数据的失真感。若传输音频数据，上述抖动缓冲区能用于减少干扰和杂音。若为视频数据，上述抖动缓冲区能用于减少畸变、杂质或类似扭曲。

可信赖队列会请求重新传输任何丢失的数据包，并保证输出上述数据包流，由服务器进行传输。不可信赖队列输出数据包流，客户端予以接收。如上所述，兼前向纠错的不可信赖队列会尝试使用前向纠错算法重建丢失的数据包。

对于不可信赖队列和兼前向纠错的不可信赖队列，丢失的数据包能由相邻的数据包合成。例如，丢失的数据包可能从相邻数据包被分派一个外推值。

客户端还能顺应网络流量情况，动态调整抖动缓冲区的容量。

步骤705中，客户端能对转换后输出进行解码，该转换输出接收自上述队列。客户端确定合适的方法，对转换后输出的各部分进行解码，下文将进行探讨。

步骤706中，各类型的转换后输出都能被适当解码。合适的解码方法部分取决于所使用的编码类型。

例如，通过传输图形API指令至合适的API，该指令在客户端被复制。大量屏幕数据能以此方式来呈现，满足最小带宽的要求。

例如，视频数据可以由合适的编解码器进行解码。如上所述，服务器能选择适当的编解码器。

例如，图形数据可以由合适的编解码器进行解码。如上所述，服务器能选择适当的编解码器。

例如，通透数据仅简单地传输过客户端，无需进一步处理。如上所述，该通透数据从队列编译而成，由具有可用资源(硬件、编解码器)的客户端所呈现。

步骤707中，图形输出被呈现。如上所述，呈现图形输出包含呈现图形API指令、视频数据、图形数据和通透数据。该呈现能进一步包含构成帧和模糊区域边界。

步骤708中，客户端退出上述步骤。

图8系为远程计算提供改进传输协议的示例网络堆栈。如上所述，网络堆栈可由服务器提供。

应用程序801能在服务器上执行。如上所述，该应用程序801可以是在服务器上执行、提供图形输出的任何软件。例如，上述软件可以是为用户所需功能提供用户接口的应用程序。

可信赖信道802能提供保证送达的数据包传输。如上所述，该可信赖信道802与可信赖队列相对应。

不可信赖信道803能提供非保证送达的数据包传输。如上所述，该不可信赖信道803与不可信赖队列相对应。

不可信赖兼前向纠错信道804能提供非保证送达兼前向纠错的数据包传输。如上所述，该不可信赖兼前向纠错信道804与不可信赖兼前向纠错队列相对应。该前向纠错提供数据包的冗余，在必要时重建丢失的数据包。上述方法能在尽可能降低额外耗损之时，增加信道的可靠性。

上述探讨的每个队列与一或多个信道相关联。每个信道具有一优先级。网络堆栈依据其优先级处理各信道。此外，必要时能在多个执行中的应用程序之间分配信道。

网络反馈模块805监控网络拥塞，并在必要时修正网络参数。例如，若检测到网络上碰撞增加，则降低传输率；若检测到数据包丢失率增加，系统能将某些类型数据的传输从非保证信道切换成非保证兼前向纠错信道。同样取决于网络情况，前向纠错参数能够被调整，影响带宽和数据包丢失率。同样地，若检测到碰撞减少，网络反馈模块805能指示需增加传输率。

解复用器806分解从网络传输接收的数据包。数据包被复用至各合适的信道。例如，每个数据包具有信道标识符，用于标识其所属的信道。

多路复用器和数据包队列807将信道的数据包复用成数据包队列，通过网络进行传输。如上所述，每个数据包具有信道标识符。多路复用器将各信道的优先级纳入考虑。

发送器确认模块808能从客户端接收可信赖通道的必要确认信息。接收器定期地传输所接收数据包的标识符。例如，数据包标识符能以确认量组集的方式传输。一旦发送器确认模块808接收到确认向量组集，接收器所接收的数据包标识符就已知了。

拥塞控制器809能执行拥塞控制模块。网络传输协议中高效拥塞控制器能防止拥塞崩溃。当发生拥塞崩溃时，由于拥塞、高数据包丢失率和大量数据包，所发生的有效吞吐量很少。现有的拥塞控制算法能在TCP和其它网络协议中实施，但效率和进取性不够，不能使用高带宽链接传输低延时、高质量的数据流。一个实施例中，网络传输协议使用不同的拥塞控制机制，有效地调查可用带宽和利用可用网络容量。

术语和定义

网络拥塞：当链接或节点传输大量数据，导致其服务质量下降时，发生网络拥塞。典型副作用包括队列延迟、数据包丢失或堵塞新连接。

拥塞信号：网络路径中已发生堵塞的通知。两个连续的数据包丢失或超时能触发此信号。

往返时间(RTT)：数据包从特定源传输到特定目的地来回所需的时间。

封包间隙(IPG)：发送器发送连续数据包的延迟时间。

循环：算法中的一步。循环时间等于平均往返时间，因此第i次的操作是对第i-1次操作的网络操作的回应时间。

拥塞控制算法描述

该算法基于速率，并控制封包间隙值的数据率。相反，TCP利用拥塞窗口值。该算法将往返时间样本和拥塞信号作为输入。

上述往返时间样本依据所发送的每个数据包计算出。往返时间样本是发送数据包和确认接收的延迟时间。因此，往返时间样本依每个确认的数据包而产生。给定往返时间样本，能计算出四个派生特性：

RTT：增益为α，所接收往返时间样本的指数平均数。

DetailedRTT：增益为β，所接收往返时间样本的指数平均数，β＞α。

RTTVariance：往返时间样本相对于往返时间平均值的方差。

BaseRTT：目前往返时间样本下界的近似值。

RTT是一段较长时间的平均值，DetailedRTT是一段较短时间的平均值，BaseRTT是通过无拥塞网络往返时间的近似最小值。

根据上述值，能派生三个无因次变量：

Feedback = \frac{DetailedRTT}{RTT},

Q_{d} = 1 - \frac{BaseRTT}{DetailedRTT},

Q_{a} = 1 - \frac{BaseRTT}{RTT} .

Feedback表示当前路由器上队列状态与其平均状态之比。Feedback通常介于(0.5，1.5)，但理论上可以是任何正数。

Q_d是介于[0，1]的详细队列因素。它表示短时间内路由器上当前队列的延迟。0表示队列很短，1表示队列很长。

Q_a是介于[0，1]的平均队列因素。它表示长时间内路由器上当前队列的延迟。

通过改变IPG值实现控制。发送端确保连续数据包之间的延时高于拥塞控制算法所得的IPG值。每次发送数据包后变化的IPG能按下列方法计算：

IPG = \{\begin{matrix} {BaseIPG}_{i} \cdot Feddback, if Q_{d} \leq Q_{thresh .} \\ {BaseIPG}_{i} \cdot Feddback \cdot [1 + R \cdot (Q_{d} - Q_{thresh .})], if Q_{d} > Q_{thresh .} \end{matrix}

其中，BaseIPG_i是本周期IPG的预期值。该值每周期进行更新或以响应拥塞信号而更新。

Q_thresh.是队列因素的阈值。当队列因素超过阈值时，需采取额外措施增加IPG，以降低路由器的队列数。

BaseIPG_i依据下列算法进行更新：

若发生堵塞：

BaseIPG_i+1＝BaseIPG_i·A，当A＞1(通常接近2)。

若第i周期未发生堵塞：

{BaseIPG}_{i + 1} = \frac{{BaseIPG}_{i} \cdot C}{{BaseIPG}_{i} + C},

其中

C = \frac{RTT}{S},

并且

S = \{\begin{matrix} S_{+} > 0, if Q_{a} \leq Q_{allowed} \\ S_{-} < 0, if Q_{a} > Q_{allowed .} \end{matrix}

如上为所述各步骤。

上述公式能从数据包率方面进行解释。数据包率是每秒发送的数据包数。不考虑详细IPG的控制，数据包率能表示为：

R_{i} = \frac{RTT}{{BaseIPG}_{i}}

并且从上述公式，能推导出：

R_{i + 1} = R_{i} + \frac{RTT}{C} = R_{i} + S .

因此，BaseIPG根据变化的具有和式减少的AIMD(和式增加积式减少)方案进行更新，以防止平均队列因素过高(＞Q_allowed)。

建立连接序列

服务器监听连接，客户端的连接(与TCP一致)。

四向握手机制：对拒绝服务(DoS)攻击更有抵抗力。

三向关闭机制：无虚假半封闭状态，与TCP一致。

下文将进行探讨连接建立和关闭的具体序列：

网络传输810能由现有协议提供，如UDP/IP。应该能够理解，其它协议同样适用，但可能减少网络堆栈的优势。例如，使用TCP/IP则向所有数据包提供保证送达，与所使用的信道无关，但明显增加了处理器和带宽消耗。

图9系服务器所执行的示例步骤，用于提供区域检测器组件。区域检测器通过检测活动，并监控图形和视频指令流，为图形输出的各区域确定合适的编码方案。

图形输出首先被分成各区域。一个实施例中，若区域是相对静态的，包含由2D图形API指令所产生的文字或简单图形，如绘制文本，则适用图形指令编码。视频编码适用于具有密集动作的区域。若接收器上解码编解码器的CPU资源可用，通透视频编码能用于含视频的区域，上述视频由使用媒体API指令、播放视频流而产生。

基于小波变换顺序编解码器适用于大量动态部分的区域，该区域变化持续而缓慢。上述区域的实例可以是幻灯片播放图片，变化频率3-5秒。简单无损图片压缩器适用于变化不大的小区域。如上所述，本申请系统还使用分布式缓存系统。

区域检测器依赖帧捕获方法，以较高频率(每秒25帧或更高)向其提供位图(或帧)F_k(901)。该区域检测器则应用如下所述的简单运动检测路由器902，为帧F_k(901)计算“运动类映射”C_k(905)。

上述结果C_k(905)是分派到各区域运动密集度的映射数，下文将进行探讨。步骤903则创建区域集{R₁ ^k，R₂ ^k，...，R_N ^k}907，该区域集是预设范围内C_k同级微区域的凸包(convex hull)，下文将进行探讨。一个实施例中，为提高效率能省略上述创建微区域凸包的步骤(这可能导致算法更简化，但不够智能)。

根据各区域的动作密集度，上述区域可能被分派一种颜色。运动密集度高的区域呈红色，而无运动的区域呈白色。开始显现零星运动的区域呈绿色，而运动减缓的区域呈黄色。联合区域907被称为宏区域，与运动类映射C_k(905)一起作为宏区域分析器908的输入。若上述联合区域未被创建，则宏区域分析器的算法不够智能，但更简化和迅速。这能被视为实施方案中的权衡。

如上所述，宏区域分析器908还能监控图形API指令流(如GDI)和视频API指令流(如DirectShow)。分析器908输出区域集，以供视频编码器912，第一类图形编码器910(大图像)和第二类图形编码器911(小图像)使用。分析器908还能删除步骤913中不通过网络传输的图形和视频指令。

对区域集909(“不传输”)，仍能使用图形/视频API指令编码器，或无需传输任何信息(图形是静态的)。

一个实施例中，“红色”区域将被编码为视频，或在步骤916中使用视频通透进行传输。“绿色”区域中，由GDI指令生成的运动(GDI区域与绿色区域的重叠部分)可以由GDI指令编码器进行传输。或者，图形编解码器的大小取决于能用于编码的区域大小。“黄色”区域可用图形编解码器进行编码，若为大区域则适用顺序编解码器，小区域则适用简单编解码器。注意，上述情况是简单探试程序的事例，然而，应该能够理解，仍可开发其它能操纵微和宏区域及其内容的实用技术。

步骤914中，第一类图形编码器可以为顺序(如基于小波变换)图形编码器。该编码器仅适用于相对较大的图像(宽度和高度超过阈值W_max和H_max)。

步骤915中，第二类图形编码器为简化、快速无损图形压缩器。该编码器仅适用于小图像，通常为块状大小(宽度和高度不超过阈值W_max和H_max)。

宏区域分析器的探试程序(heuristics)在下文进行进一步阐明。

图10系服务器所执行的示例步骤，用于提供简单运动检测器组件。

步骤1001中，服务器接收一个计算机生成帧F_k，其中k为该帧的序号。

步骤1002中，服务器依据如下所使用视频编码器核心的宏块结构，将Fk分解为矩形或方形块b^k _p，q。

步骤1003中，服务器将帧F_k的每一块b^k _i，j与其前一帧F_k-1的相同块b^k-1 _i，j相对比。

步骤1004中，服务器测试块b^k _i，j是否与块b^k-1 _i，j相同，若相同，则服务器进入步骤1005a；若不相同，则服务器进入步骤1005b。

步骤1005a中，服务器降低微区域b_i，j的运动评分m^k _i，j，并设定m^k _i， _j＝m^k _i，j-Δ₁，其中Δ₁为非负整数。一个实施实例中，Δ₁＝1。

步骤1005b中，服务器增加微区域b_i，j的运动评分m^k _i，j，并设定m^k _i， _j＝m^k _i，j+Δ₂，其中Δ₂为非负整数。一个实施实例中，Δ₂＝4。

步骤1006中，基于下列运动评分值m^k _i，j，服务器为每个微区域b_i，j分派其运动类(“颜色”)c^k _i，j：

若m^k _i，j＝0， ci，j＝0(运动类“透明”)；

若0＜m^k _i，j ＜T₁，c^k _i，j＝1(运动类“绿色”)；

若T₁≤m^k _i，j ＜T₂，c^k _i，j＝2(运动类“黄色”)；

若T₂≤m^k _i，j ＜T₃，c^k _i，j＝3(运动类“红色”)；

其中T₁，T₂，T₃为运动评分m_i，j.的阈值。

一个实施实例中，T₁＝10，T₂＝20，T₃＝30。

步骤1007中，服务器输出c^k _i，j值的矩形数组C_k。

服务器以当前帧率的频率(通常每秒20-40次)执行图示的常规例程，应该能够理解。

图11A系第一运动检测器的示例屏幕截图。图示网页截屏包含两处运动密集区域。区域1101为“红色”，因为该区域为快速变化的flash动画。区域1102为“红色”，因为该区域为Adobe Flash视频。区域1101的右方一块区域的运动密集度在降低。利用简单无损图形编解码器能够对该微区域进行编码。该图像元素也被缓存。

图11B系第二运动检测器的示例屏幕截图。图示网页截屏与上述讨论的截屏相似，但包含一个绿色(1105)和一个黄色(1104)区域。上述区域与前述屏幕截屏的区别很小，且并非由操作系统图形API指令所生成。相反，上述区域以Adobe Flash动画方式生成，因此使用简单无损图像编解码器对上述区域进行编码。或者，上述区域被缓存，并不要求传输。

区域1105包含变化缓慢的大图像，因此使用基于小波变换图形编解码器处理这一宏区域。

区域1103和1106仍为运动密集区，使用视频编码器进行编码。

图11C系第三运动检测器的示例屏幕截图。图示网页截屏与上述讨论的截屏相似，但区域118的颜色从绿色变成黄色，因为其图形开始加速变化。该区域检测器仍使用基于小波变换图形编解码器进行编码，或该区域检测器将整个区域视为一个视频区。

区域1107和1109如上所述继续进行编码。

图12系为远程计算提供改进传输协议的示例视频编码器。该视频编码器包含视频编码核心1205，能执行标准的视频编码算法，如H.264/MPEG-4AVC或专用低延时的视频编码器。应该能够理解，某些情况下要求标准规格的视频编码核心，而其他情况下为优化性能要求专用视频编码核心。

此处所述视频编码器包含帧预处理器1204，该帧预处理器能在图像上覆盖遮罩。上述方法能使视频编码器仅处理必要区域。帧预处理器在下文予以探讨。

视频编码核心控制器1201与各系统组件进行通信，并初始化该编码核心的某些参数或更改上述参数(如图像大小或比特率)。

编码核心的多个实例能同时执行，能同时为多个分辨率进行编码。

区域历史记录/缓存1202从历史分析中保存了几十帧和区域集，以供区域检测器使用，并快速预测至视频区的切换。

图13系为预处理图形输出的示例步骤。如上所述，所述步骤能在服务器上执行，所述步骤目的在于避免为协调不同区域和大小，频繁地初始化视频编码核心。此类步骤从时间和性能方面考虑，成本很高。解决方案之一是用大区域进行初始化，用黑色层覆盖不活跃区域，从而节省视频编码核心内置运动估计流程的处理资源，实现不活跃区域的有效传输，大部分情况下不传输。

步骤1301中，服务器以帧Fk 1308全尺寸初始化视频编码核心(宽度x高度)。

步骤1302中，服务器为视频编码从宏区域分析器处接收区域集{VR₁ ^k，VR₂ ^k，...，VR_N ^k}，如上所述。

步骤1303中，服务器将区域{VR₁ ^k，VR₂ ^k，...，VR_N ^k}的图像覆盖在黑色(#000000)矩形框BLANK_WxH上，且尺寸WxH与帧F_k的尺寸相同，得到帧F′_k。F′_k＝BLANK_WxH+VR₁ ^k+VR₂ ^k+...+VR_N ^k，其中操作″+″表示逻辑加法或在位图上执行。VR₁ ^k(1306)，VR₂ ^k(1307)，和VR₃ ^k(1309)如图所示。

步骤1304中，服务器将帧序列{F′_k}作为视频编码核心的输入，如上所述。例如，视频编码核心能使用H.264标准。

步骤1305中，服务器对帧{F′_k}进行编码，例如视频压缩器使用H.264/MPEG-4AVC标准或其它标准。

图14系为提供顺序图像编码器的示例步骤。如上所述，顺序图像编码器能在服务器上执行。因为其分两个系列准备编码图形数据：第一系列1415和第二系列1416，该图像编码器为顺序式。步骤1415中，服务器即时发送LL-子带，在客户端绘出粗略图像。

第一系列1415可以是较小尺寸，能快速传输至接收器，提供模糊图像。相反，第二系列1416为所压缩图像的完全、高品质版本，包含更多数据。第二系列1416被传输至接收器的延时更久。

应该能够理解，上述编码器能提供附加粒度，并且该编码器非常合适大图像。

第一步，编码器将输入的RGB图像(1401)转换成YCbCr色彩空间(1402)，产生Y组件(1403)、Cb组件(1404)和Cr组件(1405)。上述Y组件为亮度组件(亮度)；上述Cb组件为蓝色差色度组件；上述Cr组件为红色差色度组件。

第二步，该编码器对上述各组件(1406-1408)采用审慎的小波转换，如Haar。Cb和Cr组件与Y组件的处理管线可以相同(如图所示)。

第三步，编码器为第一数据系列使用LL小波子带。将上述数据发送至网络1409前，利用游程编码压缩该数据，在输出上述结果之前(1415)利用游程编码压缩器(1413)压缩该结果。步骤1413能将LL子带的结果压缩至总输出尺寸的一半以上。

应该能够理解的是，游程编码(RLE)是一种数据压缩的形式，其中“运行”数据(“运行”是指同一数据值在连续的数据元素中出现的序列)仅以单一数据值和次数进行存储，而非原始数据。游程编码是非常简单、迅速的压缩算法。然而，其它数据压缩算法也同样适用。

余下三个小波子带以类似方式处理。HL，LH，和HH子带(1410-1412)在输出前，被馈送到游程编码压缩器(1414)。

小波子带代表四类“子图像”；LL代表原始图像的缩小版；HH代表噪声电平。子带间具有高度相关性，易于被压缩(即利用游程编码算法)。

图15A系示例的数据包结构。数据包格式1500展示了能用于上述系统的示例数据包格式。

图15B系示例的块格式。通用块格式1502展示了能用于上述系统的示例块格式。

图15C系可信赖和不可信赖信道的示例块格式。块格式1504展示了能用于上述系统的示例块格式。

图15D系前向纠错信道的示例块格式。块格式1506展示了能用于上述系统的示例块格式。

图15E系示例Ping块的格式。Ping块的格式1508展示了能用于上述系统的示例块格式。

图15F系示例Ping响应块。Ping响应块的格式1510展示了能用于上述系统的示例块格式。

图15G展示了握手序列。步骤1512中，通过发送初始化及其初始序列号，客户端启动。

图15H系示例的初始化块。初始化块1514展示了能用于上述系统的示例块格式。

图15I系示例的初始化确认块。初始化确认块1516展示了能用于上述系统的示例块格式。服务器回复初始化确认，包含服务器初始序列号和cookie(二进制数据)。

图15J系示例的cookie_echo块。Cookie_echo块格式1518展示了能用于上述系统的示例块格式。为回复上述初始化确认，客户端以COOKIE_ECHO回复，包含F(cookie)。

图15K系示例的cookie_ack块。Cookie_ack块格式1518展示了能用于上述系统的示例块格式。为回复上述cookie_echo块，服务器发送COOKIE_ACK，从而通知客户端已成功连接。服务器仅在COOKIE_ECHO成功后，分配大量的内部结构，从而防止与TCP SYN泛洪攻击相似的攻击。

图15L系示例的连接终止序列。流程1522展示了同级1发送全部等待数据，随后发送终止信息(SHUTDOWN)。

同级2接收到终止信息，其发送全部等待信息，随后发送终止确认信息(SHUTDOWN_ACK)。

一旦接收终止确认信息，同级1发送完成信息，因此通知同级2，连接已终止。

图15M系示例的终止块。终止块格式1524展示了能用于上述系统的示例块格式。

图15N系示例的终止确认块。终止确认块格式1526展示了能用于上述系统的示例块格式。

图150系示例的终止完成块。终止完成块格式1528展示了能用于上述系统的示例块格式。

应该能够理解的是，上文所述的实施例中接收器可以是隐形眼镜显示器。隐形眼镜显示器在2009年9月《IEEE Spectrum》的″隐形眼镜中的增强现实″一文中予以讨论。

http://www.spectrum.ieee.org/biomedical/bionics/augmented-reality-in-a-contact-lens/0(最后更新日期2009年9月28日)。本申请参考引用并入了上述文章内容。这种隐形眼镜能给佩戴者显示信息，并通过无线设备进行通信。这些设备能起到上文所述接收器的作用，并通过覆盖佩戴者视野中的图形增强用户的现实。作为紧致设备，这些设备在功能上受到限制，例如，仅能呈现图形指令和文本。当佩戴者聚焦其环境中的对象时，该设备的一个实施例能显示相应文本。

应该能够理解的是，上文所述的实施例中输出图形可以是3D图形。3D图形可以是由多个摄像机拍摄的特殊图形，然后合并在一起创建全息图或其他3D图形。上述系统能轻松地支持此类3D图形：3D图形经服务器适当压缩，并传输至接收器用于呈现。假定接收器有适当的计算资源和呈现功能，就能向用户呈现该3D图形。3D图形在2009年9月5日“经济学人-技术季刊”22页的“3D技术-近在咫尺”中予以讨论，本申请参考引用并入了上述文章内容。

如上所述，本发明的实施例可以是提供计算机所生成输出的系统，特别是图形输出，也包括其他输出类型。该系统包含被配置为传递数字信息的网络。该系统包含与网络通信的服务器，该服务器被配置为执行应用程序，和输出捕获和编码引擎模块(OCE引擎)。该应用程序提供图形输出。OCE引擎模块被进一步配置为拦截从应用程序输出的图形和其他类型。OCE引擎模块更进一步被配置为将图形输出转换为至少图形指令和视频编解码器数据之一。该OCE引擎利用合适的数据压缩和编码方式，对其他输出类型(音频流、数据文件等)进行编码。该OCE引擎进一步被配置为通过网络传输转换后输出。该系统包含通过网络与服务器通信的客户端，该客户端被配置为执行图形和视频解码和呈现引擎模块(GVDR引擎)。该GVDR引擎被配置为，响应所接收的被传输转换后输出和呈现的图形输出。该GVDR引擎模块还被配置为在客户端拦截用户输入，传输所拦截的用户输入至服务器的输入处理模块。该OCE引擎模块还进一步被配置为将图形输出转换为至少图形编解码数据和通透数据之一。OCE引擎模块还能被配置为执行区域检测模块，该区域检测模块被配置为将图形输出分成各区域，且转换与各区域相关的图形输出。上述图形输出能包含全运动视频，其中全运动视频被附在一个区域内。该图形输出能由通用中间图形指令语言所表示。云引擎模块进一步被配置为接收客户端所拦截的用户输入。服务器输入处理模块进一步被配置为向应用程序提供被拦截的用户输入，以供处理。网络可能不可信赖，通过网络的传输可能是非保证送达的。

本发明的另一实施例可以是提供图形输出的系统。该系统包含被配置为传递数字信息的网络。该系统包含与网络通信的服务器，该服务器被配置为执行应用程序和OCE引擎模块。该应用程序能提供图形输出。OCE引擎模块被进一步配置为拦截从应用程序输出的图形和的计算机生成的其他类型输出。OCE引擎模块还被进一步配置为将图形输出转换为图形指令和视频编解码器数据，并通过网络传输转换后输出。该系统包含通过网络与服务器通信的多个客户端，上述客户端被配置为执行GVDR引擎模块。该GVDR引擎被配置为，响应所接收的被传输转换后输出和呈现的图形输出。该GVDR引擎模块还被配置为拦截用户输入，传输所拦截的用户数据至服务器的输入处理模块，以供应用程序处理。

本发明的又一实施例可以是传输图形和计算机所生成其他类型输出的方法。该方法包含拦截从执行中应用程序的图形输出和计算机所生成其他类型的输出。该方法包含将拦截的图形输出转换为至少图形指令和视频编解码器数据之一，通过网络将转换后输出传输至客户端，执行GVDR引擎模块。上述传输包含将转换后输出解析为可信赖队列、不可信赖队列和不可信赖兼前向纠错队列，其中每个队列含多个信道。上述传输还包含传输可信赖队列，其中可信赖队列中每个数据包由客户端确认，并包含该可信赖数据包的序列号。上述传输也包括传输不可信赖队列，其中不可信赖队列中每个数据包包含其序列号。上述传输同样包括传输不可信赖兼前向纠错队列，其中不可信赖兼前向纠错队列中每个数据包包含变换编码，该变换编码含用于恢复丢失数据包的冗余信息。所拦截数据输出还能进一步转化为至少图形编解码器数据和通透数据之一。上述方法更包括将图形输出分成各区域，转换与各区域相关的图形输出。上述图形输出能包含全运动视频，其中全运动视频被附在一个区域内。该图形输出能由通用中间图形指令语言所表示。可信赖队列能用于传输图形指令，而不可信赖队列能用于传输视频编解码器数据。传输转换后输出进一步包含依据拥塞控制调节传输带宽。上述方法亦可接收所拦截的用户输入，向执行中应用程序提供被拦截的用户输入，以供其处理。

本发明的又一实施例可以是接收图形输出的方法。该方法包含通过网络从服务器端接收转换后输出，该服务器执行应用程序，提供图形输出和OCE引擎模块，并将图形输出转换成转换后输出。上述接收包含接收可信赖队列，其中可信赖队列中每个数据包包含其序列号，接收该可信赖队列还包含响应所接收的可信赖队列数据包，向服务器传输确认信息。上述接收也包括传输不可信赖队列，其中不可信赖队列中每个数据包包含其序列号。上述接收同样包括传输不可信赖兼前向纠错队列，其中不可信赖兼前向纠错队列中每个数据包包含变换编码，该变换编码含用于恢复丢失数据包的冗余信息。上述接收包含将上述可信赖、不可信赖及不可信赖兼前向纠错队列编译成所接收的转换后输出。该方法包含从所接收的转换后输出呈现图形输出。上述方法还包含响应所拦截的用户输入，将被拦截的用户输出传输至云引擎模块。上述用户输入能通过可信赖队列被传输至服务器。上述接收还包含抖动缓冲区的处理。上述转换后输出至少包含下列之一：图形指令、视频编解码器数据、图形编解码器数据和通透数据。图形输出被分成多个区域，并且与每一区域相联系的图形输出被转化成至少下列之一：图形指令、视频编解码器数据、图形编解码器数据和通透数据。上述图形输出包含全运动视频，其中全运动视频被附在上述多个区域之一。

本申请所述的具体实施例表示本发明实例或实施例，并且上述实施例具有说明性，而非限制性。为阐释之目的，上述说明书中列举了众多细节要求以提供本发明的透彻理解。然而，显而易见的是本领域技术人员无需此细节要求便能实践上述发明。

本说明书中“一个实施例”或“一些实施例”的引用指引用文献所述与实施例相关的特定特性、结构或特征至少包含在本发明的一个实施例之中。各实施例的特性和方面能整合至其他实施例中，并且本申请所述的实施例可能未执行所述的全部特性或各方面。本领域技术人员应该能够理解：上述实例和实施例仅用于示例，而无限制性。

本申请已描述当前被认为本发明最实用、高效的系统、设备和方法的实施例，应该能够理解的是本申请公开内容并不限于所公开的实施例。自本领域技术人员阅读说明书，研究绘图后，上述技术人员认为系属于本发明明显的排列、增加、等同、组合和改进，均包含在本发明真实精神和范围之内。本申请公开范围因赋予最广泛的解释，以便包含上述修改和相似的结构。因此，本申请旨在包含落入本发明真实精神和范围之内的所有修改、排列和等同。

Claims

1.一种系统，包含：

服务器，通过数字计算机网络与客户端进行通信；和

可由服务器执行的应用程序，其中该应用程序提供计算机生成的输出，该服务器被配置为：

从应用程序处拦截计算机生成的输出；

将计算机生成的输出转换成至少图形指令和视频编解码器数据其中之一；和

通过网络传输转换后的输出；和

其中该客户端被配置为：

执行，解码和呈现图形和视频；

呈现图形输出，以响应接收之被传输转换后的输出；

拦截用户输入；和

通过网络传输被拦截的用户输入至服务器。

2.如权利要求1所述的系统，其中服务器被进一步配置为将图形输出转换为至少图形编解码器数据和通透数据其中之一。

3.如权利要求2所述的系统，其中服务器被进一步配置为：

将图形输出分成多个区域；

转换与每一区域相关的图形输出；和

平滑上述多个区域间的边界区域。

4.如权利要求3所述的系统，其中图形输出包含全运动视频，并且该全运动视频被包含在上述多个区域之一内。

5.如权利要求1所述的系统，其中图形指令系由通用中间图形指令语言所表示。

6.如权利要求1所述的系统，其中服务器被进一步配置为：从客户端接收被拦截的用户输入；和

将被拦截的用户输入提供给应用程序以进行处理。

7.如权利要求1所述的系统，其中网络不可信赖，且该网络的传输并非保证。

8.如权利要求1所述的系统，其中服务器被进一步配置为利用至少本地运动检测例程和运动预测例程其中之一，将图形输出转换为视频编解码器数据，其中服务器将该图形输出分成多个区域集，每个区域集具有相似的运动特征。

9.如权利要求8所述的系统，其中服务器被配置为计算每个区域集的运动评分值，其中该运功评分值表示运动特征。

10.如权利要求1所述的系统，其中服务器被进一步配置为，通过选择具有图形活动的区域进行处理，而在转换前预处理图形输出。

11.如权利要求10所述的系统，其中预处理进一步包含在图形输出上覆盖遮罩，以模糊静态区域。

12.如权利要求1所述的系统，其中服务器被进一步配置为将图形输出编码为视频编解码器数据，利用至少基于标准的编码核心和专用编码核心其中之一，包含与每一区域相关的区域历史记录。

13.如权利要求1所述的系统，其中服务器被进一步配置为：

接收RGB图像数据；

在RGB图像数据上执行小波转换；

将转换后数据分成包含LL-子带数据的第一系列和包含HL子带数据、LH子带数据和HH子带数据的第二系列；

将压缩后的第一系列传输至接收端；和

传输第一系列后，将压缩后的第二系列传输至接收端。

14.一种系统，包含：

服务器，通过数字计算机网络与多个客户端进行通信；和

从应用程序处拦截计算机生成的输出；

通过网络传输转换后的输出；和

其中该客户端被配置为：

执行，解码和呈现图形和视频；

呈现图形输出，以响应接收之被传输转换后的输出；

拦截用户输入；和

通过网络传输被拦截的用户输入至服务器。

15.一种计算机实施方法，包含：

从执行中应用程序处拦截图形输出；

将所拦截的输出转换为至少图形指令和视频编解码器数据其中之一；和

通过网络将转换后的输出传输给客户端，其中前述传输包含：

将转换后的输出解析成可信赖队列、不可信赖队列和不可信赖兼前向纠错队列，其中每一队列具有多个信道，每一信道具有相应的优先级；

传输可信赖队列，其中可信赖队列中每个数据包由客户端确认，并包含一可信赖数据包序列号；

传输不可信赖队列，其中不可信赖队列中每个数据包包含一不可信赖数据包序列号；和

传输不可信赖兼前向纠错队列，其中不可信赖兼前向纠错队列中每个数据包包含一变换编码，该变换编码含用于恢复丢失数据包的冗余信息。

16.如权利要求15所述的计算机实施方法，其中被拦截的输出被进一步转换成至少图形编解码器数据和通透数据其中之一。

17.如权利要求16所述的计算机实施方法，进一步包含：

将图形输出分成多个区域；

转换与每一区域相关的图形输出；和

平滑上述多个区域的边界区域。

18.如权利要求17所述的计算机实施方法，其中图形输出包含全运动视频，并且该全运动视频被包含在上述多个区域之一内。

19.如权利要求15所述的计算机实施方法，其中图形指令由通用中间图形指令语言所表示。

20.如权利要求15所述的计算机实施方法，其中可信赖队列用于传输图形指令，不可信赖队列用于传输视频编解码器数据。

21.如权利要求15所述的计算机实施方法，其中传输转换后的输出进一步包含依据拥塞控制，调节传输带宽。

22.如权利要求15所述的计算机实施方法，进一步包含：

接收所拦截的用户输入；和

向应用程序提供被拦截的用户输入，以供处理。

23.一种计算机实施方法，包含：

通过网络从服务器接收转换后的输出，该服务器执行应用程序，提供图形输出，并将图形输出转换为转换后输出，其中前述接收包含：

接收可信赖队列，其中可信赖队列中每个数据包包含一可信赖数据包序列号，前述传输还包含向客户端传输确认信息，以响应所接收的可信赖数据包队列；

接收不可信赖队列，其中不可信赖队列中每个数据包包含一不可信赖数据包序列号；

接收不可信赖兼前向纠错队列，其中不可信赖兼前向纠错队列中每个数据包包含一变换编码，该变换编码含用于恢复丢失数据包的冗余信息；和

将上述可信赖队列、不可信赖队列及不可信赖兼前向纠错队列编译成所接收之转换后的输出；

从所接收的转换后的输出呈现图形输出；

将被拦截的用户输出传输至服务器，以响应所拦截的用户输入。

24.如权利要求23所述的计算式实施方法，其中通过可信赖队列将用户输入传输至服务器。

25.如权利要求23所述的计算机实施方法，其中上述接收还包括抖动缓冲区的处理。

26.如权利要求23所述的计算式实施方法，其中每一队列与多个信道相关，并且每一信道利用一个抖动缓冲区处理传来数据。

27.如权利要求23所述的计算式实施方法，其中转换后输出至少包含图形指令、视频编解码器数据、图形编解码器数据和通透数据之一。

28.如权利要求27所述的方法，其中图形输出被分成多个区域，且与每一区域相关的图形输出被转换成至少图形指令、视频编解码器数据、图形编解码器数据和通透数据其中之一。

29.如权利要求28所述的方法，其中图形输出包含全运动视频，并且该全运动视频被包含在多个区域之一内。

30.一种系统，包含：

服务器，通过数字计算机网络与客户端进行通信；和

可由服务器执行的应用程序，其中该应用程序产生计算机生成的图形输出，该服务器被配置为：

从应用程序处拦截计算机生成的输出；

将计算机生成的输出转换成多个数据流；和

通过网络传输转换后输出；和

该客户端被配置为：

解码和呈现图形和视频；

呈现计算机生成的输出，以响应接收的被传输之转换后的输出；

拦截用户输入；和

传输被拦截用户输入至服务器。

31.如权利要求30所述的系统，其中网络系依用户数据报协议(UDP)而执行。

32.如权利要求30所述的系统，其中服务器被进一步配置为执行拥塞控制模块，用于最小化延时，并优化可用带宽之使用。

33.如权利要求30所述的系统，其中服务器被进一步配置为执行网络反馈单元，以根据网络拥塞级别调整前向纠错(FEC)参数。

34.如权利要求30所述的系统，其中服务器利用拦截器模块拦截计算机生成的输出，该计算机生成的输出至少是音频信号，计算机数据，USB接口信号和打印排队其中之一。