用于具有可缩放视频编码服务和多播的多点会议的系统和方法.pdf

在具有多播能力且其中视听信号被可缩放编码的多端点视频会议系统中设置多播可缩放视频通信服务器(MSVCS)。MSVCS附加地具有到端点的单播链路。MSVCS高速缓存通过多播通信信道接收自端点的视听信号数据，并通过或者单播或者多播通信信道向请求被高速缓存的数据的端点重传数据。

1.  一种多端点视频会议系统，其中视听信号被可缩放地编码成包括基层和一个或多个增强层的数层，所述会议系统包括：
多个端点，各自可接收和/或传送可缩放视听信号；
多播可缩放视频通信服务器(MSVCS)，通过对应的单播通信信道链接至所述端点的每一个；
通信网络，提供链接所述端点和所述MSVCS的多条多播通信信道，
其中所述端点被配置成使用所述多条多播通信信道向其它端点和所述MSVCS传送其各自的视听信号层，并且其中所述MSVCS被配置成高速缓存通过所述多条多播通信信道接收自所述多个端点的视听信号数据，并通过单播通信信道向通过其单播通信信道请求所述高速缓存的视听信号数据的端点重传所述数据。

2.  如权利要求1所述的系统，其特征在于，端点通过加入用于另一端点的传输的特定多播通信信道组来针对接收自所述另一端点的视听信号数据的个性化布局执行率匹配和分辨率选择。

3.  如权利要求1所述的系统，其特征在于，所述由端点使用的多播通信信道的至少之一提供高可靠性传输，并且其中由所述端点传送的所述视听信号数据的至少基层通过所述提供高可靠性传输的多播通信信道来传送。

4.  如权利要求1所述的系统，其特征在于，还包括多个链接的MSVCS、SVCS和合成SVCS。

5.  如权利要求1所述的系统，其特征在于，所述MSVCS还被配置成执行多播路由器的功能。

6.  如权利要求1所述的系统，其特征在于，还包括仅通过单播通信信道链接到所述MSVCS且不具有对任何多播通信信道的访问的至少一个端点，其中所述MSVCS还被配置成操作为用于从多播启用端点向仅通过单播通信信道链接的所述至少一个端点传送数据的SVCS或合成SVCS，以及使用对应多播通信信道向所述多播启用端点逆向地传送接收自该端点的视听数据。

7.  如权利要求1所述的系统，其特征在于，所述MSVCS还被配置成通过首先向所述端点的每一个指派一个多播通信信道组地址并通过其对应的单播通信信道向每个端点传送所有所述指派以使得所述端点可加入所有被指派的多播通信信道组地址且每个端点可向指派给其的所述多播通信信道组地址传送测试分组，并且在一时段之后向所述MSVCS报告它们已从其接收到测试分组的其它端点或多播通信信道组地址的列表来标识任何多播通信信道对于所述端点或在所述端点之间是否可用。

8.  一种多端点视频会议系统，其中视听信号被可缩放地编码成包括基层和一个或多个增强层的数层，所述会议系统包括：
多个端点，各自可接收和传送可缩放视听信号；
多播可缩放视频通信服务器(MSVCS)，通过一条或多条对应的单播通信信道链接至所述端点的每一个；
通信网络，提供将所述MSVCS链接到所述端点的多条多播通信信道，
其中所述端点被配置成使用其对应的单播通信信道向所述MSVCS传送其各自的视听信号层数据，并且其中所述MSVCS被配置成通过所述多条多播通信信道向所述端点重传收到的视听信号层数据。

9.  如权利要求8所述的系统，其特征在于，端点通过加入用于所述MSVCS的传输的特定多播通信信道组来针对接收自其它端点的数据的个性化布局执行率匹配和分辨率选择。

10.  如权利要求8所述的系统，其特征在于，所述MSVCS还被配置成高速缓存接收自所述多个端点的视听信号数据，并通过单播通信信道向通过其对应的单播通信信道请求所述高速缓存的视听信号数据的端点重传所述数据。

11.  如权利要求8所述的系统，其特征在于，所述将端点链接到MSVCS的单播通信信道的至少之一提供高可靠性传输，并且其中由所述端点传送的所述视听信号数据的至少基层通过所述提供高可靠性传输的单播通信信道来传送。

12.  如权利要求8所述的系统，其特征在于，所述MSVCS被配置成在创建转发给接收端点的输出视频信号之前选择性地消去或修改接收自传送端点的输入视频信号中与高于所述基空间或质量层的层相对应的部分，并且在所述输出视频信号中显式地编码或信号通知使用低空间或质量层数据。

13.  如权利要求8所述的系统，其特征在于，还包括多个链接的MSVCS、SVCS和合成SVCS。

14.  如权利要求8所述的系统，其特征在于，所述MSVCS还被配置成执行多播路由器的功能。

15.  如权利要求8所述的系统，其特征在于，还包括仅通过单播通信信道链接到所述MSVCS且不具有对任何多播通信信道的访问的至少一个端点，其中所述MSVCS还被配置成操作为用于从多播启用端点向仅通过单播通信信道链接的所述至少一个端点传送数据的SVCS或合成SVCS，以及使用对应的多播通信信道向所述多播启用端点传送接收自该端点的视听数据。

16.  如权利要求8所述的系统，其特征在于，所述MSVCS还被配置成通过选择多播通信信道组地址并通过所有所述端点的对应单播通信信道将其传送给所有所述端点以使得所述端点可加入所选择的多播通信信道组地址，并且在一时段之后向所述MSVCS报告它们是否已接收到由所述MSVCS向所选择的多播通信信道组地址传送的测试分组来标识任何多播通信信道是否可为所述端点所用。

17.  一种用于操作多端点视频会议系统的方法，其中视听信号被可缩放地编码成包括基层和一个或多个增强层的数层，所述会议系统包括：
多个端点，各自可接收和/或传送可缩放视听信号；
多播可缩放视频通信服务器(MSVCS)，通过对应的单播通信信道链接至所述端点的每一个；
通信网络，提供链接所述端点和所述MSVCS的多条多播通信信道，
所述方法，包括：
由所述端点使用所述多条多播通信信道向其它端点和所述MSVCS传送其各自视听信号层；
在所述MSVCS处，高速缓存通过所述多条多播通信信道接收自所述多个端点的视听信号数据；
以及通过单播通信信道向通过其单播通信信道请求所述高速缓存的视听信号数据的端点重传高速缓存的数据。

18.  如权利要求17所述的方法，其特征在于，还包括
在端点处通过加入用于另一端点的传输的特定多播通信信道组来针对接收自所述另一端点的视听信号数据的个性化布局执行率匹配和分辨率选择。

19.  如权利要求17所述的方法，其特征在于，所述由端点使用的多播通信信道的至少之一提供高可靠性传输，所述方法还包括通过所述提供高可靠性传输的多播通信信道来传送所述端点的所述视听信号数据的至少所述基层。

20.  如权利要求17所述的方法，其特征在于，还包括包含多个链接的MSVCS、SVCS和合成SVCS。

21.  如权利要求17所述的方法，其特征在于，还包括使用所述MSVCS来执行多播路由器的功能。

22.  如权利要求17所述的方法，其特征在于，至少一个端点仅通过单播通信信道链接到所述MSVCS且不具有对任何多播通信信道的访问，所述方法还包括：
操作所述MSVCS作为用于从多播启用端点向仅通过单播通信信道链接的所述至少一个端点传送数据的所述SVCS或合成SVCS；以及
使用对应的多播通信信道向所述多播启用端点逆向地传送接收自该端点的视听数据。

23.  如权利要求17所述的方法，其特征在于，还包括：
通过首先向所述端点的每一个指派一个多播通信信道组地址并通过其对应单播通信信道向每个端点传送所有所述指派以使得所述端点可加入所有被指派的多播通信信道组地址且每个端点可向指派给其的所述多播通信信道组地址传送测试分组，并且在一时段之后向所述MSVCS报告它们已从其接收到测试分组的其它端点或多播通信信道组地址的列表来使用所述MSVCS标识任何多播通信信道对于所述端点或在所述端点之间是否可用。

24.  一种用于操作多端点视频会议系统的方法，其中视听信号被可缩放地编码成包括基层和一个或多个增强层的数层，所述会议系统包括：
多个端点，各自可接收和传送可缩放视听信号；
多播可缩放视频通信服务器(MSVCS)，通过一条或多条对应的单播通信信道链接至所述端点的每一个；
通信网络，提供将所述MSVCS链接到所述端点的多条多播通信信道，
所述方法，包括：
在所述端点处，使用其对应单播通信信道向所述MSVCS传送其各自的视听信号层数据；以及
在所述MSVCS处，通过所述多条多播通信信道向所述端点重传收到的视听信号层数据。

25.  如权利要求24所述的方法，其特征在于，端点通过加入用于所述MSVCS的传输的特定多播通信信道组来针对接收自其它端点的数据的个性化布局执行率匹配和分辨率选择。

26.  如权利要求24所述的方法，其特征在于，还包括：
在所述MSVCS处，
高速缓存接收自所述多个端点的视听信号数据；以及
通过单播通信信道向通过其对应单播通信信道请求所述高速缓存的视听信号数据的端点重传所述数据。

27.  如权利要求24所述的方法，其特征在于，所述将端点链接到所述MSVCS的单播通信信道的至少之一提供高可靠性传输，所述方法还包括通过所述提供高可靠性传输的单播通信信道来传送来自所述端点的所述视听信号数据的至少所述基层。

28.  如权利要求24所述的方法，其特征在于，还包括：在创建转发给接收端点的输出视频信号之前使用所述MSVCS来选择性地消去或修改接收自传送端点的输入视频信号中与高于所述基空间或质量层的层相对应的部分；以及
在所述输出视频信号中显式地编码或信号通知使用低空间或质量层数据。

29.  如权利要求24所述的方法，其特征在于，还包括包含多个链接的MSVCS、SVCS和合成SVCS。

30.  如权利要求24所述的方法，其特征在于，还包括使用所述MSVCS来执行多播路由器的功能。

31.  如权利要求24所述的方法，其特征在于，至少一个端点仅通过单播通信信道链接到所述MSVCS且不具有对任何多播通信信道的访问，所述方法还包括将所述MSVCS操作为用于从多播启用端点向仅通过单播通信信道链接的所述至少一个端点传送数据的SVCS或合成SVCS，以及使用对应多播通信信道向所述多播启用端点逆向地传送接收自该端点的视听数据。

32.  如权利要求24所述的方法，其特征在于，还包括通过选择多播通信信道组地址并通过所有所述端点的对应单播通信信道将其传送给所有所述端点以使得所述端点可加入所选择的多播通信信道组地址，并且在一时段之后向所述MSVCS报告它们是否已接收到由所述MSVCS向所选择的多播通信信道组地址传送的测试分组来使用所述MSVCS标识任何多播通信信道是否可为所述端点所用。

33.  一种包括用于执行方法权利要求17-32中的至少一项所述的步骤的指令集的计算机可读介质。

用于具有可缩放视频编码服务和多播的多点会议的系统和方法
说明书
相关申请的交叉引用
本申请要求2006年9月29日提交的美国临时专利申请S/N.60/827,469的权益。此外，本申请涉及国际专利申请No.PCT/US06/28365、PCT/US06/028366、PCT/US06/061815、PCT/US06/62569、PCT/US07/062357、PCT/US07/65554、PCT/US07/065003、PCT/US06/028367和PCT/US07/63335。共同转让的所有前述申请通过引用全部结合于此。
发明领域
本发明涉及多媒体数据通信系统。具体而言，本发明涉及通过将网络支持的多播和可缩放视频会议服务器一同使用来实现的多点视频会议功能。
发明背景
在多点视频会议中，期望使得由每个参与方生成的压缩视频数据可供希望接收其的每个其它参与方所用。在单播网络中，这要求由每个端点源或者由多点控制单元(MCU)对若干参与方/端点重复相同数据的传输。MCU接收由所有参与方/端点生成的数据并将数据——通常作为混合——发送给希望接收其的其它参与方/端点。显然，视频会议在单播网络系统上的带宽要求与会议参与方的数量成比例的增长。
当支持多播的网络可用于视频会议时，每个端点可仅将其视频数据一次发送到多播组中。希望接收数据的其它端点可加入多播组。网络可使用良好建立的技术(例如，如RFC 1075中所描述的DVMRP协议)建立最优分发树以向多播组的成员传输多播视频数据。
在接收机驱动分层多播技术(参见，例如，接收机驱动分层多播，StevenMcCanne，Van Jacobson，Martin Vetterli，ACM SIGCOMM计算机通信评论，第26卷，第4期，第117-130页，1996年10月，ISBN：0-89791-790-1)中，无需MCU，且视频数据是使用分层或可缩放编码技术来编码的，其中接收到每个附加层提高收到视频的质量。每个层在随后由每个端点发送到单独的多播组，从而允许每个接收机通过选择其加入的具体多播组选择其从其它参与方接收的带宽和接收质量。
尽管使用多播技术会导致对多点会议高效使用网络带宽，但是仅依赖于网络支持的多播——即没有专用MCU——的会议系统架构具有若干缺点：
1.网络支持的多播在全球因特网上不可用。因此，单纯基于多播的解决方案不能用于全球多点会议。
2.当多播组在彼此并非多播连接的不同网络上局部地管理时，必须在这些多播组之间建立映射。
3.两个或多个同时会议的多播组地址管理必须联合执行以消除潜在的地址冲突。
4.当接收端点错失分组数据时，从源向整组参与方/端点重复多播该错失数据效率低下，因为其它成员端点将接收冗余信息。
5.当新参与方加入多播组时，压缩视频对于新参与方而言不可解码，因为预测编码可能被用于压缩视频。
因此，为了部分或完全支持多播的网络上的高效多点视频会议，现在对知晓新多播和可缩放编码的MCU或服务器的设计作出考虑。
发明内容
本发明提供了用于执行使用可缩放数字视频编码以及底层通信网络的多播传输能力的多点视频会议的系统和方法。可缩放性和多播的组合协同地操作以克服当前视频会议系统的若干限制。
提供了知晓新多播和可缩放编码的MCU或服务器(在下文中为“知晓多播的可缩放视频编码服务器(MSVCS)”)的设计。
本本发明的方法可包括局部化单播传输。本发明的方法利用多播传输以在网络中有效使用带宽，并且同时利用对局部化单播传输的使用来使与诸如差错恢复等辅助操作相关联的带宽开销最小化。
根据以下对优选实施例的详细描述和附图，本发明的其它特征、本质和各种优点将更加显而易见，附图中：
图1a-1d是根据本发明的原理将SVCS架构与多播相组合的示例性系统配置的示意图解；
图2是根据本发明的原理的多播启用企业网上的示例性MSVCS操作的示意图解；
图3是根据本发明的原理的具有多个位置的多播启用企业网上的示例性MSVCS操作的示意图解；
图4是根据本发明的原理的具有本地多播的多站点企业网上的示例性MSVCS操作的示意图解；
图5是根据本发明的原理的运营商管理的多播网络上的示例性MSVCS操作的示意图解；
图6是根据本发明的原理的具有单播企业网的多播主干上的示例性MSVCS操作的示意图解；
图7是示例性多播连通性发现过程的示意图解；以及
图8是根据本发明原理的示例性连通性表。
在所有附图中，除非另外指明，相同的附图标记和字符用于指示所示实施例的类似特征、元素、组件或部分。此外，现在将参照附图，同时结合示例性实施例对本发明进行详细描述。
具体实施方式
本发明将网络支持的多播功能的使用与可缩放视频会议服务器(SVCS)的使用相组合，该可缩放视频会议服务器实现基于可缩放视频编码(SVC)技术的视频通信和多点会议。
SVC是其中视频流由提供在多个空间分辨率、帧速率、和画面质量(SNR)下对原始视频流的重构的多个比特流表示的编码过程。可选择各种重构以计及计算机环境中的不同CPU能力、显示大小、用户偏好和比特率。SVC比特流通常是以锥形方式来构造的，具有基层流以及一个或多个增强层流。对增强层本身的解码不会产生对原始视频流的忠实再现。相反，为了合需保真度水平(例如，在空间、时间、或质量维度上)的适当解码，对至少基层流以及可能地对其它增强层流的访问是必需的。ITU-T H.264国际标准附录G的修订版3提供了SVC的示例。此外，国际专利申请No.PCT/US06/28365描述了专为视频会议应用设计的可缩放视频编码技术。可缩放编码技术也可应用于音频(参见例如ITU-T G.729.1(G.729EV)标准)。在下文中，为了便于描述，统一代表使用SVC的给定视频源的比特流集合可以单数形式被称为‘SVC流’。应当理解，SVC流将包含至少一个比特流(基层)，并且可能包含一个或多个增强层比特流。还应当理解，虽然在本文中在视频传输的上下文中描述本发明，但是本发明的技术也可在使用可缩放音频编码的音频传输的上下文中应用。
在视频会议中，SVC流从每个端点被传送到SVCS。传输可通过两个或多个虚拟或物理信道。典型地，但是并非必需，这些不同信道可提供不同服务质量(QoS)水平。QoS支持可由底层通信网络提供，或者可使用众所周知的传输层技术(例如，FEC、ARQ)在应用层上实现。此外，国际专利应用No.PCT/US06/061815描述了可缩放视频的差错弹性传输的专用技术，藉由此最低时间水平的递送经由重传而没有增加系统的端对端延迟得到保证。
当提供不同QoS水平时，将SVC层指派至不同信道可通过使用其来输送基层以及在信道上有更多带宽可用的情况下还输送一些增强层来利用增加的可靠性水平。假定——但不丧失一般性——使用两个虚拟或物理信道，则高可靠信道(HRC)包括基画面质量信息(基层)而低可靠信道(LRC)包括对画面的增强(更好的质量、分辨率或帧速率)。信息被构造成LRC上的信息损耗将仅导致画面质量的非实质降级。当没有QoS从底层网络或应用层可用时，SVC层指派至不同信道可基于其它考虑来实现，如将在下文中描述的。在此类情形中，不要求将特定信道标识为HRC或LRC。在以下描述中，记号‘CN’——其中N＝0，1，2...，——指示SVC流通过其传送或携带的各种信道。编码视频信号的基层总是仅在信道C0上承载，然而，该信道C0也可承载其它层。当QoS可用时，还将理解，C0与HRC相对应。
在使用SVCS的网络上的视频会议中，一旦接收到来自每个参与方的端点的SVC流，SVCS就选择每个可缩放视频流的必需部分并将其传送给每个端点。SVCS可作为另一SVCS的端点，从而允许在可能的情况下级联服务器。可在国际专利申请No.PCT/US06/028366、PCT/US06/061815、PCT/US06/62569、PCT/US07/63335、PCT/US07/062357、PCT/US07/65554、PCT/US07/065003和PCT/US06/028367得到关于用于SVCS以及基于SVCS的通信系统的设计的方法和系统的详细信息。注意：在PCT/US06/028366中所描述的SVCS系统中，端点到SVCS、SVCS到SVCS和SVCS到端点的通信皆是使用点对点单播来实现的。
本发明包括可藉由其在改进的视频会议和其它视频通信系统的设计使用底层网络的多播能力的机制。本发明还包括用于将国际专利申请No.PCT/US07/63335、PCT/US07/062357、PCT/US07/65554、PCT/US07/065003和PCT/US06/028367中所描述的技术直接应用于多播启用系统中的机制。这些机制将在本文中逐一描述。
至于用于利用网络多播能力的机制，应当注意，从基于网际协议(IP)网络起就已考虑网络支持的多播。然而，其在因特网上的部署却是近年来的。多播IP地址在建立IP网络上多播应用中扮演重要角色。在Ipv4中，专用地址组(即，D类地址)被保留为多播IP地址。任何端点可向这些地址中的任一个发送分组。希望接收这些分组的其它端点必须向其(多播启用)路由器显式地指示它们希望接收发往此特定多播地址的分组(通常称为“加入”多播组)。类似地，端点还必须向其路由器指示何时希望停止接收发送到此特定多播地址的分组(通常称为“离开”多播组)。此类指示可借助诸如因特网组成员协议(IGMP)等标准协议来实现。
在IP网络中，没有负责分配将由端点在任何给定时间在因特网上使用的特定多播地址的中央控制。因此，这种分配任务必须由本地网络管理或由端点自身来处理。S.Pejhan、A.Eleftheriadis和D.Anastassiou在“Distributed MulticastAddress Management in the Global Internet(全球因特网中的分布式多播地址管理)”，(IEEE通讯选题杂志，关于全球因特网特刊，第13卷，第8号，1995年10月，第1445-1456页)中提供了对该问题的详细分析并且还描述了用于执行多播地址管理的可能协议。本发明还包括藉由其MSVCS可“发现”网络的多播结构，该MSVCS通过网络与其端点和其它MSVCS连接。在本文中参照图7描述这些技术。
目前，网络支持的多播部署可以见到两种方式：(1)专用企业多播解决方案；以及(2)由IP服务提供商管理的受管理企业多播解决方案。在任一解决方案中，企业具有经由或者单播或者多播运营商主干连接的多个站点。在专用企业解决方案中，多播地址分配是通过专用企业网络管理作出的。专用企业解决方案易受到跨若干专用(未受管理)企业多播网络的多播IP地址冲突的影响。相反，在受管理企业多播解决方案中，IP服务提供商管理多播地址块，并且可提供对跨多个企业网络预订的多播IP地址空间的唯一划分，由此避免多播IP地址冲突的可能性。
本文中参照图1-7描述本发明的机制。图1示出了MSVCS在具有完全或部分多播支持的内联网的上下文中的操作。其它附图示出了扩展至涵盖与专用或受管理企业解决方案相关联的更复杂的情形。假定MSVCS具有一多播地址集可供其访问(或者通过管理指派、与多播地址管理实体的交互或者发现)。
图1(a)示出了其中两个或多个端点(例如，端点E1-E3)以星型配置被连接到SVCS 102的简单SVCS系统100a。(参见例如PCT/US06/28365和PCT/US06/028366)。所有端点E1-E3向SVCS 102传送其视频和音频数据，该SVCS 102进而从每个发送方选择恰当信息并将其转发到预期接收方。在此配置中，SVCS上的比特率负载是较重的。在N个参与方各自传送B千位/秒的情况下，总传入率是N·B千位/秒。此外，假定每个参与方从所有其它参与方接收整个流，则传出率为N(N-1)B千位/秒(即，参与方的数目N的二次函数)。
图1(b)示出了MSVCS系统100b，其类似于SVCS系统100a，区别在于SVCS 102由知晓多播的可缩放视频编码服务器(MSVCS)104替代。在系统100b中，端点E1-E3直接使用多播与彼此通信。如附图中所示，系统100b可被配置成使得MSVCS 104也可任选地通过监听路径LP接收端点的传输(在其多播地址上‘监听’)，如下所描述的，这对于局部化差错恢复具有显著益处。在图1(b)中所示的系统100b的配置中，视频和音频数据的主流量不通过MSVCS 104，并且结果服务器上的比特率要求得以最小化。忽略监听路径LP，则没有视频或音频流量在MSVCS 104上。如果虑及监听路径LP上的流量，则在接收方向上服务器上的负载仅为N·B千位/秒。没有传出数据通信量(除如下描述的情况)。因此，消除传出带宽的二次(关于参与方的数目)依存性。
在其中在端点之间使用多播的系统100b的操作中，每个端点向具体与之(即，该端点)相关联的多播地址集传送信息。MSVCS 104通过与每个端点建立的单播控制路径CP通知每个端点使用哪些多播地址(参见图1(b))。这些相同的地址被传达给所有其它端点，以使得在接收参与方/端点期望来自特定传送端点的接收的情况下，接收端点可预订或加入(在IGMP术语中)与传送端点的地址相关联的多播组。为了将特定SVC层添加到其传入视频流，接收端点简单地加入传送端点的相关联多播组。相反地，接收端点离开相关联多播组以从其传入视频流中丢弃该特定SVC层。
配置系统100b以使得所有端点E1-E3向单个地址集合(即，单个多播组)传送是可能的。这种配置的局限性在于，现在每个接收端点将必须接收来自所有其它参与方的相应视频(或音频)层数据或者都不接收。
或者传送端点自身或者MSVCS 104可决定在端点的传输中各个SVC层应如何指派给个体多播组。例如，如果MSVCS 104知道每个端点可用的最小比特率，则其可指令端点在其C0信道中包括足够数量的时间或质量层以使得该信道被充分利用但不过载。相反，MSVCS 104可指令端点创建附加低质量层(例如，具有低帧率)，以使得至少基层可通过C0传送给所有端点。
注意：在一些SVC系统实现中，实现介于显式编码在视频比特流中的层之间的质量点也是可能的。(参见例如国际专利申请No.PCT/US06/061815和PCT/US07/63335)。通过接收增强层的子集并执行恰当隐藏，获得落在单独基层或具有完全增强层的基层的质量之间的‘分数’质量水平(从PSNR点的观点来看)是可能的。国际专利申请No.PCT/US07/63335描述了L0、L1、L2和S0帧的传输的示例，其带有对错失的S1和S0帧的基于隐藏的恢复。在配置成利用此类基于隐藏的恢复的系统102b中，MSVCS 104可指令端点(例如，通过其单播控制信道CP)创建附加“分数”或中间质量多播组，其(该端点)将仅向该多播组传送增强层的恰当局部部分。希望接收此中间质量的端点可预订基层信道及此局部增强多播组。在此类系统100b中，在完全增强层在其本身的多播组中被同时传送的情况下，将有比特率开销，但是此类开销很小。可通过仅向单独多播组传送完全增强层与用于达成分数质量的子集之间的差异替代传送完全增强层来消除此比特率开销。
多播传输系统的已知缺陷在于，如果信道上的特定分组的传输中发生差错，则不得不再次从源向所有参与方/端点传送潜在纠错或补偿重传，而且不仅是向未接收到该特定分组的端点进行传送。虽然源端点使用到体验到分组丢失的特定接收端点的单播连接重传错失的分组是可能的，但是实际上源与接收端点之间的距离(在网络方面)会是显著的。结果，重传分组对于显示而言将过迟到达。本发明包括用于克服此缺陷的差错恢复服务的技术。该技术涉及将重传责任委托给MSVCS而非委托给发送端点。例如，MSVCS 104可被配置成监听所有端点的传输，并且高速缓存分组的全部或一部分(例如，国际专利申请No.PCT/US06/061815术语中的‘R’分组)。当接收端点检测到差错时，可在随后通过该接收端点到MSVCS 104的单播链路指令该MSVCS重传错失/误差分组。MSVCS随后通过单播链路传送分组。MSVCS 104通常不传送任何传出视频或音频数据话务，而是替代地仅在差错发生时传送。此外，该技术使端点从执行高速缓存和重传的任务中摆脱出来。
此针对差错恢复服务的技术具有良好的差错局部化属性，因为MSVCS104通常比传送端点更靠近(在网络方面)体验到差错的接收端点。此外，此技术具有比常规端点重传技术低的带宽需求。作为示例性示例，假定系统100b中的每个端点具有分组丢失概率p(0<p<1)。则从MSVCS 104提供差错恢复的平均传出率将为N·B/(1-p)千位/秒，这是Bernoulli随机过程的期望值。即使对于高至20％的p值，来自MSVCS 104的平均传出比特率将仅为传入比特率的25％。相比之下，在传统星型配置(例如，具有SVCS)中，如果差错存在，则仍必须将此相同的传出比特率添加到总量上。
用于实现此差错恢复方案的变体的系统100b的替换性配置在图1(c)中被示为系统100c。在系统100c中，来自端点的传输被单播至MSVCS 104，随后从MSVCS 104向端点进行多播传输。在此配置中，到MSVCS 104的总体传入比特率与以上所描述的系统100b的相等。传出比特率与传入比特率相等(忽略可能的重传)，并且在参与方的数目大于2的情况下仍比星型配置(图1a)的小得多。
系统100c中MSVCS 104的操作类似于系统100a中SVCS 102的操作。在系统100c中，MSVCS 104自身建立多播组集合，传入视频(和音频)的各个SVC层将通过该多播组集合被传送。MSVCS 104在两种系统中操作的相似性在虑及作为‘聚集’端点加入特定多播组的每组端点等效于传统SVCS系统(例如，系统100a)的单个端点时变得显而易见。与在系统100b中相类似，系统100c中的MSVCS 104可通过确保C0组满足所有接收方的最小比特率要求来执行率匹配。虽然SVCS(例如，SVCS 102)对每个个体端点执行率匹配，但是MSVCS对‘聚集’端点执行率匹配。系统100c配置的附加益处在于，MSVCS 104可更容易地执行统计复用，因为在将所有流传输至端点之前这些流在MSVCS被组合。此外，类似于系统100b，可针对改进率匹配和率控制能力在系统100c中建立‘分数质量’多播组，其具有类似的低带宽开销，如以下所描述的。
例如，假定在系统100c中端点E1向端点E3进行传送。端点E1包括在来自MSVCS 104的每个多播信道中的层的数目将取决于E1-E3可用的比特率而改变。换言之，端点E1-E3变成‘聚集用户’，MSVCS 104将以与SVCS原本对待个体端点相同的方式对待该‘聚集用户’。如在系统100b中那样，MSVCS104可高速缓存传入分组，并且在接收端点检测到差错的情况下使它们可用于重传。这些重传可在MSVCS 104与端点之间的单播信道上发生，以使得与重传相关联的带宽开销被完全局部化。此外，用于误差弹性和率控制的更复杂的基于SVCS的技术可如同将其应用于系统100b中那样应用于系统100c中。
通常，在国际专利申请PCT/US06/061815、PCT/US07/63335、PCT/US07/65554和PCT/US07/062357中所描述的所有误差弹性、合成、稀疏化和其它技术可直接应用于MSVCS的操作中。仅有的区别在于，MSVCS情形要求考虑数据传输应当在多播信道还是单播信道上。有利地，解决特定端点中的丢失的差错恢复措施应当被单播地传送。在合成SVCS(参见，例如PCT/US06/62569)中，合成流的传输可以是多播的。类似地，在执行稀疏化的SVCS(PCT/US07/062357)中，对稀疏化流的多播或单播的抉择是基于所有接收端点还是仅一个端点具有用于接收的恰当信道(高质量，且没有或极少的分组丢失)来决定的。在任一情形中，在单独的多播组中，非稀疏化流可同时与稀疏化流并排存在。当在SVCS上使用转码(参见例如PCT/US07/65554)时，通常这样做以容纳非SVC端点(例如，H.264AVC端点)，因此经转码的流的单播传输将是适当的。如果两个或多个传统端点存在于系统中，且正接收特定参与方/端点传输，则可针对此类传统端点在MSVCS处独自建立单独多播组。在此类系统中，在此将仅应用服务器驱动多播配置，因为传统端点——根据定义——并非是知晓多播的。
注意，图1a-1c中所示的系统服务器和端点配置可以任何合适方式被融合或组合。图1(d)示出了示例性系统100d，其中端点E1如在系统100a中那样使用单播与中的MSVCS 104通信，端点E2和E3如在系统100c中那样单播地传送并多播地从MSVCS 104接收，而端点E4-E6如在系统100b中那样全部处在其中MSVCS进行监听的多播云(multicast cloud)中。在系统100d中，为了桥接各种传输类型或端点，MSVCS 104还向E4-E5多播云传送源自E1和E2-E3的信号。在所有其它方面中，与MSVCS 104协作的每个端点子集(E1、E2-E3、E4-E5)的操作与如上所述的系统100a-c的相同或相类似。在下文中，术语“单播”、“端点驱动多播”和“服务器驱动多播”分别可用于指图1a-1c中的系统类型(例如，系统100a-100c)。
图2-7示出了具有更复杂MSVCS配置的系统，可能在其中可采用SVCS(知晓多播和非知晓多播)的企业环境中碰到这些MSVCS配置。例如，图2示出了用于专用或受管理企业多播解决方案220的配置200，其中位于企业内联网中的MSVCS 210被配置成遵照以下服务和特征：
a)MSVCS 210将以服务器驱动或端点驱动多播配置的任一种(或其组合)使用多播地址集。为了实现它，MSVCS 210必须能够与内联网的现有IP多播组地址管理系统协作，以便正确保留用于会议会话的多播地址。地址管理系统与MSVCS 210之间必需的通信是借助站点专用协议来执行的。作为替换，MSVCS 210可自身处置多播地址分配。
b)MSVCS 210向所选的多播地址发送其接收自企业网络端点外部、SVCS或其它MSVCS(例如，SVCS 230)的视频数据，以经由多播在内部分发数据。无论始发MSVCS(例如，SVCS 230)是执行服务器驱动还是端点驱动多播，此操作皆是相同的。在后一情形中，服务器MSVCS 210有效地桥接两个网络。
c.MSVCS 210向外部端点、SVCS、或MSVCS(例如，SVCS 230)发送接收自内联网客户端的视频数据。
d.多播启用网络上的MSVCS 210可在通过将丢失分组重发到端点来修复它们或提供内部帧以启动新近加入的参与方上充当代理。(参见例如如上所描述的由MSVCS提供的差错恢复服务)。
图3示出了用于具有经由虚拟专用网(VPN)互联的多个位置或站点320的专用企业解决方案的配置300，并且其中所选多播地址以跨越提供商主干的隧穿方式在多个站点上蔓延。在配置300中，多点会议的实现仅要求在各位置之一处能够使用多播地址发送和接收的单个MSVCS 310。
图4和5分别示出了用于具有并非经由虚拟专用网(VPN)互联而是替换地通过运营商的多播支持主干网连接的多个位置的受管理企业网解决方案的配置400和500。在此类情形中，将有由运营商分配给每个受管理企业客户的唯一多播地址。多播地址被保留给多点视频会议和企业的多个站点内的多播。在此类情形中，多点会议的实现将要求如图4中所示的位于每个内联网站点处的MSVCS 410或如图5中所示位于运营商的主干网处的MSVCS 510。
在配置400中，不同位置处的两个MSVCS 410使用单播彼此进行通信。两个MSVCS 410可交换配置信息，以使得它们中的每一个可关于率控制、统计复用等作出恰当决定。有效地，当将数据从多播转换成单播时，MSVCS 410充当远程网络的代理并呈现所有被组合的源。MSVCS 410还通过计及链路约束条件在聚集源上应用所有智能率控制/成形。MSVCS 410也可以与标准SVCS程序中看到的相同的方式在该链路上执行差错恢复功能。
在配置500中，MSVCS 510可协调跨许多受管理企业520建立的多点视频会议会话，因为每个多播会议会话在受管理企业站点上使用由运营商指派的唯一的多播地址集。如图5中所示，如果多点视频会议会话是跨若干受管理企业客户520建立的，则运营商可将单独的多播地址块用于企业间会议，在其情形中，具有由运营商主宿的MSVCS 510会是有益的。
最后，图6示出了用于其中多播可在主干网620中可用但是所有企业网络630没有多播支持可用的环境的配置600。在此配置中，设置在运营商网络620中的MSVCS 610可使用多播与其它MSVCS 610通信。这样做时，各种MSVCS610可充当直接连接到它们的企业630 SVCS的代理。例如，MSVCS 610’可多播地传送其接收自SVCS 630’的信息。MSVCS 610’还将连接到其相关联SVCS630’的端点的要求通知对等MSVCS 610，以使得对等MSVCS 610可关于哪些层要传送以及送往哪些多播地址作出决定。
通常，MSVCS(或一个以上的MSVCS)应当以使得能够快速响应所有参与端点的重传请求的方式定位在网络内。虽然不保证两个端点之间的单播和多播路由具有显著共同的组件，但是对于具有足够多播路由器密度的适度的良好连接的网络，假定计算出的多播路由将横贯在端点之间提供良好平衡(网络距离)的网络点是合理的。因此，在MSVCS是共宿(即，在相同装备上操作)、共处一地、或非常靠近(在网络方面)多播路由器的情况下，可能是有益的。此类布局的附加益处在于，通过多播通信信道从一个端点传播到另一个的分组不必从多播路由器上拷贝下来以通过并非沿着给定或其它多播通信信道路由的辅助路径到达监听MSVCS。
图2-6中所示的配置200-600假定MSVCS与现有IP多播地址管理系统协作。然而，存在这种情形：此类地址管理系统不存在或此类协作不可行或不实际。对于此类情形，本发明向MSVCS提供用于多播地址和连通性发现的机制。MSVCS可被配置成完全或部分发现(1)可用多播地址以及(2)多播拓扑(即，哪些客户端处于多播IP地址组中)。
在发现程序中，所配置的MSVCS选择一多播IP地址集并通过单播连接将它们发送到乐意参与到多点会议中的所有客户端。每个客户端还被指派为仅针对该集中多播地址的一个的发送方。随后，客户端将测试包发送到其被指派的多播地址，同时监听整个多播地址集上来自其它客户端的测试包。每个客户端在随后向MSVCS报告其接收记录，即，从其接收测试包的多播地址列表。此测试程序使得MSVCS能够生成多播连通图。测试程序可在会议会话建立时执行，从而允许MSVCS确定哪些客户端可彼此使用多播。
参照图7中所示的系统700可理解多播连通性发现程序的操作。系统700包括具有未知多播支持的网络720。例如，四个端点Ep1-Ep4可能希望参与到网络720上的多点会议中。最初，MSVCS 710不知晓这些端点Ep1-Ep4之间的多播连通性。为了启动发现程序，MSVCS 710向每个端点Ep1-Ep4发送其所选择的合适的多播地址集。对地址的选择可以是这种形式的：与MSVCS 710正在处理的其它会议没有重叠。MSVCS 710还指派单个端点作为每个地址的发送方。另外添加一个多播地址以允许MSVCS参与到发现过程中。因此，在此示例中，总的地址数目为5个地址(例如，“A”、“B”、“C”、“D”和“E”)。在不失一般性的情况下，可假定选择成第一端点Ep1作为第一多播地址A的发送方、第二端点Ep2作为B的发送方，依此类推，而第五地址E由MSVCS710使用。在接收到这些地址指派之后，所有端点和MSVCS 710开始向其相应被指派的地址A、B、C、D或E发送预定测试包。同时，所有端点和MSVCS710监听其它四个地址(即，他们加入并成为与其它四个地址相对应的四个多播组的成员)。在发现程序下发送的测试分组可承载预定签名，以使得可将它们与可能由其它机器或端点发送到这些多播地址的其它分组区分开。在可被适当地选择成计及参与到会话中的端点之间的时间延迟的预定时间段之后，每个端点Ep1-Ep4发送它从其接收到测试分组的地址列表。使用此数据，MSVCS710可例如制备参考表(例如，图8的表800)。
在表800中，单元格中的标记“x”指示其编号被显示在对应行标题中并报告其已在列标题上所示的多播地址处接收到测试分组的端点。通常，可能预期多播接收是对称的(即，如果端点1侦听到端点2，则端点2应当也侦听到端点1)，且是传递性的(即，如果端点2侦听到端点1而端点3侦听到端点2，则端点3应当也侦听端点1)。然而，这些属性并非在所有情形中都得到保持，这取决于多播基础设施的实现。对于表800中给出的示例，MSVCS 810可报告端点1、2和4可使用双向多播来向彼此传送数据。
虽然已描述了被认为是本发明的优选实施例的那些，但是本领域技术人员应当认识到，可作出其它及进一步的改变和更改而不背离本发明的精神，并且旨在要求保护落在本发明的真实范围内的所有此类改变和更改。例如，本文所描述的MSVCS的功能也可全部都在SVC客户端中实现。在此情形中，可避免单独MSVCS的部署。
应当理解，根据本发明，本文所描述的技术可使用任何合适的硬件和软件的组合来实现。用于实现和操作前述率估计和控制技术的软件(即，指令)可被设置在计算机可读介质上，该介质可包括但不限于：固件、存储器、存储设备、微控制器、微处理器、集成电路、ASIC、可在线下载的介质、以及其它可用介质。