用于广播直播媒体流的系统和方法与流程

相关申请的交叉引用

本申请要求于2017年10月19日提交的美国临时专利申请no.62/574,662的优先权，其全部内容通过引用合并于此。

以下总体上涉及流媒体的传输、处理和分发，并且更具体地涉及用于广播直播媒体流的系统和方法。

背景技术：

传统上，诸如电视新闻和体育赛事报道的直播、专业质量的节目的制作仅是可以访问和控制昂贵的演播室设备、演播室空间和训练有素的人员的复杂媒体组织的领域。

近来，诸如视频和音频的用户生成的媒体内容变得非常流行。这是由用户对利用现代便携式用户设备的高质量视频和音频捕获能力、高速网络的泛在性、日益可靠的通信基础设施带来的优势以及用户可以浏览并提供内容的诸如youtube、twitch、periscope和facebooklive的新媒体平台的可用性的兴趣所致。

随着用户生成的内容越来越受欢迎，传统的媒体制作人通常已经接受了新媒体平台，以用作他们正在制作的直播内容可以广播到的替代或附加频道。这也引起了许多消费者对新媒体平台的兴趣，因为他们能够使用也提供通常不太正式的用户生成内容的相同媒体平台来消费专业制作的及时内容。

当今的用户可以通过其设备、网络和媒体消费平台来访问各种直播媒体流特征和功能。但是，对于个人用户而言，在不能访问大型媒体组织可用的昂贵设备、工作室网络和操作人员的情况下，生成期望的且功能强大的专业级直播节目仍然是困难且昂贵的。同时，可能有兴趣扩展其操作以适应即时制作或其他临时制作以便报道新出现的事件或从广泛传播的事件中收集贡献以便获得特定世界事件的“基本真相”的这类大型媒体组织也体验到他们自身的基础设施限制。尤其是，此类组织的固定设备、工作室空间和人员，发现这些资产只能扩展到目前为止。

已经出现了各种技术来增强用户生成复杂的直播媒体内容的能力。例如，卡尔曼森(kalmanson)等的美国专利申请公开no.2018/0063556公开了用于在直播流视频平台上提供访客广播的系统和方法，以便个人用户可以将其他用户的视频流合并到广播中。此外，可以使用各种视频聊天服务和相关应用。但是，当前可用的服务、应用、系统和方法并不旨在为用户——专业操作者和随意操作者——提供对专业质量的直播制作工具的随时访问，这些专业质量的直播制作工具易于部署和控制并且整合源自各种用户的设备的直播媒体以便处理广播质量的直播媒体流到各种平台的摄入、混合和分发。

技术实现要素：

根据一个方面，提供了一种用于直播媒体广播的基于网络的系统，包括：服务器系统，该服务器系统包括处理结构，该处理结构被配置为：部署可在请求客户端计算设备上执行的处理器可执行程序代码，以向请求客户端计算设备提供基于浏览器的混合用户界面，以使用由请求客户端计算设备从服务器系统接收到的至少一个媒体流，在浏览器中进行选择性混合，以生成混合视频流和至少一个相关联的音频流；处理结构进一步被配置为：从其他客户端计算设备接收一个或多个直播媒体流；通过至少一个直播流媒体连接，将来自一个或多个直播媒体流的媒体数据流传输到请求客户端计算设备；以及从请求客户端计算设备接收混合视频流和至少一个相关联的音频流。

在一个实施例中，服务器系统处理结构被配置为：通过至少一个web实时通信(webrtc)连接，将来自一个或多个所接收的直播媒体流的媒体数据流传输到请求客户端计算设备。

在一个实施例中，服务器系统处理结构被配置为：通过至少一个webrtc连接，来接收混合视频流和至少一个相关联的音频流。

在一个实施例中，服务器系统处理结构被进一步配置为：处理混合视频流和至少一个相关联的音频流中的一个，以形成用于广播的至少一个的基于实时消息传输协议(基于rtmp)的媒体流。

在一个实施例中，服务器系统处理结构被进一步配置为：处理混合视频流和至少一个相关联的音频流中的一个，以形成用于广播的至少一个基于http直播流(基于hls)的媒体流。

在一个实施例中，服务器系统处理结构被进一步配置为：处理混合视频流和至少一个相关联的音频流中的一个，以形成用于广播的至少一个基于超光速(ftl)的媒体流。

在一个实施例中，服务器系统处理结构被进一步配置为：处理混合视频流和至少一个相关联的音频流中的一个，以形成用于广播的至少一个媒体流，其中，用于广播的至少一个媒体流选自由以下各项组成的组：至少一个基于webrtc的媒体流、至少一个对等媒体流和至少一个直播分块媒体流。

在一个实施例中，所接收的一个或多个直播媒体流包括：至少一个直播媒体流，该至少一个直播媒体流通过webrtc连接从另一个客户端计算设备被流传输到服务器系统。

在一个实施例中，所接收的一个或多个直播媒体流包括：至少一个直播媒体流，该至少一个直播媒体流通过webrtc连接使用dtls-srtp(数据报传输层安全性-安全实时传输协议)从另一个客户端计算设备被流传输到服务器系统。

在一个实施例中，所接收的一个或多个直播媒体流包括：至少一个直播非webrtc媒体流，其中，服务器系统处理结构被配置为：摄取至少一个直播非webrtc媒体流；对至少一个直播非webrtc媒体流进行转码以生成webrtc兼容的媒体流；使用实时流传输协议(rtsp)将webrtc兼容的媒体流发布到服务器系统的webrtc网关；以及使用服务器系统的webrtc网关，通过相应的webrtc连接将webrtc兼容的媒体流流传输到请求客户端计算设备，以使用请求客户端计算设备进行选择性混合。

在一个实施例中，至少一个直播非webrtc媒体流是实时消息传输协议(rtmp)媒体流。

在一个实施例中，至少一个直播非webrtc媒体流是http直播流(hls)媒体流。

在一个实施例中，至少一个直播非webrtc媒体流是ftl(超光速)媒体流。

在一个实施例中，服务器系统处理结构被进一步配置为：将混合视频流流传输到其他客户端设备中的一个或多个客户端设备；以及将至少一个定制混合音频流中的每一个定制混合音频流流传输到其他客户端设备中的相应客户端设备。

在一个实施例中，基于浏览器的混合用户界面包括：阵容区域，该阵容区域用于显示正在由请求客户端计算设备从服务器系统接收的一个或多个媒体流中的每一个媒体流的至少表示；和场景区域，该场景区域用于显示在阵容区域中表示的媒体流中的至少一个或多个媒体流的所选择的混合。

在一个实施例中，阵容区域进一步用于显示在请求客户端计算设备本地生成或正在由请求客户端计算设备从另一个计算设备接收的一个或多个附加媒体流的表示。

在一个实施例中，基于浏览器的混合用户界面包括：布局选择器，该布局选择器用于从多个可选择布局中选择用于所选择的混合的布局。

在一个实施例中，基于浏览器的混合用户界面包括：媒体池区域，该媒体池区域用于显示一个或多个可选择的图像、视频文件和音频文件中的每一个的表示，该一个或多个可选择的图像、视频文件和音频文件可用于包括在所选择的混合中。

在一个实施例中，基于浏览器的混合用户界面包括：持久音频区域，该持久音频区域用于显示从媒体池区域中选择的一个或多个所选择的视频文件和音频文件中的每一个的表示，以作为持久音频包括在所选择的混合中。

在一个实施例中，基于浏览器的混合用户界面包括：视频叠加区域，该视频叠加区域用于显示从媒体池区域中选择的一个或多个所选择的视频和图像文件中的每一个的表示，以作为视频包括在所选择的混合中。

在一个实施例中，基于浏览器的混合用户界面包括：馈送池区域，该馈送池区域用于显示一个或多个附加媒体流中的每一个的可选择表示，该一个或多个附加媒体流可从服务器系统被流传输到请求客户端计算设备。

在一个实施例中，在馈送池区域中显示的可选择表示包括文本。

在一个实施例中，服务器系统处理结构被配置为：从一个或多个附加媒体流中的每一个附加媒体流中提取静止图像；并将每个静止图像传输到请求客户端计算设备，以作为可选择表示的至少一部分显示在馈送池区域中。

在一个实施例中，服务器系统处理结构被进一步配置为：部署可在其他客户端计算设备上执行的处理器可执行程序代码，以向其他客户端计算设备提供基于浏览器的参与者界面，以分别呈现至少准备就绪的视频流和相应的准备就绪的定制音频流。

根据另一方面，提供了一种非暂时性计算机可读介质，该非暂时性计算机可读介质体现了可在服务器系统上执行的用于直播媒体广播的计算机程序，该计算机程序包括：用于执行下述操作的计算机程序代码：部署可在请求客户端计算设备上执行的处理器可执行程序代码，以向请求客户端计算设备提供基于浏览器的混合用户界面，以使用由请求客户端计算设备从服务器系统接收到的至少一个媒体流，在浏览器中进行选择性混合，以生成混合视频流和至少一个相关联的音频流；用于从其他客户端计算设备接收一个或多个直播媒体流的计算机程序代码；用于通过至少一个直播流媒体连接将来自一个或多个直播媒体流的媒体数据流传输到请求客户端计算设备的计算机程序代码；以及用于从请求客户端计算设备接收混合视频流和至少一个相关联的音频流的计算机程序代码。

根据另一方面，提供了一种由服务器系统实施的用于直播媒体广播的方法，该方法包括：部署可在请求客户端计算设备上执行的处理器可执行程序代码，以向请求客户端计算设备提供基于浏览器的混合用户界面，以使用由请求客户端计算设备从服务器系统接收到的至少一个媒体流，在浏览器中进行选择性混合，以生成混合视频流和至少一个相关联的音频流；从其他客户端计算设备接收一个或多个直播媒体流；通过至少一个直播流媒体连接将来自一个或多个直播媒体流的媒体数据流传输到请求客户端计算设备；以及从请求客户端计算设备接收混合视频流和至少一个相关联的音频流。

根据另一方面，提供了一种用于直播媒体广播的基于网络的系统，包括：服务器系统，该服务器系统包括处理结构，该处理结构被配置为：接收至少一个直播非webrtc媒体流；摄取至少一个直播非webrtc媒体流；对至少一个直播非webrtc媒体流进行转码，以生成webrtc兼容的媒体流；使用实时流传输协议(rtsp)将webrtc兼容的媒体流发布到服务器系统的webrtc网关；以及使用服务器系统的webrtc网关，通过相应的webrtc连接将webrtc兼容的媒体流流传输到请求客户端计算设备，以使用请求客户端计算设备进行选择性混合。

在一个实施例中，服务器系统处理结构被配置为：对至少一个直播非webrtc媒体流进行转码以生成webrtc兼容的媒体流，包括降低至少一个直播非webrtc媒体流的视频分量的分辨率。

在一个实施例中，服务器系统处理结构被配置为：对至少一个直播非webrtc媒体流进行转码以生成与webrtc兼容的媒体流，包括对至少一个直播非webrtc媒体流的至少音频分量进行解码，以使用webrtc兼容的音频格式进行重新编码。

在一个实施例中，webrtc兼容的媒体流是基于rtp的媒体流。

在一个实施例中，基于rtp的媒体流的分组的分组大小小于或等于1472个字节。

在一个实施例中，基于rtp的媒体流的分组的分组大小为1200个字节。

在一个实施例中，服务器系统处理结构被配置为：从请求客户端计算设备接收混合视频流和至少一个相关联的音频流；使用rtsp将混合视频流和至少一个相关联的音频流播放到服务器系统中的至少一个重新流化器进程；使混合视频流和至少一个相关联的音频流正使用rtsp被播放到的至少一个重新流化器进程中的每一个重新流化器进程基于混合视频流和至少一个相关联的音频流生成至少一个广播媒体流。

在一个实施例中，至少一个重新流化器进程中的每一个重新流化器进程与相应的目的地计算系统相关联，其中，服务器系统处理结构被配置为：将每个广播媒体流传输到相应的目的地计算系统以进行广播。

在一个实施例中，至少一个广播流包括至少一个基于实时消息传输协议(rtmp)的广播流。

在一个实施例中，至少一个广播流包括至少一个基于http直播流(基于hls)的广播流。

在一个实施例中，至少一个广播流包括至少一个基于超光速(基于ftl)的广播流。

在一个实施例中，所述至少一个广播流包括选自由以下各项组成的组的至少一个广播流：基于webrtc的媒体流、对等媒体流和直播分块媒体流。

根据另一方面，提供了一种非暂时性计算机可读介质，该非暂时性计算机可读介质体现了可在服务器系统上执行的用于直播媒体广播的计算机程序，该计算机程序包括：用于接收至少一个直播非webrtc媒体流的计算机程序代码；用于摄取至少一个直播非webrtc媒体流的计算机程序代码；用于对至少一个直播非webrtc媒体流进行转码以生成webrtc兼容的媒体流的计算机程序代码；用于使用实时流传输协议(rtsp)将webrtc兼容的媒体流发布到服务器系统的webrtc网关的计算机程序代码；以及用于下述操作的计算机程序代码：使用服务器系统的webrtc网关，通过相应的webrtc连接将webrtc兼容的媒体流流传输到请求客户端计算设备，以使用请求客户端计算设备进行选择性混合。

根据另一方面，提供了一种由服务器系统实施的用于直播媒体广播的方法，该方法包括：接收至少一个直播非webrtc媒体流；摄取至少一个直播非webrtc媒体流；对至少一个直播非webrtc媒体流进行转码，以生成webrtc兼容的媒体流；使用实时流传输协议(rtsp)将webrtc兼容的媒体流发布到服务器系统的webrtc网关；以及使用服务器系统的webrtc网关，通过相应的webrtc连接将webrtc兼容的媒体流流传输到请求客户端计算设备，以使用请求客户端计算设备进行选择性混合。

根据另一方面，提供了一种用于直播媒体广播的基于浏览器的混合器，包括：计算设备，该计算设备包括处理结构，该处理结构被配置为：通过网络从服务器系统接收至少一个直播视频流；生成基于浏览器的混合用户界面，以使用所接收的至少一个直播视频流进行选择性混合；基于选择性混合，在浏览器内生成至少混合视频流；并将混合视频流和相关联的至少一个音频流流传输到服务器系统。

在一个实施例中，通过网络接收到的至少一个直播视频流通过web实时通信(webrtc)连接被流传输到计算设备。

在一个实施例中，通过web实时通信(webrtc)连接从计算设备对混合视频流和关联的至少一个音频流进行流传输。

在一个实施例中，至少一个音频流包括主混合音频流和至少一个定制混合音频流。

在一个实施例中，基于浏览器的混合用户界面包括：阵容区域，该阵容区域用于显示正在由计算设备从服务器系统接收的一个或多个视频流中的每一个视频流的至少表示；和场景区域，该场景区域用于显示在阵容区域中表示的视频流中的至少一个或多个视频流的所选择的混合。

在一个实施例中，阵容区域进一步用于显示在计算设备本地生成的或正在由计算设备从另一个计算设备接收的一个或多个附加媒体流的表示。

在一个实施例中，基于浏览器的混合用户界面包括：布局选择器，该布局选择器用于从多个可选择布局中选择用于所选择的混合的布局。

在一个实施例中，基于浏览器的混合用户界面包括：媒体池区域，该媒体池区域用于显示一个或多个可选择的图像、视频文件和音频文件中的每一个的表示，该一个或多个可选择的图像、视频文件和音频文件可用于包括在所选择的混合中。

在一个实施例中，基于浏览器的混合用户界面包括：持久音频区域，该持久音频区域用于显示从媒体池区域中选择的一个或多个所选择的视频文件和音频文件中的每一个的表示，以作为持久音频包括在所选择的混合中。

在一个实施例中，基于浏览器的混合用户界面包括：视频叠加区域，该视频叠加区域用于显示从媒体池区域选择的一个或多个所选择的视频和图像文件中的每一个的表示，以作为视频包括在所选择的混合中。

在一个实施例中，基于浏览器的混合用户界面包括：馈送池区域，该馈送池区域用于显示一个或多个附加媒体流中的每一个附加媒体流的可选择表示，该一个或多个附加媒体流可从服务器系统被流传输到计算设备。

在一个实施例中，在馈送池区域中显示的可选择表示包括文本。

在一个实施例中，服务器系统处理结构被配置为：从一个或多个附加媒体流的每一个附加媒体流中提取静止图像；并将每个静止图像传输到计算设备以作为可选择表示的至少一部分显示在馈送池区域中。

在一个实施例中，计算设备处理结构被进一步配置为：在叠加图像缓冲区中存储从所选择的一个或多个视频和图像文件中提取的图像数据；在主图像缓冲区中存储用于选择性混合的至少一个视频流的连续帧；以及通过依次组合叠加图像缓冲区中的内容和主图像缓冲区中的内容来生成混合视频流的帧。

根据另一方面，提供了一种非暂时性计算机可读介质，该非暂时性计算机可读介质体现了可在计算系统上执行的计算机程序，以将计算系统提供为基于浏览器的混合器以进行直播媒体广播，该计算机程序包括：用于通过网络从服务器系统接收至少一个直播视频流的计算机程序代码；用于生成基于浏览器的混合用户界面以使用所接收的至少一个直播视频流进行选择性混合的计算机程序代码；用于基于选择性混合在浏览器内生成至少混合视频流的计算机程序代码；以及用于将混合视频流和相关联的至少一个音频流流传输到服务器系统的计算机程序代码。

根据另一方面，提供了一种计算机实现的用于直播媒体广播的基于浏览器的混合的方法，该方法包括：通过网络从服务器系统接收至少一个直播视频流；生成基于浏览器的混合用户界面，以使用所接收的至少一个直播视频流进行选择性混合；基于选择性混合，在浏览器内生成至少混合视频流；将混合视频流和相关联的至少一个音频流流传输到服务器系统。

附图说明

现在将参考附图描述本发明的实施例，其中：

图1是示出根据实施例的直播媒体流传输系统的示意图；

图2是示出根据实施例的适合用作图1的直播媒体流传输系统的一个或多个组件的硬件平台的计算系统的硬件架构的示意图；

图3是示出根据实施例的图1的直播媒体流传输系统的软件组件架构的框图；

图4是示出根据实施例的图1的直播媒体流传输系统的媒体流架构的框图；

图5描绘了根据实施例的在导演(director)计算设备的web浏览器内显示的基于浏览器的导演用户界面；

图6描绘了在广播之前正在由导演建立视频混合时的基于浏览器的导演；

图7描绘了图5的基于浏览器的用户界面，其中视频混合已由导演建立并且因此正准备与音频一起广播；

图8描绘了处于不同状态的特别是最近已经选择了“上线”控件的图7的基于浏览器的导演用户界面；

图9描绘了根据实施例的诸如将被显示在膝上型计算设备或台式计算设备的显示屏上的用于参与者计算设备的基于浏览器的参与者用户界面；

图10描绘了根据实施例的诸如将被显示在平板计算设备的显示屏上的用于参与者计算设备的可替选的基于浏览器的参与者用户界面；

图11描绘了根据实施例的诸如将被显示在诸如基于ios的设备的智能电话计算设备的显示屏上的用于参与者计算设备的基于应用的用户界面；

图12描绘了处于不同状态的图8的基于浏览器的导演用户界面；

图13描绘了处于不同状态的图12的基于浏览器的导演用户界面；和

图14描绘了处于不同状态的特别是最近已经选择了“上线”控件的图13的基于浏览器的导演用户界面。

具体实施方式

图1是示出根据实施例的直播媒体流传输系统10的示意图。在该实施例中，直播媒体流传输系统10包括经由网络与服务器系统200通信的多个参与者计算设备100，以及也经由网络与服务器系统200通信的多个导演计算设备300。直播媒体流传输系统10的服务器系统200根据平台提供商建立的各个方案，经由网络与在各个平台提供商控制下的多个目的地计算系统400接合。

直播媒体流传输系统10可操作为使操作导演计算设备300中的一个导演计算设备的导演能够产生高质量的直播广播，该直播广播包含由他的或她的导演计算设备300和一个或多个参与者计算设备100经由服务器系统200提供的流传输内容，以近实时地分发给目的地计算系统400并由目的地计算系统400分发给观看者。

在该实施例中，参与者计算设备100可以是能够生成和接收音频和/或视频内容并且能够使用rtp(实时传输协议)和/或一些其他的适合于流传输音频和/或视频媒体的实时通信(rtc)机制向服务器系统200流传输这样的内容以及从服务器系统200流传输这样的内容的任何计算设备，诸如台式计算机、智能电话、膝上型计算机、平板计算机，或另一其他合适的计算设备。rtp特别是可用于处理ip网络上的音频和视频流的传输的网络协议。部署rtp的流通过用户数据报协议(udp)传输，该用户数据报协议(udp)是用于在ip网络中以称为数据报的分组发送内容的更基本的协议中的一种协议。可以使用对应的rtsp(实时流传输协议)协议提供对使用rtp部署的媒体的流传输的控制，从而使接收设备或进程能够播放或暂停传入的流。

参与者计算设备100可以支持web浏览器，该web浏览器能够通过集成特定应用程序编程接口(api)，通过web浏览器提供对rtc功能的访问。这种访问rtc功能的格式通常称为webrtc。支持webrtc的此类参与者计算设备100的示例包括支持google的chromeweb浏览器等的各种计算设备。

在此实施例中，参与者计算设备100可以可替选地是能够生成和接收音频和/或视频内容并且由于仅支持不支持webrtc的web浏览器而被配置成支持自身被配置为实现rtp的非浏览器应用的操作的任何计算设备。此类参与者计算设备100的示例是那些可以被提供有被配置为支持rtp的非浏览器应用(或“应用”)的计算设备，包括被配置为运行在其上web浏览器safari(在撰写本文时)不支持webrtc功能的ios(苹果移动设备操作系统)的计算系统。

此外，在该实施例中，参与者计算设备100可以可替选地是能够至少生成音频和/或视频内容并且能够使用rtmp(实时消息传输协议)将这种内容流传输到服务器系统200的任何计算设备。此类计算设备可以是那些被配置为能够使用obs(开放广播软件)、xsplit、livestream等产生音频和/或视频内容并且能够使用rtmp、网络摄像机系统等来流传输此类内容的传统演播室和表演者系统的计算设备。一般来说，rtmp是用于流传输音频、视频和其他数据的基于tcp(传输控制协议)的消息传输协议，并且其被定向为通过客户端和服务器之间的协商消息传输来平稳地且可靠地传递内容。rtmp通常不用于从诸如智能电话的移动设备传输内容，因为专注于移动设备的应用开发人员已倾向于选择部署更易于使用和更具有安全性的基于rtp的设置。但是，包括具有网络功能的摄像机系统和用于控制它们的个人计算设备的专业演播室系统仍通常使用具有其自身优势的obs和其他传统系统，并且因此也取决于正在产生的流媒体的基于rtmp的传输的传统可靠性。

如将在下面进一步详细描述的，系统10能够支持并完全集成来自各种不同的参与计算设备100的webrtc传输的流媒体和rtmp传输的流媒体。这使得系统10能够被更广泛地部署为在媒体广播期间从参与者/表演者摄取更广泛的内容。例如，媒体广播可以被配置为通过同时集成来自参与者的计算设备100的直播流而包括多个参与者之间的直播对话，每个参与者的计算设备100位于各自的地理位置，而不必在每个位置都具有摄像机操作员并且无需参与者前往专业运营的演播室。此外，如将要描述的那样，系统10可以由演播室操作员有效地部署，而不会占用演播室空间，同时以高质量、高灵活性和以合理的成本将其产生专业级内容的能力扩展到其实体能力之外。此外，集成能力强大，以使节目制作人借鉴，操纵、组合和部署来自众多参与者和内容源的内容，以便产生出最具创意、信息量和效果的节目。

在该实施例中，服务器系统200是在基于云的配置或更固定位置的配置内作为虚拟机或物理机操作的一个或多个单独服务器。

在该实施例中，导演计算设备300可以是能够生成和接收音频和/或视频内容，并且能够使用诸如webrtc的rtc向服务器系统200和从服务器系统200流传输此类内容，并且能够处理到服务器系统200和从服务器系统的多个音频和/或视频的处理、操纵和传输的任何计算设备。适当的导演计算设备的示例是具有足够的处理能力、存储和操作存储器以处理多个媒体流而不会过度降低下游正在生产和传输的质量的那些导演计算设备，诸如配备适当的台式计算机或膝上型计算机。在该实施例中，导演计算设备300支持能够支持诸如谷歌的chrome网页浏览器的webrtc的网络浏览器的操作。

在该实施例中，服务器系统200可以与其接合的目的地计算系统400包括社交网络和其他直播广播计算系统，每个直播广播计算系统包括计算设备的相应个体或网络，并提供用于通过rtmp接收和处理直播媒体流的接口。在该实施例中，所示的特定目的地计算系统400是facebooklive、twitch、youtubelive和periscope。众所周知，facebooklive(https://live.fb.com)是社交网络提供商facebook提供的用于使直播能够流传输到社交网络上的时间线的平台。twitch(https://www.twitch.tv/)是主要面向以视频游戏及其玩家为特色的直播媒体流的广播以及针对粉丝和玩家等的对话线程的处理的平台。youtubelive(https://www.youtube.com)是还用于诸如访谈、纪录片等的直播媒体流的广播的平台。periscope(https://www.pscp.tv)是主要面向公开共享从移动设备捕获的直播媒体流以供访问该站点的用户使用的平台。为了可靠地处理，这些目的地计算系统400传统上要求诸如系统10的内容提供商使用rtmp传输其直播媒体流。

图2是示出计算系统1000的硬件架构的示意图。计算系统1000适合作为用于任何单独的计算设备100、服务器系统200中的任何单独的服务器以及任何单独的导演计算设备300的硬件平台。计算系统1000也可能适合作为单个目的地计算系统400的硬件平台，但是应该理解，由于出于本描述的目的，由于存在用于与单个目的地计算系统400进行接合的明确定义的架构，因此，任何目的地计算系统400的特定底层硬件架构在本说明书的范围之外。

特定的计算系统1000可以特别地配置有软件应用和硬件组件，以使用户能够创作、编辑和播放诸如数字音频和视频的媒体，以及能够根据各种所选择的参数，将媒体从各种格式编码、解码和/或转码以及编码、解码和/或转码成各种格式，该各种格式诸如mp4、avi、mov、webm、h.264、h.265、vp8、vp9、opus、mp3等，从而如特定应用、媒体播放器或平台所期望的，对数字音频和视频进行压缩、解压缩、查看和/或操纵。计算系统1000还可被配置为使作者或编辑者能够形成特定数字视频的多个副本，每个副本以各自的比特率被编码，以促进将相同的数字视频流传输至各种下游用户，这些下游用户可能具有不同或随时间变化能力，以通过自适应比特率流对数字视频进行流传输。

计算系统1000包括用于传送信息的总线1010或其他通信机制，以及与总线1010耦合以处理信息的处理器1018。计算系统1000还包括耦合到总线1010以存储要由处理器1018执行的信息和指令的主存储器1004，该主存储器1004诸如随机存取存储器(ram)或其他动态存储设备(例如，动态ram(dram)、静态ram(sram)和同步dram(sdram))。此外，主存储器1004可以用于在处理器1018执行指令期间存储临时变量或其他中间信息。处理器1018可以包括用于在指令执行期间存储此类临时变量或其他中间信息的诸如寄存器的存储器结构。计算系统1000进一步包括耦合到总线1010以存储用于处理器1018的静态信息和指令的只读存储器(rom)1006或其他静态存储设备(例如，可编程rom(prom)、可擦除prom(eprom)和电可擦除prom(eeprom))。

计算系统1000还包括耦合到总线1010的磁盘控制器1008，以控制一个或多个用于存储信息和指令的存储设备，该存储设备诸如磁硬盘1022和/或固态驱动器(ssd)和/或闪存驱动器以及可移除介质驱动器1024(例如，诸如usb钥匙或外部硬盘驱动器的固态驱动器、软盘驱动器、只读光盘驱动器、读/写光盘驱动器、光盘自动点唱机、磁带驱动器和可移除磁光驱动器)。可以使用适当的设备接口(例如，串行ata(sata)、外围组件互连(pci)、小型计算系统接口(scsi)、集成设备电子器件(ide)、增强型ide(e-ide)、直接存储器访问(dma)、超dma以及基于云的设备接口)将存储设备添加到计算系统1000。

计算系统1000还可包括专用逻辑设备(例如，专用集成电路(asic))或可配置逻辑设备(例如，简单可编程逻辑设备(spld)、复杂可编程逻辑设备(cpld)和现场可编程逻辑门阵列(fpga))。

计算系统1000还包括耦合到总线1010的显示控制器1002，以控制显示器1012，诸如led(发光二极管)屏幕、有机led(oled)屏幕、液晶显示器(lcd)屏幕或适合于向计算机用户显示信息的某些其他设备。在实施例中，显示控制器1002结合了用于主要处理图形密集的或其他高度并行的操作的专用图形处理单元(gpu)。这样的操作可以包括通过对包括诸如球体和立方体的多边形的线框对象施加纹理、阴影等来进行渲染，从而以计算系统1000的整体性能为代价减轻处理器1018必须进行这种密集的操作。gpu可以结合专用图形存储器，用于存储在其操作期间生成的数据，并且包括帧缓冲ram存储器，用于将处理结果存储为位图以激活显示器1012的像素。使用诸如opengl、direct3d等的图形定向的应用编程接口(api)，可以由在计算系统1000上运行的应用来指示gpu进行各种操作。

计算系统1000包括输入设备，诸如键盘1014和定点设备1016，用于与计算机用户进行交互并向处理器1018提供信息。定点设备1016例如可以是鼠标、轨迹球或指点杆，用于将方向信息和命令选择传送给处理器1018并控制显示器1012上的光标移动。计算系统1000可以采用与输入设备耦合的显示设备，诸如触摸屏。可以采用其他输入设备，诸如经由有线或无线地向计算系统提供数据的那些输入设备，诸如包括红外检测器、陀螺仪、加速度计、雷达/声纳等的手势检测器。打印机可以提供由计算系统1000存储和/或生成的数据的打印清单。

计算系统1000响应于显示控制器1002的处理器1018和/或gpu执行包含在存储器(诸如，主存储器)中的一个或多个指令的一个或多个序列而执行本文中讨论的部分或全部处理步骤。这样的指令可以从诸如硬盘1022或可移除介质驱动器1024的另一个处理器可读介质读入主存储器1004中。还可以采用在具有中央处理单元和一个或多个图形处理单元的诸如计算机系统1000的多处理装置中的一个或多个处理器，以执行包含在主存储器1004或gpu的专用图形存储器中的指令序列。在替代实施例中，可以使用硬连线电路代替软件指令或与软件指令结合使用。

如上所述，计算系统1000包括至少一个处理器可读介质或存储器，用于保存根据本发明的教导编程的指令并且用于包含本文所述的数据结构、表、记录或其他数据的存储器。处理器可读介质的示例包括固态设备(ssd)、基于闪存的驱动器、光盘、硬盘、软盘、磁带、磁光盘，prom(eprom、eeprom、闪存eprom)、dram、sram、sdram或任何其他磁性介质、光盘(例如，cd-rom)或任何其他光学介质、打孔卡、纸带或其他带有孔图案的物理介质、载波(如下所述)或计算机可以从中读取的任何其他介质。

存储在处理器可读介质中的任一个或组合上的是用于控制计算系统1000、用于驱动一个或多个设备以执行本文中讨论的功能以及用于使计算系统1000能够与人类用户交互(例如，用于控制音频和视频以及其他媒体的直播流的混合)的软件。此类软件可以包括但不限于设备驱动程序、操作系统、开发工具和应用软件。这样的处理器可读介质进一步包括用于执行本文所讨论的所执行的处理的全部或部分(如果处理是分布式的)的计算机程序产品。

本文讨论的计算机代码设备可以是任何可解释或可执行的代码机制，包括但不限于脚本、可解释程序、动态链接库(dll)、java类和完整的可执行程序。而且，为了更好的性能、可靠性和/或成本，本发明的处理的多个部分可以是分布式的。

向处理器1018提供指令的处理器可读介质可以采用多种形式，包括但不限于非易失性介质、易失性介质和传输介质。非易失性介质包括例如光盘、磁盘和磁光盘，诸如硬盘1022或可移除介质驱动器1024。易失性介质包括动态存储器，诸如主存储器1004。传输介质包括同轴电缆、铜线和光纤，包括构成总线1010的导线。传输介质还可以采用声波或光波的形式，诸如在使用各种通信协议的无线电波和红外数据通信期间生成的声波或光波。

在对处理器1018执行一个或多个指令的一个或多个序列以供执行时可能涉及各种形式的处理器可读介质。例如，指令最初可以被携带在远程计算机的磁盘上。远程计算机可以将用于远程实现本发明的全部或部分的指令加载到动态存储器中，并使用调制解调器通过有线或无线连接发送指令。计算系统1000本地的调制解调器可以经由有线以太网接收数据或经由wifi无线地接收数据并将数据放置在总线1010上。总线1010将数据携带到主存储器1004，处理器1018从该主存储器1004检索并执行指令。由主存储器1004接收到的指令可以可选地在处理器1018执行之前或之后存储在存储设备1022或1024上。

计算系统1000还包括耦合到总线1010的通信接口1020。通信接口1020提供耦合到被连接到例如局域网(lan)1500或诸如互联网的另一个通信网络2000的网络链接的双向数据通信。例如，通信接口1020可以是附接到任何分组交换lan的网络接口卡。作为另一示例，通信接口1020可以是非对称数字用户线(adsl)卡、综合业务数字网络(isdn)卡或调制解调器，以提供到对应类型的通信线的数据通信连接。无线链接也可以被实现。在任何这样的实施方式中，通信接口1020发送和接收携带表示各种类型的信息的数字数据流的电、电磁或光信号。

网络链路通常提供通过一个或多个网络到其他数据设备的数据通信，包括但不限于启用电子信息流。例如，网络链路可以通过本地网络1500(例如，lan)或通过由服务提供商操作的设备来提供到另一台计算机的连接，该服务提供商通过通信网络2000提供通信服务。本地网络1500和通信网络2000使用例如携带数字数据流的电、电磁或光信号以及相关联的物理层(例如，cat5电缆、同轴电缆，光纤等)。可以在基带信号或基于载波的信号中实现通过各种网络的信号以及在网络链路上并且通过通信接口1020的信号，这些信号携带去往和来自计算系统1000的数字数据。基带信号将数字数据作为未调制电脉冲进行传输，这些未调制的电脉冲描述了数字数据比特的流，其中术语“比特”应广义地解释为意指符号，其中每个符号表达至少一个或多个信息比特。数字数据还可以用于调制载波，诸如利用幅度、相位和/或频移键控信号调制载波，该信号在导电介质上传播，或者作为电磁波通过传播媒介进行传输。因此，通过调制载波，可以通过“有线”通信信道将数字数据作为未调制的基带数据发送和/或在不同于基带的预确定的频带内发送数字数据。计算系统1000可以通过网络1500和2000、网络链路和通信接口1020来发送和接收包括程序代码的数据。此外，网络链路可以提供通过lan1500到移动设备1300(诸如，个人数字助理(pda)、膝上型计算机或蜂窝电话)的连接。

计算系统1000可以配备有直播广播/流设备，或者与该直播广播/流设备通信，该直播广播/流设备几乎实时地接收和发送从特定直播事件、表演者或参与者几乎实时捕获的数字视频/音频内容流。

计算系统的替代配置可以用于实现本文描述的系统和过程。

在本文描述的数据库中实现的电子数据存储可以是表、阵列、数据库、结构化数据文件、xml文件或诸如硬盘1022或可移除介质1024的一些其他功能数据存储中的一个或多个。

适用于回放传输到目的地计算系统400的给定媒体流的计算设备可以采用多种形式中的任何一种，包括适当提供的计算系统，诸如计算系统1000，或具有类似或相关架构的一些其他计算系统。例如，媒体播放器计算系统可以使用中央处理单元(cpu)或cpu和gpu(如果适当配备)来处理数字视频以进行回放，或者可以是基于硬件的解码器。包括gpu的媒体播放器计算系统可以支持抽象的应用编程接口，诸如opengl，供在计算系统上运行的媒体播放器应用使用以指示媒体播放器计算系统的图形处理单元进行各种图形密集的或其他高度并行的操作。媒体播放器可以采取台式或膝上型计算机、智能电话或其他移动设备、虚拟现实头盔或一些其他适当地配备和配置的计算设备的形式。

特别地，可以采用各种形式的计算设备来回放音频和视频内容，诸如头戴式显示器、增强现实设备、全息显示器、也可以通过各种传感器使用机器视觉以及头部运动来解释手势和脸姿势的输入/显示设备、可以对语音命令做出反应的设备以及提供触觉反馈、环绕声音频和/或可穿戴设备的设备。这样的设备可能能够跟踪眼睛，并且能够检测和接收记录脑波的神经信号和/或其他生物特征信号作为输入，该输入可用于控制音频和视频内容的视觉和听觉表示。

图3是示出根据实施例的可操作用于产生特定会话或节目的直播媒体流传输系统10的软件组件架构的框图。图3中示出了参与者计算设备100的示例，特别是具有通过webrtc支持rtp的网络浏览器并通过网络浏览器提供用户界面的参与者计算设备100a、具有支持rtp的非浏览器应用并通过非浏览器应用提供用户界面的参与者计算设备100b以及具有支持rtmp的更传统的obs应用并基于obs应用提供用户界面的参与者计算设备100c。在图3中还示出了示例导演计算设备300和服务器系统200，在该实施例中，该服务器系统200以示出的配置实例化并且使用由googlecloud平台提供的云计算服务由一个或多个物理服务器支撑。还示出了四个不同的示例目的地计算系统400a、400b、400c和400d。在该实施例中，目的地计算系统400a是facebooklive计算系统，目的地计算系统400b是twitch计算系统，目的地计算系统400c是periscope计算系统，目的地计算系统400d是youtubelive计算系统。在该实施例中，使用基于ip的通信协议通过互联网来进行计算设备100与服务器系统200之间以及服务器系统200与目的地计算系统400之间的通信。还示出了仪表板计算系统500，其在该实施例中还通过互联网与服务器系统200通信。仪表板计算系统500用于向服务器系统200的管理员用户或操作员提供用于从远程位置监视服务器系统200的操作的界面。

将理解的是，服务器系统200可以被多个导演计算设备300同时使用，以产生涉及不同的各个参与者和到相同或不同目的地计算系统400的不同通道的各个独立的节目。通过如上所述的经由云计算装置来部署服务器系统200，以已知的方式促进将被缩放以处理多个节目和多个参与者的服务器系统200的容量。

被配置为使用rtp与服务器系统200一起传输媒体流的参与者计算设备100a由服务器系统200配备了参与者用户界面110，用于在参与者计算设备100a上运行的web浏览器内的操作。特别地，一旦如将要描述的，参与者在被导演邀请参加特定节目之后通常已经注册为用户，就在参与者计算设备100a上运行的网络浏览器经由参与者交互(诸如，点击超链接)被引导以向在服务器系统200中执行的web服务器210(在本实施例中为openrestyweb服务器)发出httpapi请求。web服务器210通过从api服务器212查询和检索可执行文件——在此实施例中为javascript文件(例如，performer.js)并将可执行文件返回到web服务器210以便部署到参与者计算设备100a来响应web浏览器的请求。

将webrtc提供的实时通信功能与诸如参与者用户界面110的基于javascript的用户界面集成需要考虑webrtc使用与web浏览器本身相同的资源池。例如，这与基于flash的应用不同，基于flash的应用可以被配置为使用与web浏览器的内存和处理线程资源不同的内存和处理线程资源来集成通信和用户界面功能。因此，基于浏览器的用户界面的实现(用于渲染诸如图标、画布等的对象)和基于webrtc的流处理(用于显示音频和视频以及如将要描述的混合音频和视频等)以及消息传输应当以资源敏感的方式进行，以便不超过web浏览器的线程限制。如将在下面描述的，服务器系统200可以在对传入直播媒体流进行转码期间执行对这种web浏览器需要操纵的数据量的一些控制，该输入的直播媒体流可以最初以非常高的视频分辨率进行编码以在将此类内容提供给web浏览器进行混合之前，将分辨率降低到更易使用的分辨率(诸如，从1080p或更高降低到720p)。

api服务器212在数据库214中生成一个或多个记录，以便生成与参与者计算设备100a相对应的参与者标识符，该标识符可以在会话期间用于路由和管理特定参与者计算设备100a的状态。当通过参与者计算设备100a上的处理结构在web浏览器环境内执行时，可执行文件显示该web浏览器内的参与者用户界面110并使该参与者用户界面110可操作。

被配置为使用rtp但经由本地安装的应用与服务器系统200一起传输媒体流的参与者计算设备100b未配备用于生成由服务器系统200部署的用户界面的可执行文件。本地安装的非web浏览器应用执行用于在本地显示用户界面的例程。然而，当连接到已经向其提供邀请的特定节目时，以与参与者计算设备100a类似的方式向参与者计算设备100b提供参与者标识符。在该实施例中，参与者计算设备100b是基于ios的智能电话。

处理动态分辨率变化对于使系统10能够以低时延运行是有用的，特别是不仅对于混合工作流是有用的，而且对于广播也是有用的，即使在特定参与者计算设备100正在通过慢得多或不太可靠的连接进行通信的情况下也是如此。至少在一定程度上，控制一些错误恢复的能力对于减少流中断、包丢失和抖动的机会也很有用。考虑到这些因素，并且进一步因为当准备作为rtmp流的用于传出传输的传入webrtc流时需要进行转码(例如，由于webrtc不支持rtmp中使用的aac音频编解码器，并且，例如，rtmp不支持webrtc中使用的opus音频编解码器以及rtmp不支持webrtc中使用的vp8和vp9视频编解码器)，并且反之亦然，所以，服务器系统200具有特定的新颖架构。特别地，服务器系统200包括完整的webrtc服务器侧实现，其使用配备有定制rtsp插件234的webrtc网关232，以将媒体数据从webrtc重新流传输到rtmp，并且反之亦然。在该实施例中，webrtc网关232是januswebrtc网关。rtsp插件234使用rtsp控件处理将已经被转码成为webrtc兼容的媒体流的传入流到的januswebrtc网关232中的发布，并使其他过程能够向后从januswebrtc网关232读取或“播放”rtsp控件以用于例如广播。这样的转码可能涉及解码与webrtc不兼容的媒体流的音频分量，并以webrtc兼容的格式重新编码音频流，和/或降低传入的高分辨率视频分量的分辨率，使得例如可以通过webrtc网关对视频进行流传输而不会使服务器系统200或下游参与者计算设备100陷入停滞。在该实施例中，在确保线程安全的同时，处理了多个线程上的多个并发流。也就是说，在确保实现代码被线程化的同时，不会以无意/破坏性的方式与用于处理和存储的共享数据结构交互。

已经发现，由于具有上述rtsp插件234的januswebrtc网关232能够使用直接源媒体流来进行重新流传输，而不是像在研究与开发期间所测试的其他系统所要求的那样，需要首先对分辨率和帧率进行归一化。此外，与其他系统相比，服务器系统200的处理结构上的负担减少了4倍，时延减少了1.5秒，并且可以支持动态分辨率改变。

被配置为使用rtmp经由本地安装的应用将媒体流传输到服务器系统200的参与者计算设备100c在表演时没有由服务器系统200配备参与者用户界面110，因为本地安装的应用执行用于本地显示用户界面的例程。

以与参与者计算设备100a类似的方式，被配置为使用rtp向服务器系统200和从服务器系统200传输媒体流的导演计算设备300由服务器系统200配备有导演用户界面310以用于在导演计算设备300上运行的网络浏览器内的操作。特别是，一旦导演通常已经被注册为指导新节目的用户，在导演计算设备300上运行的web浏览器就经由导演交互(例如，点击超链接)来引导，以向web服务器210发出httpapi请求。web服务器210通过从api服务器212查询并检索可执行文件——在此实施例中为javascript文件(例如switcher.js)并且将可执行文件返回到web服务器210以便部署到导演计算设备300来执行web浏览器的请求。当在导演计算设备300上的网页浏览器环境内执行时，可执行文件显示该web浏览器内的导演用户界面310并使导演用户界面310可操作。

对仪表板计算设备500进行提供基于web的用户界面的类似过程。

服务器系统200进一步包括分发管理器进程216。分发管理器进程216经由http与api服务器212进行通信，并且经由http与数据库214进行通信，并处理与目标计算系统400a-400d的各个基于http的通信，包括启用帐户授权、输出广播设置、拆卸以及经由websocket和与各个导演计算设备300的http连接进行的错误处理。

服务器系统200进一步包括现场指导进程218，该现场指导进程218用于在给定节目的持续时间内使用websocketsapi与参与者计算设备100a、导演计算设备300以及仪表板计算设备500的web浏览器中的每一个web浏览器保持持久的通信连接，以便传输媒体流和其他数据。现场指导进程218还使用websocketsapi与参与者计算设备100a和导演计算设备300的web浏览器中的每一个web浏览器保持持久的通信连接。现场指导进程218通常管理不同组件之间的通信及其状态，除了由分发管理器进程216管理的与目的地计算设备400的通信连接。

在该实施例中是janus守护的守护进程224用作由导演计算设备300和参与者计算设备100a和100b到januswebrtc网关232的附加websocketapi连接的接口。janus守护代表导演计算设备300以及参与者计算设备100a和100b经由各自的websocket代理连接与januswebrtc网关232相互作用，从而响应于由导演提供与会话的各个广播id相关联的电子邀请，来验证正由参与者计算设备100呈现的邀请码。

在该实施例中，如将要描述的，利用rtsp插件来修改januswebrtc网关232，以便提供对使用网关232从webrtc输入产生rtsp输出的质量处理。

服务器系统200还包括在该实施例中为nginx服务器的http服务器236，该服务器被实例化以处理来自诸如上述参与者计算设备100c的基于非浏览器的系统的基于rtmp和rtsp的媒体流、其他数据和控制信号，该基于非浏览器的系统被定向成产生rtmp媒体流。http服务器236使用http与守护进程238进行通信，该守护进程238通过消息传输队列进程(如下所述)将验证从参与者计算设备100c提供的连接url解析的流密钥，以便验证连接并授权http服务器236通过该连接接收媒体流，并将该媒体流与特定的节目相关联，以如将在下面描述的那样相应地将流的内容路由到适当的导演计算设备300。在该实施例中，守护进程238是nginx守护进程。

消息传输队列架构被部署在服务器系统200内，以便处理服务器系统200的进程之间的消息传输，从而例如通过验证流密钥以便由授权http服务器238摄取媒体流以及通过验证广播id、邀请码、社交网络授权、帐户详细信息、经授权的持久流密钥等来促进它们的互操作。在该实施例中，rabbitmq消息队列进程和数据库220接收并处理将由分发管理器216、现场指导进程218、守护进程224和守护进程238提供和检索的消息。

在与rabbitmq消息队列进程和数据库220的通信中，用于促进互操作的还有媒体后台调度进程222、重新流化器进程226(在此实施例中，基于ffmpeg的重新流化器进程)、记录器进程230(在此实施例中，基于ffmpeg的记录器进程)和rtmp摄取器进程228(在本实施例中，基于ffmpeg的摄取器进程)。

图4是示出根据实施例的图1的直播媒体流传输系统的媒体流架构的框图。一旦已经建立了表演，参与者计算设备100a就通过使用webrtc(经由web浏览器)提供的dtls(数据报传输层安全性)协议使用安全rtp(srtp)协议沿着数据库214中与参与者计算设备100a相关联的各个通道将传出直播媒体流或直播流170a的集合传输到januswebrtc网关232的janus核心233以进行处理和路由。直播媒体流170a包括在计算设备100a上的web浏览器的指导下使用视频摄像机捕获的视频内容和使用参与者计算设备100a的麦克风捕获的音频内容。在该实施例中，视频内容由参与者计算设备100a使用vp8视频编解码器进行编码以通过srtp/dtls进行流传输，并且音频内容由参与者计算设备100a使用opus音频编解码器进行编码以通过srtp/dtls进行流传输。编解码器与webrtc兼容。可以采用替代编解码器。同样，从januswebrtc网关232的janus核心233沿着数据库214中与参与者计算设备100a相关联的各个通道来传输传入预览媒体流或流270a的集合以进行显示。传入预览媒体流包括分别使用vp8视频编解码器和opus音频编解码器编码的视频内容和音频内容。同样，可以采用替代编解码器。单独的通道(未显示)分别用于传输其他数据，诸如分别用于导演和参与者之间的通信以及导演、参与者和服务器系统计算设备300、100和200之间的通信的用户可读文本消息和机器可读状态消息。

类似地，一旦已经建立了表演，参与者计算设备100b就通过使用由本地应用提供的dtls(数据报传输层安全性)协议使用安全rtp(srtp)协议沿着数据库214中与参与者计算设备100b相关联的各个信道将传出直播媒体流或直播流170b的集合传输到januswebrtc网关232的janus核心233以进行处理和路由。直播媒体流170b包括在计算设备100b上本地应用的指导下使用视频摄像机捕获的视频内容和使用参与者计算设备100b的麦克风捕获的音频内容。在该实施例中，视频内容由参与者计算设备100b使用vp8视频编解码器进行编码以通过srtp/dtls进行流传输，并且音频内容由参与者计算设备100b使用opus音频编解码器进行编码以通过srtp/dtls进行流传输。在替代实施例中，可以使用其他音频和/或视频编解码器，例如，诸如vp9、h265。同样，传入预览媒体流或流270b的集合从januswebrtc网关232的janus核心233沿着数据库214中与参与者计算设备100b相关联的各个通道进行传输以进行显示。传入预览媒体流包括分别使用vp8视频编解码器和opus音频编解码器编码的视频内容和音频内容。同样，在替代实施例中，可以使用其他音频和/或视频编解码器，例如，诸如vp9、h265。单独的通道(未显示)用于其他数据的传输，诸如使用参与者计算设备100b经由服务器系统200发送的导演和参与者之间的文本消息。

参与者计算设备100c使用非webrtc兼容的rtmp沿着数据库214中与参与者计算设备100c相关联的各个通道将传出媒体流或流170c的集合传输到服务器系统200的rtmp摄取网关236以进行处理和路由。媒体流170c包括在参与者计算设备100c上的本地(例如，基于obs的)应用的指导下使用视频摄像机捕获的视频内容和使用参与者计算设备100c的麦克风或连接到参与者计算设备100c的麦克风捕获的音频内容。在该实施例中，视频内容由参与者计算设备100c使用h.264视频编解码器进行编码以通过rtmp进行流传输，并且音频内容由参与者计算设备100b使用mp3音频编解码器进行编码以通过rtmp进行流传输。在该实施例中，与参与者计算设备100a和100b不同，参与者计算设备100c未被提供传入预览媒体流或流集合，参与者计算设备100c也不维护与服务器系统200的用于传输用于消息传输的其他数据的附加通道。这样，在该实施例中，参与者计算设备100c仅充当媒体流的源。在参与者计算设备100c的操作者希望像其他参与者计算设备100一样接收传入预览媒体流的情况下，该操作者可以另外操作与服务器系统200相互作用但功能与参与者计算设备100a或100b中的一个参与者计算设备相似的另一个不同配置的参与者计算设备100。

在该实施例中，导演计算设备300接收从januswebrtc网关232的janus核心233沿着数据库214中与参与者计算设备100a、100b和100c中的各个参与者计算设备相关联的各个通道被传输的多个传入媒体流170a、170b、171c。通过由januswebrtc网关232的janus核心233所提供的dtls(数据报传输层安全性)协议使用安全rtp(srtp)协议，沿着数据库214中用于跟踪的与参与者计算设备100a和100b相关联的各个通道将传入媒体流传输到导演计算设备300的web浏览器。媒体流包括分别使用webrtc兼容的vp8视频编解码器和opus音频编解码器编码的视频内容和音频内容。如将要描述的，传入媒体流170a和170b在从参与者计算设备100a和100b的各个参与者计算设备被接收到以后已经被janus核心233有效地中继而没有经过修改，而由服务器系统200使用由http服务器236通过rtmp接收到的媒体流170c的内容，近乎实时的构建传入媒体流171c。

导演计算设备300还生成传出或混合视频流370，以通过使用webrtc(经由web浏览器)提供的dtls(数据报传输层安全性)协议使用安全rtp(srtp)协议，沿着数据库214中与导演计算设备300相关联的各个通道将传出或混合视频流370传输到januswebrtc网关232的janus核心233，以进行处理和路由。视频流370包括在导演计算设备300处基于(由导演)所选择的由janus核心233传输的传入媒体流170、170b，171c中的一个或多个传入媒体流的内容和/或其他本地媒体数据(诸如视频和静态图像文件)的内容的混合所生成的视频内容，和/或在导演计算设备300上的web浏览器的指导下使用导演计算设备300的视频摄像机捕获和/或直接从另一个源被流传输到基于浏览器的混合器的任何视频内容。由导演计算设备300使用vp8编解码器对混合视频流370的内容进行编码，以通过srtp/dtls进行流传输。在替代实施例中，可以使用其他音频和/或视频编解码器，例如，诸如vp9、h265。通常，混合视频流370是由操作者使用导演计算设备300完成的混合的结果，并且混合视频流370的副本将由janus核心233被路由到参与者计算设备100a和100b中的每一个参与者计算设备，以用作它们各自的传入媒体流270a、270b的视频分量。webrtc网关232也将处理混合视频流370，以如下所述在导演计算设备300的操作者的指导下进行实际的进一步处理，并路由到所选择的目的地计算设备400进行广播。

导演计算设备300还生成多个音频流372a、372b和374，以通过使用webrtc(经由web浏览器)提供的dtls(数据报传输层安全性)协议使用安全rtp(srtp)协议，沿着各个通道将音频流372a、372b和374传输到januswebrtc网关232的janus核心233。沿着数据库214中用于跟踪的与参与者计算设备100a相关联的通道传输音频流372a。沿着数据库214中用于跟踪的与参与者计算设备100b相关联的通道传输音频流372b。沿着数据库214中用于跟踪的与导演计算设备300相关联的通道传输音频流374。

在该实施例中，音频流372a、372b和374包括在导演计算设备300处基于(由导演)所选择的由janus核心233传输的传入媒体流170、170b，171c中的一个或多个传入媒体流的内容和/或其他本地媒体数据(诸如音频文件)的内容的混合生成的音频内容，和/或在导演计算设备300上的web浏览器的指导下使用导演计算设备300的麦克风捕获的和/或直接从另一个源流被传输到基于浏览器的混合器的任何音频内容。导演计算设备300使用opus编解码器对传出音频流372a、372b和374的内容进行编码，以通过srtp/dtls进行流传输。这是webrtc兼容的编解码器。在替代实施例中，可以使用其他编解码器。通常，音频流372a、372b和374是由操作者使用导演计算设备300完成的混合的结果，并且音频流372a将由janus核心233被路由到参与者计算设备100a，而音频流372b将由janus核心233被路由到参加者计算设备100b，以用作其各个传入预览媒体流270a、270b的相应音频分量。继而，webrtc网关232还将处理音频流374，以便如下所述在导演计算设备300的操作者的指导下进行实际的进一步处理，诸如直接广播和/或与传出视频流370一起路由到所选择的目的地计算设备400进行广播。

将注意的是，尽管存在要被反馈回参与者计算设备100并被处理和路由以进行广播的单个混合视频流370，但是存在由导演计算设备300生成的与传出视频流370相关联的多个音频流372a、372b、374。这样做是为了向正在接收由导演准备的视频混合的馈送的每个参与者计算设备100提供不包括最初在各个参与者计算设备100上生成的音频的定制音频混合。以这种方式，每个参与者不必听到他们自身的音频反馈，因为如果根据通过服务器系统200被传输到导演计算设备300、被混合并通过服务器系统200被传输回来而仅略有延迟，则将是可以感知的。这样，一般来说，如果有媒体流170正在导演计算设备300上被混合的x个参与者计算设备100，则将存在由导演计算设备300生成的x个定制混合音频流和由导演计算设备300生成的其他主要混合音频流374。

在导演计算设备300处本地完成的音频和视频混合使服务器系统200通过利用导演计算设备300的处理能力而不是仅仅利用服务器系统200的处理能力来减轻服务器系统200对要执行的每个混合进程进行显著地线性缩放。这减少了服务器系统200的运行成本。此外，采用导演计算设备300而不是服务器系统200进行这种混合，使导演计算设备300能够促进对混合和即时反馈的精确控制，而没有延时、同步丢失，并且固有的事件信令问题是导演计算设备300仅指示服务器系统200进行混合，并仅被提供有到所得到的混合中的窗口。

虽然为每个混入的参与者提供定制音频混合增加每个单独的导演计算设备300上的处理负担(例如，在仅提供一个最终的音频混合上)，但是施加在导演计算设备300上的附加处理负担是值得权衡的，因为它确保了系统10对于参与者而言是愉快地使用，并且操作导演计算设备300的导演被提供有关正在被混合的实际内容的实时反馈。

仍然参考图4，在服务器系统200处从参与者计算设备100c(以及其他类似的设备，这些设备不是通过rtp传输媒体流而是通过诸如rtmp的非webrtc兼容格式来传输媒体流)接收到的传入媒体流在http服务器236处被接收。http服务器236包括rtmp插件以将其提供为rtmp摄取网关，并且因此，实际上，处理与诸如参与者计算设备100c的参与者计算设备的连接，以及处理通过这些连接被传输的媒体流。具有rtmp插件的http服务器236警告服务器系统200的其他组件：存在入站rtmp流并且一旦经过验证，就经由ffmpeg服务器针对每个传入媒体流实例化ffmpeg摄取进程228，并将每个传入媒体流通过rtmp内部传输到相应ffmpeg摄取进程228。

继而，在该实施例中，ffmpeg摄取进程228以适当的方式对rtmp流进行转码以形成rtp流，摄取进程228使用rtsp将rtp流“播放”到januswebrtc网关232的rtsp插件234中。在该实施例中，以适当方式进行转码可能涉及将以1080p传入的被rtmp流传输的h264+ac内容转换为720p的被rtp/rtsp流传输的h264+opus内容。在这样的示例中，aac音频不是webrtc兼容的，通过将传入音频解码和重新编码而转码为webrtc兼容的opus音频格式，以使用rtp/rtsp进行传输。此外，将理解的是，1080p视频与webrtc兼容，但是在本申请中，可能在整个系统10的上下文中引入不适当的传输和处理延迟，并且因此在被播放到rtsp插件234中之前降低了分辨率，以进行下游处理。可以进行其他转换、降采样和有用的操纵，并且在本文中使用术语转码时对其他转换、降采样和有用的操纵进行更一般的提及。

rtsp插件234继而近乎实时地在januswebrtc网关232内部将rtp/rtsp传输的内容中继到janus核心233，以继而传输到导演计算设备300以进行混合等，其方式类似于结合在参与者计算设备100a和100b处发起的媒体流所描述的方式。

将注意的是，当使用rtsp作为中介从rtmp转换为webrtc时，分组大小是重要的参数。在该实施例中，rtsp插件234被配置为考虑到从rtmp传输的内容提取并被danus核心加密为用于webrtc的dtls的分组的大小可以未经修改而超过dsl(数字订户线)分组的最大允许大小，导致客户端(诸如导演计算设备300)静默地丢弃分组。例如，在测试期间，发现对于典型用途，通常不会在客户端侧被丢弃的经加密的分组的最大大小为1472字节，这可以在30fps下可靠地实现720p分辨率。

尽管通常可以以在加密之前将分组大小减小到1472字节的方式来完成rtsp插件234的实现，但是某些通信网络(诸如vpn或虚拟专用网络)可能施加附加安全开销，从而导致分组大小超过1472个字节。这样，在该实施例中，为了与通过非webrtc兼容格式(诸如rtmp)提供媒体的非常宽范围的参与者计算设备以及非常宽范围的联网场景兼容，由rtsp插件234产生的预加密的分组大小是1200个字节。发现使用较小的分组大小也可以实现720p和30fps。

因此，rtsp插件234和用于将最初使用rtsp的非webrtc兼容的媒体流摄取和播放到使用rtsp插件234的webrtc网关中的管道用作一种机制，通过该机制，经由诸如rtmp输出源的非webrtc兼容格式被摄取的媒体流中的内容可以与原始基于rtp的媒体流的内容一起完全被集成到混合中。

可替选地或附加地，为了摄取其他形式的非webrtc兼容媒体流，http服务器236的其他能力可以包括用于不同传输协议的不同插件。例如，虽然在以上实施例中，rtmp插件将http服务器236提供为rtmp摄取网关，但是在其他实施例中，可以提供http直播流(hls)插件来摄取和实例化各个ffmpeg摄取进程228，以处理hls媒体流的转码的管道和经转码的媒体流经由rtsp插件234到webrtc网关232的rtp/rtsp供应。类似地，可以提供“超光速(ftl)”插件以摄取和实例化各个ffmpeg摄取进程228，以处理ftl媒体流的转码的管道，并且rtp/rtsp经由rtsp插件234将经转码的媒体流提供给webrtc网关232。可以类似的方式类似地支持其他格式。

rtsp插件234还用作密钥机制，通过该密钥机制，在导演计算设备300(以及可以同时处理各个参与者的各个节目的任何其他导演计算设备300)上生成的基于dtls-srtp的媒体流可以由服务器系统200进行转码以进行广播，诸如用于通过rtmp传输到目的地计算系统400以进行广播。更具体地，在导演计算设备300使混合视频流370和混合音频流374“上线”的情况下，如将进一步详细描述的，由导演计算设备300向janus核心233发送指令以相应地路由这些媒体流。作为响应，janus核心233通过rtp将混合视频流370和混合音频流374路由到rtsp插件234，涉及使用媒体框架(gstreamer)进程进行解包。这些音频流和视频流可以在此过程中在这一点处被复用在一起，或者可以是分开的，但以其他方式链接。在rtsp的控制下，rtsp插件234通过rtp传输经转码的音频和视频以将rtp传输的媒体“播放”到一个或多个ffmpeg重新流化器进程226。为准备好广播的媒体流将被路由到的每个目的地计算系统400上的每个通道实例化ffmpeg重新流化器进程226。每个ffmpeg226重新流化器进程继而近乎实时地将rtp传输的内容转码成与之相关联的通道/目的地计算系统400所需的相应格式，并沿着相应的通道通过rtmp将经转码的内容的相应流传输到相应的目的地计算系统400。要注意的是，通过服务器系统200的分发管理器216来处理与通过其传输媒体流的信道相对应的http连接。

为了操作新的广播会话，希望操作他或她的计算设备作为导演计算设备300的用户使用导演计算设备300的web浏览器导航到服务器系统200以请求实例化新的广播会话。这使用户(导演)基于先前存在的帐户完成基于web的登录过程，或创建帐户。导演可以将他的或她的帐户与现有的社交网络帐户(诸如facebook)相关联，从而自动配置广播将被传输到的目的地计算系统400。

当已经确认了导演的凭证时，现场指导218结合数据库214触发新会话id的创建，并检索与导演的帐户相关联的各种元素，包括社交网络授权、经配置的输出(目的地计算系统400)、帐户详细信息、经授权的永久流密钥(持续在服务器系统200以供某些帐户持有者随时间针对不同会话使用的那些流密钥)以及视频服务器位置。现场指导218还触发与会话id相关联的邀请码的创建，该邀请码可以被提供给导演并由导演使用以使用各个参与者计算设备100向所选择的参与者提供将媒体数据路由到特定会话(与另一会话截然相反)的手段，以由导演酌情决定并入广播。

web服务器210通过将可执行文件部署到导演计算设备300来为导演计算设备300提供导演用户界面，以在导演计算设备300上的web浏览器内执行。当在导演计算设备300的web浏览器环境内执行可执行文件时，该可执行文件在该web浏览器内显示导演用户界面310并使导演用户界面310可操作。导演用户界面310请求导演计算设备300的操作者访问导演计算设备300的本地默认摄像机和麦克风的许可，以便为会话提供本地媒体馈送。此外，如果已经预先配置了与任何目的地计算系统400的任何连接，则分发管理器216使用oauth(开放授权)启动与目的地计算系统400的双向api连接，从而建立通道，媒体和其他数据可沿该通道在服务器系统200和所连接的目的地计算系统400之间被路由。导演可以经由导演用户界面手动建立到一个或多个目的地计算系统400的用于会话的通道。

现场指导218还发起聊天/消息传输服务，以使得能够在导演计算设备300与要被连接到服务器系统200并与会话相关联的任何参与者计算设备100之间进行文本消息传输。如将要描述的，现场指导218还管理参与者状态。

图5描绘了根据实施例的在web浏览器内显示的基于浏览器的导演用户界面310，并且图6描绘了在广播之前正在由导演建立第一视频混合和第一音频混合的同时的图5的基于浏览器的用户界面。

导演用户界面310呈现馈送池区域320、阵容区域330、媒体池区域340、视频混合区域350、持久音频区域360、视频叠加区域370、聊天区域380、直播监视器区域390和目的地配置区域395。

在此实施例中，馈送池区域320为导演提供了用于为参与者生成电子邀请(电子消息，诸如包含合并有与当前会话id相关联的邀请码的超链接的电子邮件或文本消息)的可选择图标321和已接受邀请并且可用于从其各个参与者计算设备100提供流媒体以可能并入广播中的参与者的表示322(在此实施例中，为静止图像和诸如名称的文本描述符，但是替代选择也是可能的)。在图6中，示出了四(4)个这样的表示322。要注意的是，尽管服务器系统200可能正在从已接受邀请的参与者的各个参与者计算设备100接收直播流媒体，但是直到导演计算设备300的操作者选择要包括在阵容区域330中的表示322时，直播流媒体才被路由到导演计算设备300。可以通过点击表示322并将表示322拖进阵容区域330中来进行选择。当导演计算设备300的操作者从馈送池区域320中选择表示322以包括在阵容区域330中时，导演用户界面310继而使导演计算设备300用信号通知现场指导218，以经由守护进程224使januswebrtc网关232通过webrtc将相应的传入媒体流从相应的参与者计算设备100路由到导演计算设备300。

在该实施例中，阵容区域330向导演提供了一种机制，用于列出其媒体流已经被导演从馈送池区域320中选择以进行可能的广播混合的那些参与者的表示332(在该实施例中，为所接收的视频以及诸如名称的文本描述符)。在图6中，示出了与相应的阵容编号(1到4)相关联的四(4)个这样的表示332。可以通过点击表示332并将表示332拖进视频混合区域350和/或持久音频区域360中来进行选择以包括在广播中。服务器系统200向其表示形式332被带入阵容区域330的参与者计算设备100提供状态更新消息，使得在参与者计算设备100上运行的参与者用户界面110可以向参与者显示“待机”状态消息。阵容区域330还包括针对每个参与者表示332的图标333，以通过在聊天区域380内键入，经由现场指导218发起的聊天/消息传输服务向各个参与者计算设备100发送消息。阵列区域330还包括针对每个参与者表示332的各个音量控件334，以控制向混合器进程提供相应参与者媒体流的音量，从而控制混合中相应参与者媒体流的相对音量。

在该实施例中，媒体池区域340向导演提供可选择图标341，以使用户能够向媒体池添加视频、静态图像或音频媒体文件或从媒体池中删除视频、静态图像或音频媒体文件，并用于显示这种媒体文件的表示342(在该实施例中为静态图像和文本描述符)。其表示342正在媒体池区域340中显示的媒体文件可用于可能并入广播中。在图6中，示出了四(4)个这样的表示342，即，两个视频文件和两个静止图像文件。可以通过点击表示342并将其拖进视频混合区域350、永久音频区域360和/或视频叠加区域370中来进行选择。对于其表示342在媒体池区域中340中被列出的音频/视频媒体文件和纯音频媒体文件，用于控制将相应媒体文件提供给混合器进程的音量的相应音量控件344控制混合中相应媒体文件的相对音量。

在该实施例中，视频混合区域350向导演提供了一个区域，在该区域中使用来自阵容区域330和媒体池区域340的资源来构建视频混合并查看显示的视频混合结果。视频混合区域350包括布局选择器352和场景区域354。布局选择器352向导演提供关于场景区域354如何被细分为场景子区域的多个选项。在此实施例中，布局选择器提供了九(9)个选项：全区域、两个相等的子区域、三个相等的子区域、具有两个下角子区域的主区域、具有左下角子区域的主区域、具有右下角子区域的主区域、具有三个右侧子区域的主区域、四个相等的子区域以及具有下三分之一子区域的主区域。

在该实施例中，如图6所示，示出选择了四个相等的子区域布局，并且已经从阵容区域330中选择了三(3)个表示332以放置在各个子区域中。此外，已经选择了两个音频输入(一个来自阵容区域330，并且一个来自媒体池区域340)以包括在持久音频区域360中。这样，当前正在构建的场景的视频混合仅包括来自参与者1、参与者2和参与者3的视频流，而正在构建的场景的主音频混合除了包括来自“twitchcon.mp4”的音频之外，还包括来自参与者1、参与者2和参与者3的音频流。在该示例中，来自“janice-elisabeth”的音频被放置在持久音频区域360中，以使该参与者即使在其相应的视频可能未被包括在视频混合本身中时也能够保持持久的音频贡献(例如，作为主持人)。

同样如图6所示，尚未选择任何媒体文件以包括在视频叠加区域370中。此外，直播监视器区域390显示为空白，因为在图6所示的导演用户界面310的状态下，操作者尚未授权将内容组合到混合中以进行广播。然而，如将要描述的，与直播监视器区域390相关联的图像和音频缓冲区的默认内容被自动经受混合处理，在该混合处理期间，仅示出黑色(默认)帧的视频流370和具有静音(默认)的音频流374正被传输到服务器系统200，以重新流传输到使用目的地配置区域395所选择和所激活的任何目的地计算设备400。以这种方式，相应的重新流化进程226被实例化并流传输内容，使得当直播视频缓冲区和直播音频缓冲区如由导演使用导演计算设备300的导演用户界面310所指示被填充混合的结果时，结果可以非常迅速地上线。

在该实施例中，目的地配置区域395列出用于使用户能够添加可以向其传输广播的目的地计算系统400(诸如，两个facebooklive时间线目的地和所列出的twitch目的地)的图标396以及用于打开或关闭到所有或单个目的地计算系统的路由的控件397。在图6中，“广播2facebook”被示出为打开，其对应于到服务器系统200的指令，以针对facebooklive目的地计算系统400上的对应通道转换并路由来自导演计算系统300的混合视频流370和主混合音频流374以用于例如用户的时间线上的直播表示。如果将任何特定的目的地计算系统400选择为开，则空白视频将被路由到目的地计算系统400，直到空白视频可以被由导演使用导演计算设备300构建的混合取代为止。以这种方式，由导演经由目的地计算系统400混合的内容的广播可以简单地通过在导演期望时将默认空白媒体流与混合媒体流进行切换来发生。

正在从各个参与者接收的直播媒体流由在导演计算设备300的web浏览器内运行的输入进程接收和处理，并且可以从该输入进程访问。例如，在浏览器内生成并呈现导演用户界面310的导演用户界面进程能够路由正由输入进程处理的要在阵容区域330中显示并且如果被用户选择则要在视频混合区域350的场景区域354的相应子区域中显示的媒体流。在导演计算设备300本地的web浏览器中执行要描述的混合进程。为了防止web浏览器超出浏览器线程限制或以其他方式压倒导演计算设备300的处理结构，对输入进程需要接收和处理的媒体流的数量进行了限制。在该实施例中，虽然仅示出了四(4)个媒体流，但是输入进程需要处理的媒体流的数量的限制是五(5)个。这基于诸如macbookpro计算机(苹果计算机公司)的典型的现代计算设备，或诸如基于windows10的具有游戏功能的膝上型计算机或台式计算机的另一个典型的设备的容量。然而，可替选地，可以将导演计算设备300配置为在初始化期间或在其他时间用信号通知服务器系统200，以通知服务器系统200导演计算设备300具有更大的能力或更小的能力来适当地运行可以处理多于五(5)个媒体流或少于五(5)个媒体流的输入进程(混合进程)，并且服务器系统200可以调整其允许传输到导演计算设备300的流的数量。将理解的是，在作为导演计算设备300正在请求开始会话的给定计算设备不能够处理最小级别的处理的情况下，可以由服务器系统200和/或由在初始化之后在所提出的导演计算系统300上执行的可执行软件向用户提供适当的警告。

混合进程接收由导演使用导演用户界面310指定的任何媒体流作为输入，这些媒体流将从输入进程被路由以包括在视频混合、主音频混合和定制音频混合中，如将在下面进一步详细描述的。更具体地，那些媒体流由导演从阵容区域330中选择以包括在场景区域354和/或持久音频区域360中。其表示332被带入场景区域354和/或持久音频区域360的参与者计算设备100由服务器系统200提供状态更新消息，使得在参与者计算设备100上运行的参与者用户界面110可以向参与者显示“准备就绪”状态消息。混合进程还接收导演已经从媒体池区域340中选择以包括在场景区域354和/或持久音频区域360和/或视频叠加区域370中的任何音频和/或视频和/或图像文件作为输入。混合进程还接收那些由导演使用导演用户界面310指定的参数作为输入。例如，参数包括由导演使用导演用户界面310指定的参数。例如，这些参数包括与各个媒体流或文件特定关联的参数(诸如由音频控件334设置的媒体流的特定音频分量的音量，或特定视频或视频流的场景区域354内的位置)和全局参数(诸如从布局选择器352中选择的整体场景布局、最终音频混合音量等)。

混合进程接收并处理已经与其一起呈现的媒体流，以产生音频片段(音频帧或顺序音频样本的集合)和视频片段(视频帧)的相应序列，然后该音频片段和视频片段可以根据各个参数和全局参数被组合。混合进程还处理从媒体池区域340中选择以包括在持久音频区域360或视频叠加区域370中的音频和/或视频文件，以产生音频片段(音频帧)和视频片段(视频帧)的相应序列。然后该音频片段和视频片段可以根据各个参数和全局参数被组合。

多个视频帧缓冲区由导演计算设备300上的web浏览器内的混合进程采用，以有效地处理被混合的不同类型的媒体。在该实施例中，对于视频混合区域350，相同大小的第一主帧缓冲区和第一叠加帧缓冲区被实例化并由混合进程采用。特别地，当由用户根据各个参数选择以包括在视频混合中时，来自媒体池的图像文件被解码并且根据参数被绘制到第一叠加帧缓冲区。作为示例，导演可以使用导演用户界面310选择图像文件，以特别地将其用作水印，或用作视频布局区域354的下三分之一中的实心图像，或用作占据整个视频布局区域354的实心图像，或以某种不同的定制方式采用。这样，由导演选择的图像文件被相应地处理，并且处理后的图像被绘制到第一叠加帧缓冲区。

使用第一叠加帧缓冲区，使得可以使用差分绘制速率用于以不同速率改变的内容，从而使导演计算设备300的gpu不必处理用于冗余地重新绘制变化较不频繁的内容同时还绘制变化较频繁的内容的线程。由于预计叠加很少改变内容，诸如在静态图像(诸如静态标志)的情况下，因此技术上不需要gpu执行绘制进程以如来自直播或基于文件的视频的视频帧所需的那样频繁地重新绘制此类叠加。在该实施例中，仅在由导演对视频叠加区域370做出更改(诸如添加或移除静态图像文件)时，才由gpu绘制第一叠加帧缓冲区，并且主帧缓冲区由gpu根据需要尽快绘制，其为至少30fps，并且通常更快，以便根据需要支持更高的帧速率的递送。在该实施例中，阿尔法通道(alphachannel)用于存储第一叠加帧缓冲区内的图像的像素的透明度值。

对静态图像文件进行的处理将取决于它们如何与视频叠加区域370相关联，包括：处理图像以将其渲染为部分透明(用作水印)，处理图像以对其进行放大或缩小用于视频混合的下三分之一或用于全屏显示，处理图像以对其进行裁剪或以定制方式将其呈现在视频混合中等。直到用户选择从场景中移除图像文件以用另一个图像或不用任何东西替换之前，处理后的图像文件保留在第一叠加图像缓冲区中，以与第一主图像缓冲区的内容混合。

在该实施例中，html画布捕获被用于第一主帧缓冲区和第一叠加帧缓冲区。html画布是可在web浏览器内使用javascript绘制图形的容器元素。在一些其中使用html画布捕获的web浏览器中，选项卡切换或应用切换将自动使非前景选项卡的画布中的重绘变慢或停止，以便管理资源。这继而导致输出视频冻结。这样，已经发现，使用不受选项卡切换影响的音频振荡器节点，来通过强制更新来调节html画布的渲染速率使得渲染能够在不在前景中的选项卡内进行。

在混合期间，在该实施例中，以比输出视频的期望帧速率更快的速率，混合进程通过绘制到第一主帧缓冲区来生成输出视频帧。(用于输出的)期望的帧速率可以例如是每秒30帧(fps)。特别地，在连续循环中，混合进程从与其一起正被呈现并正在解码的视频帧的每个序列中提取下一视频帧。在提取视频帧之后，混合进程根据由导演针对相应媒体流指定的参数来处理视频帧。例如，导演可以使用导演用户界面310选择媒体流，以包括在四象限场景布局的左上象限中，如图7针对媒体流1所示出的。这样，混合进程将裁剪和/或缩放视频帧到与左上象限的大小相对应的大小，并将该视频帧绘制到与左上象限的位置相对应的位置中的第一主帧缓冲区。混合进程将对从由导演选择以包括在主视频混合中的媒体流中提取的所有视频序列执行这些步骤，从而在整个第一主帧缓冲区中绘制内容。

在循环的每次迭代期间，在视频帧已经被绘制到第一主帧缓冲区的情况下，混合进程根据阿尔法通道信息将第一叠加帧缓冲区和第一主帧缓冲区的内容进行组合。根据参数，这具有将水印“叠加”到第一主帧缓冲区上或用第一叠加帧缓冲区的非空内容替换第一主帧缓冲区的下三分之一的效果等。将理解的是，在导演将第一叠加帧缓冲区中的图像选择为全屏图像的情况下，可以通过混合进程来进行优化，例如以覆盖对第一主帧缓冲区的单独处理和将视频帧绘制到第一主帧缓冲区，并简单地以期望的帧速率将第一叠加帧缓冲区的内容复制到第一主帧缓冲区，从而避免了导演计算设备300进行其结果仅简单通过全屏叠加而被重写的图像处理的处理结构。另一方面，为了节省gpu周期，第一叠加图像缓冲区中的阿尔法通道值为0(因此是完全透明的)的像素不与第一主图像缓冲区中相应位置的像素组合。

在实施例中，在由导演选择的叠加是视频文件而不是静态图像文件的情况下，可以通过混合进程以较高速率写入第一叠加帧缓冲区以提供对与视频文件的各个视频帧相对应的第一叠加帧缓冲区的更新。混合进程可以通过根据视频文件帧速率(例如，其可能低于直播视频所需的帧速率)或根据gpu的能力分配gpu处理资源来优化此进程，从而管理gpu上的负载。例如，通常将需要最高的帧速率来混合来自直播传入媒体流和媒体池视频文件的视频，并且可以自动或手动采用优化以使gpu能够使此类媒体流到主帧缓冲区的较高帧速率绘制优先于叠加视频文件到叠加帧缓冲区的绘制。将理解的是，与典型的直播媒体流相比，典型的叠加视频文件可能需要处理更少的帧间差异。

在如上所述已经绘制了第一主帧缓冲区的情况下，第一主帧缓冲区的内容被传递到导演用户界面310，并且特别地被绘制到屏幕以重写当前在场景区域354中显示的内容。由于第一主帧缓冲区的大小可能比场景区域354大(更多的像素)，因此将第一主帧缓冲区的内容绘制到场景区域354将涉及按比例缩小第一主帧缓冲区的内容。

第一主帧缓冲区的内容也作为视频帧被添加到由web浏览器内的混合进程产生的混合视频流中。在这一阶段还将进行与如所理解的用于将视频帧合并到混合视频流中的附加进程一起的时间码的应用。

同样在混合期间，在该实施例中，以与输出音频的期望采样率相对应的速率，混合进程在第一主音频缓冲区中生成输出音频采样以用于第一主音频混合。期望的采样率可以例如是每秒48,000个采样。如果将30fps用于输出视频，则这对应于每个视频帧1600个音频采样。这样，与特定视频帧相关联的时间码也可以与1600个音频采样的对应集合相关联。

特别地，在连续循环中，混合进程从正与其一起呈现并正在解码的音频采样的每个序列中提取音频采样的各个集合(例如，1600个音频采样的集合)。在从特定音频序列中提取出采样的特定集合之后，混合进程根据用户使用导演用户界面310针对相应媒体流指定的参数来处理该集合。使用上面给定示例，其中导演使用导演用户界面310选择(所组合的音频和视频)媒体流以包括在四象限场景布局的左上象限中，可由导演指定用于第一主音频混合的所选择的媒体流的音频分量的音频音量，使得混合进程将相应地处理音频采样的集合，以设置其进入主音频混合的音量。混合进程将对从导演选择的以包括在主音频混合中的媒体流中提取的所有音频序列进行此进程，并将采样加在一起并归一化总音量，从而以类似于将内容绘制到整个第一主帧缓冲区的方式形成1600个采样的所组合的集合。

还将1600个采样的所组合的集合作为音频“帧”添加到由混合进程产生的主混合音频流。在这个阶段还进行与所理解的用于将音频帧合并到主混合音频流中的附加处理一起的时间码的应用。各种压缩或其他效果可以刚好在音频接口输出之前被应用，或可以在1600个样本的所组合的集合上被应用为全局效果。主混合音频流还被传递到导演计算设备300的音频接口，以与混合视频流的显示同步地回放给导演。

混合进程如上所述生成主混合音频流，但是还为其媒体流已被导演选择以包括在混合视频和混合音频中的每个单独的参与者生成定制混合音频流。定制混合音频流是在传入媒体流的相应音频分量被有效静音的情况下生成的，使得各个参与者不会被“反馈”它们自身的音频。这样，混合进程实例化一个或多个定制音频缓冲区——每个“混入”参与者的一个——并将与混合参与者相对应的标识符与定制音频缓冲区相关联。在该实施例中，除了从由相应参与者提供的媒体流提取的音频采样集合之外，混合进程将来自被选择以包括的贡献媒体流的所有音频采样的集合组合在每个定制音频缓冲区中(如以上结合主音频缓冲区所描述的)。例如，如果有其媒体流已被选择用于包括在混合视频和主混合音频混合中的四(4)个参与者，则为参与者1调用的定制音频缓冲区将包含来自参与者2、参与者3和参与者4的音频采样的相应集合(以及来自从媒体池中选择的音频/视频文件的任何音频采样)，而为参与者2调用的定制音频缓冲区将包含来自参与者1、参与者3和参与者4的音频采样的相应集合(以及来自从媒体池中选择的音频/视频文件的音频采样)。这样，如果其媒体流已被选择用于包括在混合视频流和主混合音频流中的参与者的数量为n，则混合视频流的数量为1，主混合音频流的数量为1，并且定制混合音频流的数量是n。定制混合音频流的数量将随着操纵导演用户界面310的导演从各种参与者中选择更少的媒体流或更多的媒体流进行混合而变化。

在该实施例中，使用webrtc通过相应通道分别对混合视频流370进行编码并传输到服务器系统200，并且使用webrtc通过相应通道分别对主混合音频流374进行编码并传输到服务器系统200。而且，定制混合音频流372a，372b分别通过webrtc在相应通道上被传输到服务器系统200。

服务器系统200将仅在导演已经按下导演用户界面310上的“上线”控件312之后将混合视频流370的副本中继到各个参与者计算设备100中的每一个参与者计算设备100，以使混合的结果被切换出以进行广播。类似地，服务器将仅在导演已经按下控件312之后将定制混合音频流372a、372b中继到各个参与者计算设备100。混合视频流370和各个定制混合音频流372a、372b的中继通过webrtc通道完成。在参与者计算设备100上的各个web浏览器或本地应用内运行的输入进程接收传入webrtc流，并处理任何本地缓冲以确保可以同步完成将定制混合音频流路由到音频接口以输出到参与者计算设备100的扬声器和将混合视频流370路由到参与者用户界面110以供参与者显示。从而，使用相应参与者计算设备100的参与者可以看到他们如何出现在正在广播的直播场景中，可以类似地看到其他参与者如何出现，并且可以听到并且因此与被包括的其他参与者交谈，而所有人都不会听到他们自身的音频被延迟反馈。

图7描绘了图5的基于浏览器的用户界面，其中第一场景已经由用户构建，因此准备上线来广播。特别地，导演已从阵容区域330中选择了四个直播媒体流中的第四个直播媒体流，以包括在布局区域354的右上角。如上所述，一旦布局区域354的所有子区域都已经通过选择填充了内容，“上线”控件312就自动呈现，并在导演用户界面310中可用以供导演选择。选择控件312使涉及传入直播媒体流、叠加视频项和音频项、布局信息以及与第一叠加图像缓冲区、第一主图像缓冲区、主混合音频缓冲区和定制混合音频缓冲区相关联的参数的混合进程被传递到第二叠加图像缓冲区、第二主图像缓冲区、主直播音频缓冲区和定制直播音频缓冲区。继而，结合第一叠加图像缓冲区、第一主图像缓冲区、主混合音频缓冲区和定制混合音频缓冲区的由音频和视频的混合进程进行的循环处理反而结合第二叠加图像缓冲区、第二主图像缓冲区、主直播音频缓冲区和定制直播音频缓冲区而继续。基于混合进程绘制，对于直播音频和视频，从第二叠加图像缓冲区、第二主图像缓冲区和主直播音频缓冲区中，继续使用webrtc通过相应通道构造、编码直播视频流370并传输到服务器系统200，并且继续使用webrtc在相应通道上分别构造、编码直播音频流374并传输到服务器系统200。相对于启动，这被称为连续，因为大约从会话的启动时间开始，基于“空的”第二叠加图像缓冲区和“空的”主图像缓冲区的黑色(默认)直播视频流继续被构造、编码并传输到服务器系统200，如基于“空的”主直播音频缓冲器的静默(默认)直播音频流一样。这样，由于在启动之后已经完成了在服务器系统200处的连接协商和进程实例化，因此可以非常快速地进行实际内容的上线。

服务器系统200向其媒体流已经被混合到已上线的视频流和音频流中的参与者计算设备100提供状态更新，使得在参与者计算设备100上运行的参与者用户界面110可以向参与者显示“直播”状态消息。

在导演使用导演用户界面310去激活到目的地计算设备400的输出的情况下，导演用户界面310向分配管理器216发送消息以停止向相应的目的地计算系统400发送主直播视频流376和主直播音频流378并关闭连接。然后，分发管理器216重新建立到各个目的地计算系统400的新连接，从而准备如导演所期望的来流传输媒体。

图8描绘了处于不同状态的特别是在最近已经选择了“上线”控件312的情况下的图7的基于浏览器的导演用户界面310。可以看到的是，直播监视器区域390显示了由导演准备并被授权上线的视频混合，使得相应的直播视频和直播音频流被流传输到服务器系统200并从服务器系统200重新被流传输到相应的目的地计算设备400。

图9描绘了根据实施例的诸如将被显示在膝上型计算设备或台式计算设备的显示屏上的用于特定参与者计算设备100a的基于浏览器的参与者用户界面110a_1。参与者用户界面110通过在屏幕上的中央区域112中显示视频分量并将音频分量路由到参与者计算设备100a的音频接口以与视频分量同步回放来呈现包括混合视频流370的副本和相应的定制混合音频流372a的副本的传入媒体流270a。从导演计算设备300经由在服务器系统200上实例化以用于会话的消息传输服务发送的文本消息114被显示在显示屏上。顶部的状态栏116显示用户的本地视频馈送、包含参与者的视频馈送的广播的状态(在该情况下为“直播”)、一些诊断117和馈送状态信息。显示可选择图标118以使参与者能够进行交流。

图10描绘了根据实施例的诸如将被显示在平板计算设备的显示屏上的用于参与者计算设备100a的可替选的基于浏览器的参与者用户界面110a_2。

图11描绘了根据实施例的诸如将被显示在诸如基于ios的设备的智能电话计算设备的显示屏上的用于参与者计算设备100b的基于应用的参与者用户界面110b。

图12描绘了处于不同状态的图8的基于浏览器的导演用户界面，特别是，基于结合第二叠加图像缓冲区、第二主图像缓冲区、主直播音频缓冲区和主定制音频缓冲区进行的混合进程的视频流和音频流被流传输到服务器系统200并从服务器系统200重新被流传输，而结合第一叠加图像缓冲区、第一主图像缓冲区、主混合音频缓冲区和定制混合音频缓冲区进行的混合进程反映在场景区域354、持久音频区域360和视频叠加区域370中。在此示例中，静态图像文件“logoclnt”的表示342已被选择并且与视频叠加区域370的一部分相关联，以用于“下三分之一”叠加。此外，现在导演已经从布局选择器352中为场景区域354选择了不同的布局。已经被安排并被授权进行广播的音频流和视频流将继续被流传输，如直播监视器区域390所示。

图13描绘了图12的基于浏览器的导演用户界面310，其中场景区域354已被完全填充，因此准备上线。特别地，导演已经从媒体池区域340中选择了视频文件，并将该视频文件与新选择的布局的右半部分相关联，从而完全填充了场景区域354。这样，导演用户界面310自动显示“上线”控件312，当该控件被选择时，将使涉及(新安排的)选择直播媒体流、叠加视频项和音频项、布局信息以及与第一叠加图像缓冲区、第一主图像缓冲区、主混合音频缓冲区和定制混合音频缓冲区相关联的参数的混合进程被传递到第二叠加图像缓冲区、第二主图像缓冲区、主直播音频缓冲区和定制直播音频缓冲区，从而取代它们，同时继续将所得的直播视频流370和主直播音频流374流传输到服务器系统200以进行下游处理(诸如广播)。

图14描绘了处于不同状态的特别是在最近已经选择了“上线”控件312的情况下的图13的基于浏览器的导演用户界面310。

尽管已经参考附图描述了实施例，但是本领域技术人员将理解，可以在不脱离由所附权利要求书限定的本发明的精神、范围和目的的情况下做出变化和修改。

例如，尽管本文所述的实施例涉及将从基于浏览器的混合系统传输的媒体流广播到服务器系统，以继而由目的地计算系统传送以进行广播，但是替代方案也是可能的。例如，广播可以由服务器系统本身而不是由另一个下游系统进行。可以由服务器系统完成这样的广播，以提供例如，诸如基于webrtc的格式、某种其他类型的对等格式或直播分块媒体流格式的一种或多种各种格式的流。

此外，尽管本文公开的实施例涉及将来自基于浏览器的混合器的混合视频和混合音频通过webrtc流传输到服务器系统，但是替代方案是可能的。例如，可以使用用于流传输混合视频和混合音频的另一种格式来进行这种流传输。

此外，尽管本文公开的实施例涉及与混合视频相关联的来自基于浏览器的混合器的混合音频的流传输，但是替代方案是可能的。例如，与混合视频关联地流传输的音频可能未与其他音频混合，而是可能替代地已经在基于浏览器的混合器中从例如本地音频源被接收，并与混合视频关联地流传输。

此外，用于广播直播媒体流的有用的且有创造性的整个系统的实施例可以采用本文中描述和示出的各个发明概念、设备、方法、技术和方面的全部或子集或单个个体。例如，单个用户可以采用诸如在本文中不时描述和示出的基于浏览器的混合器，更简单地是用于自身广播和导演控制的控制台，而不必以本文所述的方式混合在其他直播媒体流中。