CN103493479A

CN103493479A - 低延迟h.264视频编码的抗误码的系统和方法

Info

Publication number: CN103493479A
Application number: CN201180058136.2A
Authority: CN
Inventors: 艾麦尼尔·韦伯
Original assignee: Blue Jeans Network Inc
Current assignee: Verizon Patent and Licensing Inc
Priority date: 2010-10-04
Filing date: 2011-10-04
Publication date: 2014-01-01
Anticipated expiration: 2031-10-04
Also published as: US9124757B2; WO2012047849A1; US20120082226A1; EP2625856A1; EP2625856B1; CN103493479B

Abstract

提出的新方案可以是系统或方法，它们可以以一种高效的方式利用和整合复数抗误码H.264编码/解码方案，来支持低延迟多媒体通讯应用的H.264兼容视频流的抗误码的编码。即使在视频流的图像帧有网络损失时，这些抗误码H.264编码/解码方案仍能用来提供较高质量的视频。它有能力恢复这样的损失，并且较其他技术能够更快的恢复，而不需要为了获得同样级别的恢复通过所述网络发送的额外的数据/帧。

Description

低延迟H.264视频编码的抗误码的系统和方法

背景技术

近年来视频会议在企业中得到了迅速的发展，这是因为商业已经变得越来越全球化，并且雇员是与一个由远程员工、搭档、供应商和顾客组成的大型体系之间进行互动。同时，在消费者领域，能够获得便宜的软件解决方案和摄影机在手提电脑和移动设备中的广泛应用，都为采用视频聊天与家人和朋友之间保持联系起到了助推作用。

然而，可用于视频会议的选项画面仍然是被分割为隔离状态，彼此间不能很好的相互联系。在企业内部也有基于硬件的会议室，装备了来自诸如宝利通、泰德和丽视等供应商提供的视频会议系统，以及被思科公司推广的高端网真系统。在价格范围的低端是基于企业视频会议应用程序的软件，如微软公司的Lync以及诸如Skype、GoogleTalk和苹果的FaceTime等。

当选择使用任意上述视频电话系统时，在价格、质量和范围方面有很大的权衡。为了实现低延迟、高清晰度的通话，大公司投资几十万美元在他们的网真系统上，但只能覆盖访问该类似的系统的一小部分人。中小型企业投资数万美元在他们的能够实现高达720的高清晰度的分辨率的硬件系统上。他们购买价值几十万美元的带有固定数量端口的多方会议单元，并通过这些多方会议单元在他们不同的分公司之间进行通讯，但是，当要做到很容易与公司外部的系统进行交流时就很困惑。公司不能够承受这种使用例如Skype客户端的高投入低品质的解决体验，但是另一方面能够与其他人轻松地连接，无论这些人是在他们公司的内部或者外部。当普通用户发现使用这些视频会议与使用那些不需要考虑这些顾虑而只是“可以工作”的手机或固定电话相比太复杂不能理解时，他们会有所顾虑。因此，尽管视频会议的技术是可行的并且大多数人能承担的起价格，但在商业中采用视频会议的比例较低。

今天，人们比从前更加需要一种消除这种顾虑并且提供一种几乎与声音通话一样价格的、不用用户考虑复杂的顾虑的高质量的视频通话。这样的服务将会连接来自于不同的供应商的不同的视频会议以及聊天系统的硬件和软件，在彼此间互相交谈时，该视频通话涉及到不同的协议（H.323,SIP,XMPP,proprietary）和具有不同的视频和音频编解码器。该视频通话将提供比现有的解决方案更低延时性和更好的视觉体验，它将要被托管在互联网或云端，因此公司不再需要花费大量资金和运营投资复杂的设备。易用性将和安装音频电话会议一样简单，不需要来自公司IT复杂的准备安排。

现有技术中的上述例子和它们的限制是用来示例说明的，不是专用的。在阅读了说明书及附图之后，将会很清楚现有技术中的其他限制。

附图说明

图1描述一个跨越多重标准和专有的视频会议系统支持虚拟会议室（Virtual Meeting Room，简称VMR）运行的系统的例子。

图2描述一个跨越多重标准和专有的视频会议系统的虚拟会议室操作过程流程图的例子。

图3描述一个媒体处理节点的各种组件的例子。

图4A-图4B描述在一个简单的并向量场景下媒体编码的实施例图表。

图5描述一个可高度扩展的音频混合和抽样的图表的例子。

图6描述一个基于互联网/云技术的音频声波回声消除器的例子。

图7A-7C描述一个在本地局域网的每个邮局协议之间或者横跨广域网的多个邮局协议（POPs）之间的多相位媒体流分配过程的例子。

图8描述一个支持虚拟会议室（VMR）的全球基础设施引擎的软件组件的例子。

图9描述一个用于容错协议的高级机制的实施例，其中该容错协议用于阻止错误输入以避免造成不稳定或安全漏洞。

图10描述一个图解防火墙穿越技术的例子。

图11描述一个图解管理和控制视频会议的例子。

图12描述一个图解使用全球基础设施引擎的多方会议单元（MCU）进行高质量事件共享的例子。

图13描述一种将一台笔记本电脑或移动电话与一个会议室系统相关联的方法的例子。

图14描述一个图解对参与者提供欢迎屏幕内容的例子。

图15描述一个在每次通话基础上个性化视频会议室的图解的例子。

图16描述一个用于个性化共享某人的桌面、笔记本电脑和/或移动电话屏幕的单一的在线“主页”的例子。

图17描述一个通过邮箱单击视频会议进行登入的实例。

图18描述一个图解向参与者传送一个虚拟现实体验的例子。

图19描述一个图解向参与者提供增强真实用户交互服务的例子。

图20A-20C示出了具有相关时间层和图像号码的H.264视频流的编码方案的例子。

具体实施方式

本发明的方法通过示例的方式进行描述而不只是限于附图，在附图中相同的标号对应相同的元件。值得注意的是，“一个”或“一”或“一些”的用法在本公开的实施例中不一定指代相同的实施例，这样引用意味着至少一个。

本发明提供一种新方法，所述新方法具有成熟的系统和方法以支持一个虚拟媒体室或虚拟会议室（Virtual Meeting Room，VMR）的操作，其中每个（VMR）可以接受来自不同的地理位置的多个参与者，接受来自视频会议终端和其他多媒体功能设备的音频、视频、演示和其他媒体流的多个视频会议源，所述其他多媒体功能设备也可以是专有的或基于标准的并且在多数参与者之间能够进行多方通讯或点对点视频会议。对于一个非限制性的例子，来自视频会议终端的视频源包括但不限于Skype，同时来自基于标准视频会议终端的视频源包括但不限于H.323和SIP。每个单一的VMR可以通过一个分散为一系列商品服务器的全球基础设施支持，所述商品服务器作为媒体处理节点共同位于互联网接入的接入点(Points of Presence，POSs)，其中这种大规模地分布式体系结构能够以一种不需要预约的方式同时支持成千上万的活动的VMRs并且其对于VMRs的用户也是透明的。每个VMRs提供给它的用户一套迄今为止视频会议的参与者从未体验过的丰富的会议和协作互动。所述的这些互动包括对视频会议会话的控制、配置、会议参与者的可视化布局、VMR的定制和以及为适应不同的参与者对会议室的改编。对于一个非限制性例子，这样的VMR是用于在两个不同的终端如Skype客户端和一个基于标准H.323端之间的点对点通话，其中所述Skype用户在不知道其它用户的终端技术的情况下对另一个发起呼叫，在确定两个终端之间转换的必要性之后自动在双方之间建立一个VMR。

所述方法进一步利用虚拟现实和增强现实技术，以各种客制化的方式去转化来自参与者的视频和音频流，以实现一系列丰富的用户体验。所述全球分布式基础设施通过多点控制单元支持在地理分散位置的参与者之间事件的共享，所述多点控制单元用于实时处理来自多个视频会议终端的多个音频和视频流。

与传统的要求每一个视频会议的参与者遵守同样地通讯标准或协议的视频会议系统相比，本发明的VMR允许视频会议的用户或参与者使用独立样式的设备和协议参与多方或点对点视频会议会话。通过在没有终端用户介入的互联网或云中对视频和音频流执行透明操作，所述方法将不同设备和不同协议的视频会议系统和现今世界上存在的各种视频聊天结合在一起使之作为一个整体的系统。

将VMR托管在互联网或云中使得参与者能够透明地向任何人发起呼叫，并且在所有注册终端设备中通过VMR给他们打电话，以及允许被呼叫者以他们希望的任意终端设备来接听该电话。一个托管在互联网或云中的VMR能使任意参与者上传媒体内容到云中，并且以他们选择的格式转播给其他参与者，可以修改或者不修改。

图1描述一个跨越多重标准和专有的视频会议系统支持虚拟会议室（VMR）操作系统100的例子。尽管图中描述的组件功能独立，这样描述只是为了便于说明。显而易见地，图中对组件的描述可以任意的合并或分成单独的软件、固件和/或硬件。此外，明显地，对于这样的组件无论是怎么样的合并或分离都能在同一个或多个主机上执行，或在一个或多个主机上的几个虚拟化的实例，其中所述一个或多个主机可以与分布在世界各地的一个或更多个网络连接。

如图1所示，所述系统100包括至少一个操作所述VMRs的VMR引擎102、一个支持所述VMRs操作的全球基础设施引擎104和一个用于加强VMRs用户体验的用户体验引擎106。

此处所用的引擎是指用于完成一个目的的软件、固件、硬件或其他组件。所述引擎主要包括存储在非易失性存储器（也指辅助存储器）中的软件指令。当执行软件指令时，至少一个子集的软件指令被处理器输入到内存（也指主存储器）中。所述处理器在内存中执行所述软件指令。所述处理器可能是一个共享处理器、一个专用处理器，或共享和专用相结合的处理器。一个典型的程序包括对硬件组件（如输入/输出设备）的调用，所述的硬件组件通常需要驱动程序的执行。所述驱动程序可能会或可能不会被认为是引擎的一部分，但区别不是主要的。

如图1所示，所述每个引擎在一个或更多个托管装置（主机）中运行。其中，所述一个主机可以是一个计算机装置、一个通讯装置、一个存储装置或具有运行软件组件能力的任意电子装置。对于一个非限制性的例子，一个计算机装置可以是但不限于一台笔记本电脑、一个台式电脑、一个平板电脑、一个苹果平板电脑、一个苹果多媒体播放器、一个苹果手机、一个苹果MP4播放器、谷歌的安卓设备、掌上电脑，或者一个服务器机器，所述服务器是一个物理的或者虚拟的服务器，并托管于服务供应商或服务供应商的第三方提供的在互联网公共或者私人数据中心，或者位于企业的私有信息中心或者办公场内。存储装置可以是但不限于一个硬盘驱动器、一张闪存驱动或任意手提式存储装置。通讯装置可以是但不限于移动电话。

如图1所示，所述每个VMR引擎102、全球基础设施引擎104和用户体验引擎106有一个或多个通讯接口（未示出），这些通讯接口是软件组件能够使所述引擎通过一个或更多的通讯网络根据确定的如TCP/IP通信协议进行相互通讯。其中，所述通信网络可以是但不限于互联网、内联网、广域网、局域网、无线网络、蓝牙、无线局域网和移动通讯网络。所述网络的物理连接和通讯协议是本领域的技术人员所熟知的。

图2描述一个跨越多重标准和专有的视频会议系统的虚拟会议室操作过程流程图的例子。为了说明起见，虽然该图以特定的顺序描绘了功能步骤，但本发明的过程不限于任何特定或安排的步骤。熟悉本领域的技术人员应该知道该图中描述的不同的步骤可以以各种方式省略、重排、合并和/或改编。

如图2所示，所述流程图200开始于方框202，其从多个参与者接受来自多个视频会议终端的多个视频会议源，其中所述每个视频会议终端与所述虚拟会议室的多个参与者中的某个参与者相关联。所述流程图200中接下来是方框204，描述的是对于VMR的每个参与者，将所述多个视频会议源转换并混合入与参与者关联的视频会议终端相兼容的复合视频和音频流。所述流程图200中接下来是方框206，描述的是启动一个能够在多个参与者之间被实时启动的多方视频会议会话，其中所述多个视频会议终端的类型不同。所述流程图200结束于方框208，所述方框208描述的是将复合音频和视频流呈现给每个VMR的参与者以增强用户体验。

虚拟会议/媒体室（VMR）

如图1所示，VMR引擎102允许参与者通过所有类型的视频会议终端进入参与一个视频会议室。所述VMR引擎102将来自于各式各样的不同制造商提供的视频设备和/或视频会议系统与终端的软件实现的视频会议源实时的合并，以有效地处理该多方视频会议。更特别地，VMR引擎102实时将来自VMR的参与者的多个视频会议源转换和组合成一个与每个视频会议终端兼容的复合视频和音频流，例如与每一个VMR的参与者关联的所述视频会议系统。其中，所述视频会议源的转化包括视频会议源的下列至少一个或更多个方面：

●视频编码格式（例如H.264、专有的，等）

●视频编码配置文件和级别（例如H.264主层面，H.264约束基线轮廓，等）

●音频编码格式（例如SILK,G7xx,等）

●通信协议（例如H.323,SIP,XMPP,proprietary,etc.）

●视频分辨率（例如QC/SIF,C/SIF,QA/GA,High Definition-720p/1080p,etc.）

●屏幕比率（例如4:3,19:9，自定义，等）

●音频流的比特率（窄频带，宽频带，等）

●视频流的比特率（1.5Mbps,768kbps，等）

●加密标准（对称密码新标准AES，所有权，等）

●声学设计（例如回音消除、噪声降低，等）

为转化视频会议源，本发明涉及的技术包括但不限于代码转换、升频、降频、转换、混合、添加和移除视频、音频和其它多媒体流、降噪和视频会议源的自动增益控制（AGC）。

在一些实施例中，所述VMR引擎102在两个不同的终端如Skype客户端和一个基于标准H.323端之间建立点对点通话，其中所述Skype用户在不知道其它用户的终端技术的情况下对另一个用户发起呼叫，在确定两个终端之间所需的转换的必要性之后，自动在两方之间提供一个虚拟会议室。在这种情况下，所述VMR用于允许两个终端之间进行通讯，而不用用户去知道或担心终端所使用的协议、视频编码、音频编码或其他技术之间的不同。

在一些实施例中，所述VMR引擎102混合和渲染所述复合视频和音频流以紧密匹配所述多个参与者关联的视频会议终端的性能，以使参与者得到更高效的会议体验。当合成最终呈现的视频和音频流帧时，所述VMR引擎102可以考虑参与者的创新视频布局以及视频会议中各种参与者的活跃性。对于一个非限制性例子，所述VMR可以给活跃的讲话者相对于其他参与者突出的显示。在一些实施例中，VMR引擎102还可以将伴随着视频会议源的多媒体数据流/内容调解为复合音频/视频流的一部分以协作处理，其中，所述多媒体数据流将要包括但不限于，幻灯片共享、电子白板、媒体流和台式机显示屏。也支持用于参与者之间实时通讯的聊天风格信息。参与者的状态信息包括但不限于所使用终端的类型，接收到的信号质量以及可以对所有的参与者显示的音频/视频的柔和状态。

在一些实施例中，媒体处理节点300用于实时转换和组合几个视频和音频流的视频会议源，以为VMR的每个参与者创建和呈现一个或更多个复合媒体流。如图3所示，媒体处理节点300可以包括下列一个或多个部件：视频合成器302、视频代码转换器304、分布式多路视频开关306、音频代码转换器/预处理器308、分布式多路多路音频混频器310、协议连接器312和一个分布式会议控制器314。在视频情况下，下列三种（或多种）形式的来自参与者的视频流对于媒体处理节点300是可用的：

●原始压缩的视频；

●未压缩的原始视频；

●低分辨率压缩缩略视频。

如图3所示，媒体处理节点300中的视频合成器302选择其需要的哪个视频流是基于需要组成和呈现给参与者的视频来选择的。上述列出的两个或多个压缩形式的视频流被视频代码转换器304转换并使用互联网上的多路地址通过分布式多路视频开关306发送，以至于其它远程的想要这些视频流的媒体处理结点可以根据需要去订阅他们。该方案允许整个集群中的结点（本地和全球）以最有效的方式共享和/或交换音频和视频流。所述数据流可以通过公共网络、专用网络或通过一个有服务级别保证的预分配的覆盖网络传输。使用这种方法，视频合成器302可以显示各种合成结果，所述合成结果包括但不仅限于只是活动的讲话者、两个并排显示的正在会话的人以及参与者要求的任何其他自定义格式，其可能包括将所述视频转换为其他表现形式。

如图3所示，媒体处理节点300中的视频代码转换器304有效地编码和解码复合视频流，其中在解码的过程中每个不同的数据流的特征将被提取。此处，视频代码转换器304收集由复合视频的编码比特流提供的信息，其中，所述的收集信息包括但不限于：

●运动矢量（Motion Vectors，MVs）；

●CBP和跳读；

●静态宏块（0运动矢量和没有CBP）；

●量化值（Qp）；

●帧速率。

所述的这些特征被用于建立一个与未压缩的视频流以及压缩的合成流或其他变换数据相关的元数据字段。

在一些实施例中，视频合成器302不仅将原始视频流组合成一个复合视频流，而且还建立了一个复合的元数据字段，以将概括于所述元数据字段的同样的操作（包括2D和3D的操作）应用至所述复合视频的个别视频流。对于一个非限制性的例子，运动矢量需要采用相同的变换，这样视频合成器302可以适用于每个原始的视频流，所述的运动矢量包括但并不限于，缩放，旋转，平移，剪切操作。所述元数据可以被应用于其他非实时性的多媒体服务，其中所述多媒体服务包括但不限于用于离线搜索和索引的记录的数据流和注释的数据流。

图4A—4B描述的是在一个并向量场景下输入的媒体编码按比例缩小为原来的二分之一的实施例图表，其中图4A描述的是怎样处理宏块，图4B描述的是怎样处理运动矢量。其中视频合成器402尽可能对齐原始视频到宏块的边界以达到好的结果。为了这个目的，视频合成器402的比较明智的选择是在保持所述视频流的目标尺寸的同时，最小化被视频流覆盖的宏块的数量。可选择地，视频合成器402可以标记视频源的边界区域，因为在视频会议的情况下，这些视频源通常的信息较少。所述元数据字段可以在视频流中包括例如讲话者的位置的信息，所示这些信息可以被分割和单独压缩。对所述复合元数据字段处理，以在一个宏块基础上提供有意义的信息以及与编码技术最佳匹配。对于非限制性实施例，

●在H.264的情况下，处理考虑了宏块被细分为4×4的子块的情况。

●在H.263的情况下，宏块不能被细分或根据所使用的附件仅仅被细分为8×8的块。

●在H.261的情况下，所述宏块不被细分。

在一些实施例中，所述视频代码转换器304被输入合成原始视频和合成元数据字段，然后视频代码转换器304使用由元数据字段提供的信息去减少计算并且集中于有意义的区域。对于非限制性实施例：

●跳过宏块检测：如果合成元数据指向一个静止兆字节MB，可以通过选择自动跳过来快速的跳过宏块检测。

●MV搜索范围：MV的搜索范围可以根据合成元数据信息动态调整，所述搜索范围可以根据元数据字段中与MV相匹配的兆字节直接估定。

●MV预测：在所述合成元数据中显示的MV是用于在运动估计期间的初级预测。

●量化：编码过程中使用的量化值是由合成元数据字段提供的数值约束。

●帧速适配：当给出的帧速没有更新时，具有较低的帧速合成的区域则被标记并跳过。

●没有运动的合成区域得到较少的比特位。

●每个视频的边界区域用较少的比特位编码。

在音频的情况下，音频代码转换器/预处理器308将通过分布式多路音频混频器310在媒体处理节点300接收的每个参与者的音频流与其它参与者所接收的音频流混合在一起。所述混合输出也可以通过分布式多路音频混频器310经由网络发送，这样其他想要接收这个数据流的节点可以订阅它，并且在他们的媒体处理结点将其与本地的数据流混合在一起。这种方法使得全球基础设施引擎104能够向以分散方式位于VMR的视频会议中的参与者提供混合视频输出。

在一些实施例中，如图5所示，所述音频代码转换器/预处理器308能够使以最佳的采样率混合来自多个编解码器的音频信号得到高扩展音频成为可能。更具体地，所述音频代码转换器/预处理器308基于与特定VMR中的参与者相关的视频终端，首先确定出可能的最佳采样率去混合音频。然后音频转码器/预处理器308估计进入每个通道上的噪声，并确定每个通道上的语音活动。只有活动的通道被混合以消除VMR的所有噪音，并且该通道是均衡地来增强信号和降低噪音。最终，音频转码器/预处理器308通过通道的标准化混合了所有的通道，并且基于VMR中所有其它的音频流为每个参与者创建唯一的数据流以消除通道上的回音。

在一些实施例中，音频转码器/预处理器308能够提供实时进行语言翻译和其他语音到文本或语音到视频的转换服务，这些服务包括但不限于英语语言翻译和字幕的实时翻译、在通话中通过语音指令互动和修改内容以及通过语音到视频服务从互联网实时引入数据。

由于视频会议的一个或多个参与者一边的坏的或不存在的回声消除常常会破坏VMR中的所有人的整个会议，在一些实施例中，如图6所示的一个实施例，所述音频代码转换器/预处理器308能够基于互联网/云自动判定在一个视频会议终端声音回波消除的需要。首先，所述音频代码转换器/预处理器308判定所述音频流从MCU（Multipoint Controler Units，多方控制单元）出来到终端并返回，这期间往返行程的延迟时间。然后音频代码转换器/预处理器308估计从MCU中出来的声音信号在扬声器和麦克风上的长期和短期的能量损耗。在终端处的自然损耗可以由下面的公式计算：

ERL=logi0(能量(麦克风信号)/能量(扬声器信号))

如果终端的自然损耗大于24分贝，没有必要去做回声消除。

分布式基础设施

对于视频会议，传统的方法是建立一个基础设施，为满足这些要求往往需要使用FPGA（现场可编程逻辑阵列）和DSP（数字信号处理器）定制硬件去实现低延迟媒体处理，并将硬件链接起来共同处理大的负荷。这样的一个自定义硬件系统在AA/格式和通信协议中不是很灵活的，由于所述硬件逻辑和DSP编码是为一组特定的AA/编解码器和格式编写和优化所以它能处理。建立该系统是非常昂贵的，它需要大量的研发团队和多年的设计周期与专业的工程技术。

支持图1所示的所述VMR引擎102的操作需要一个多协议视频桥接方案，如业界所熟知的多点控制单元，以及前述讨论的媒体处理节点，以处理和构成来自各种不同终端的视频会议源。传统地，一个MCU是通过将特殊的FPGA（现场可编程逻辑阵列）和100s的DSP（数字信号处理器）配合在一起的由自定义硬件建立的，最终形成昂贵的刀片框架安装系统中的具有许多数字信号处理器板的多点控制单元。即便是这样如此昂贵的系统，当参与者使用HD视频时它连接到MCU也仅仅能实现10s或100s的速度。为了达到更大的的范围，服务供应商不得不购买许多这种刀片箱子并且将负载平衡器和自定义脚本放在一起。但是该方法是非常昂贵的且难以实施，很难对DSP软件和使用的FPGA代码编程并且很难在全球范围内无缝分发。此外，该系统通常运行专用的操作系统，这就使得很难添加第三方软件和迅速的提供新的特征以及一些功能，这样当虚拟会议室跨越多个MCU时，为虚拟会议室中的参与者提供灵活的影像合成的能力就丧失了。

如图1所示的实施例，所述全球基础设施引擎104能够使得通过建立MCUs（Multipoint Controler Units，多方控制单元）作为媒体处理节点，利用非定制(off-the-shelf，或称为现成的)部件，例如用Linux/x86的CPU（中央处理器）和PC的GPU(图像处理器)来代替定制硬件，处理媒体流，来有效的和可扩展的处理和合成媒体流。这些MCU可以以堆叠式(rack-and-stack)云计算风格被部署，从而实现以最具扩展性和性价比高的方法来支持VMR服务。过去的5年中在数字信号处理（DSP）功能方面，所述x86结构已经有了极大的提高。此外，现有的用于渲染PC图形的图像处理器（GPU）可以用来增强CPU的处理能力。

如图1所示，全球基础设施引擎104支持并且使所述VMR的运行具有下列至少有一个或多个属性：

●支持多种音频格式和协议的能力；

●可扩展的混合和合成音频和视频流；

●在全球范围内以最小延迟的服务传递；

●建立资金效率和运行成本效率。

在一些实施例中，全球基础设施引擎104能够将本地局域网上的以及跨地域的x86服务器集群作为MCU的媒体处理节点300，以实现接近无限的扩展。所有的媒体处理节点300作为一个巨大的MCU协同工作。在一些实施例中，例如这些聚集的MCU的设计利用网络层多路传送和一种新颖的多比特率的数据流分布方案来实现无限扩展。在这种设计下，全球基础设施引擎104能够根据每个通话参与者的数量、呼叫者的地理分布和跨越全世界多个POP协议的呼叫的分布实现极大的可扩展性。

在一些实施例中，全球基础设施引擎104在第三方数据中心通过接入点（Points of Presence，POP）方式在全球分配所述MCU以处理有着不同通信协议的视频终端的视频会议源。每个POP有着所要求的能够处理来自所述接入点所在的地理区域的负载的处理能力例如服务器）。用户或参与者连接到所述视频会议系统100并被所述全球基础设施引擎104引导到最近的POP（连接器）以便他们最小化他们的延迟时间。一旦参与者到达所述全球基础设施引擎104的POP，他们的音频和视频流会议源可以在所述POP间的高性能网络继续。这样分布的全球基础设施引擎104使得有史以来建立的最大的媒体处理引擎（VMR引擎102）作为一个单一系统100来运行。如果使用传统的基于DSP/FPGA自定义硬件的方法建立，该系统需要大量的资本、研发成本和巨大的匹配的操作脚本。

图7A-7C描述都来自一个POP的本地局域网的或者在广域网上跨越多个POP的多相位媒体流分配过程的例子。如图7A所示，其描述媒体流分布阶段一，具有一个POP的单节点媒体分布，在该阶段中，举个非限制性例子，来自一个视频会议的参与者的视频会议源通过，运行H.323的会议室系统、运行H.323的PC、运行Skype的PC，根据邻近会议主机的原则，其全部连接到POP内的一个节点，在该阶段中，所述视频会议源是负载平衡的但不聚集在POP节点之间。图7B描述媒体流分布阶段二，具有一个POP的聚集节点媒体分布，其中来自参与者的视频会议源在POP中聚集的节点之间是负载均衡的，并且所述音频/视频流在POP中的节点之间是分散的/溢出的。图7C描述媒体流分布阶段三，在具有POP的聚集节点和不同的POP之间均完成媒体分配，在该阶段，一些会议的参与者可以连接到距他们最近的POP而不是一个单一的POP。

在一些实施例中，所述全球基础设施引擎104将允许多个其它全球分布式专用网络去连接它，其中包括但不限于对视频会议服务的部署：如微软的Lycn聊天工具要求在边缘节点处联合（例如多个组织机构之间的合作）、以及几个通讯和传输协议的转换和解码。

在一些实施例中，全球基础设施引擎104可以限制来自一个视频会议的每个参与者的视频会议源最多只能通过系统中的媒体节点和/或POPs的两个跃点。然而，可能获取具有执行编码转换和编码转发的中间媒体处理节点的其它层级。使用这个方案，全球基础设施引擎104能够向参与者提供与不支持可扩展视频编码（SVC）的设备相关联的伪可扩展视频编码，例如视频会议的每个参与者支持具有适当比特率加速/减速能力的音视频编码（AVC）。在媒体分布式网络中，所述全球基础设施引擎104取得所述的AVC数据流并将他们改编为多比特率AVC数据流。根据所述方案，仍然可以在支持SVC的设备上使用SVC，随着参与者客户端设备对SVC采用的增加以及这种网络的采用和成长，也可能在在内部网络使用SVC而不是多比特率AVC数据流。

图8描述一个支持虚拟会议室（VMR）的全球基础设施引擎104的软件组件的例子。一些所述组件的包括但不限于用于在H.26x、G.7xx和SILK之间处理编码转换、影像合成、混合和消除回声的媒体网关引擎、媒体处理引擎和在H.323、Skype、SIP、XMPP、内网互联之间的多协议连接器，诸如会议控制、屏幕和演示共享、聊天，等网站应用程序，通过这些结点和全球基础设施引擎104的POPs进行分散，以实现实时通讯。所述一些组件，包括但不限于用户/账户管理、计费系统、用于指导、监控和节点管理的网络运营中心（NOC）系统是在一个或多个集中但冗余的节点上运行。其他的组件包括但不限于通用应用程序框架和平台（例如Linux/x86的CPU、GPU、包管理、聚集）可以是在分布节点和集中管理节点两种节点上运行

当到达服务器的输入是通过一个开放性的网络尤其是不受信任的资源接受的时候，为了防止安全漏洞、拒绝服务攻击和服务的不稳定性必须对输入进行验证。在视频会议情况下，需要验证从一个会议终端输入的音频/视频流，所述验证包括控制协议信息和压缩的媒体流，这两者必须进行验证。编码对不信任的输入的处理是负责在其进入系统传播之前，对不信任的输入的验证和清楚检查，这点很重要。历史已经表明依靠这作为唯一的验证对策是不够的。对于一个非限制性的例子，H.323大量的利用抽象语法标记法一（ASN.1）进行编码，几年来，大多数公用ASN.1的实施有一些安全问题，ASN.1的复杂性使得它几乎是不可能去手编一个完完全安全的解析程序。对于另一个非限制性例子，许多H.264视频解码器的实施不包含由于性能原因的边界检查，反而包括当它执行一个无效的存储读取并触发故障时去重新启动编解码器的系统特定的代码。

在一些实施例中，图9描述全球基础设施引擎104通过协议连接器212提供一个高级的容错协议处理机制以防止不当的输入造成不稳定和可能出现的安全漏洞的一个实例图解。所有处理协议控制信息和压缩的音频与视频流的编码被隔离在一个或多个单独的、独立的、无特权的进程中。更特别地，

●单独进程：每个正进入的连接都应该要引起一个由协议连接器212创建处理的新的进程。所述进程将要负责解压缩进入的媒体流、将进入的控制信息转换为内部API呼叫和将所述媒体解压缩为一个内部未压缩的形式。对于一个非限制性例子，入站的H.264视频在传递到另一个进程之前可以被转换成YUV420P帧。这样做的目的是，如果这个进程崩溃，系统的其他部分将不会受到影响。

●独立进程：每个连接都应该在自己的进程中处理。一个给定的进程应该仅仅负责一个视频电话终端，因此，如果这个进程崩溃，只是单个终端受到影响，而系统的其他人不会注意到任何事情。

●非特权进程：每个进程应尽可能与系统的其他部分相互独立。为了做到这一点，理想上是每个进程最好通过自己的用户证书运行，并且可以使用改变根目录系统调用使得大部分文件系统无法访问。

●性能方面注意事项：协议连接器212将要引进一些进程，在这些进程中通常只有一个存在时将带来性能下降的可能性，特别是在处理音频和视频流的系统中在进程之间需要移动大量的数据。为了实现这个目的，可以利用共享内存设施以减少需要复制的数据量。

在一些实施例中，全球基础设施引擎104支持基于互联网/云的客户端-服务器体系结构的分布式容错消息传送，其中所述分布式容错消息传送提供一个或多个下列特征：

●在可靠和不可靠的传输机制下具有直接单播、广播、多路广播和任播流量的能力。

●平衡访问媒体处理节点的服务请求与敏感内容或空闲服务器分类之间的负载的能力。

●不管程序是否崩溃都能够传输信息的同步和异步传输机制。

●包括使用有效的扇出技术进行原子广播的基于优先级和时间顺序传输机制。

●利用单写和原子广播实现一个有效的扇出的能力。

●有选择地放弃非实时排队的信息以提高实时响应的能力。

●具有放弃未传输的非实时事件能力的基于优先级的排队机制。

●一个事务意识消息系统。

●基于会议室、IP地址、进程名和进程号等内容与一个分层条目的命名系统集成。

传统地，所述视频会议参与者的传统视频终端，如使用H.323协议的视频会议终端，其主要与企业或组织机构的局域网内的其他终端连接。人们曾多次尝试使H.323终端穿过防火墙与企业网络外部的终端进行无缝通讯，其中一些防火墙已经在ITU协议中被标准化的防火墙扩展至H.323，称之为H.460.17,18,19,23,24，而其他一些被视频会议设备供应商采用的尝试，包括在公司网络的DMZ中去部署网关硬件或软件。然而，事实证明这些尝试没有一个是成功的，组织间的通话一直是繁琐的，并且只能通过繁重的IT的支持和参与来进行。

在一些实施例中，全球基础设施引擎104使得视频会议参与者的传统视频会议终端能够无缝防火墙穿越与其它终端进行通讯。由于传统视频会议通常执行标准化协议，而这些标准化的协议不承担（assume）可用的基于互联网/云的服务，全球基础设施引擎104利用至少一个或多个以下的技术来实施如图10的实施例所示的防火墙穿越：

●将所有从位于防火墙外的终端呼出的视频会议限制到全球基础设置引擎104的一个服务器上，其中该服务器能通过一个每个用户都可访问的网络上的公共的IP地址获得。

●保持一系列用于到达全球基础设施引擎104的UDP/IP端口，并且全球基础设施引擎104通过该一系列UDP/IP端口将媒体分配到一个小的指定的端口子集。这使得具有严格防火墙政策的公司，与完全打开防火墙相比，只是在一个相对狭窄的范围打开防火墙。

●提供了一个简单的基于Web浏览器的应用程序，该应用程序允许任何用户都可以轻松运行一系列的检查以确定公司防火墙的性能和行为，并且确定使用H.323终端时防火墙是否是一个问题或需要变更任何规则。

●提供一个增强的基于浏览器的应用程序，所述应用程序作为一个隧道代理服务器使任何用户能在浏览器或本地PC操作系统上运行软件，以允许终端将所述软件隧穿到一个或多个互联网上的公共服务器。可选择地，所述软件能以独立的方式在任意PC或本地的或虚拟的网络上的服务器上运行，形成代理服务器以实现同样的隧穿。

在图1所示的实施例中。用户体验引擎106向VMR的参与者呈现包括但不限于复合音频/视频流的多媒体内容，以增强参与者用户体验(UE)。由用户体验引擎106向在VMR引擎102上主持的VMR会议的参与者所提供的所述用户体验(UE)，主要包括以下的一个或多个方面：

●与视频会议终端的物理交互。用户体验引擎106能够以一种独立于设备/制造商的方式控制一个VMR中的多方通讯视频会议的建立和管理。大部分与制造商提供的远程控制的物理交互可以归入web应用程序，其中所述web应用程序可以从任何计算机或通讯设备中启动，包括膝上型电脑、智能手机、平板电脑。在一些实施例中，鉴于基于互联网/云的软件能够将这些交互识别和转化成可操作事件，这些交互也可以通过语音或视觉命令驱动。

●与web应用程序相关的用户界面(Ul)控制参与者与所述VMR引擎102的相互交流。此处，用户体验引擎106控制主持人与会议参与者之间的互动。通过用户体验引擎106提供的一个直观的用户界面(Ul)，视频会议的参与者能够控制诸如视频布局、静音参与者、发送聊天信息、共享屏幕和添加第三方视频内容等特征。

●视频/多媒体内容：用户体验引擎控制，在视频会议期间以及当参与者登录到一个VMR中在屏幕上实际看到的，以屏幕输出、合成会议源、欢迎条幅等形成呈现的内容。在一些实施例中，所述用户界面Ul和/或多媒体内容可能包含与参与者的呼叫体验的性能指标相关的信息，这些信息包括但不限于视频分辨率、视频和音频比特率、连接质量、连接数据包丢失率、作为呼叫结果获得的碳补偿，节省的交通费用，以及与传统的基于微处理器MCU呼叫相比节省的费用。这也是一种环保的解决方案，例如可以节省不频发的飞行旅程或为同样的行驶里程所花费的金钱以及与飞行状态水平相似的各种状态水平相关联的炫耀的权利。可以根据获得的状态的不同水平制定激励程序，鼓励参与者使用与旅游会议相对的视频会议。这对于他们在商业利益上使用视频会议给予个人奖励。

●自定义具有特殊应用程序的视频会议（例如纵向行业）。为了使视频会议满足特殊行业的需要，用户体验引擎106允许用户自定义VMR，这就使得会议参与者可以体验新水平的协作和会议的有效性。这些纵向行业或专业包括但不限于雇佣和招聘、远程教育、远程医疗、安全法律口供、例如运动、音乐会、客户支持等即时事件的共享查看等。

●根据每个主持人和/或参与者的喜好和特权个性化VMR。当安排视频会议时，用户体验引擎106为主持人提供能够个性化会议的能力。这些自定义的实例包括但不限于初始的欢迎横幅、议程表上传、指定将要用在会议中使用的视频布局和给会议参与者特权。

尽管大部分传统的视频会议系统耗资数十万美元，但他们在会议期间为会议的组织者，或者给参与者在控制用户体验方面提供非常有限的自由度和灵活性。布局来自预先配置的几个选择的选项，并且在通话期间可以修改的设置也是有限的。

在一些实施例中，在参与者通话期间，用户体验引擎106提供主持人发起的会议内的在安全和隐私设置上的管理和控制，其中所述的管理和控制特征包括但不限于，静音视频会议中的一个特定的讲话者、控制和/或向所有人或者部分参与者广播与一个视频会议终端相关的布局、与部分参与者有选择地共享额外的材料（对于非限制性实施例，在一个人力资源纵向应用程序中，其中多个面试官在一个普通的呼叫中面试候选人）。

通过互联网/云提供视频会议服务，用户体验引擎106减少了传统的视频会议系统的许多局限性。对于一个非限制性例子，在视频会议中，用户体验引擎106使与不同类型的视频会议终端相关联的参与者通过互联网互相谈话。对于一个非限制性例子，来自H.323终端的参与者和来自桌面客户端如Skype的参与者之间相互交谈，主持人和参与者可以从许多选项中进行选择。此外，与传统的被动桥接会议相比，通过在云中提供终止服务，用户体验引擎106可以访问参与者能够使用的视频会议的更丰富的功能。更特别地，每个参与者都可以控制下列方面的一个或多个：

1.在他/她的会议终端的屏幕上显示哪一个活动的VMR会议的活动的参与者他/她的视频窗口。

2.不同的参与者在他/她的会议终端的屏幕上应该如何布置的选项。

3.在哪里和如何在他/她的会议终端的屏幕上查看第二视频信道（屏幕共享、演示共享、共同观看其他内容）的布局选项。

使用这种会议内控制，主持人可以通过现有技术所不允许或不提供的方式控制特定通话的安全和隐私设置。

如图11所示，除上述选项之外，所述呼叫的主持人具有丰富的通过web界面来选择的选项来管理和控制视频会议，其中这些选项包括但不限于：

1．通话过程中静音部分参与者。

2.在呼叫过程中和部分参与者共享内容。

3.规定一个他/她的视频会议终端屏幕的标准的布局和一些其它参与者能看到的显示的呼叫者。

4.选择在部分参与者的各自的视频窗口中显示呼叫者说明的元数据，包括用户名称、网站名称和任何其他元数据。

5.通过一个实时、动态web界面以轻松和无缝的方式添加和删除视频会议呼叫的参与者。

6.轻松定制向加入呼叫的视频呼叫者显示的欢迎屏幕，可以显示呼叫的相关信息以及服务商提供商或者或呼叫主持人希望参与者看到的任何音频或视频材料。

在一些实施例中，用户体验引擎106通过在主VMR中创建子房间能够使VMR中的私人会议成为可能，任意子集的参与者可以加入该私人会议并进行私人聊天。对于一个非限制性实施例，参与者在保持在主VMR中的同时，可以邀请其他人进行一个快速的音频/视频或文字交谈。

在一个视频会议的参与者之间的分享经验活动通常要求同一个地方的所有的参与者是实际存在的。否则，当它发生在互联网上时，往往质量是非常差的，实现这一技术所必须的步骤对于一个一般人而言想要把它变成实际可行的技术是相当有挑战性的。

在一些实施例中，用户体验引擎106提供了通过VMR协同浏览事件，这些事件是可以预定并且在参与者之间共享的，这样他们能够体验同时多人参与一件事情的乐趣，并且通过视频会议一起分享该体验。对于一个非限制性实施例，所述共享的事件可以是一场人们希望与朋友们一起享受的超级杯比赛、或一群朋友一起观看一些电影预告片的快速会话，从而决定将要去电影院观看哪个。

在一些实施例中，如图12中的实施例所描述的，用户体验引擎106利用全球基础设施引擎104中的MCU提供一个事件共享的方便、快捷和高质量的解决方案。更特别地，用户体验引擎106使呼叫发起者1202邀请一群其他参与者1204通过web界面1206共享VMR中的视频会议。一旦加入到VMR中的web界面1206中的每个人共享在线视频和内容，然后发起参与者1202可以呈现需要共享的内容所在的网站的链接，并且所述内容直接从内容源流入同样的VMR1206，不管该内容是与发起参与者1202在一起的，还是位于网络上的第三方网站或内容服务器上。参与者1202可以在观看内容1210的同时继续与其他参与者1204进行对话，这些观看内容的特征包括但不限于，例如哪里可以看见、它的音频级别、是否需要消音、是否暂停或暂时移除等各种项目的布局，这些是由共享这些内容1210人控制，类似于上述讨论的视频会议主持人管理和控制视频会议的控制。该方法提供一种引人注目的和新颖方式使分布在世界各地中还想要一起经历一个事件的一群人来观看现场直播。这就使得围绕在主动参与现场直播事件周围的一整套新的应用程序成为可能，这种现场直播事件包括例如会议或结婚等社会事件。

在一些实施例中，用户体验引擎106能够实现多视图显示和视频会议的参与者的设备无关控制。此处，所述每个视频终端都有它自己的用户界面并且在会议室中对于硬件视频系统是可用的，所述每个视频会议终端都有一个不容易使用的远程遥控。为了使连接VMR的用户体验简单，用户体验引擎106最大限度地减少了需要利用本地界面实施的操作，并将所有这些功能移动到大多数用户熟悉的装置中运行的界面，这些用户熟悉得装置包括例如台式电脑、笔记本电脑、移动电话或移动平板电脑，通过这些使得用户体验尽可能独立于终端装置用户界面功能而去控制VMR。通过这种与设备无关的视频会议控制，用户体验引擎106提供了灵活性、易于使用、丰富的体验和扩展功能，它使得这种体验对于参与者来讲是远过个人的并且是很有意思的。

在一些实施例中，用户体验引擎106也可以让参与者使用多设备/视频会议终端来参与和/或控制视频会议。在一台设备,例如视频会议室系统上，参与者可以接受音频和视频流。在另一台设备，例如笔记本电脑或平板电脑上，参与者可以发送/接受演示材料、聊天信息等，并且还可以用它来控制会议，如对一个或多个参与者静音、为演示需要使用画中画而改变视频会议终端屏幕的布局等。笔记本电脑上的操作被反映到视频会议室系统，因为两者都连接到同样的托管的视频会议的VMR上。

目前，从H.232终端接连一个视频会议往往需要通过对设备的远程控制来执行频繁的步骤。除了逻辑问题,例如在请求的会议室定位远程遥控之外,还有从目录中获取正确的号码来呼叫、进入指定的代码进行远程呼叫等方面的学习曲线相关的问题。终端参与者以及桌面参与者在打开他们的视频装置加入议会时，直接被加入会议中。

在一些实施例中，用户体验引擎106通过向参与者呈现欢迎屏幕提供了一个全新的方式以改善和简化用户体验，其中向参与者呈现的欢迎屏幕内容包括但不限于用于图14的实施例中的视频会议的互动欢迎握手、闪屏、进入房间号码相关信息的交互、欢迎视频等。为了从一个视频会议终端加入一个呼叫，主持人要做的所有事情就是需要呼叫他/她所订阅的个人VMR号码。然后主持人可以设置呼叫的详细信息，所述信息包括形成和其他参与者欢迎握手部分的丰富的媒体内容，其可以被设置为主持人所主持的所有呼叫的默认选项。其他参与者呼入VMR并且进入指定号码的房间进行会议呼叫。在加入VMR时，他们首先享受设置为欢迎页面的丰富的媒体内容，包括会议内容说明，例如议程、各呼叫方的名称、公司相关统计数据等。这些内容还可以是更通用的而非商业应用程序，包括视频、音乐、动画、广告等任意flash内容。加入呼叫后，该显示还在参与者他/她的屏幕上显示一个对于参与者特定的代码，其可以用于为共享内容向会议传送内容。所述代码也可以通过一个用于呼叫的web应用程序输入或通过声音或视觉指令运行，其中所述声音或视觉指令被互联网云中的软件识别和处理，然后转化为可执的事件。

图13描述一个会议室系统与笔记本电脑或移动电话连接方式的例子，其中所述参与者使用一个家庭网络（HAN）房间会议系统1002并使用远程遥控上的进入目录向一个熟知的VMR1004拨出，一旦连接成功，用户体验引擎106播放一个欢迎屏幕以及一个与该视频会议相关的“会议ID”。所述参与者进入一个web应用程序1006或移动应用程序1008，并将该会议ID连同其希望加入的VMR的会议号码一起输入该应用程序，使得参与者进入VMR中。可选择地，一个参与者可以根据下列的一种方式进入到一个托管在VMR中的视频会议：

●在会议室系统中使用按键提示音

●通过语音识别控制一次拨号进入

●从笔记本向会议室系统播放识别的音乐或声音

●一旦连接对会议室的相机显示一些手势或模式。

上述所描述的体验也为任意参与者提供了不使用默认的打开音频或视频流的机会。当所有参与者进入并且呼叫准备开始时，所述主持人可以在全球范围内开始该呼叫，并且每个参与者可以细微的控制是否开启/关闭他们的音频/视频。在一些实施例中，当参与者等待时，这也允许提供货币化（monetizable）服务，例如对小范围的参与者、时区、人口以及由互联网云端的服务所决定的其他特征播放流媒体广告。在其他实施例中，当人们等待呼叫开始时，可以显示关于服务器中引入的新功能的视频，在其他实施例中，参与者在电话会议中的详细信息可以以丰富的多媒体格式被显示，现有技术中不可能有这种技术。

目前，希望组织视频通话的消费者只有两种选择，要么选择使用H323终端的商业/专业选项，例如宝利通（Polycom）或泰德系统，或使用功能/质量有限的桌面应用程序，这种应用程序向用户显示参与者的邮票大小的视频，而且特别地，是显示在一个简单的或乏味的背景或界面上。

为了解决这个问题，图15描述了用户体验引擎106提供个性化VMR允许参与者在每次通话基础上去自定义(或定制)或个性化他/她的会议体验，这些显著的转变、革命化和大众化了视频会议体验。对于企业用户来说，用户体验引擎106在会议期间为通话寻找会议室，或者类似的专业设置和不同类型的背景、欢迎音乐、欢迎横幅、其他状态和聊天信息以及五彩纸带等提供布局和背景。

主持人能够从基于预定计划提供给他/她的一系列选项中挑选一个。对于零售的消费者，所述体验将是更加非正式的和变化的。呼叫者可以以任意他/她喜欢的方式装饰他/她的房间。参与者的用于VMR的个人网站可以同样地装饰和个性化。在呼叫期间，用户体验引擎106可以提取或读入这些被参与者指定的可定制选项，并把他们置入这个定制VMR中，这样这种体验比传统的呼叫体验更加丰富。

通过互联网/云提供个性化会议服务具有在任意终端去除处理器计算能力的明显优势。只要终端能够接受和处理编码的视频流，用户体验引擎106能够对参与者提供任意级别的丰富媒体内容作为他们的部分呼叫体验，所有这些可以被VMR中的主持人控制和设置。

对于一个两人对话，与传统的将双方并排显示的平面布局不同，用户体验引擎106可以呈现3D布局，来自双方参与者的输入视频被设置成使他们看起来正在彼此看着对方，这样视频会议中的其他参与者看到的对话更自然。同样地，对于一个非传统性的应用程序，例如远程医疗，或者病人可以和医生远程谈话的一个电话会议，所述的会议本身可以被做的像一个医生的办公室。当患者在等待医生时可以观看一些健康相关问题的视频，一旦医生呼进来，这些体验可以模拟一个虚拟的医生的办公室访问。其他的应用程序包括但不限于一些情景，例如招聘可能他们具有自定义的布局和看起来不一样的视频呼叫，其中在他们的视频中，被面试者的简历可以被面试官看到，并且简历可以被面试官编辑和注释，但是这可能是对被面试者是隐藏的。

一个“汇接”服务，例如我们的保留呼叫者匿名的服务，其允许他们从任意软件或硬件终端中呼入，而不被接听者发现呼叫人的任何个人身份信息。

目前，对于web用户来说一个最重要的痛点就是对远程协作缺乏方便和完整的解决方案。有许多场景，在这些场景中用户需要与远程用户分享当前在他们屏幕上的东西,例如一个绘画、一个视频、在线故障检测期间他们的设备当前的状态以及指定的一些内容。目前要做到这一点唯一的方法是要签署一个支持屏幕共享的桌面客户端，请求联络允许开始共享。如果一方没有这样的客户端，或者他希望共享的屏幕那个人客户端上的联系人，该方法则无效的。此外，这些解决方案不适用于手机和其他小屏幕设备。

在一些实施例中，用户体验引擎106创建一个单一的在线“主页”用于与其他的视频会议终端个性化地共享某人的桌面、笔记本电脑和/或移动屏幕。在本文的讨论中，屏幕共享指的是通过在另一端/远端视频会议终端的屏幕上显示某一个人的屏幕,使得能够看到一个远端机器的屏幕的动作，或者同时在一个流媒体形式中。这种共享的一些微小的变化包括允许远程用户仅仅看到某人屏幕的一部分、给他们额外的能力与某人的屏幕进行交互等。对于非限制性的实施例，为了屏幕共享，用户体验引擎106提供一个或更多的下列特征：

●能够以个性化、一致的方式访问HTTP或HTTPS。如图16所示，对于一个非限制性实施例，一个服务的用户将被分配一个http://myscre.en/joeblow形式的网址（URL），无论该用户何时共享他的一个或多个他/她的屏幕时，都作为访问用户屏幕的固定访问链接。然后所述用户能和他/她的朋友、同事、在线的社交网络等共享这个URL。此处，所述URL可以是一个所谓的缩略网址（TinyURL）（域名通常小于10个字符）可以对网络上的位置作一个简单的速记。

●访问某人的屏幕共享网址是可以通过默认选项自定义的，以实现只有当用户主动的选择共享他/她的屏幕时访问才能实现。此外，通过向用户提供参与者通行代码的合并、定时屏幕共享会话和IP地址过滤选项，以确保最大程度的控制用户共享他/她的屏幕的人群。

●当在屏幕共享模式下，可以向参与者显示可用屏幕的列表，参与者可以选择这些列表中的一个或多个进行观看。根据主机的权限设置，他们也可以发出远程访问与共享的屏幕进行交互。

如Skype公司已经创建了浏览器插件，其通过在显示在他/她浏览器上的任意号码旁边显示一个“Skype电话”图标，允许一个参与者用单击的方式对显示在他/她浏览器上的任意号码进行呼叫，并通过一个Skype桌面客户端传送这些呼叫。另一方面，如今的用户的在线联系人可能是在多个存储方式中的一个，如谷歌联系人、交易所、雅虎联系人、Skype、Facebook等。尽管这些联系人在本机应用程序中能以不同的方式交互（对于非限制性实施例，例如悬停于谷歌联系人，会向用户出现一个具有与该联系人发邮件或即时通话选项的菜单），但是没有一个简单普遍的方式来提供跨越不同联系协议的，类似于Skype对号码所做的一键式视频呼叫功能。

在一些实施例中，用户体验引擎106支持web浏览器和/或桌面插件，其使得能够智能一键式视频会议呼叫来自于视频会议终端的认证协议的VMR联系人中的参与者能够（而非号码）。如本文所述，插件指的是扩展一个较大程序的功能的一小片软件，所述插件常被用在web浏览器和桌面应用程序中，以在特定区域延伸它们的功能。

在一些实施例中，用户体验引擎106创建的插件提供了这样功能，无论什么情况下，来自验证协议的联系人都被显示在浏览器中（如Gmail，YI Mail等）和/或桌面应用程序（例如MS Outlook，雷鸟（Thunderbird）等）中。如图17所示，由用户体验引擎106提供的一键式视频会议呼叫插件提供至少有下列特征：

1.用户必须同意安装这些插件以及激活所述插件的应用程序。

2.为了启用应用程序，来自认证协议（假设是消息协作和谷歌联系人）的每一个联系人旁边有一个“视频呼叫”图标。对于一个非限制性例子，如果在一个用户的Exchange邮箱中的邮件的发送者是一个认证协议，则信箱的显示界面被增加一个视频通话的图标以及一个显示更多选项的小箭头。

3.单击该图标在用户和联系人之间通过VMR建立一个视频会议呼叫，其中双方选择适当的视频终端。

4.单击所述箭头为用户提供用户可以通过VMR服务与联系人进行交互的方式的完整列表，所述VMR服务包括音频呼叫、安排一个将来的呼叫等。

在一些实施例中，当一些视频会议呼叫房间太亮并导致注意力分散时，用户体验引擎106自动执行视频增益控制。类似于音频系统中的AGC（自动增益），视频会议终端的所有房间的亮度是视频会议的一部分，其可以被调整以产生一种会议发生在同一个地方的假象。可选的，视频自动增益控制可以由会议中感觉一个或多个房间的亮度令其不安的参与者打开。

在一些实施例中，用户体验引擎106提供关于进行中的视频会议费用节省的实时信息，例如每个会议的节省的英里、汽油成本、酒店成本。其中，参与者之间的距离可以根据IP地址的地理位置和英里数计算，并且联邦英里数积分可以根据每次通话节省的英里计算以在屏幕上呈现一个总金额。所述声称的碳抵消也可以根据参与者的位置和呼叫的持续时间计算，并适当的显示给参与者。

虚拟实境（VR）表现了计算机化身与静态图像之间光谱跨度，其中所述计算机化身是预配置供选取的，所述静态图像是可上传的并且在有限程度上动态的（animated）。在一个多方视频通话设置中，没有办法要么将该参与者迁移到一个虚拟世界中，而同时保持他们现实世界的人物角色，要么将他们移植入一个虚拟实境（VR）世界中并且同时动画他们的人物角色。

在一些实施例中，为了解决上述讨论的两个问题，用户体验引擎106通过全球基础设施引擎104的MCU向一个视频会议的参与者呈现逼真的虚拟实境（VR）事件。像传统的视频会议呼叫一样，所述VMR接受来自不同参与者摄像机的音频/视频流的输入并把他们复合成一个整体，然后进行编码和分别传送所述复合视频给每一个参与者。如图18所示，当参与者希望一个事件的虚拟实境（VR）版本时，用户体验引擎106接受下列一个或更多额外的步骤向参与者传送VR体验。

1.图像检测和分割组件1802接受来自于每个参与者的输入的视频。

2.分割组件1802从视频流的背景中检测和提取出参与者，并提供关于他/她在视频流中的位置和其它特征的元数据。

3.然后用户体验引擎106通过虚拟实境渲染组件1804在参与者面部上增加各种各样的特征或通过应用任意图像变换算法变换面部，使参与者变得生动。用户体验引擎106可以进行进一步分析面部和特征检测以及充分使参与者的脸部生动化，进而创建一个脸部本身的半动画版本。

4.在媒体处理节点300内的视频合成器302通过用由虚拟实景的（生动化的）参与者覆盖的背景替换所选取的背景，并向其他参与者提供该视频流。

通过这种方法，用户体验引擎106能够获取和转换来自不同参与者，以不同的自定义方式输入的视频和音频流，以达到不同的用户体验。

在一些实施例中，用户体验引擎106可以将所有参与者从他们的的视频流环境中提取出来，然后将他们添加到一个共同的环境中并且作为一个视频流发送。对于一个非限制性实施例，位于不同的地理位置的不同参与者进行呼叫都可以看起来像是彼此坐在会议桌前的谈话。

提供小范围的，实时提供的关于在特定地理范围内的用户可用的服务的广告具有广阔的市场应用前景和巨大的利益。现存的少数的解决方案严重依赖或完全依赖GPS相关信息，或者移动设备上的高性能处理器来执行所要求的程序以产生该信息。在一些实施例中，用户体验引擎106允许通过全球基础设施引擎104的MCUs实现基于互联网/云计算的增强现实的用户交互服务。更近一步地，用户体验引擎106对由参与者/用户视频会议终端（例如，一个带摄像头的手机）采集的视频流进行解析，并且提供增强现实的视频连同参与者所在地理区域可获得服务的注释一起反馈给用户，例如当地活动、娱乐和餐饮选择等。用户只需要将一个视频电话放在VMR,并且将他/她的视频摄像头对准他或她所感兴趣的地方。正如图19所示，用户体验引擎106和全球基础设施引擎104在云端处理接收到的视频，这样用户设备中不需要具有处理器能力，对于一个非限制性实施例，通过图像检测和分割组件1902分析广告牌、可以确认的路标以确认核实从位置服务数据库1904获取的GPS信息，或从用户GPS获取的信息，以确定他/她的行踪。用户体验引擎106然后用收集的用户地理信息更改输入视频源并通过元数据合成器1906覆盖该视频流，以向用户产生一个增强现实视频流，其中该元数据合成器具有的元数据包括，例如步行范围内餐馆的名字、当地娱乐场所的名字等。

如图19所示，图像检测和分割组件1902是该逻辑的核心，其用来分析输入视频和从视频中提取感兴趣的区域。位置服务数据库1904被填入关于不同压缩编码的信息，其可以将GPS信息和/或压缩编码作为输入，并提供关于在该区域的服务的丰富数据以及其它可能感兴趣的信息。如前所述，元数据合成器1906从图像检测和分割组件1902，位置服务数据库1904获取输入信息，并实时呈递有用的元数据，所述并且用关于周围环境的有用的元数据覆盖输入视频源。

在一些实施例中，当用户在所述区域周围行走时，用户体验引擎106可能提供一个该区域的指导旅行，所述用户体验引擎106可以预先在屏幕上填充关于该区域的风景和声音的更多信息。在另外一些实施例中，用户体验引擎106也可以在视频中填充信息，以及显示可能在附近的朋友的照片，以将这种增强现实服务嵌入已存在的服务中，以定位位于同一区域的朋友。

在一些实施例中，由用户体验引擎106提供的增强现实服务是可定制的，不仅仅是在向用户的移动终端上安装下载的任何软件时，而且是在每次使用方式上。用户使用增强现实服务可能是为了各种各样的目的，对一个非限制性实施例，在某一个时刻进行411查询，在那之后，用户可以立即打电话和得到一个突出显示的当地旅游的虚拟旅程，不久之后，用户可能还需要餐馆的相关信息去大餐一顿。随着能够在在第三方网站上得到关于每一个地方的更多信息，用户体验引擎106提供一种无缝的方式与因特网/云端上的每一个提供者密切关联，以向每个用户提供更多当前信息。。由于这种方法是完全堆架式，只取决于用户选择的方案，所述通话可以通过一个具备更强大运行能力的系统来运行以获取并为用户提供更多有用的信息，这样依据每个用户所需要的功能提供一套完整的定价选择。

在一些实施例中，户体验引擎106通过在云端对不同语言的实时翻译，来支持一个现场直播视频会议中实时多媒体通讯的免费翻译，，这样VMR的参与者就可以使用不同语言进行相互交流，以及进行智能会话。更近一步地，所述实时基于云技术的翻译可能包括但不限于一种或多种下述选择方案：

●以一个通用的语言，实时语音加字幕，例如，一个视频会议中，不同的发言者可以说在不同的语言，同时翻译和字母被无缝地在云中完成；

●为语音发起服务，例如搜索和基于位置的服务，提供的从语言到可视化的翻译;

●以每个参与者为他/她选择的相应语言翻译的声音；

●和讲话者所说的语言相同，但可以选择不同的声音以替代讲话者的声音；

●通过云技术，以不同的语言向不同用户提供多媒体演讲/会议的同声翻译；

●不只应用音频/视频传输，还实时传输从发送者格式到接收者所选择接收数据的格式的文件/输入，其中这种转换是在云中实现。

考虑到构建的延迟，当两方或者多方当事人使用不同语言进行沟通时，可以通过采用人工翻译来替代这种功能。低延迟H.264视频编码的抗误码(Error resilient)方案

实时多媒体通讯系统，比如上文描述的系统，需要高效、低延迟的编码和解码机制来支持，尤其是对于H.264视频流。当今，实时交互视频通讯正开始在消费者和商业领域广泛应用。同时，这种通讯所使用的网络在过去的10年中也得到了大幅的改善，并且在性能和质量方面还在不断地改进。高端商业远程呈现会议通过高质量、低损耗的专用网络来实现，而家用视频聊天通常使用跨越全球中转站的公共因特网或使用带宽拥挤、竞争激烈、高损失的无线网络来实现。这样的商业和消费者视频通讯正在越来越多的通过同一类型的网络融合在一起，并且不再那么容易将这样的视频通讯仅限制在高质量专用网络上。在一个非限制的例子中，访问东京的商业旅行者需要参加纽约总部和伦敦分公司之间的一个远程呈现会议。游行者没有从他的旅馆房间到纽约总部的高质量专用网络。纽约总部和分公司可能有专用连接，但是考虑到成本，该连接也可能切换为通过公共因特网运行。在这种情况下，由于所述网络的不断变化的状态，为这样的视频会议而使用的实时视频技术需要适应损失，以仍然提供商业级别的会议体验。这是为实时多媒体通讯系统建立视频流的高效、低延迟编码/解码方案的动机所在。

提出的新方案可以是系统或方法，它们可以以一种高效的方式利用和整合复数抗误码H.264编码/解码方案，来支持低延迟多媒体通讯应用的H.264兼容视频流的抗误码的编码。即使在视频流的图像帧有网络损失时，这些抗误码H.264编码/解码方案仍能用来提供较高质量的视频。它有能力恢复这样的损失，并且较其他技术能够更快的恢复，而不需要为了获得同样级别的恢复通过所述网络发送的额外的数据/帧，这是个令人恼火的问题。所述编码方案还具有能够与在所述视频流的接收端的未更改的解码器一起工作的特性。

在一些实施例中，视频代码转换器，比如图3中示出的媒体处理节点300的视频代码转换器304，能够用作编码和发送所述视频流的一个视频编码器，也能够用作接收和解码所述视频流的一个视频解码器。所示视频编码器和所述视频解码器能够与在不同地理位置的不同媒体处理节点相关，它们被用来实现和整合所述抗误码H.264视频编码方案，其包括但不限于在下文介绍的被描述为“分层P结构(hierarchical P structures)”和“参考帧选择(referenceframe selection)”的技术。

分层P结构

分层P结构是以分层结构组织的一组已编码的图像帧，如果所述分层结构的较高时间层(higher temporal layer)的图像帧丢失，在所述分层结构的较低时间层(lower temporal layer)的图像帧仍然能够由视频解码器解码。在H.264编码时，使用反向预测(backward prediction)将所述分层结构中的所有图像帧编码为P图像帧，比如在时间上较早产生的帧能够被用来预测在时间上较晚产生的帧。在图20A示出了一个例子中，所述图像帧被组织成从0至3的四个时间层（深度为4），它们沿时间轴从左到右按时间依次排布。在一个非限制的例子中，如果2层的图像帧丢失了，具有箭头指向所述2层的图像帧的0层的图像帧仍然能够被解码，被所述2层的图像帧的箭头指向的3层的图像帧则不能被解码。

在一些实施例中，为了在视频流的不同帧率时具有相同的结构长度，作为媒体处理节点的视频编码器的视频代码转换器304，可以基于视频流的帧率改变H.264视频流的分层P结构的深度(层数)。在图20A示出了一个例子中，对于30帧/秒的视频流，所述深度可以是4层或8帧（两个连续的0层的图像帧之间的距离），结构长度为8/30秒=264ms。对于15帧/秒的视频流，所述深度可以是3层或4帧，具有相同的结构长度4/15秒=264ms。

参考帧选择

在一些实施例中，为了通过重新排序所述解码操作和记录收到的H.264视频流的长/短期参考帧(long/short term reference frames)建立所述分层P结构，作为媒体处理节点的视频解码器的视频代码转换器304可以使用来自H.264的显示图像缓存(display picture buffer，简称DPB)。所述长/短期参考帧已经被编码，并在丢失了一个或多个帧时能够被用来作为所述视频流的继续解码的重新开始点(restarting point)。此外，视频代码转换器304还可以预测和解码给定时间层的相同或更低的时间层的已编码的图像帧。

图20B示出了4层的分层P结构、相关的时间层和图像号码的一个例子，其中采用具有2深度的显示图像缓存（一个为长期参考帧，另一个为短期参考帧），对于第一个8帧，标记0层作为所述长期参考帧。下面的列表描述了在编码每帧图像后所述显示图像缓存(DPB)的状态：

图像号码	DPB状态
		0	Long term reference0->Picture0
1	Long term reference0->Picture0
		2	Long term reference0->Picture0;Short term reference->Picture2
3	Long term reference0->Picture0;Short term reference->Picture2
		4	Long term reference0->Picture0;Short term reference->Picture4
5	Long term reference0->Picture0;Short term reference->Picture4
		6	Long term reference0->Picture0;Short term reference->Picture6
7	Long term reference0->Picture0;Short term reference->Picture6
		8	Long term reference0->Picture8;Short term reference->Picture6
9	Long term reference0->Picture8;Short term reference->Picture6

在一些实施例中，作为视频解码器的视频代码转换器304可以通过反向通道机制(比如，在网络工程任务组(Internet Engineering Task Force)的RFC4585中描述的实时传输控制协议(基于RTCP的反馈（TRP/AVPF）)的扩展RTP简介，其在这里作为参考)触发参考帧选择方案，基于一帧的部分或全帧丢失给所述视频编码器提供了负反馈。参考帧选择的实现通常需要大的DPB缓存以保持多个候选参考帧。参考帧选择方案背后的想法是保证在编码侧的DPB中包含足够多的图像(参考帧)以覆盖在所述视频编码器和所示视频解码器之间的往返通讯延迟，以至于合适的参考帧仍然在DPB中，并在发生帧丢失时能够被提供给所述视频解码器。当通过负反馈给所述视频编码器提供有关丢失了一帧图像的视频解码信号时，所述视频编码器会在所述DPB中挑选在时间上较所述丢失帧更早被编码的一个参考帧，并将其发送给所述视频解码器。随后，所述视频解码器使用来自所述视频编码器的所述参考帧预测下一图像帧。

虽然提供较在H.264中发送瞬时解码刷新(instantaneous decodingrefresh，简称IDR)帧(其中所述IDR被用来同步或重启所述视频流的解码)更好的预测，由于需要非常大的DPB以在帧丢失的情况下保持必要的参考帧，在长往返通讯延迟面前，参考帧选择可能不会总是提供理想编码视频流。因此希望对使用长期参考帧来最小化DPB的大小的参考帧选择方案进行一些改动。

整合方案

在一些实施例中，作为视频编码器的视频代码转换器304采用结合上文描述的分层P结构和参考帧选择两者的优点的视频编码方案。具体来说，所述结合的编码方案利用时间P结构来最小化帧丢失的影响，并即使在所述分层结构中的0层的图像帧丢失的情况下，给所述视频解码器提供参考帧以继续所述视频解码器的解码。此外，所述结合的编码方案可以利用H.264的特点以最小化所述视频编码器所占用的资源。

在一些实施例中，视频代码转换器304通过类似上文描述的使用长期参考帧和重新排序操作（reorder operations）的技术建立时间结构以实现所述结合的方案。所述差别是使用了多个长期参考帧（在一个非限制的例子中，一个额外的长期参考帧对应250ms的往返通讯延迟）。在一个非限制的例子中，每增加250ms的往返通讯延迟，需要在所述显示图像缓存中增加存储一个长期参考帧。250ms的往返通讯延迟需要深度为3的DPB，500ms的往返通讯延迟需要深度为4的DPB。

在一些实施例中，所述视频编码器可以以循环方式(round robin fashion)记录用作0时间层的所述长期参考帧。所述视频编码器可以跟踪哪个长期参考帧当前被用来建立所述分层结构。如果所述视频解码器信号显示丢失了0层的图像帧，所述视频编码器决定使用哪个长期参考帧来解码所述下一图像帧。从所述DPB中选择哪个长期参考帧的决定基于负反馈确定，此时所述视频编码器可以选择在所述指示的丢失帧紧前的长期参考帧。所述决定也可以根据估计的往返通讯延迟而被直接推断出来。在这种情况下，所述丢失图像帧或所述图像帧的丢失部分的详细信息/负反馈是不需要的，只需要所述视频流的图像帧的丢失的指示。

图20C和下面的图表示出了，所述视频流中的第一个16帧图像序列是如何被所述视频代码转换器304(用作视频编码器)使用新的结合编码方案编码的。需要知道的是，对于所述额外的长期参考帧使用循环方式。使用的长期参考帧的号码能够被适当的增加。

图像号码	DBP状态
		0	Long term reference0->Picture0
1	Long term reference0->Picture0
		2	Long term reference0->Picture0;Short term reference->Picture2
3	Long term reference0->Picture0;Short term reference->Picture2
		4	Long term reference0->Picture0;Short term reference->Picture4
5	Long term reference0->Picture0;Short term reference->Picture4
		6	Long term(LT)reference0->Picture0;Short term(ST)reference->Picture6

7	Long term reference0->Picture0;Short term reference->Picture6
		8	LT reference1->Picture8;LT reference0->Picture0;ST reference->Picture6
9	LT reference1->Picture8;LT reference0->Picture0;ST reference->Picture6
		10	LT reference1->Picture8;LT reference0->Picture0;ST reference->Picture10
11	LT reference1->Picture8;LT reference0->Picture0;ST reference->Picture10
		12	LT reference1->Picture8;LT reference0->Picture0;ST reference->Picture12
13	LT reference1->Picture8;LT reference0->Picture0;ST reference->Picture12
		14	LT reference1->Picture8;LT reference0->Picture0;ST reference->Picture14
15	LT reference1->Picture8;LT reference0->Picture0;ST reference->Picture14
		16	LT reference1->Picture8;LT reference0->Picture16;ST reference->Picture14

除了支持上文描述的交叉平台实时多媒体通讯系统，结合了分层P结构和参考帧选择两者优势的H.264视频编码方案，还能够被用来支持视频流、视频广播、视频监控和更多其他类型的需要在媒介上编码视频并具有信息损失的应用。

一个实施例可以根据本发明所揭示内容的指导，通过使用一般的或专用的数字电脑或微处理器实现，这对于计算机领域的技术人员来说是显而易见的。在本申请所公开内容的教导下，熟练的程序员能够很容易地编写出相适应的软件编码，这对于软件领域的所属技术人员来说也是显而易见的。并且本发明通过使用集成电路或者通过适当的常规元件电路相互连接组成适当的网络对于所属技术领域的技术人员而言也是显而易见的。

一个实施例包括一个计算机程序产品，所述计算机程序产品是一个机器可读的媒介，其上储存有指令，其可以指令一个或多个主机执行本文中所提出的任何功能。机器可读的存储介质可以包括但不限于，一种或多种类型的磁盘包括软盘、光盘、DVD,CD-ROMs，DRAMs,VRAMs，快速闪存器，磁卡或光卡，纳米系统（包括分子存储器Ics），或者其它任何类型的适合存储指令和/或数据的媒体和设备。存储在任何计算机可读取介质上，本发明包括软件，这种软件是用于控制通用/专门的计算机或者微处理器的硬件，以及能够让计算机或微处理器与用户交互或者执行本发明的其他机制，这样的软件可以包括但不限于，设备驱动程序，操作系统，运行环境平台/容器，和应用程序。

上面要求保护主题的各种实施例的描述已经提供了说明和描述的目的。它的目的并不是为了穷举或限制所要求保护的主题所公开的准确形式。许多修改和变化对于所属技术领域的技术人员而言都是显而易见。系统的实施例和方法中所描述的界面（interface），这些内容很明显可以使用等价的软件概念来替换，比如类、方法、类型、模型、组件、构件（bean）,模块，对象模型，程序，线程和其它合适的内容。上述系统的实施例和方法中所描述的组件，很明显这些概念的可以使用等价的概念进行替换，例如类、方法、类型、界面、模块、对象模型和其它合适的内容。被选择和描述的实施例是用来最佳的描述本发明的原理和实际应用，这样使得相关领域的技术人员能够理解本发明所要求保护的主题，因此各种具体的实施例和为了特定用途可预期的各种修改都是合适的。

权利要求书(按照条约第19条的修改)

1.一个系统，包括：

一个视频编码器，在其运行时，其

将视频流的复数图像帧编码并组织为分层P-结构中的复数时间层；

在与所述视频编码器相关的显示图像缓存中记录所述视频流的一个或多个已编码的参考帧，其中每个参考帧已经被所述视频编码器编码，并能被视频解码器在一个或多个帧丢失时用作所述视频流的继续解码的重新开始点；

通过网络发送所述视频流的图像帧；

在所述视频解码器基于所述一个或多个丢失帧提供负反馈时在所述显示图像缓存中挑选一个在时间上较所述一个或多个丢失帧更早被编码的参考帧；

将所述参考帧发送至所述视频解码器；

所述视频解码器，在其运行时，其

接收通过网络发送来的所述视频流，其中所述视频流具有所述一个或多个丢失帧；

基于所述一个或多个丢失帧通过反向通道机制给所述视频解码器提供所述负反馈以触发所述参考帧的选择；

在所述视频流的解码过程中使用1)解码在所述分层P-结构中较所述一个或多个丢失帧的时间层更低的时间层的图像帧和2)使用的挑选的参考帧作为所述视频流的继续解码的重新开始点的结合恢复所述视频流的图像帧中的一个或多个丢失帧。

2.根据权利要求1中所述的系统，其特征在于：

所述视频编码器和所述视频解码器与在不同地理位置的不同媒体处理节点相关。

3.根据权利要求1中所述的系统，其特征在于：

当所述视频解码器与一个或多个编码方案一起工作时，所述视频解码器并未被更改。

4.根据权利要求1中所述的系统，其特征在于：

所述视频编码器根据H.264编码使用反向预测将所述视频流的图像帧编码成为P图像帧。

5.根据权利要求1中所述的系统，其特征在于：

所述视频编码器将所述视频流的图像帧组织为所述分层P-结构的复数时间层，使得所述视频解码器仍能够解码在所述分层P-结构中较所述视频流的一个或多个丢失帧的时间层更低的时间层的图像帧。

6.根据权利要求5所述的系统，其特征在于：

所述视频编码器根据所述视频流的帧率改变所述分层P-结构的层数以在不同帧率时保持同样的长度。

7.根据权利要求5所述的系统，其特征在于：

所述视频解码器预测并解码给定时间层的相同或更低的时间层的已编码的图像帧。

8.根据权利要求1所述的系统，其特征在于：

所述显示图像缓存包含足够的图像帧以覆盖在所述视频解码器和所述视频编码器之间的往返通讯延迟。

9.根据权利要求1所述的系统，其特征在于：

所述视频解码器使用来自所述视频编码器的参考帧预测下一图像帧。

10.根据权利要求1所述的系统，其特征在于：

所述视频编码器在所述显示图像缓存中记录了多个已编码的参考帧。

11.根据权利要求1所述的系统，其特征在于：

即使在所述分层结构中的0时间层的图像帧丢失时，所述视频编码器提供所述参考帧给所述视频解码器以使得所述视频解码器继续解码。

12.根据权利要求1所述的系统，其特征在于：

为了继续解码所述视频编码器以循环方式选择所述参考帧。

13.根据权利要求1所述的系统，其特征在于：

所述视频编码器选择所述视频解码器指示的丢失帧紧前的参考帧。

14.根据权利要求1所述的系统，其特征在于：

所述视频编码器基于所述视频流的图像帧的丢失帧的指示选择所述参考帧，而没有所述丢失帧的详细信息。

15.一种方法，其包括：

记录所述视频流的一个或多个已编码的参考帧，其中每个参考帧已经被所述视频编码器编码，并能被视频解码器在一个或多个帧丢失时用作所述视频流的继续解码的重新开始点；

通过网络发送所述视频流的图像帧；

接收通过网络发送来的所述视频流，其中所述视频流具有所述一个多个丢失帧；

基于一个或多个丢失帧提供负反馈以触发所述参考帧的选择；

在收到基于所述一个或多个丢失帧提供的负反馈时挑选一个在时间上较所述一个或多个丢失帧更早被编码的参考帧；和

在所述视频流的解码过程中使用1)解码在所述分层P-结构中较所述一个或多个丢失帧的时间层更低的时间层的图像帧和2)使用挑选的参考帧作为所述视频流的继续解码的重新开始点的结合恢复所述视频流的图像帧中的一个或多个丢失帧。

16.根据权利要求15所述的方法，其特征在于：其还包括：

根据H.264编码使用反向预测将所述视频流的图像帧编码成为P图像帧。

17.根据权利要求15中所述的方法，其特征在于：其还包括：

将所述视频流的图像帧组织为分层结构的复数时间层，使得所述视频解码器仍能够解码在所述分层结构中较所述视频流的一个或多个丢失帧的时间层更低的时间层的图像帧。

18.根据权利要求17所述的方法，其特征在于：其还包括：

根据所述视频流的帧率改变所述分层结构的层数以在不同帧率时保持同样的长度。

19.根据权利要求17所述的方法，其特征在于：其还包括：

预测并解码给定时间层的相同或更低的时间层的已编码的图像帧。

20.根据权利要求15中所述的方法，其特征在于：其还包括：

在所述显示图像缓存中记录足够的图像帧以覆盖在所述视频解码器和所述视频编码器之间的往返通讯延迟。

21.根据权利要求15所述的方法，其特征在于：其还包括：

使用收到的参考图像帧预测下一图像帧。

22.根据权利要求15所述的方法，其特征在于：其还包括：

在所述显示图像缓存中记录了多个已编码的参考帧。

23.根据权利要求15述的方法，其特征在于：

即使在所述分层结构中的0时间层的图像帧丢失时，提供所述参考帧给所述视频解码器以使得所述视频解码器继续解码。

24.根据权利要求15所述的方法，其特征在于：

为了继续解码以循环方式选择所述参考帧。

25.根据权利要求15所述的方法，其特征在于：

选择所述视频解码器指示的丢失帧紧前的参考帧。

26.根据权利要求15所述的方法，其特征在于：

基于所述视频流的图像帧的丢失帧的指示选择所述参考帧，而没有所述丢失帧的详细信息。

Claims

1.一个系统，包括：

视频编码器，在其工作时，其

基于一个或多个H.264编码方案编码并组织视频流的复数图像帧；

通过网络发送所述视频流的图像帧；

视频解码器，在其工作时，其

接收通过网络发送来的所述视频流，其中所述视频流的图像帧中的一个或多个帧丢失了；

在所述视频流的解码过程中恢复所述视频流的图像帧中的一个或多个丢失帧，而不需要通过所述网络发送额外的帧。

2.根据权利要求1中所述的系统，其特征在于：

3.根据权利要求1中所述的系统，其特征在于：

4.根据权利要求1中所述的系统，其特征在于：

5.根据权利要求1中所述的系统，其特征在于：

所述视频编码器将所述视频流的图像帧组织为分层结构的复数时间层，使得所述视频解码器仍能够解码在所述分层结构中较所述视频流的一个或多个丢失帧的时间层更低的时间层的图像帧。

6.根据权利要求5所述的系统，其特征在于：

所述视频编码器根据所述视频流的帧率改变所述分层结构的层数以在不同帧率时保持同样的长度。

7.根据权利要求5所述的系统，其特征在于：

8.根据权利要求1中所述的系统，其特征在于：其还包括：

与所述视频编码器相关的显示图像缓存，其用来记录所述视频流的一个或多个参考帧，其中每个参考帧已经被所述视频编码器编码，并能被所述视频解码器用作具有一个或多个丢失帧的视频流的继续解码的重新开始点。

9.根据权利要求8所述的系统，其特征在于：

10.根据权利要求8所述的系统，其特征在于：

所示视频解码器基于所述一个或多个丢失帧通过反向通道机制提供负反馈给所述视频编码器以触发所述参考帧的选择。

11.根据权利要求10所述的系统，其特征在于：

所述视频编码器

在所述视频解码器基于所述一个或多个丢失帧提供所述负反馈时在所述显示图像缓存中挑选一个在时间上较所述一个或多个丢失帧更早被编码的参考帧；

将所述参考帧发送至所述视频解码器。

12.根据权利要求11所述的系统，其特征在于：

13.一个系统，包括：

一个视频编码器，在其运行时，其

将视频流的复数图像帧编码并组织为分层结构中的复数时间层；

在与所述视频编码器相关的显示图像缓存中记录所述视频流的一个或多个已编码的参考帧；

通过网络发送所述视频流的图像帧；

一个视频解码器，在其运行时，其

在所述视频流的解码过程中使用1)解码在所述分层结构中较所述一个或多个丢失帧的时间层更低的时间层的图像帧和2)使用已编码的参考帧中的一个作为所述视频流的继续解码的重新开始点的结合恢复所述视频流的图像帧中的一个或多个丢失帧，而不需要通过所述网络发送额外的帧。

14.根据权利要求14所述的系统，其特征在于：

15.根据权利要求14所述的系统，其特征在于：

16.根据权利要求14所述的系统，其特征在于：

为了继续解码所述视频编码器以循环方式选择所述参考帧。

17.根据权利要求14所述的系统，其特征在于：

18.根据权利要求14所述的系统，其特征在于：

19.一种方法，其包括：

通过网络发送所述视频流的图像帧；

20.根据权利要求19所述的方法，其特征在于：其还包括：

21.根据权利要求19中所述的方法，其特征在于：其还包括：

22.根据权利要求21所述的方法，其特征在于：其还包括：

23.根据权利要求21所述的方法，其特征在于：其还包括：

24.根据权利要求19中所述的方法，其特征在于：其还包括：

在显示图像缓存中记录所述视频流的一个或多个参考帧，其中每个参考帧已经被所述视频编码器编码，并能被所述视频解码器用作具有一个或多个丢失帧的视频流的继续解码的重新开始点。

25.根据权利要求24中所述的方法，其特征在于：其还包括：

26.根据权利要求24所述的方法，其特征在于：其还包括：

基于所述一个或多个丢失帧通过反向通道机制提供负反馈给所述视频编码器以触发所述参考帧的选择。

27.根据权利要求26所述的方法，其特征在于：其还包括：

将所述参考帧发送至所述视频解码器。

28.根据权利要求27所述的方法，其特征在于：其还包括：

使用收到的参考图像帧预测下一图像帧。

29.一种方法，其包括：

在显示图像缓存中记录所述视频流的一个或多个已编码的参考帧；

通过网络发送所述视频流的图像帧；

30.根据权利要求29所述的方法，其特征在于：其还包括：

在所述显示图像缓存中记录了多个已编码的参考帧。

31.根据权利要求29述的方法，其特征在于：

32.根据权利要求29所述的方法，其特征在于：

为了继续解码以循环方式选择所述参考帧。

33.根据权利要求29所述的方法，其特征在于：

选择所述视频解码器指示的丢失帧紧前的参考帧。

34.根据权利要求29所述的方法，其特征在于：