CN111656774B - 用于在群组视频呼叫中优化联播流的系统和方法 - Google Patents

Abstract

系统、方法和非暂时性计算机可读介质可以识别群组视频呼叫中的一组参与者，其中每个参与者与上行链路容量和下行链路容量相关联，并且该组参与者包括一组发送方参与者和一组订阅方参与者。对于一组发送方参与者中的第一发送方参与者，将由第一发送方参与者上传的一个或更多个视频流层是基于一组订阅方参与者中的一个或更多个订阅方参与者的下行链路容量来确定的。一个或更多个订阅方参与者中的每个订阅方参与者被分配来接收将由第一发送方参与者上传的一个或更多个视频流层中的一个视频流层。

Description

用于在群组视频呼叫中优化联播流的系统和方法

发明领域

本技术涉及数字通信领域。更具体地，本技术涉及用于在群组视频呼叫(groupvideo call)中优化联播流(simulcast stream)的技术。

背景

如今，人们经常将计算设备用于各种各样的目的。例如，用户可以使用他们的计算设备与其他用户通信。这种通信在社交网络系统中越来越受欢迎。诸如社交网络系统上的数字通信可能涉及各种类型的通信。某些类型的数字通信允许用户进行集中交流。例如，用户可以通过使用社交网络系统支持的消息传递系统或电子邮件系统来以一个或更多个特定用户作为目标。作为另一个示例，用户可以与其他用户进行音频通信或视频通信。

在许多情况下，视频通信可能是用户的首选，因为视频通信可以让用户最有效地传达信息，并模拟现实生活中的交流。在某些情况下，不同位置的两个参与者可以进行视频通信。还可以希望允许多个位置的一组用户使用视频通信来促进该组当中的通信。

概述

本公开的各种实施例可以包括被配置成识别群组视频呼叫中的一组参与者的系统、方法和非暂时性计算机可读介质，其中每个参与者与上行链路容量和下行链路容量相关联，并且该组参与者包括一组发送方参与者(sender participant)和一组订阅方参与者(subscriber participant)。对于一组发送方参与者中的第一发送方参与者，将由第一发送方参与者上传的一个或更多个视频流层(video stream layer)是基于一组订阅方参与者中的一个或更多个订阅方参与者的下行链路容量来确定的。一个或更多个订阅方参与者中的每个订阅方参与者被分配来接收将由第一发送方参与者上传的一个或更多个视频流层中的一个视频流层。

在一个实施例中，将由第一发送方参与者上传的一个或更多个视频流层是基于订阅了第一发送方参与者的订阅方参与者的下行链路容量来确定的。

在一个实施例中，每个订阅方参与者订阅至少一个发送方参与者。

在一个实施例中，将由第一发送方参与者上传的每个视频流层与比特率相关联。

在一个实施例中，基于订阅了第一发送方参与者的订阅方参与者的下行链路容量和与第一发送方参与者相关联的上行链路容量，为将由第一发送方参与者上传的每个视频流确定比特率。

在一个实施例中，基于上行链路容量对一组发送方参与者进行排名。

在一个实施例中，为一组发送方参与者中的第一发送方参与者确定将由第一发送方参与者上传的一个或更多个视频流层还包括，基于订阅了发送方参与者的订阅方参与者的下行链路容量，为一组发送方参与者的每个发送方参与者确定将由发送方参与者上传的一个或更多个视频流层。

在一个实施例中，为该组参与者中的每个发送方参与者确定将由发送方参与者上传的一个或更多个视频流层包括，按基于排名的顺序迭代地处理每个发送方参与者。

在一个实施例中，迭代地处理每个发送方参与者包括多次迭代，每次迭代与一组发送方参与者中的特定发送方参与者相关联，并且每次迭代包括对订阅了与该迭代相关联的特定发送方参与者的每个订阅方参与者进行迭代地处理。

在一个实施例中，对订阅了特定发送方参与者的每个订阅方参与者进行迭代地处理包括：为每个订阅方参与者确定是否创建将由特定发送方参与者上传的新层，或者将该订阅方参与者分配给与特定发送方参与者相关联的先前创建的层。

应当理解，从附图中和从下面的详细描述中，所公开的技术的许多其他特征、应用、实施例和/或变型将是明显的。本文描述的结构、系统、非暂时性计算机可读介质和方法的附加和/或替代实现可以被使用而不偏离所公开的技术的原理。

在涉及方法、系统和存储介质的所附权利要求中具体公开了根据本发明的实施例，其中，在一个权利要求类别(例如方法)中提到的任何特征也可以在另一个权利要求类别(例如系统或计算机程序产品)中被要求保护。在所附权利要求中的从属或往回引用仅为了形式原因而被选择。然而，也可以要求保护由对任何前面权利要求的有意往回引用(特别是多项引用)而产生的任何主题，使得权利要求及其特征的任何组合被公开并可被要求保护，而不考虑在所附权利要求中选择的从属性。可以被要求保护的主题不仅包括如在所附权利要求中阐述的特征的组合，而且还包括在权利要求中的特征的任何其他组合，其中，在权利要求中提到的每个特征可以与在权利要求中的任何其他特征或其他特征的组合相结合。此外，本文描述或描绘的实施例和特征中的任一个可以在单独的权利要求中和/或与本文描述或描绘的任何实施例或特征的任意组合或与所附权利要求的任何特征的任意组合来被要求保护。

附图简述

图1示出了根据本公开的实施例的包括群组视频呼叫模块的示例系统。

图2示出了根据本公开的实施例的与自动带宽分配相关联的示例伪代码。

图3示出了根据本公开的实施例的与自动下行链路容量保留相关联的示例伪代码。

图4A-图4Q示出了根据本公开的实施例的与群组视频呼叫联播优化相关联的示例场景。

图5示出了根据本公开的实施例的与群组视频呼叫联播优化相关联的示例方法。

图6示出了根据本公开实施例的可以在各种场景中利用的示例系统的网络图，该示例系统包括示例社交网络系统。

图7示出了根据本公开实施例的可以在各种场景中利用的计算机系统或计算设备的示例。

附图仅为了说明的目的描绘了所公开的技术的各种实施例，其中附图使用相似的参考数字来标识相似的元素。本领域中的技术人员将从下面的讨论中容易认识到，在附图中示出的结构和方法的替代实施例可以被采用而不偏离本文描述的所公开的技术的原理。

详细描述

优化群组视频呼叫中联播流的大小

如上所述，人们经常将计算设备用于各种各样的目的。例如，用户可以使用他们的计算设备与其他用户通信。这种通信在社交网络系统中越来越受欢迎。诸如社交网络系统上的数字通信可能涉及各种类型的通信。某些类型的数字通信允许用户进行集中交流。例如，用户可以通过使用社交网络系统支持的消息传递系统或电子邮件系统来以一个或更多个特定用户为目标。作为另一个示例，用户可以与其他用户进行音频通信或视频通信。

在许多情况下，视频通信可能是用户的首选，因为视频通信可以让用户最有效地传达信息并模拟现实生活中的交流。在某些情况下，不同位置的两个参与者可以进行视频通信。还可以希望允许多个位置的一组用户使用视频通信来促进该组当中的通信。

具体出现在计算机技术领域中的传统方法包括数字通信，其中多个用户参与群组视频呼叫。通常，来自群组视频呼叫中的一个或更多个参与者的视频流基本上实时地传输给其他参与者。群组视频呼叫中的参与者可以请求不同级别的视频质量。例如，参与者可以请求高质量流、标准质量流或低质量流。然而，参与者可能请求比他们的网络连接最适合提供的质量更高的视频流。例如，即使用户的网络连接并不最适合提供高质量视频流，用户也可能请求高质量视频流。在这种情况下，某些传统方法选择基于具有最低可用下行链路容量的参与者来对视频流比特率进行限制。例如，考虑一个群组视频呼叫中有四个参与者的示例场景。四个参与者中的三个参与者可以向第四参与者请求高质量视频流。然而，三个参与者中的第一参与者具有100kbps的下行链路容量，而第二参与者和第三参与者各自具有更大的下行链路容量5Mbps。在某些常规方法下，由第四参与者上传的高质量视频流的比特率和/或质量可以被限制为小于100kbps，以便适应具有100kbps下行链路容量的第一参与者。由于第一参与者的低下行链路容量，请求高质量视频流的所有三个参与者都接收受限的高质量视频流。这导致不期望的结果，即群组视频呼叫中的其他参与者可能不必要地被迫接收较低质量的视频流，即使他们能够接收较高质量的视频流，并且上传用户(uploading user)能够上传较高质量的视频流。这种方法甚至可能导致“高质量”流的质量低于“低质量”流的情况，这取决于哪个用户请求了哪个流。例如，在上述示例场景中，如果具有5Mbps下行链路容量的第三参与者已经请求了低质量视频流，则低质量视频流可能比高质量视频流具有更高的质量，因为第一参与者正在限制高质量视频流。

其他传统方法已经将每个上传参与者的上行链路容量划分为各种质量的视频流的预定比率。例如，可以划分参与者的上行链路容量，使得80％的上行链路容量用于高质量流，15％的上行链路容量被保留用于中等质量流，并且5％的上行链路容量被保留用于低质量流。然而，这种方法未能考虑参与群组视频呼叫的用户的特定特征。因此，这种方法不能基于参与群组视频呼叫的特定参与者群组来优化用户体验。

一种根植于计算机技术的改进方法克服了与计算机技术领域中特别出现的传统方法相关联的前述和其他缺点。通常，可以识别参与群组视频呼叫的一组参与者。例如，该组参与者可以由负责管理群组视频呼叫的中央服务器来识别。一组参与者中的每个参与者可以与上行链路容量和下行链路容量相关联。一个或更多个参与者可以被识别为将上传一个或更多个视频流以供群组视频呼叫中的其他参与者接收并查看的发送方参与者。一个或更多个参与者可以被识别为将接收并查看由另一个参与者上传的至少一个视频流的订阅方参与者。群组视频呼叫中的给定参与者可以仅是发送方参与者、仅是订阅方参与者或者是发送方参与者和订阅方参与者两者。一组参与者中的每个发送方参与者可以被指示上传不同质量(例如，比特率)的一个或更多个视频流层。发送方参与者要上传的视频流层的数量和与每个视频流层相关联的比特率可以基于发送方参与者的上行链路容量和群组视频呼叫中其他参与者的下行链路容量来被确定。该确定可以例如由中央服务器做出。例如，中央服务器可以指示第一参与者上传具有第一质量(例如，第一比特率)的第一视频流层和具有第二质量(例如，第二比特率)的第二视频流层。第一和第二视频流层以及第一和第二比特率可以基于第一参与者的上行链路容量和基于群组视频呼叫中其他参与者的下行链路容量来被确定。可以迭代地执行视频流层和比特率的确定，直到每个发送方参与者都被分配了将由该发送方参与者上传的一个或更多个视频流层。当迭代完成时，每个发送方参与者与他或她负责上传的一个或更多个视频流层相关联，并且每个订阅方参与者与订阅方参与者将接收的来自一个或更多个发送方参与者中的每个的一个视频流层相关联。在某些实施例中，群组视频呼叫中的每个参与者可以通信地连接到中央服务器。中央服务器可以被配置为从一个或更多个发送方参与者接收视频流层，并且基于一个或更多个订阅方参与者的订阅将视频流层发送给该一个或更多个订阅方参与者。下文提供了与所公开的技术相关的更多细节。

图1示出了根据本公开的实施例的包括群组视频呼叫模块102的示例系统100。群组视频呼叫模块102可以被配置成识别参与群组视频呼叫的一组参与者。该组参与者中的每个参与者可以与上行链路容量和下行链路容量相关联。一个或更多个参与者可以被识别为发送方参与者。发送方参与者是上传一个或更多个视频流以供群组视频呼叫中的其他参与者接收并查看的那些参与者。一个或更多个参与者可以被识别为订阅方参与者。订阅方参与者是那些接收并查看由另一个参与者上传的至少一个视频流的参与者。群组视频呼叫中的给定参与者可以仅是发送方参与者、仅是订阅方参与者或者是发送方参与者和订阅方参与者两者。订阅方参与者可以与一个或更多个订阅相关联。每个订阅可以与订阅方参与者和发送方参与者相关联，并且订阅可以指示订阅方参与者已经请求和/或将接收由发送方参与者上传的视频流(本文也称为“视频流层”)。每个订阅还可以与质量设置或质量指示符相关联，指示订阅方参与者所请求的视频流的质量。例如，订阅方参与者和发送方参与者之间的订阅可以指示订阅方参与者是向发送方参与者请求了高质量视频流层、标准质量视频流层还是低质量视频流层。

对于一组参与者中的每个发送方参与者，群组视频呼叫模块102可以基于发送方参与者的上行链路容量和群组视频呼叫中其他参与者(例如，订阅方参与者)的下行链路容量来确定要由该发送方参与者上传的一个或更多个视频流层。由特定发送方参与者上传的每个视频流层可以具有特定质量(例如，特定比特率)和/或与特定质量相关联。例如，对于一组参与者中的第一发送方参与者，群组视频呼叫模块102可以检查第一发送方参与者的上行链路容量和已经订阅了第一发送方参与者的每个订阅方参与者(例如，从第一发送方参与者接收视频流作为群组视频呼叫的一部分的每个订阅方参与者)的下行链路容量。基于这些因素，群组视频呼叫模块102可以指示第一发送方参与者(即，与第一发送方参与者相关联的计算设备)上传具有第一质量(例如，第一比特率)的第一视频流层、具有第二质量(例如，第二比特率)的第二视频流层，等等。在各种实施例中，当确定每个发送方参与者将上传多少流以及以什么比特率上传时，可以进行额外的考虑。这些额外的考虑可以包括，例如，发送方参与者的能力，诸如CPU速度、GPU处理速度、其他硬件性能度量或能力等。

群组视频呼叫模块102可以迭代地循环遍历群组视频呼叫中的每个发送方参与者，并确定将由每个发送方参与者上传的视频流层，直到已经为群组视频呼叫中的每个发送方参与者做出了这样的确定。在各种实施例中，当群组视频呼叫模块102的迭代处理完成时，每个发送方参与者与他或她负责上传的一个或更多个视频流层相关联。另外，当迭代处理完成时，每个订阅方参与者与来自订阅方参与者订阅的每个发送方参与者的一个视频流层相关联。例如，考虑一个示例场景，其中在一个群组视频呼叫中有三个参与者，每个参与者都是发送方参与者，并且每个参与者还订阅了每个其他参与者。可以指示每个参与者上传一个或更多个视频流层，每个视频流层具有特定的比特率。第一参与者可以被分配来接收来自第二参与者的特定视频流层和来自第三参与者的特定视频流层，第二参与者可以被分配来接收来自第一参与者的特定视频流层和来自第三参与者的特定视频流层，并且第三参与者可以被分配来接收来自第一参与者的特定视频流层和来自第二参与者的特定视频流层。可以基于订阅方参与者的下行链路容量和发送方参与者的上行链路容量来确定订阅方参与者到由发送方参与者上传的特定视频流层的分配。群组视频呼叫模块102可以被配置为从群组视频呼叫中的每个发送方参与者接收视频流层，并且基于特定订阅方参与者到特定视频流层的分配，将视频流层发送到群组视频呼叫中的订阅方参与者。在各种实施例中，群组视频呼叫模块102的一个或更多个功能可以在中央服务器中实现。群组视频呼叫的参与者可以连接到中央服务器，并且可以将视频流层上传到中央服务器，并且从中央服务器接收由其他参与者上传的视频流层。尽管本公开的各种实施例将参考群组视频呼叫来描述各种概念，但是应当理解，本公开可以应用于数据流(例如音频数据、视频数据、其他媒体等)的任何交换。

如图1的示例所示，群组视频呼叫模块102可以包括参与者信息模块104、带宽分配模块106和视频呼叫模块108。在一些情况下，示例系统100可以包括至少一个数据储存器110。在该附图以及本文的所有附图中示出的部件(例如，模块、元件等)仅是示例性的，并且其他实现可以包括附加的、更少的、集成的或不同的部件。为了不使相关细节模糊，一些部件可能没有被示出。在各种实施例中，结合群组视频呼叫模块102描述的一个或更多个功能可以以任何合适的组合来被实现。

在一些实施例中，群组视频呼叫模块102可以部分或全部被实现为软件、硬件或其任意组合。通常，本文讨论的模块可以与软件、硬件或其任意组合相关联。在一些实施方式中，模块的一个或更多个功能、任务和/或操作可以由软件例程、软件过程、硬件和/或其任意组合来执行或实施。在一些情况下，群组视频呼叫模块102可以部分或全部被实现为在一个或更多个计算设备或系统上(例如在服务器系统或客户端计算设备上)运行的软件。在一些情况下，群组视频呼叫模块102可以部分或全部在诸如图6的社交网络系统630的社交网络系统(或服务)内实现，或者被配置为与社交网络系统(或服务)结合操作或集成。类似地，在一些实例中，群组视频呼叫模块102可以部分或全部在客户端计算设备(例如，图6的用户设备610)内实现，或者被配置为与客户端计算设备结合操作或集成。例如，群组视频呼叫模块102可以被实现为运行在用户计算设备或客户端计算系统上的专用应用(例如，app)、程序或小应用程序，或者在这些专用应用(例如，app)、程序或小应用程序中实现。包含或实现用于执行群组视频呼叫模块102的功能的指令的应用可以由开发者创建。应用可以被提供给存储库或在存储库中被维护。在某些情况下，应用可以通过网络(例如，互联网)上传或以其他方式传输到存储库。例如，与应用的开发者相关联或受其控制的计算系统(例如，服务器)可以向存储库提供或传输应用。存储库可以包括例如“应用”商店，在该商店中可以维护应用以供用户访问或下载。响应于用户下载应用的命令，可以通过网络将应用从存储库提供或以其他方式传输到与用户相关联的计算设备。例如，与存储库的管理者相关联或在其控制下的计算系统(例如，服务器)可以使得或允许应用被传输到用户的计算设备，从而用户可以安装并运行应用。在某些情况下，应用的开发者和存储库的管理者可以是不同的实体，但在其他情况下可以是相同的实体。应当理解，许多变化是可能的。

如示例系统100中所示，群组视频呼叫模块102可以被配置为与至少一个数据储存器110通信和/或操作。数据储存器110可以被配置成存储并维护各种类型的数据。在一些实现中，数据储存器110可以存储与社交网络系统(例如，图6的社交网络系统630)相关联的信息。与社交网络系统相关联的信息可以包括关于用户的数据、用户标识符、社交关连(social connection)、社交互动、简档信息、人口统计信息、位置、地理围栏区域、地图、地点、事件、页面、群组、帖子、通信、内容、信息流(feed)、账户设置、隐私设置、社交图以及各种其他类型的数据。在一些实施例中，数据储存器110可以存储由群组视频呼叫模块102使用的信息。例如，数据储存器110可以存储用于群组视频呼叫中的视频流层创建和/或带宽分配的各种规则、群组视频呼叫订阅信息、诸如下行链路容量和上行链路容量之类的用户特征等。预期可以有许多变化或其他可能性。

参与者信息模块104可以被配置成识别参与群组视频呼叫的一组参与者。每个参与者可以与上行链路容量和下行链路容量相关联。参与者信息模块104可以被配置成确定每个参与者的上行链路和下行链路容量，或者被配置成从另一个源接收该信息。

参与者信息模块104还可以被配置成接收群组视频呼叫中的参与者的订阅信息。如所讨论的，群组视频呼叫中的一个或更多个参与者可以被识别为发送方参与者，其上传一个或更多个视频流层以供群组视频呼叫中的其他参与者接收并查看。此外，群组视频呼叫中的一个或更多个参与者可以被识别为订阅方参与者，其接收并查看由群组视频呼叫中的其他参与者上传的一个或更多个视频流层。给定参与者可以既是发送方参与者又是订阅方参与者。例如，在每个参与者都在上传视频流并且还在查看群组视频呼叫中所有其他参与者的视频流的群组视频呼叫中，每个参与者既是发送方参与者又是订阅方参与者。

由参与者信息模块104接收的订阅信息可以识别在群组视频呼叫中哪些订阅方参与者订阅了哪些发送方参与者。订阅信息还可以包括指示订阅方参与者和发送方参与者之间的每个订阅的所请求的质量级别的质量信息。例如，质量信息可以指示订阅方参与者是向特定发送方参与者请求了高质量视频流层、标准质量视频流层还是低质量视频流层。

在某些实施例中，订阅的质量信息可以由参与者直接输入。例如，订阅方参与者可以在用户界面中选择一个选项，该选项指定订阅方参与者想要接收的质量级别。在某些实施例中，可以推断订阅的质量信息。在该实施例的特定实例中，可以基于订阅方参与者的观看模式来推断质量信息。例如，如果订阅方参与者在全屏视图中具有第一发送方参与者，而所有剩余发送方参与者在缩略图视图(thumbnail view)中，则可以推断订阅方参与者想要来自第一发送方参与者的高质量视频流，以及来自剩余发送方参与者的低质量视频流。在另一示例中，如果订阅方参与者在网格视图(grid view)中具有所有发送方参与者，使得发送方参与者以基本上相等大小的图块(tile)显示，则可以推断订阅方参与者想要来自每个发送方参与者的中等质量视频流。在该实施例的另一个实例中，可以基于订阅方参与者和/或发送方参与者正在使用的群组视频呼叫装备来推断质量信息。群组视频呼叫装备可以包括硬件和/或软件部件。例如，如果订阅方参与者使用高端专用视频会议装备连接到群组视频呼叫，则可以假设订阅方参与者希望从每个发送方参与者接收可用的最高质量视频流层。

带宽分配模块106可以被配置为基于发送方参与者的上行链路容量和群组视频呼叫中其他参与者的下行链路容量，来为群组视频呼叫中的每个发送方参与者确定要由发送方参与者上传的一个或更多个视频流层。带宽分配模块106还可以被配置为基于发送方参与者的上行链路容量和群组视频呼叫中其他参与者的下行链路容量来确定每个视频流层的质量级别(例如，比特率)。在某些实施例中，将由发送方参与者上传的一个或更多个视频流层及其各自的比特率可以基于订阅了发送方参与者的订阅方参与者的下行链路容量来被确定。

带宽分配模块106还可以被配置为分配群组视频呼叫中的每个订阅方参与者从订阅方参与者订阅的群组视频呼叫中的每个发送方参与者接收一个视频流层。通过将订阅方参与者分配给由发送方参与者上传的特定视频流层，带宽分配模块106确定订阅方参与者将从发送方参与者接收具有特定比特率的视频流层。

在各种实施例中，带宽分配模块106可以以迭代方式确定将由群组视频呼叫中的发送方参与者上传的视频流层。例如，可以基于排名标准对一组发送方参与者进行排序和/或排名，并且带宽分配模块106可以基于该排序顺序地处理每个发送方参与者。当每个发送方参与者被处理时，带宽分配模块106可以确定将由发送方参与者上传的一个或更多个视频流层以及每个视频流层的质量级别(例如，比特率)，并且可以分配订阅了发送方参与者的每个订阅方参与者来接收一个或更多个视频流层中的特定视频流层。在一个实施例中，带宽分配模块106可以基于上行链路容量按从最低上行链路容量到最高上行链路容量的升序对一组发送方参与者进行排名。带宽分配模块106可以基于该排名顺序地处理发送方参与者。例如，带宽分配模块106可以首先处理具有最低上行链路容量的第一发送方参与者，并且基于第一发送方参与者的上行链路容量和订阅了第一发送方参与者的订阅方参与者的下行链路容量来确定将由第一发送方参与者上传的一个或更多个视频流层以及一个或更多个视频流层的比特率。带宽分配模块106然后可以处理具有第二最低上行链路容量的第二发送方参与者，并且基于第二发送方参与者的上行链路容量和订阅了第二发送方参与者的订阅方参与者的下行链路容量等来确定将由第二发送方参与者上传的一个或更多个视频流层以及视频流层的比特率，依此类推，直到已经处理了所有发送方参与者。一旦所有发送方参与者的迭代处理完成，每个发送方参与者被分配上传具有指定比特率的一个或更多个视频流层的任务，并且每个订阅方参与者被分配从订阅方参与者订阅的每个发送方参与者接收一个视频流层。

在各种实施例中，由带宽分配模块106执行的处理可以周期性地和/或间歇性地重复。例如，在某些实施例中，可以基于更新的参与者信息(例如，更新的一组参与者、更新的上行链路容量、更新的下行链路容量、更新的订阅信息等)以规则的时间间隔(例如，每两秒钟)周期性地执行由带宽分配模块106执行的处理。在某些实施例中，可以基于特定事件来重复和/或更新由带宽分配模块106执行的处理。例如，每次参与者加入群组视频呼叫和/或每次参与者离开群组视频呼叫时，可以基于更新的参与者信息来重复由带宽分配模块106执行的处理。

为了理解清楚，本文将分别参考图2和图3中描绘的伪代码200和300的示例集合来更详细地描述对应于带宽分配模块106的各种实施例的带宽分配模块106的各种特征。

视频呼叫模块108可以被配置成管理群组视频呼叫。如所讨论的，群组视频呼叫可以具有多个参与者，包括一个或更多个发送方参与者和一个或更多个订阅方参与者。多个参与者可以以各种组合彼此订阅。如上所述，对于多个参与者的至少一个子集(即，一组发送方参与者)，带宽分配模块106可以为每个发送方参与者确定要由发送方参与者上传的一个或更多个视频流层以及每个视频流层的比特率。视频呼叫模块108可以被配置成接收由群组视频呼叫中的每个发送方参与者上传的视频流层。此外，如上所述，对于多个参与者的至少一个子集(即，一组订阅方参与者)，带宽分配模块106可以分配每个订阅方参与者从订阅方参与者订阅的每个发送方参与者接收一个视频流层。视频呼叫模块108可以基于由带宽分配模块106确定的视频流层分配，来向每个订阅方参与者发送适当的视频流(即，视频流层)。

图2示出了根据本公开的实施例的用于实现带宽分配模块106的各种功能和特征的示例伪代码200。应当理解，伪代码200实现特定实施例，但是本公开不限于该实施例，并且许多变化是可能的。伪代码200将群组视频呼叫中的参与者列表(也称为“端点(endpoint)”)、每个参与者的上行链路容量以及每个参与者的下行链路容量作为输入。该函数还可以接收不同参与者之间的一组“订阅”作为输入。

在伪代码200的第204行，基于上行链路容量按升序对一组参与者进行排序。在不同的实施例中，带宽分配模块106可以被配置为基于不同的排序或排名标准对一组参与者进行排名和/或排序。

第205-237行实现了第一迭代序列，在该序列中，基于参与者的排名顺序来顺序地处理被识别为发送方参与者的每个参与者。例如，在该示例实施例中，第一次迭代将处理具有最低上行链路容量的第一发送方参与者，第二次迭代将处理具有第二最低上行链路容量的第二发送方参与者，依此类推，直到所有发送方参与者都已被处理。第一迭代序列中的每次迭代将参考在该次迭代中被处理的“发送方参与者”和订阅了该发送方参与者的一个或更多个“订阅方参与者”来被描述。

在第206-208行，识别出订阅了发送方参与者的一组订阅方参与者。在第209-210行，为一组订阅方参与者中的每个订阅方参与者确定“保留下行链路(reserveddownlink)”。每个订阅方参与者的保留下行链路是使用函数“ComputeReservedDownlink”确定的。将参照图3更详细地描述每个订阅方参与者的保留下行链路的确定。在这一点上，足以说明订阅方参与者的保留下行链路代表订阅方参与者的可用下行链路容量的一部分，该部分是为正在被处理的发送方参与者临时保留的。在第212行，基于保留下行链路，按升序对订阅了发送方参与者的每个订阅方参与者进行排名。

第213行和214行初始化两个值“prev_layer_kbps”和“current_layer_to_upload”，以用于在第215-231行中实现的第二迭代序列。第二迭代序列对订阅了在第一迭代序列的当前迭代中被处理的发送方参与者的每个订阅方参与者进行迭代地处理。在该示例实施例中，每个订阅方参与者按照从最低保留下行链路到最高保留下行链路的顺序被顺序地处理。将参考在第二迭代序列的特定迭代中处理的“当前订阅方参与者”和在较宽的第一迭代序列的特定迭代中处理的“当前发送方参与者”来描述第二迭代序列。在第216行，值“current_layer_kbps”被设置为等于当前订阅方参与者的保留下行链路容量和当前发送方参与者的剩余上行链路容量中的较小者。值“current_layer_kbps”表示可以为当前发送方参与者创建和/或分配的潜在的新视频流层的大小。

在第217-222行，基于最小差异阈值确定是否为当前发送方参与者创建新的视频流层。在第217行，确定潜在的新视频流层的大小(current_layer_kbps)相对于先前视频流层是否满足最小差异阈值。在该特定实施例中，确定潜在的新视频流层的大小是否比先前视频流层(prev_layer_kbps)大至少两倍。如果是，current_layer_to_upload计数器递增(第218行)，并且为发送方参与者创建新的视频流层(第219行)。新视频流层的比特率等于current_layer_kbps(第219行)。在第220行，从当前发送方参与者的可用上行链路容量中减去新视频流层的比特率。在第230行，当前订阅方参与者被映射到新创建的视频流层。换句话说，当前订阅方参与者将从当前发送方参与者接收比特率等于current_layer_kbps的新创建的视频流层。

然而，如果潜在的新视频流层(current_layer_kbps)不满足最小差异阈值，即不比先前视频流层大至少两倍，则不创建新层，并且当前订阅方参与者被映射到先前视频流层(第221、222和230行)。

如所讨论的，伪代码200的第215-230行对订阅了当前发送方参与者的每个订阅方参与者进行迭代地处理。对于每个订阅方参与者，比特率分配模块106确定可以创建的潜在的新视频流层的大小(current_layer_kbps)。潜在的新视频流层的大小等于当前订阅方参与者的保留下行链路，或者，如果当前发送方参与者没有足够的剩余上行链路来满足当前订阅方参与者的保留下行链路，则潜在的新视频流层的大小等于当前发送方参与者的剩余上行链路容量(第216行)。比特率分配模块106确定潜在的新视频流层是否保证由发送方参与者上传的新视频流层的创建，或者当前订阅方参与者是否应当被分配给先前创建的视频流层。该确定可以基于潜在的新视频流层的大小和先前创建的视频流层的比特率之间的差异阈值来进行。在示例伪代码200中，该差异阈值被定义为使得潜在的新视频流层必须至少是先前视频流层的两倍大(第217行)。在其他实施例中，可以使用不同的差异阈值。例如，差异阈值可以是任何倍数或绝对差(例如，比先前视频流层大100kbps)，或者是它们的组合。在某些实施例中，例如，可以为不同范围的比特率定义多个差异阈值。如果潜在的新视频流层满足差异阈值，则以等于潜在的新视频流层的大小的比特率来创建新视频流层(第219行)，并且当前订阅方参与者被分配给新视频流层(第230行)。当前发送方参与者的剩余上行链路容量也通过减去新视频流层的大小来被更新(第220行)。如果潜在的新视频流层不满足差异阈值，则当前订阅方参与者被分配给先前视频流层(即，已经被创建并分配给当前发送方参与者的视频流层)(第221、222和230行)。

一旦在第215-231行中实现的第二迭代序列完成了订阅了当前发送方参与者的一组订阅方参与者的处理，当前发送方参与者就被分配了将由发送方参与者上传的一个或更多个视频流层，其中每个视频流层具有特定的比特率。例如，发送方参与者可以被分配上传比特率为100kbps的第一视频流层、比特率为500kbps的第二视频流层和比特率为1Mbps的第三视频流层。此外，一组订阅方参与者中的每个订阅方参与者已经被分配到将由当前发送方参与者上传的一个或更多个视频流层中的特定一个。被分配到特定视频流层的订阅方参与者指示订阅方参与者将从当前发送方参与者接收具有特定比特率的视频流层。例如，第一订阅方参与者可以被分配来接收100kbps视频流层，第二订阅方参与者可以被分配来接收500kbps视频流层，第三订阅方参与者可以被分配来接收1Mbps视频流层，并且第四订阅方也可以被分配来接收1Mbps视频流层。在第232-236行，通过减去订阅方参与者已被分配的视频流层的比特率来更新每个订阅方参与者的下行链路容量。

对于特定的发送方参与者，第205-237行的第一迭代序列的每次迭代运行第215-231行的第二迭代序列。可以看出，一旦已经为每个发送方参与者运行了第215-231行的第二迭代序列，每个发送方参与者就被分配发送方参与者负责上传的一个或更多个不同质量的视频流层，并且每个订阅方参与者将被分配到来自订阅方参与者订阅的每个发送方参与者的特定视频流层。

第223-229行实现了一个替代实施例，该实施例允许潜在的进一步优化发送方参与者上行链路容量使用。在第224行，确定当前发送方参与者的剩余上行链路容量是否大于或等于先前视频流层的比特率，以及当前订阅方参与者的保留下行链路是否大于或等于当前发送方参与者的剩余上行链路容量的两倍。如果这两个条件都满足，则先前视频流层的比特率被加回到当前发送方参与者的剩余上行链路容量中(第225行)。修改先前视频流层的比特率，使得先前视频流层的比特率等于发送方参与者的剩余上行链路容量的1/4(第226行)，并且创建新的视频流层，其比特率等于发送方参与者的剩余上行链路容量的3/4(第227-228行)。本质上，这些额外的行解决了一种特定的情况，其中可能希望降低先前视频流层的比特率，以便能够适应与先前视频流层充分不同的第二视频流层。

图3示出了根据本公开的实施例的用于实现带宽分配模块106的各种功能的示例伪代码300。具体而言，伪代码300描绘了一个实施例，通过该实施例，带宽分配模块106可以相对于特定的发送方参与者来为订阅方参与者确定保留下行链路。订阅方参与者的保留下行链路可以基于订阅方参与者的剩余下行链路容量来被确定。如所描述的，订阅方参与者的剩余下行链路容量随着在图2的伪代码200的第205-237行中实现的迭代序列的每次迭代而被更新。在第一次迭代中，订阅方参与者的剩余下行链路容量等于他们的总下行链路容量。然而，在第一次迭代之后，下行链路容量的某个部分可以被分配来接收来自第一发送方参与者的视频流层，并且在第二次迭代之后，下行链路容量的某个部分可以被分配来接收来自第二发送方参与者的视频流层，依此类推，使得特定订阅方参与者的剩余下行链路容量将潜在地随着每次迭代而减少。在各种实施例中，可以基于在进行确定时订阅方参与者的剩余下行链路容量来确定订阅方参与者的保留下行链路。

订阅方参与者的保留下行链路也可以基于订阅方参与者对特定发送方参与者的订阅的质量级别来被确定。如所述，订阅方参与者对特定发送方参与者的订阅可以与多个质量级别中的特定质量级别相关联。例如，在一个实施例中，可以有低质量级别、中等质量级别和高质量级别。在一个实施例中，订阅方参与者可以指定他们希望从特定发送方参与者接收哪个质量级别。在另一个实施例中，例如，可以基于订阅方参与者选择的观看模式来推断质量级别。

在示例伪代码300中，定义了四个质量级别。质量级别4表示最高质量级别，而质量级别1表示最低质量级别。如果订阅方参与者已经向发送方参与者请求了质量级别为2的订阅，则订阅方参与者的保留下行链路被计算为订阅方参与者的剩余下行链路容量除以订阅方参与者的待处理的发送方参与者的数量(第305-306行)。例如，考虑一个示例场景，其中订阅方参与者订阅了四个不同的发送方参与者。此外，图2的第205-237行的迭代序列已经经历了一次迭代，使得发送方参与者之一已经被处理，并且订阅方参与者已经被分配给该发送方参与者的特定视频流层，但是剩余的三个发送方参与者还没有被处理，并且订阅方参与者还没有被分配给那些发送方参与者的视频流层。订阅方参与者的剩余下行链路容量已经被更新以反映订阅方参与者已经订阅的一个视频流层，并且订阅方参与者的待处理的发送方参与者的数量等于3。这样，在该示例场景中，订阅方参与者的保留下行链路将等于他或她的剩余下行链路容量除以3。

如果订阅方参与者已经向发送方参与者请求了3级或4级订阅(即，高质量订阅)，则订阅方参与者的保留下行链路被计算为订阅方参与者的剩余下行链路容量乘以高清晰度比率(HD_RATIO)。在示例伪代码300中，高清晰度比率被设置为0.5(第304行)，使得保留下行链路被计算为订阅方参与者的剩余下行链路容量的一半。在各种实施例中，HD_RATIO可以是不同的值，并且如对第304行的注释所示，可以基于例如订阅方参与者剩余的要处理的订阅而变化。

如果订阅方参与者已经向发送方参与者请求了1级订阅，则订阅方参与者的保留下行链路可以取决于订阅方参与者的剩余订阅。在示例伪代码300中，如果订阅方参与者具有未决的、未处理的更高清晰度层订阅(例如，3级或4级)，则保留下行链路被计算为订阅方参与者的剩余下行链路容量乘以(1-HD_RATIO)，并且该乘积除以(订阅方参与者的剩余订阅-1)(第311-312行)。本质上，该计算通过计算剩余下行链路容量与(1-HD_RATIO)的乘积，然后将剩余的下行链路容量除以未决订阅的数量减1，来为未决的更高清晰度层订阅保留一部分订阅方参与者的剩余下行链路容量。然而，如果订阅方参与者没有未决的、未处理的高清晰度层订阅，则以与2级/中等清晰度订阅相同的方式计算保留下行链路(第313-315行)。

现在将参考示例场景提供额外的澄清和解释。

图4A-图4Q示出了根据本公开的实施例的与群组视频呼叫联播优化相关联的示例场景400。根据各种实施例，示例场景400演示了群组视频呼叫模块102的各种功能。如图4A所示，示例场景400包括参与群组视频呼叫的四个用户402、404、406和408。每个用户都订阅了其他所有用户。此外，示例场景400包括三个订阅质量级别：级别1或“低清晰度”(LD)、级别2或“标准清晰度”(SD)、以及级别3或“高清晰度”(HD)。

用户402具有200kbps的上行链路容量和200kbps的下行链路容量。用户402已经向每个其他用户请求了标准清晰度视频流。例如，这可以是用户402已经选择了群组视频呼叫的“网格视图”的实例，使得其他参与者都显示在大小基本相等的单独窗口中。

用户404具有300kbps的上行链路容量和200kbps的下行链路容量。用户404已经向用户406和408请求了低清晰度视频流，并向用户402请求了高清晰度视频流。这可以是例如用户404具有全屏视图上的用户402，并且具有以缩略图视图显示的用户406和408的实例。

用户406具有350kbps的上行链路容量和600kbps的下行链路容量。像用户402一样，用户406已经向每个其他用户请求了标准清晰度视频流。

用户408具有800kbps的上行链路容量和1000kbps的下行链路容量。类似于用户404，用户408已经向用户404和406请求了低清晰度视频流，并向用户402请求了高清晰度视频流。

如上所述，在一个实施例中，可以基于上行链路容量按升序对用户组402、404、406、408进行排名，然后基于该排名按顺序进行迭代处理。在示例场景400中，根据在图2的伪代码200(包括伪代码200的第223-229行)中实现的实施例来处理群组视频呼叫。

在图4B中，在图2的第205-237行中实现的迭代序列的第一次迭代处理具有最低上行链路容量的用户402。在该第一次迭代中，用户402是发送方参与者，并且用户404、406和408各自都是订阅了用户402的订阅方参与者。在示例场景400中，根据在图3的伪代码300中实现的实施例，相对于发送方参与者，为每个订阅方参与者确定保留下行链路。如上所述，每个订阅方参与者的保留下行链路是基于订阅方参与者的剩余下行链路容量和与订阅方参与者对发送方参与者的订阅相关联的质量级别来被确定的。用户404已经向发送方参与者(即用户402)请求了高清晰度视频流。这样，用户404的保留下行链路被计算为用户404的剩余下行链路容量(200kbps)除以2(如伪代码300的第304行中的HD_RATIO所指定的)。因此，用户404的保留下行链路是100kbps。用户406已经向用户402请求了标准清晰度视频流。这样，用户406的保留下行链路被计算为用户406的剩余下行链路容量(600kbps)除以用户406的剩余待处理的订阅数量。在该第一次迭代中，没有一个发送方参与者被处理，这意味着用户406仍有三个剩余订阅待处理。这样，用户406的保留下行链路是600kbps/3＝200kbps。用户408已经向用户402请求了高清晰度视频流。这样，用户408的保留下行链路被计算为用户408的剩余下行链路容量(1000kbps)除以2，即500kbps。

图4C示出了订阅方参与者的进一步处理。根据图2的第212行，基于保留下行链路按升序对每个订阅方参与者进行排名。根据在图2的第215-236行中实现的第二迭代序列，基于排名顺序地处理每个订阅方参与者。第二迭代序列的第一次迭代处理具有最低保留下行链路的用户404。创建大小等于用户404的保留下行链路(100kbps)的第一视频流层，并将用户404分配给第一视频流层。比特率为100kbps的第一视频流层的创建表明发送方参与者(用户402)将上传比特率为100kbps的第一视频流层。这样，用户402具有专用于第一视频流层的100kbps的他或她的上行链路容量，以及剩余的100kbps的上行链路容量。将订阅方参与者(用户404)分配给该第一视频流层表示用户404将从用户402接收100kbps的视频流层。如前所述，虽然本公开可以声明订阅方参与者“从”发送方参与者接收视频流层，但是应当理解，在各种实施例中，该接收不是视频流层从一个参与者到另一个参与者的直接传输。相反，在各种实施例中，由于发送方参与者将视频流层上传到中央服务器，并且中央服务器基于被分配接收该视频流层的订阅方参与者将视频流层发送给订阅方参与者，所以订阅方参与者“从”发送方参与者接收视频流层。

第二迭代序列的第二次迭代处理具有第二最低保留下行链路的用户406。基于图2的第217行，确定剩余上行链路容量不足以创建新层，因为用户402的剩余上行链路容量(100kbps)不比先前创建的视频流层(100kbps)的大两倍。然而，基于图2的第224行，确定用户402的剩余上行链路容量大于或等于先前创建的视频流层，并且用户406的保留下行链路大于或等于用户402的剩余上行链路的两倍。在这种情况下，基于图2的第224-229行，先前视频流层的比特率被加回到用户402的剩余上行链路容量中(第225行)，先前视频流层被重新定义为具有等于剩余上行链路容量的1/4的比特率(第226行)，并且以等于剩余上行链路容量的3/4的比特率来创建新视频流层(第228行)。这样，第一视频流层被重新定义为具有50kbps而不是100kbps的比特率，并且新的第二视频流层被创建为具有150kbps的比特率。用户404保持被分配给第一视频流层，其现在是50kbps的视频流，并且用户406被分配给新创建的第二视频流层，其是150kbps的视频流。用户402现在被分配上传50kbps视频流层和150kbps视频流层，这完全利用了用户402的上行链路容量。

第二迭代序列的第三次迭代处理具有第三最低保留下行链路的用户408。用户402剩余的上行链路容量不足以创建新的视频流层。这样，用户408被分配到先前视频流层，即150kbps的视频流层。

图4D总结了图2的第205-237行的迭代序列的第一次迭代的结果。用户402被分配上传两个视频流层，第一视频流层具有50kbps的比特率，并且第二视频流层具有150kbps的比特率。用户402的上行链路容量通过减去用户402将上传的两个视频流层的比特率来被更新，导致剩余的上行链路容量为0kbps。

用户404被分配从用户402接收第一视频流层，并且用户406和408都被分配从用户402接收第二视频流层。用户404的下行链路容量通过减去50kbps来被更新，用户406的下行链路容量通过减去150kbps来被更新，并且用户408的下行链路容量通过减去150kbps来被更新。图4E展示了在图2的第205-237行的迭代序列的第一次迭代之后参与者的状态。

图4F示出了图2的第205-237行的迭代序列的第二次迭代的开始。在该第二次迭代中，用户404被选择作为被处理的发送方参与者，因为用户404具有四个用户中第二最低上行链路容量，并且用户402、406和408各自都是订阅了用户404的订阅方参与者。再次，根据图3的伪代码300中实现的实施例，相对于发送方参与者，为每个订阅方参与者确定保留下行链路。用户402已经向发送方参与者(即用户404)请求了标准清晰度视频流。这样，用户402的保留下行链路被计算为用户402的剩余下行链路容量(200kbps)除以用户402的剩余待处理的订阅数量。用户402仍有三个剩余订阅待处理(用户404、406和408)，因此用户402的保留下行链路是200kbps/3＝66kbps。用户406也向用户404请求了标准清晰度视频流。这样，用户406的保留下行链路被计算为用户406的剩余下行链路容量(450kbps)除以用户406的剩余待处理的订阅数量。用户406的订阅之一已经被处理(用户402)，因此用户406只剩下两个订阅需要处理(用户404和408)。这样，用户406的保留下行链路是450kbps/2＝225kbps。用户408已经向用户402请求了低清晰度视频流(如图3的第309-315行所示)。用户408没有剩余的高清晰度订阅要处理。因此，用户408的保留下行链路等于用户408的剩余下行链路容量除以用户408的剩余待处理的订阅数量。用户408还有两个订阅要处理(用户404和406)。因此，用户408的保留下行链路是850kbps/2＝425kbps。

图4G示出了订阅方参与者的进一步处理。根据图2的第212行，基于保留下行链路按升序对每个订阅方参与者进行排名。根据在图2的第215-236行中实现的第二迭代序列，基于排名顺序地处理每个订阅方参与者。第二迭代序列的第一次迭代处理具有最低保留下行链路的用户402。创建大小等于用户402的保留下行链路(66kbps)的第一视频流层，并将用户402分配给第一视频流层。比特率为66kbps的第一视频流层的创建表明发送方参与者(用户404)将上传比特率为66kbps的第一视频流层。这样，用户404具有专用于第一视频流层的66kbps的他或她的上行链路容量，以及剩余的234kbps的上行链路容量。

第二迭代序列的第二次迭代处理具有第二最低保留下行链路的用户406。确定用户406的保留下行链路(小于用户404的剩余上行链路容量)至少是先前创建的视频流层的两倍。这样，创建了大小等于用户406的保留下行链路(225kbps)的新的第二视频流层。用户404现在负责上传两个视频流，第一个是66kbps，并且第二个是225kbps，这意味着用户404剩余9kbps的上行链路容量。用户406被分配给第二视频流层。

第二迭代序列的第三次迭代处理具有第三最低保留下行链路的用户408。用户404剩余的上行链路容量不足以创建新的视频流层。这样，用户408被分配到先前视频流层，即225kbps的视频流层。

图4H总结了图2的第205-237行的迭代序列的第二次迭代的结果。用户404被分配上传两个视频流层，第一视频流层具有66kbps的比特率，并且第二视频流层具有225kbps的比特率。通过减去用户404将上传的两个视频流层的比特率来更新用户404的上行链路容量，导致剩余的上行链路容量为9kbps。用户402被分配从用户404接收第一视频流层，并且用户406和408都被分配从用户404接收第二视频流层。用户402的下行链路容量通过减去66kbps来被更新，用户406的下行链路容量通过减去225kbps来被更新，并且用户408的下行链路容量通过减去225kbps来被更新。图4I展示了在图2的第205-237行的迭代序列的第二次迭代之后参与者的状态。

图4J示出了图2的第205-237行的迭代序列的第三次迭代的开始。在该第三次迭代中，用户406被选择作为被处理的发送方参与者，因为用户406具有四个用户中第三最低上行链路容量，并且用户402、404和408各自都是订阅了用户406的订阅方参与者。再次，根据图3的伪代码300中实现的实施例，针对发送方参与者(在该迭代中是用户406)为每个订阅方参与者确定保留下行链路。用户402已经向发送方参与者(即用户406)请求了标准清晰度视频流。这样，用户402的保留下行链路被计算为用户402的剩余下行链路容量(134kbps)除以用户402的剩余待处理的订阅数量。用户402现在剩余两个订阅要处理(用户406和408)，因此用户402的保留下行链路是134kbps/2＝67kbps。用户404已经向用户406请求了低清晰度视频流。用户404没有任何剩余的高清晰度订阅要处理。这样，用户404的保留下行链路被计算为用户404的剩余下行链路容量(150kbps)除以用户404的剩余待处理的订阅数量。用户404还有两个订阅要处理(用户406和408)。这样，用户404的保留下行链路是150kbps/2＝75kbps。用户408已经向用户406请求了低清晰度视频流。用户408没有剩余的高清晰度订阅要处理。因此，用户408的保留下行链路等于用户408的剩余下行链路容量除以用户408的剩余要处理的订阅数量。用户408只剩下一个订阅需要处理(用户406)。因此，用户408的保留下行链路是625kbps/1＝625kbps。

图4K示出了订阅方参与者的进一步处理。根据图2的第212行，基于保留下行链路按升序对每个订阅方参与者进行排名。根据在图2的第215-236行中实现的第二迭代序列，基于排名顺序地处理每个订阅方参与者。第二迭代序列的第一次迭代处理具有最低保留下行链路的用户402。创建大小等于用户402的保留下行链路(67kbps)的第一视频流层，并将用户402分配给第一视频流层。这表明发送方参与者(用户406)将上传比特率为67kbps的第一视频流层。这样，用户406具有专用于第一视频流层的67kbps的他或她的上行链路容量，以及剩余的283kbps的上行链路容量。

第二迭代序列的第二次迭代处理具有第二最低保留下行链路的用户404。确定用户404的保留下行链路不满足相对于先前视频流层的差异阈值，即，不是先前视频流层的比特率的至少两倍。这样，用户404被分配给先前创建的比特率为67kbps的第一视频流层。

第二迭代序列的第三次迭代处理具有第三最低保留下行链路的用户408。用户406的剩余上行链路容量小于用户408的保留下行链路容量。这样，潜在新层的大小被设置为等于用户406的剩余上行链路容量(即283kbps)。潜在新层的大小满足差异阈值，即至少是先前视频流层的比特率的两倍。因此，创建了具有283kbps比特率的新的第二视频流层。用户408被分配给第二视频流层。

图4L总结了图2的第205-237行的迭代序列的第三次迭代的结果。用户406被分配上传两个视频流层，第一视频流层具有67kbps的比特率，并且第二视频流层具有283kbps的比特率。用户406的上行链路容量通过减去用户406将上传的两个视频流层的比特率来被更新，导致剩余的上行链路容量为0kbps。用户402和404都被分配从用户406接收第一视频流层，并且用户408被分配从用户406接收第二视频流层。通过减去67kbps来更新用户402的下行链路容量，通过减去67kbps来更新用户404的下行链路容量，并且通过减去283kbps来更新用户408的下行链路容量。图4M示出了在图2的第205-237行的迭代序列的第三次迭代之后参与者的状态。

图4N示出了图2的第205-237行的迭代序列的第四次也是最后一次迭代的开始。在该第四次迭代中，用户408被选择作为正被处理的发送方参与者，并且用户402、404和406各自都是订阅了用户408的订阅方参与者。再次，根据图3的伪代码300中实现的实施例，相对于发送方参与者，为每个订阅方参与者确定保留下行链路。用户402已经向发送方参与者(即用户408)请求了标准清晰度视频流。这样，用户402的保留下行链路被计算为用户402的剩余下行链路容量(67kbps)除以用户402的剩余待处理的订阅数量。用户402现在只剩下一个订阅需要处理(用户408)，因此用户402的保留下行链路是67kbps/1＝67kbps。用户404已经向用户408请求了低清晰度视频流。用户404没有任何剩余的高清晰度订阅要处理。这样，用户404的保留下行链路被计算为用户404的剩余下行链路容量(83kbps)除以用户404的剩余待处理的订阅数量。用户404只剩下一个订阅需要处理(用户408)。这样，用户404的保留下行链路是83kbps/1＝83kbps。用户406已经向用户408请求了标准清晰度视频流。因此，用户406的保留下行链路等于用户406的剩余下行链路容量除以用户406的剩余要处理的订阅数量。用户406只剩下一个订阅需要处理(用户408)。因此，用户406的保留下行链路是225kbps/1＝225kbps。

图4O示出了订阅方参与者的进一步处理。根据图2的第212行，基于保留下行链路按升序对每个订阅方参与者进行排名。根据在图2的第215-236行中实现的第二迭代序列，基于排名顺序地处理每个订阅方参与者。第二迭代序列的第一次迭代处理具有最低保留下行链路的用户402。创建大小等于用户402的保留下行链路(67kbps)的第一视频流层，并将用户402分配给第一视频流层。用户408具有专用于第一视频流层的67kbps的他或她的上行链路容量，以及剩余的733kbps的上行链路容量。

第二迭代序列的第二次迭代处理具有第二最低保留下行链路的用户404。确定用户404的保留下行链路不满足相对于先前视频流层的差异阈值，即，不是先前视频流层的比特率的至少两倍。这样，用户404被分配给先前创建的67kbps的第一视频流层。

第二迭代序列的第三次迭代处理具有第三最低保留下行链路的用户406。用户406的保留下行链路(225kbps)小于用户408的剩余上行链路容量(733kbps)。这样，潜在新层的大小被设置为等于用户406的保留下行链路(即225kbps)。潜在新层的大小满足差异阈值，即至少是先前视频流层的比特率的两倍。因此，创建了具有225kbps比特率的新的第二视频流层。用户406被分配给第二视频流层。

图4P总结了图2的第205-237行的迭代序列的第四次迭代的结果。用户408被分配上传两个视频流层，第一视频流层具有67kbps的比特率，并且第二视频流层具有225kbps的比特率。用户408的上行链路容量通过减去用户408将上传的两个视频流层的比特率来被更新，导致剩余的上行链路容量为508kbps。用户402和404都被分配从用户408接收第一视频流层，并且用户406被分配从用户408接收第二视频流层。用户402的下行链路容量通过减去67kbps来被更新，用户404的下行链路容量通过减去67kbps来被更新，并且用户406的下行链路容量通过减去225kbps来被更新。图4Q示出了在图2的第205-237行的迭代序列的第四次也是最后一次迭代之后参与者的状态。可以看出，每个发送方参与者(在这种情况下，每个参与者)被分配了参与者将上传的一个或更多个视频流层，并且每个订阅方参与者(在这种情况下，每个参与者)被分配从订阅方参与者订阅的每个发送方参与者接收具有特定比特率的一个视频流。

虽然上述示例场景描述了群组视频呼叫中的每个参与者既是发送方参与者又是订阅方参与者的示例场景，但是应当理解，本公开能够处理并管理具有不同特征的群组视频呼叫。例如，参与者的子集可以是发送方参与者，使得只有一些参与者上传视频流，和/或参与者的子集可以是订阅方参与者，使得只有一些参与者从其他参与者接收视频流。类似地，虽然上面描述的示例场景描述了每个参与者从每个其他参与者接收视频流的示例场景，但是应当理解，本公开可以解决不同的场景。例如，某些订阅方参与者可能仅订阅来从发送方参与者的子集接收视频信息流。许多变化是可能的。

上述示例实施例通常试图利用尽可能多的发送方参与者的上行链路容量和尽可能多的订阅方参与者的下行链路容量。然而，在某些场景中，即使额外的上行链路容量和/或下行链路容量可用，也可能希望对比特率施加限制或上限(cap)。例如，如果订阅方参与者已经向发送方参与者请求了低清晰度视频流，则可能希望限制低清晰度视频流的比特率，即使订阅方参与者具有足够的下行链路容量，并且发送方参与者具有足够的上行链路容量来容纳非常高比特率的视频流。这样，在各种实施例中，特定质量级别的订阅可以以最大比特率为上限。例如，低质量订阅可以以第一最大比特率为上限，而标准或中等质量订阅可以以大于第一最大比特率的第二最大比特率为上限，而高质量订阅可以以大于第二最大比特率的第三最大比特率为上限，或者在各种实施例中，可以根本不被限制。

图5示出了根据本公开的实施例的与优化群组视频呼叫联播流相关联的示例方法500。应当理解，除非另有说明，否则在本文讨论的各种实施例的范围内，可以以类似或替代的顺序或并行地执行额外的、更少的或替代的步骤。

在框502，示例方法500可以识别群组视频呼叫中的一组参与者，其中每个参与者与上行链路容量和下行链路容量相关联，并且该组参与者包括一组发送方参与者和一组订阅方参与者。在框504，示例方法500可以基于订阅了发送方参与者的订阅方参与者的下行链路容量，为一组发送方参与者中的每个发送方参与者确定将由发送方参与者上传的一个或更多个视频流层。在框506，对于一组订阅方参与者中的每个订阅方参与者，示例方法500可以分配订阅方参与者接收将由订阅方参与者订阅的每个发送方参与者上传的一个或更多个视频流层中的一个视频流层。

设想可以有与本公开的各种实施例相关联的许多其他用途、应用和/或变型。例如，在一些情形中，用户可以选择是否选择加入(opt-in)以利用所公开的技术。所公开的技术还可以确保各种隐私设置和偏好被维护，并且可以防止隐私信息被泄露。在另一示例中，本公开的各种实施例可以随着时间的推移而学习、改进和/或被完善。

社交网络系统–示例实施

图6示出了根据本公开实施例的可以在各种场景中被利用的示例系统600的网络图。系统600包括一个或更多个用户设备610、一个或更多个外部系统620、社交网络系统(或服务)630和网络650。在实施例中，关于上述实施例讨论的社交网络服务、提供者和/或系统可以被实现为社交网络系统630。为了说明的目的，图6所示的系统600的实施例包括单个外部系统620和单个用户设备610。然而在其他实施例中，系统600可以包括更多个用户设备610和/或更多个外部系统620。在某些实施例中，社交网络系统630由社交网络提供者操作，而外部系统620与社交网络系统630分离，因为它们可以由不同的实体操作。然而，在各种实施例中，社交网络系统630和外部系统620协同操作以向社交网络系统630的用户(或成员)提供社交网络服务。在这个意义上，社交网络系统630提供了平台或骨干网，其他系统(例如外部系统620)可以使用该平台或骨干网来通过互联网向用户提供社交网络服务和功能。

用户设备610包括可以接收来自用户的输入并经由网络650来传输并接收数据的一个或更多个计算设备。在一个实施例中，用户设备610是执行例如Microsoft Windows兼容操作系统(OS)、Apple OS X和/或Linux发行版的传统计算机系统。在另一实施例中，用户设备610可以是具有计算机功能的设备，如智能电话、平板电脑、个人数字助理(PDA)、移动电话等。用户设备610被配置成经由网络650进行通信。用户设备610可以执行允许用户设备610的用户与社交网络系统630交互的应用(例如，浏览器应用)。在另一实施例中，用户设备610通过由用户设备610的原生(native)操作系统(例如iOS和ANDROID)提供的应用编程接口(API)来与社交网络系统630交互。用户设备610被配置成使用有线和/或无线通信系统经由网络650来与外部系统620和社交网络系统630进行通信，网络650可以包括局域网和/或广域网的任何组合。

在一个实施例中，网络650使用标准通信技术和协议。因此，网络650可以包括使用诸如以太网、802.11、全球互通微波接入(WiMAX)、3G、4G、CDMA、GSM、LTE、数字用户线路(DSL)等技术的链路。类似地，在网络650上使用的网络协议可以包括多协议标签交换(MPLS)、传输控制协议/互联网协议(TCP/IP)、用户数据报协议(UDP)、超文本传输协议(HTTP)、简单邮件传输协议(SMTP)、文件传输协议(FTP)等。可以使用包括超文本标记语言(HTML)和可扩展标记语言(XML)的技术和/或格式来表示通过网络650交换的数据。此外，可以使用诸如安全套接字层(SSL)、传输层安全(TLS)和互联网协议安全(IPsec)的常规加密技术来对所有或一些链路进行加密。

在一个实施例中，用户设备610可以通过使用浏览器应用612处理从外部系统620和从社交网络系统630接收的标记语言文档614来显示来自外部系统620和/或来自社交网络系统630的内容。标记语言文档614识别内容以及描述内容的格式或呈现的一个或更多个指令。通过执行包括在标记语言文档614中的指令，浏览器应用612使用由标记语言文档614所描述的格式或呈现来显示所识别的内容。例如，标记语言文档614包括用于生成并显示具有多个帧(frame)的网页的指令，这些帧包括从外部系统620和社交网络系统630检索的文本和/或图像数据。在多种实施例中，标记语言文档614包括数据文件，该数据文件包括可扩展标记语言(XML)数据、可扩展超文本标记语言(XHTML)数据或其他标记语言数据。此外，标记语言文档614可以包括JavaScript对象简谱(JSON)数据、带填充的JSON(JSONP)和JavaScript数据，以便于在外部系统620和用户设备610之间的数据交换。用户设备610上的浏览器应用612可以使用JavaScript编译器来对标记语言文档614进行解码。

标记语言文档614还可以包括或链接到应用或应用框架，例如FLASH^TM或Unity^TM应用、Silverlight^TM应用框架等。

在一个实施例中，用户设备610还包括一个或更多个cookie 616，cookie616包括指示用户设备610的用户是否登录到社交网络系统630内的数据，这可以实现从社交网络系统630传递到用户设备610的数据的修改。

外部系统620包括一个或更多个web服务器，其包括一个或更多个网页622a、622b，这些网页使用网络650被传递到用户设备610。外部系统620与社交网络系统630分离。例如，外部系统620与第一域相关联，而社交网络系统630与单独的社交网络域相关联。被包括在外部系统620中的网页622a、622b包括标记语言文档614，其识别内容并且包括指定所识别的内容的格式或呈现的指令。

社交网络系统630包括用于社交网络(包括多个用户)并且向社交网络的用户提供与社交网络的其他用户通信并交互的能力的一个或更多个计算设备。在一些实例中，社交网络可以由图(即，包括边和节点的数据结构)表示。其他数据结构也可以用来表示社交网络，包括但不限于数据库、对象、类、meta元素、文件或任何其他数据结构。社交网络系统630可以由操作者掌管、管理或控制。社交网络系统630的操作者可以是人、自动化应用或用于管理内容、调整策略和收集在社交网络系统630内的使用度量的一系列应用。可以使用任何类型的操作者。

用户可以加入社交网络系统630，且然后添加对他们希望关连到的社交网络系统630的任何数量的其他用户的关连。如在本文所使用的，术语“朋友”指社交网络系统630的任何其他用户，用户经由社交网络系统630与任何其他用户形成关连、关联(association)或关系。例如在实施例中，如果在社交网络系统630中的用户被表示为在社交图中的节点，则术语“朋友”可以指在两个用户节点之间形成的并直接连接两个用户节点的边。

关连可以由用户明确地添加，或者可以由社交网络系统630基于用户(例如，作为同一教育机构的校友的用户)的共同特性来自动创建。例如，第一用户特别地将特定的其他用户选择为朋友。在社交网络系统630中的关连通常在两个方向上，但不需要是这样，因此术语“用户”和“朋友”取决于参考系。在社交网络系统630的用户之间的关连通常是双边的(“双向的”)或“相互的”，但是关连也可以是单边的或“单向的”。例如，如果鲍勃和乔都是社交网络系统630的用户并且关连到彼此，则鲍勃和乔是彼此的关连。另一方面，如果鲍勃希望关连到乔以查看由乔传递到社交网络系统630的数据，但是乔不希望形成相互关连，则单边连接可以被建立。在用户之间的关连可以是直接关连；然而，社交网络系统630的一些实施例允许经由一个或更多个级别的关连或分离度的关连是间接的。

除了建立并维护在用户之间的关连并允许在用户之间的交互之外，社交网络系统630还向用户提供对由社交网络系统630支持的各种类型的项目采取动作的能力。这些项目可以包括社交网络系统630的用户可能属于的群组或网络(即，人、实体和概念的社交网络)、用户可能感兴趣的事件或日历条目、用户经由社交网络系统630可以使用的基于计算机的应用、允许用户借助由社交网络系统630提供或通过社交网络系统630提供的服务来购买或销售项目的交易、以及用户可以在社交网络系统630上或外执行的与广告的交互。这些仅仅是用户可以在社交网络系统630上对其作用的项目的几个示例，并且许多其他项目是可能的。用户可以与能够在社交网络系统630中或在外部系统620中被表示的、与社交网络系统630分离的、或者经由网络650耦合到社交网络系统630的任何事物进行交互。

社交网络系统630也能够链接各种实体。例如，社交网络系统630使用户能够通过API、web服务或其他通信渠道来与彼此以及外部系统620或其他实体进行交互。社交网络系统630生成并维护包括由多条边互连的多个节点的“社交图”。社交图中的每个节点可以表示可以作用于另一个节点和/或可以由另一个节点作用的实体。社交图可以包括各种类型的节点。节点的类型的示例包括用户、非个人实体、内容项、网页、群组、活动、消息、概念以及可以由社交网络系统630中的对象表示的任何其他事物。在社交图中的两个节点之间的边可以表示在两个节点之间的特定类型的关连或关联，这可以由节点关系或由节点中的一个节点在另一个节点上所执行的动作产生。在一些情况下，在节点之间的边可以被加权。边的权重可以表示与该边相关联的属性，例如在节点之间的关连或关联的强度。不同类型的边可以具有不同的权重。例如，当一个用户“赞(like)”另一个用户时创建的边可以被赋予一个权重，而当一个用户加另一个用户为好友(befriend)时创建的边可以被赋予不同的权重。

作为示例，当第一用户将第二用户识别为朋友时，在社交图中生成将表示第一用户的节点和表示第二用户的第二节点连接的边。当各种节点与彼此关联(relate)或交互时，社交网络系统630修改连接各种节点的边以反映关系和交互。

社交网络系统630还包括用户生成的内容，这增强了用户与社交网络系统630的交互。用户生成的内容可以包括用户可以添加、上传、发送或“发布”到社交网络系统630的任何内容。例如，用户将帖子从用户设备610传递到社交网络系统630。帖子可以包括数据(例如状态更新或其他文本数据)、定位信息、图像(例如照片)、视频、链接、音乐或其他类似数据或媒体。内容也可以由第三方添加到社交网络系统630。内容“项”被表示为在社交网络系统630中的对象。以这种方式，通过经由各种通信渠道发布各种类型的媒体的文本和内容项来鼓励社交网络系统630的用户与彼此进行通信。这种通信增加了用户与彼此的交互，并增加了用户与社交网络系统630交互的频率。

社交网络系统630包括web服务器632、API请求服务器634、用户简档储存器636、关连储存器638、动作记录器640、活动日志642和授权服务器644。在本发明的实施例中，社交网络系统630可以包括用于各种应用的附加的、更少的或不同的部件。没有示出其他部件(例如网络接口、安全机构、负载平衡器、故障转移服务器、管理和网络操作控制台等)，以便不使系统的细节模糊。

用户简档储存器636维护关于用户账户的信息，包括传记、人口统计和其他类型的描述性信息，例如工作经历、教育历史、爱好或偏好、定位以及由用户声明或由社交网络系统630推断的信息等。该信息存储在用户简档储存器636中，使得每个用户被唯一地识别。社交网络系统630还在关连储存器638中存储描述在不同用户之间的一个或更多个关连的数据。关连信息可以指示具有相似或共同的工作经历、组成员资格、爱好或教育历史的用户。另外，社交网络系统630包括用户定义的在不同用户之间的关连，允许用户指定他们与其他用户的关系。例如，用户定义的关连允许用户生成与其他用户的关系，这些关系并行于用户的真实生活关系，例如朋友、同事、伙伴等。用户可以从预定义类型的关连中进行选择，或者根据需要定义他们自己的关连类型。与社交网络系统630中的其他节点(例如非个人实体、存储桶(bucket)、集群中心、图像、兴趣、页面、外部系统、概念等)的关连也存储在关连储存器638中。

社交网络系统630维护关于对象的数据，用户可以与该对象交互。为了维护该数据，用户简档储存器636和关连储存器638存储由社交网络系统630维护的相应类型的对象的实例。每种对象类型都有适于存储适合于对象的类型的信息的信息字段。例如，用户简档储存器636包含具有适于描述用户的账户的字段和与用户的账户相关的信息的数据结构。当特定类型的新对象被创建时，社交网络系统630初始化相应类型的新数据结构，给它分配唯一的对象标识符，并开始根据需要来向对象添加数据。例如，这可能在用户成为社交网络系统630的用户时出现，社交网络系统630在用户简档储存器636中生成用户简档的新实例，给用户账户分配唯一标识符，并开始用由用户提供的信息来填充用户账户的字段。

关连储存器638包括适于描述用户到其他用户的关连、与外部系统620的关连或与其他实体的关连的数据结构。关连储存器638还可以使关连类型与用户的关连相关联，用户的关连可以结合用户的隐私设置来被使用以调节对关于用户的信息的访问。在本发明的实施例中，用户简档储存器636和关连储存器638可以被实现为联合数据库(federateddatabase)。

存储在关连储存器638、用户简档储存器636和活动日志642中的数据使社交网络系统630能够生成社交图，该社交图使用节点来识别各种对象并且使用连接节点的边来识别在不同对象之间的关系。例如，如果第一用户与社交网络系统630中的第二用户建立关连，则来自用户简档储存器636的第一用户和第二用户的用户账户可以充当社交图中的节点。由关连储存器638存储的在第一用户和第二用户之间的关连是在与第一用户和第二用户相关联的节点之间的边。继续该示例，第二用户然后可以在社交网络系统630内向第一用户发送消息。可以被存储的发送消息的动作是在社交图中的表示第一用户和第二用户的两个节点之间的另一条边。另外，消息本身可以被识别并被包括在社交图中，作为关连到表示第一用户和第二用户的节点的另一个节点。

在另一示例中，第一用户可以在由社交网络系统630维护的图像中(或者可选地，在由在社交网络系统630外部的另一系统维护的图像中)标记第二用户。图像本身可以被表示为社交网络系统630中的节点。该标记动作可以在第一用户和第二用户之间创建边，以及在每个用户和图像之间创建边，图像也是社交图中的节点。在又一示例中，如果用户确认参加事件，则用户和事件是从用户简档储存器636获得的节点，其中事件的参加是在可以从活动日志642检索的节点之间的边。通过生成并维护社交图，社交网络系统630包括描述许多不同类型的对象以及在这些对象当中的交互和关连的数据，提供了社交相关信息的丰富源。

web服务器632经由网络650来将社交网络系统630链接到一个或更多个用户设备610和/或一个或更多个外部系统620。web服务器632提供网页以及其他网络相关内容，例如Java、JavaScript、Flash、XML等。web服务器632可以包括邮件服务器或用于在社交网络系统630和一个或更多个用户设备610之间接收并按规定路线发送消息的其他消息传送功能。消息可以是即时消息、排队消息(例如，电子邮件)、文本和SMS消息或者任何其他合适的消息格式。

API请求服务器634允许一个或更多个外部系统620和用户设备610通过调用一个或更多个API函数来调用来自社交网络系统630的访问信息。API请求服务器634还可以允许外部系统620通过调用API来向社交网络系统630发送信息。在一个实施例中，外部系统620经由网络650向社交网络系统630发送API请求，并且API请求服务器634接收该API请求。API请求服务器634通过调用与API请求相关联的API来处理该请求以生成适当的响应，API请求服务器634经由网络650来将该响应传递到外部系统620。例如，响应于API请求，API请求服务器634收集与用户相关联的数据(例如已经登录到外部系统620内的用户的关连)，并将所收集的数据传递到外部系统620。在另一实施例中，用户设备610以与外部系统620相同的方式经由API来与社交网络系统630进行通信。

动作记录器640能够从web服务器632接收关于在社交网络系统630上和/或外的用户动作的通信。动作记录器640用关于用户动作的信息来填充活动日志642，使社交网络系统630能够发现由它的用户在社交网络系统630内和在社交网络系统630外采取的各种动作。特定用户相对于在社交网络系统630上的另一个节点采取的任何动作可以通过在活动日志642中或在类似数据库或其他数据仓库中维护的信息来与每个用户的账户相关联。被识别并存储的由用户在社交网络系统630内采取的动作的示例可以包括例如，添加到另一个用户的关连、向另一个用户发送消息、从另一个用户读取消息、查看与另一个用户相关联的内容、参加由另一个用户发布的事件、发布图像、尝试发布图像、或与另一个用户或另一个对象交互的其他动作。当用户在社交网络系统630内采取动作时，该动作被记录在活动日志642中。在一个实施例中，社交网络系统630将活动日志642维护为条目的数据库。当在社交网络系统630内采取动作时，该动作的条目被添加到活动日志642。活动日志642可以被称为动作日志。

此外，用户动作可以与在社交网络系统630外部的实体(例如与社交网络系统630分离的外部系统620)内出现的概念和动作相关联。例如，动作记录器640可以从web服务器632接收描述用户与外部系统620的交互的数据。在该示例中，外部系统620根据在社交图中的结构化动作和对象来报告用户的交互。

用户与外部系统620交互的动作的其他示例包括用户表达对外部系统620或另一实体的兴趣、用户将讨论外部系统620或在外部系统620内的网页622a的评论发布到社交网络系统630、用户将统一资源定位符(URL)或与外部系统620相关联的其他标识符发布到社交网络系统630、用户参加与外部系统620相关联的事件、或者由用户进行的与外部系统620相关的任何其他动作。因此，活动日志642可以包括描述在社交网络系统630的用户和与社交网络系统630分离的外部系统620之间的交互的动作。

授权服务器644实施社交网络系统630的用户的一个或更多个隐私设置。用户的隐私设置确定与用户相关联的特定信息可以如何被分享。隐私设置包括与用户相关联的特定信息的规范以及信息可以被分享的一个或更多个实体的规范。信息可以被分享的实体的示例可以包括其他用户、应用、外部系统620、或可能潜在地访问信息的任何实体。可以由用户分享的信息包括用户账户信息(例如简档照片)、与用户相关联的电话号码、用户的关连、由用户采取的动作(例如添加关连)、改变用户简档信息等。

可以以不同的粒度水平提供隐私设置规范。例如，隐私设置可以识别要与其他用户分享的特定信息；隐私设置识别工作电话号码或一组特定的相关信息(例如，包括简档照片、家庭电话号码和状态的个人信息)。可选地，隐私设置可以应用于与用户相关联的所有信息。也可以以不同的粒度水平指定可以访问特定信息的该组实体的规范。信息可以分享的不同组的实体可以包括例如，用户的所有朋友、朋友的所有朋友、所有应用、或所有外部系统620。一个实施例允许该组实体的规范包括实体的枚举。例如，用户可以提供被允许访问某些信息的外部系统620的列表。另一实施例允许规范包括一组实体以及不被允许访问信息的例外。例如，用户可以允许所有外部系统620访问用户的工作信息，但是指定不被允许访问工作信息的外部系统620的列表。某些实施例将不被允许访问某些信息的例外的列表称为“黑名单”。属于由用户指定的黑名单的外部系统620被阻止访问在隐私设置中指定的信息。信息的规范的粒度和信息被共享的实体的规范的粒度的各种组合是可能的。例如，所有个人信息可以与朋友分享，而所有工作信息可以与朋友的朋友分享。

授权服务器644包含确定与用户相关联的某些信息是否可以由用户的朋友、外部系统620和/或其他应用和实体访问的逻辑。外部系统620可能需要来自授权服务器644的授权来访问用户的更私密且敏感的信息，例如用户的工作电话号码。基于用户的隐私设置，授权服务器644确定另一用户、外部系统620、应用、或另一实体是否被允许访问与用户相关联的信息，包括关于由用户采取的动作的信息。

在一些实施例中，社交网络系统630可以包括群组视频呼叫模块646。如本文更详细讨论的，群组视频呼叫模块646例如可以被实现为群组视频呼叫模块102。如前所述，应当理解，可以有许多变化或其他可能性。例如，在一些实施例中，群组视频呼叫模块646的一个或更多个功能可以在用户设备610中实现。如前所述，应当理解，可以有许多变化或其他可能性。

硬件实现

前述过程和特征可以由各种机器和计算机系统架构以及在各种网络和计算环境中实现。图7示出了根据本发明实施例的可以用于实现本文描述的一个或更多个实施例的计算机系统700的示例。计算机系统700包括用于使计算机系统700执行本文讨论的过程和特征的指令集。计算机系统700可以连接(例如，联网)到其他机器。在联网部署中，计算机系统700可以在客户端-服务器网络环境中的服务器机器或客户端机器的能力下进行操作，或者作为在对等(peer-to-peer)(或分布式)网络环境中的对等机器来进行操作。在本发明的实施例中，计算机系统700可以是社交网络系统630、用户设备610和外部系统620、或者其部件。在本发明的实施例中，计算机系统700可以是在构成社交网络系统630的全部或部分的许多服务器当中的一个服务器。

计算机系统700包括处理器702、高速缓存704以及存储在计算机可读介质上的指向本文描述的过程和特征的一个或更多个可执行模块和驱动程序。另外，计算机系统700包括高性能输入/输出(I/O)总线706和标准I/O总线708。主桥(host bridge)710将处理器702耦合到高性能I/O总线706，而I/O总线桥712将两个总线706和708耦合到彼此。系统存储器714和一个或更多个网络接口716耦合到高性能I/O总线706。计算机系统700还可以包括视频存储器和耦合到视频存储器的显示设备(未示出)。大容量存储装置718和I/O端口720耦合到标准I/O总线708。计算机系统700可以可选地包括键盘和定点设备、显示设备、或耦合到标准I/O总线708的其他输入/输出设备(未示出)。共同地，这些元件旨在表示广泛类别的计算机硬件系统，包括但不限于基于由加利福尼亚州(California)圣克拉拉(SantaClara)的英特尔公司制造的x86兼容处理器和由加利福尼亚州森尼维尔(Sunnyvale)的超威半导体(AMD)公司制造的x86兼容处理器以及任何其他合适的处理器的计算机系统。

操作系统管理并控制计算机系统700的操作，包括往返软件应用(未示出)的数据输入和输出。操作系统提供在系统上执行的软件应用和系统的硬件部件之间的接口。可以使用任何合适的操作系统，例如LINUX操作系统、可从加利福尼亚州库比蒂诺(Cupertino)的苹果计算机公司获得Apple Macintosh操作系统、UNIX操作系统、

操作系统、BSD操作系统等。其他实现方式是可能的。

将在下面更详细地描述计算机系统700的元件。特别是，网络接口716提供在计算机系统700和各种网络(诸如以太网(例如，IEEE 802.3)网络)中的任一种、背板等之间的通信。大容量存储装置718提供数据和编程指令的永久存储，以执行由上面识别的相应计算系统实现的上述过程和特征，而系统存储器714(例如，DRAM)提供当由处理器702执行时的数据和编程指令的临时存储。I/O端口720可以是提供在可以耦合到计算机系统700的附加外围设备之间的通信的一个或更多个串行和/或并行通信端口。

计算机系统700可以包括各种系统架构，并且计算机系统700的各种部件可以被重新排列。例如，高速缓存704可以与处理器702一起在芯片上。可选地，高速缓存704和处理器702可以封装在一起作为“处理器模块”，其中处理器702被称为“处理器核心”。此外，本发明的某些实施例可以既不需要也不包括所有上述部件。例如，耦合到标准I/O总线708的外围设备可以耦合到高性能I/O总线706。此外，在一些实施例中，可以仅存在单个总线，其中计算机系统700的部件耦合到该单个总线。此外，计算机系统700可以包括附加部件，例如附加处理器、存储设备或存储器。

一般来说，本文描述的过程和特征可以被实现为操作系统或特定应用、部件、程序、对象、模块、或被称为“程序”的指令系列的一部分。例如，一个或更多个程序可以用于执行本文描述的特定过程。程序通常包括在计算机系统700中的各种存储器和存储设备中的一个或更多个指令，其当由一个或更多个处理器读取并执行时使计算机系统700执行操作以执行本文描述的过程和特征。可以在软件、固件、硬件(例如，专用集成电路)、或其任何组合中实现本文描述的过程和特征。

在一个实现方式中，本文描述的过程和特征被实现为由计算机系统700在分布式计算环境中单独或共同地运行的一系列可执行模块。前述模块可以由硬件、存储在计算机可读介质(或机器可读介质)上的可执行模块、或者两者的组合来实现。例如，模块可以包括由在硬件系统中的处理器(例如处理器702)执行的多个指令或指令系列。最初，指令系列可以存储在存储设备(例如大容量存储装置718)上。然而，指令系列可以存储在任何合适的计算机可读存储介质上。此外，指令系列不需要存储在本地，并且可以经由网络接口716从远程存储设备(例如网络上的服务器)被接收。指令从诸如大容量存储装置718的存储设备被复制到系统存储器714中，且然后由处理器702进行访问和执行。在各种实现中，一个或更多个模块可以由在一个或更多个位置上的一个或更多个处理器(例如在并行处理环境中的多个服务器)执行。

计算机可读介质的示例包括但不限于可记录类型的介质(例如易失性和非易失性存储器设备)；固态存储器；软盘和其他可移动盘；硬盘驱动器；磁性介质；光盘(例如，光盘只读存储器(CDROM)、数字通用盘(DVD))；其他类似的非暂时性(或暂时性)、有形(或非有形)存储介质；或任何类型的介质，其适于存储、编码或携带用于由计算机系统700执行的一系列指令，以执行本文描述的过程和特征中的任一个或更多个。

为了解释的目的，阐述了许多具体细节，以便提供对本描述的透彻理解。然而对于本领域中的技术人员将明显的是，可以在没有这些具体细节的情况下实践本公开的实施例。在一些实例中，以框图形式示出了模块、结构、过程、特征和设备，以便避免使本描述模糊。在其他实例中，功能框图和流程图被示出为表示数据和逻辑流。框图和流程图的部件(例如，模块、块、结构、设备、特征等)可以以不同于如在本文明确描述并描绘的方式来被不同地组合、分离、移除、重新排序和替换。

在本说明书中对“一个实施例”、“实施例”、“其他实施例”、“一系列实施例”、“一些实施例”、“各种实施例”等的提及意指关于实施例描述的特定特征、设计、结构或特性被包括在本公开的至少一个实施例中。例如，短语“在一个实施例中”或“在实施例中”在说明书中的不同地方中的出现并不一定都指同一实施例，也不是与其他实施例相互排斥的单独的或可选的实施例。此外，无论是否存在对“实施例”等的明确提及，都描述了各种特征，这些特征可以多方面地被组合并且包括在一些实施例中，但是在其他实施例中也可以多方面地被省略。类似地，描述了各种特征，其可以是对于一些实施例而不是其他实施例的优先选择或要求。

本文使用的语言主要为了可读性和教学目的而被选择，并且它可以不被选择为描写或限制创造性主题。因此，意图是本发明的范围不由该详细描述限制，而是由在基于它的申请上发布的任何权利要求进行限制。因此，本发明的实施例的公开旨在是说明性的，而不是对在所附权利要求中阐述的本发明的范围的限制。

Claims (18)

1.一种计算机实现的方法，包括：

由计算系统识别群组视频呼叫中的一组参与者，其中，每个参与者与上行链路容量和下行链路容量相关联，并且所述一组参与者包括一组发送方参与者和一组订阅方参与者；

由所述计算系统基于所述一组订阅方参与者中的一个或更多个订阅方参与者的下行链路容量，为所述一组发送方参与者中的每个发送方参与者迭代地确定将由所述发送方参与者上传的一个或更多个视频流层；其中

为所述一组发送方参与者中的每个发送方参与者迭代地确定将由所述发送方参与者上传的一个或更多个视频流层包括：按基于排名的顺序迭代地处理每个发送方参与者；和

对于所述一个或更多个订阅方参与者中的每个订阅方参与者，由所述计算系统分配所述订阅方参与者接收将由所述一组发送方参与者中的至少一个发送方参与者上传的所述一个或更多个视频流层中的至少一个视频流层。

2.根据权利要求1所述的计算机实现的方法，其中，将由第一发送方参与者上传的所述一个或更多个视频流层是基于订阅所述第一发送方参与者的订阅方参与者的下行链路容量来确定的。

3.根据权利要求1所述的计算机实现的方法，其中，每个订阅方参与者订阅至少一个发送方参与者。

4.根据权利要求1所述的计算机实现的方法，其中，将由第一发送方参与者上传的每个视频流层与比特率相关联。

5.根据权利要求4所述的计算机实现的方法，还包括基于订阅所述第一发送方参与者的订阅方参与者的下行链路容量和与所述第一发送方参与者相关联的上行链路容量，确定将由所述第一发送方参与者上传的每个视频流层的比特率。

6.根据权利要求1所述的计算机实现的方法，还包括基于上行链路容量对所述一组发送方参与者进行排名。

7.根据权利要求1所述的计算机实现的方法，其中：

迭代地处理每个发送方参与者包括多次迭代，每次迭代与所述一组发送方参与者中的特定发送方参与者相关联，并且

每次迭代包括迭代地处理订阅了与所述迭代相关联的所述特定发送方参与者的每个订阅方参与者。

8.根据权利要求7所述的计算机实现的方法，其中，迭代地处理订阅了所述特定发送方参与者的每个订阅方参与者包括：

为每个订阅方参与者确定是否创建将由所述特定发送方参与者上传的新层，或者将所述订阅方参与者分配给与所述特定发送方参与者相关联的先前创建的层。

9.一种系统，包括：

至少一个处理器；和

存储指令的存储器，所述指令在被所述至少一个处理器执行时，使得所述系统执行一种方法，所述方法包括：

识别群组视频呼叫中的一组参与者，其中，每个参与者与上行链路容量和下行链路容量相关联，并且所述一组参与者包括一组发送方参与者和一组订阅方参与者；

基于所述一组订阅方参与者中的一个或更多个订阅方参与者的下行链路容量，为所述一组发送方参与者中的每个发送方参与者迭代地确定将由所述发送方参与者上传的一个或更多个视频流层；其中

为所述一组发送方参与者中的每个发送方参与者迭代地确定将由所述发送方参与者上传的一个或更多个视频流层包括：按基于排名的顺序迭代地处理每个发送方参与者；和

对于所述一个或更多个订阅方参与者中的每个订阅方参与者，分配所述订阅方参与者接收将由所述一组发送方参与者中的至少一个发送方参与者上传的至少一个视频流层。

10.根据权利要求9所述的系统，其中，将由第一发送方参与者上传的所述一个或更多个视频流层是基于订阅所述第一发送方参与者的订阅方参与者的下行链路容量来确定的。

11.根据权利要求9所述的系统，其中，每个订阅方参与者订阅至少一个发送方参与者。

12.根据权利要求9所述的系统，其中，将由第一发送方参与者上传的每个视频流层与比特率相关联。

13.根据权利要求12所述的系统，其中，所述指令在被所述至少一个处理器执行时还使得所述系统执行：基于订阅所述第一发送方参与者的订阅方参与者的下行链路容量和与所述第一发送方参与者相关联的上行链路容量，确定将由所述第一发送方参与者上传的每个视频流层的比特率。

14.一种包括指令的非暂时性计算机可读存储介质，当由计算系统的至少一个处理器执行时，所述指令使得所述计算系统执行一种方法，所述方法包括：

识别群组视频呼叫中的一组参与者，其中，每个参与者与上行链路容量和下行链路容量相关联，并且所述一组参与者包括一组发送方参与者和一组订阅方参与者；

基于所述一组订阅方参与者中的一个或更多个订阅方参与者的下行链路容量，为所述一组发送方参与者中的每个发送方参与者迭代地确定将由所述发送方参与者上传的一个或更多个视频流层；其中

为所述一组发送方参与者中的每个发送方参与者迭代地确定将由所述发送方参与者上传的一个或更多个视频流层包括：按基于排名的顺序迭代地处理每个发送方参与者；和

对于所述一个或更多个订阅方参与者中的每个订阅方参与者，分配所述订阅方参与者接收将由所述一组参与者中的至少一个发送方参与者上传的所述一个或更多个视频流层中的至少一个视频流层。

15.根据权利要求14所述的非暂时性计算机可读存储介质，其中，将由第一发送方参与者上传的所述一个或更多个视频流层是基于订阅所述第一发送方参与者的订阅方参与者的下行链路容量来确定的。

16.根据权利要求14所述的非暂时性计算机可读存储介质，其中，每个订阅方参与者订阅至少一个发送方参与者。

17.根据权利要求14所述的非暂时性计算机可读存储介质，其中，将由第一发送方参与者上传的每个视频流层与比特率相关联。

18.根据权利要求17所述的非暂时性计算机可读存储介质，其中，当由计算系统的至少一个处理器执行时，所述指令还使得所述计算系统执行：基于订阅所述第一发送方参与者的订阅方参与者的下行链路容量和与所述第一发送方参与者相关联的上行链路容量，确定将由所述第一发送方参与者上传的每个视频流层的比特率。

Images