CN113507641B - 一种基于客户端的多路视频混屏方法、系统及设备 - Google Patents

Abstract

本申请实施例公开了一种基于客户端的多路视频混屏方法、系统及设备，方法包括：基于混屏模块启动指令，创建主进程，并在主进程中创建流提取模块、合成线程以及编码线程；通过流提取模块在视频服务器中提取若干直播互动端的直播视频流；通过合成线程将若干直播视频流中同一时刻的若干直播图像帧，按照预设布局合成一张目标图像帧；基于合成的目标图像帧，得到目标图像序列；通过编码线程将目标图像序列编码为目标视频流，并发送到内容分发网络CDN。用以解决现有的视频混屏方法在服务器端进行导致灵活性低，在客户端进行不能更改视频混屏时的布局的技术问题。本申请属于一般的图像处理或产生领域。可以满足不同场景下的不同混屏布局需求。

Description

一种基于客户端的多路视频混屏方法、系统及设备

技术领域

本申请涉及视频混屏技术领域，尤其涉及一种基于客户端的多路视频混屏方法、系统及设备。

背景技术

在一个大型的直播（5000以上的参与者）场景下，其中几个到几十个参与者有视频连麦需求，而剩下的99%的参与者往往只是观看而不连麦。为了降低平台的运营成本，可以让这99%的用户通过观看一路混合视频流（包含很多连麦上来的视频）的方式参与到直播过程中，同时延时也不能太大（3-5S以内），这就需要将N个视频源实时合成到一个视频中，之后通过网络分发出去。

现有的视频混屏方法大多在服务器端进行，但是一旦出现故障，需要重启服务器，并重新开一次直播，修复故障的时间较长，也容易造成直播中断，降低用户体验感。其次，服务器混屏的推流端在云端，推流时需要租一个机房，这种情况下推流接入链路的选择会受限于机房，购买的内容分发网络（Content Delivery Network，CDN）的提供商与机房的提供商需要保持一致，导致CDN的接入链路不易做优化，因此，在服务器端进行混屏的灵活性较低。另外，在服务器每进行一个视频会议或直播，都需要在服务器中生成一个混屏模块，非常耗CPU，运营成本太高。

在客户端进行混屏可以解决上述问题，但是现有的客户端混屏方法往往通过抓屏软件抓取直播屏幕，这种方法无法更改视频的混屏布局，且容易把与直播视频无关的其他窗口也混到视频中，用户体验较低。

发明内容

本申请实施例提供了一种基于客户端的多路视频混屏方法、系统及设备，用于解决如下技术问题：现有的视频混屏方法在服务器端进行导致灵活性低，在客户端进行不能更改视频混屏时的布局。

本申请实施例采用下述技术方案：

本申请实施例提供一种基于客户端的多路视频混屏方法，方法包括：基于混屏模块启动指令，创建主进程，并在所述主进程中创建流提取模块、合成线程以及编码线程；通过所述流提取模块在视频服务器中提取若干直播互动端的直播视频流；通过所述合成线程将所述若干直播视频流中同一时刻的若干直播图像帧，按照预设布局合成一张目标图像帧；基于合成的所述目标图像帧，得到目标图像序列；通过所述编码线程将所述目标图像序列编码为目标视频流，并发送到内容分发网络CDN。

本申请实施例通过将混屏工作放在客户端进行，在出现故障时对于故障的修复更加快捷方便，比在服务器中进行时故障恢复时间更快。通过多线程方法将多个视频流中的图像帧合成一张图像帧，可以随意改变混屏的布局，还能够节省混屏的时间，降低直播延迟。且在选择CDN时，可以不被服务器机房的标配CDN所限制，从而选择性价比更高的CDN网络，节省成本。通过多线程协同完成混屏工作。

在一种可行的实施方式中，通过所述流提取模块在视频服务器中提取若干直播互动端的直播视频流之后，所述方法还包括：为提取的每个所述直播视频流创建一个子进程，并在所述子进程中创建解码线程；通过Socket通信方式将提取的所述直播视频流发送到所述解码线程；通过所述解码线程对每个所述直播视频流进行解码，得到若干直播图像帧序列。

本申请实施例通过为每个直播视频流创建一个子进程，并通过多个子进程同时对多个直播视频流进行解码，大大节省了多路视频解码所需的时间，在整体上看也节省了混屏的时间。

在一种可行的实施方式中，在通过所述解码线程对每个所述直播视频流进行解码，得到若干直播图像帧序列之后，所述方法还包括：在所述主进程与每个所述子进程之间均创建一块共享内存；其中，所述共享内存通过内存映射将主进程和每个子进程之间的内存进行共享；将所述解码线程中得到的所述若干直播图像帧序列实时存储于所述共享内存中。

本申请实施例通过独立的混屏模块来完成混屏工作，客户可以将混屏模块在任意一个设备上运行，没有设备限制，且共享内存的应用使得混屏模块在工作时节省大量内存，即使是32位的设备也可以同时支持几十路视频的混屏工作，通用性极高，能够提升用户体验。

在一种可行的实施方式中，通过所述合成线程将所述若干直播视频流中同一时刻的若干直播图像帧，按照预设布局合成一张目标图像帧，具体包括：通过所述合成线程，在所述共享内存中获取每个直播视频流对应的直播图像帧序列，并将所述直播图像帧序列按照时间轴进行对齐；基于调用指令，调用对应的预设布局；将对应于同一时刻的所有直播图像帧，按照所述预设布局合成为一张目标图像帧；其中，所述预设布局用于指示每张所述直播图像帧在所述目标图像帧中的位置和尺寸。

在一种可行的实施方式中，将对应于同一时刻的所有直播图像帧，按照所述预设布局合成为一张目标图像帧，具体包括：基于预设映射方法，将同一时刻的所有直播图像帧分别映射到所述预设布局中的对应区域，得到一张目标图像帧；其中，所述预设映射方法至少包括以下任意一项或多项：像素点抽样映射方法、插值映射方法。

在一种可行的实施方式中，所述基于调用指令，调用对应的预设布局，具体包括：接收来自直播主导者的调用指令；其中，所述调用指令中包含对应的预设布局；根据所述调用指令调用所述对应的预设布局，并按照所述预设布局对所述直播图像帧进行合成；在直播过程中，若接收到来自所述直播主导者的新的调用指令，则根据所述新的调用指令调用新的预设布局，以使当前时刻之后的所述目标图像帧以新的预设布局进行显示。

本申请实施例通过在混屏模块中设置多种混屏布局，使得多个互动端的视频可以以多种布局显示在同一画面中，可以满足多人直播连麦、多人视频会议等不同场景下的不同布局需求，在直播或会议过程中也可以随时切换布局，满足用户的具体需求。

在一种可行的实施方式中，通过所述编码线程将所述目标图像序列编码为目标视频流，具体包括：将所述合成线程中得到目标图像帧按照时间顺序进行排列，得到所述目标图像序列，并发送到所述编码线程中；通过所述编码线程，对所述目标图像序列进行编码，得到目标视频流；在得到目标视频流之后，所述方法还包括：将所述目标视频流封装为实时消息传输协议(Real Time Messaging Protocol,RTMP)流。

在一种可行的实施方式中，通过所述编码线程将所述目标图像序列编码为目标视频流，发送到内容分发网络CDN，具体包括：根据主CDN供应商所支持的运营商对应的网络速率，选择接入的运营商；将所述运营商接入所述主CDN供应商的边缘节点；将所述RTMP流通过所述边缘节点发送到主CDN的核心节点，以使所述主CDN核心节点将所述RTMP流分发到观看直播的若干直播观看端；在所述主CDN供应商所支持的运营商的网络速率均小于预设阈值的情况下，接入备CDN供应商。

本申请实施例通过准备两个以上的CDN供应商，保证在主CDN供应商网络效果不好的情况下能够迅速接入备用的CDN供应商接口，保证直播混屏的正常进行。

本申请实施例还提供了一种基于客户端的多路视频混屏系统，所述系统包括：视频服务器，用于接收并存储若干直播互动端的直播视频流；

混屏推流客户端，用于基于混屏模块启动指令，创建主进程，并在所述主进程中创建流提取模块、合成线程以及编码线程；通过所述流提取模块在视频服务器中提取若干直播互动端的直播视频流；通过所述合成线程将所述若干直播视频流中同一时刻的若干直播图像帧，按照预设布局合成一张目标图像帧；基于合成的所述目标图像帧，得到目标图像序列；通过所述编码线程将所述目标图像序列编码为目标视频流，并发送到内容分发网络CDN；

内容分发网络CDN，用于将所述目标视频流分发到若干直播观看端。

另外，本申请实施例还提供了一种基于客户端的多路视频混屏设备，包括：

至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有能够被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述任一实施方式所述的一种基于客户端的多路视频混屏方法。

本申请实施例提供的一种基于客户端的多路视频混屏方法、系统及设备在出现故障时对于故障的修复更加快捷方便，比在服务器中进行时故障恢复时间更快。通过独立的混屏模块来完成混屏工作，客户可以将混屏模块在任意一个设备上运行，没有设备限制，降低运营成本。本申请的推流端网络接入灵活，可以在接入时根据网络的实际接入效果灵活选择合适的推流端网络。另外，本申请中的混屏模块通过多线程协同实现图像帧合成，可以灵活改变视频混屏的布局，而直接在视频服务器获取直播视频流，也不会将桌面上无关的窗口抓取到直播中，用户观感好。最后，本申请还采用了共享内存技术，混屏模块在工作时节省大量内存，即使是内存较小的设备也可以支持多路视频混屏，通用性高。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1为本申请实施例提供的一种基于客户端的多路视频混屏方法流程图；

图2为本申请实施例提供的一种基于客户端的多路视频混屏系统及混屏模块；

图3为本申请实施例提供的一种CDN网络接入流程示意图；

图4为本申请实施例提供的一种基于客户端的多路视频混屏系统结构示意图；

图5为本申请实施例提供的一种基于客户端的多路视频混屏设备结构示意图。

具体实施方式

本申请实施例提供了一种基于客户端的多路视频混屏方法、系统及设备。

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本说明书实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

图1为本申请实施例提供的一种基于客户端的多路视频混屏方法流程图，如图1所示，基于客户端的多路视频混屏方法具体包括步骤101-步骤106：

步骤101、混屏推流客户端基于混屏模块启动指令，创建主进程，并在主进程中创建流提取模块、合成线程以及编码线程。

具体地，多个直播互动端发起连麦或视频会议请求，向混屏推流客户端发送混屏模块启动指令，同时将参与连麦或视频会议的多个直播互动端的实时视频流传输到视频服务器。

进一步地，混屏推流客户端收到混屏模块启动指令后，随即启动混屏模块，同时在混屏模块中创建一个主进程，并在主进程中分别创建流提取模块、合成线程以及编码线程。

作为一种可行的实施方式，若互动端A、B、C、……、N发起实时视频会议，每个互动端自动将各自的实时直播视频流发送到视频服务器（或可称为视频云），同时混屏推流客户端收到混屏模块启动指令，启动混屏模块，创建主进程，同时在主进程中创建合成线程、编码线程以及各互动端对应的流提取模块。其中，合成线程动态创建对应的流提取模块，每个需要混屏的直播视频流都对应一个流提取模块。

步骤102、混屏推流客户端通过流提取模块在视频服务器中提取若干直播互动端的直播视频流。

具体地，传统的在服务器中进行混屏的方法，每进行一次直播就需要生成一个混屏模块，由于混屏模块占用的CPU空间较大，生成过多混屏模块会非常消耗服务器的CPU，增加服务器平台的运营成本。且混屏程序运行于服务器端，出现故障时恢复较慢。如果选择的内容分发网络CDN供应商和租的机房不是同一供应商，CDN推流效果可能不是最好，限制了CDN的选择。因此通过混屏推流客户端中的流提取模块在视频服务器中提取出对应的直播视频流，从而将直播视频流放在混屏推流客户端中进行混屏工作，能够避免上述问题。

在一个实施例中，A视频流提取模块根据视频标识在视频服务器中提取出A视频流。

步骤103、混屏模块为提取的每个直播视频流创建一个子进程，并在子进程与主进程之间创建共享内存。

具体地，混屏模块为提取出的每个直播视频流分别创建一个子进程，并在子进程中创建解码线程。其中，解码线程与流提取模块同时创建，并一一对应。流提取模块通过Socket通信方式将提取的直播视频流发送到对应的解码线程。然后解码线程对接收到的每个直播视频流进行解码，得到若干个直播图像帧序列。

需要说明的是，对直播视频流解码的方式可以选择目前现有的解码技术，如H.264等，本申请不作赘述。

进一步地，将混屏工作放在客户端中进行会面临一个新的问题：客户端、终端等设备的内存比服务器要小很多，因此能够同时进行混屏的视频流数量会大幅降低，特别是32位终端的内存更小。为解决此问题，本申请中的混屏模块在主进程与每个子进程之间均创建一块共享内存。每个子进程将解码线程中解码出的直播图像帧序列实时存储于共享内存中，以使主进程可以根据预设布局在共享内存中直接获取直播图像帧。共享内存的应用可以使混屏模块在工作时节省大量内存，即使是32位的设备也可以同时支持几十路视频的混屏工作，完全能够满足一般的直播连麦、视频会议的混屏需求。因此本申请提供的混屏模块不受设备的限制，通用性高。

在一个实施例中，若不采用共享内存技术，32位程序的使用内存一般是2G，混屏模块中，进程本身+编码器+视屏队列等的内存消耗大约为500M，而一路全高清（FHD）视频流解码模块需要的内存一般是200M左右，那么32位程序可以支持同时参与混屏的FHD视频流的路数为（2G-0.5G）/200M=7.5（路）。若采用共享内存技术，一路FHD视频流占用的主进程的内存为：预设布局中的宽*预设布局中的高*一个像素占用的字节数*缓存的帧数。而预设布局中的高最大为1920像素，随着同时参与混屏数量的增多，这个值是越来越小的，比如1/4分屏时，预设布局中的高即为1920/2=960。同样，预设布局中的宽最大为1080。一个像素占用的字节数一般采用RGBA，为4字节。缓存的帧数一般为2帧。所以一路FHD视频流占用主进程中的最大内存为：1920*1080*4*2，约等于17M，那么32位程序可以支持同时参与混屏的FHD视频流的路数为（2G-0.5G）/17M，约等于375路。可见，采用共享内存技术可以节省大量内存，支持更多路视频流同时参与混屏。

作为一种可行的实施方式，解码线程不断解码主进程通过Socket通信方式发过来的直播视频流，再不断刷新共享内存。工作于主进程中的合成线程即可得到共享内存中实时更新的图像帧序列。

本申请中的流提取模块、编码线程、合成线程以及解码线程同时工作，每条线程每处理完一张图像帧即可将处理完的图像帧发送到下一线程，同时继续处理下一张图像帧。多线程协同合作进行混屏工作，能够节省混屏所需时间，降低直播观看端的观看延迟，提高观众的观看体验。

步骤104、通过合成线程将若干直播视频流中同一时刻的若干直播图像帧，按照预设布局合成一张目标图像帧。

具体地，合成线程在共享内存中获取每个直播视频流对应的直播图像帧序列后，将所有的直播图像帧序列按照时间轴进行对齐。

进一步地，在直播或者视频会议中往往会因为直播内容或会议内容的不同，需要改变每个视频在画面中的位置或尺寸，为使这种改变变得更加灵活，本申请中的混屏模块通过合成线程接收来自直播主导者的调用指令。其中，调用指令中包含当前时刻对应的目标图像帧的预设布局。若没有接收到调用指令，则使用当前原本的预设布局来合成目标图像帧。预设布局可以人为提前设定，并保存在混屏推流客户端中，以供直播主导者选择。

例如，直播主导者在直播过程中可以点击各种预设布局的按钮，选择此时需要以什么样的布局来分布画面中的视频，以及可以执行将某个视频放大缩小或者挪动位置等操作，每种操作对应一种调用指令，后台即可根据直播主导者的操作向混屏推流客户端发出对应的调用指令。若当前直播主导者指定的预设布局为布局1，当前时刻混屏推流客户端接收到调用布局2的指令，则控制混屏模块使用布局2对当前时刻及之后的图像帧进行合成，得到符合布局2的目标视频流。若没有接收到任何调用指令，则继续用布局1来进行混屏。

进一步地，合成线程根据调用指令调用对应的预设布局，将对应于同一时刻的所有直播图像帧，按照预设布局合成为一张目标图像帧。其中，预设布局用于指示每张直播图像帧在目标图像帧中的位置和尺寸。

作为一种可行的实施方式，合成线程通过像素点抽样映射方法或插值映射方法，将同一时刻的所有直播图像帧分别映射到当前预设布局中的对应区域，得到一张目标图像帧。

在一个实施例中，在合成线程将所有的直播图像帧序列按照时间轴进行对齐后，若当前时刻为T1，合成线程选取各直播图像帧序列中T1时刻的图像帧，根据T1时刻使用的预设布局，将图像帧的像素点抽样或插值映射到合成图像中的某个区域，例如将A视频流中的图像帧映射到如图2中所示的合成线程中的A视频的区域。

作为一种可行的实施方式，在混屏过程中，若接收到来自直播主导者的新的调用指令，则根据新的调用指令调用新的预设布局，以使当前时刻之后的目标图像帧以新的预设布局进行合成，合成线程根据时间轴不断执行合成过程，得到各个时刻对应的目标图像帧。

步骤105、基于合成的目标图像帧，得到目标图像序列。

具体地，合成线程将得到的各个时刻对应的目标图像帧按照时间顺序进行排列，得到目标图像序列，并发送到编码线程中。

例如，将得到的每张目标图像帧按时间进行排列，得到目标图像序列T1、T2、……、Tn，然后发送到编码线程。

步骤106、通过编码线程将目标图像序列编码为目标视频流，并发送到内容分发网络CDN。

具体地，编码线程对收到的目标图像序列进行编码，得到目标视频流。然后将目标视频流封装为实时消息传输协议RTMP流，然后发送到CND网络。

作为一种可行的实施方式，编码线程使用的编码技术与解码线程使用的解码技术相对应，比如若解码线程使用H.264解码技术进行解码，那么编码线程则使用H.264编码技术进行编码。

在一个实施例中，图2为本申请实施例提供的一种基于客户端的多路视频混屏系统及混屏模块，下面通过图2详细解释本申请实施例提出的混屏方案：

如图2所示，直播互动端1、2、3、……发起直播连麦，将各自的直播视频流发送到视频服务器，同时向混屏推流客户端发送混屏模块调用指令。混屏推流客户端接收到混屏模块调用指令后调用混屏模块。混屏模块启动后，创建主进程与子进程，在主进程中创建合成线程、编码线程以及直播互动端直播互动端1、2、3、……对应的流提取模块，在子进程中创建解码线程。

然后通过流提取模块分别调取视频服务器中对应的直播视频流，并通过Socket通信将调取的直播视频流发送到对应的子进程中的解码线程进行解码。解码线程对接收到的直播视频流进行实时解码，并将解码出的图像帧存储到共享内存中。

合成线程在共享内存中取出属于各个直播视频流的图像帧序列，并按照时间轴进行对齐。然后确定当前的目标图像帧的预设布局，将T1时刻的图像帧1、2、3、……分别映射在预设布局中的对应区域，从而得到T1时刻的目标图像帧。然后将各个时刻的目标图像帧按时间排序，得到目标图像序列。

合成线程将目标图像序列发送到编码线程进行编码，得到目标视频流，然后混屏推流客户端再将目标视频流封装为实时消息传输协议RTMP流推送到内容分发网络CDN，由CDN将RTMP流分发到直播观看端。至此，一次完整的混屏过程完成，但在直播互动端的直播过程中，上述混屏过程持续进行，不断将新的视频图像帧合成为目标图像帧，直至直播结束。

进一步地，混屏推流客户端根据主CDN供应商所支持的运营商对应的网络速率，选择接入的运营商。然后将运营商接入主CDN供应商的边缘节点。最后将RTMP流通过边缘节点发送到主CDN的核心节点，以使主CDN核心节点将RTMP流分发到观看直播的若干直播观看端。

作为一种可行的实施方式，图3为本申请实施例提供的一种CDN网络接入流程示意图，如图3所示，301为主CDN的边缘节点，302为备CDN的边缘节点。为了应付推流过程中可能会出现CDN运营商或网络接入供应商网络情况不好的情况，本申请提前购买两个以上CDN供应商，一个主CDN供应商，1个以上的备CDN供应商，以使现场保证能够随时接入至少2个CDN供应商。在主CDN供应商所支持的运营商的网络速率均小于预设阈值的情况下，接入备CDN供应商。

进一步地，图3中影响CDN推流质量的因素有两个：

1.内容分发网络的边缘节点不能保证推流质量。

2.混屏推流客户端宽带接入的运营商当时的网络负载情况，即混屏推流客户端到CDN边缘节点之间的网络负载情况。

例如，在推流过程中，如果发现电信的效果不好，可以随时切换到其他的宽带接入商，如联通或者移动。如果发现主CDN供应商边缘节点部署情况有异常或效果不好，则接入备CDN供应商。以克服影响CDN推流质量的两个因素，保证推流效果。

图4为本申请实施例提供的一种基于客户端的多路视频混屏系统结构示意图，如图4所示，系统包括：

多个直播互动端410，用于将视频流发送到视频服务器420。

视频服务器420，用于接收并存储多个直播互动端410的直播视频流。

混屏推流客户端430，可调用混屏模块，用于基于混屏模块启动指令，创建主进程，并在主进程中创建流提取模块、合成线程以及编码线程；通过流提取模块在视频服务器中提取若干直播互动端的直播视频流；通过合成线程将若干直播视频流中同一时刻的若干直播图像帧，按照预设布局合成一张目标图像帧；基于合成的目标图像帧，得到目标图像序列；通过编码线程将目标图像序列编码为目标视频流，并发送到内容分发网络440。

需要说明的是，本申请中的混屏推流客户端430可以是任意一个能够调用接口、运行程序的设备或终端，比如可以是一台笔记本电脑，而不限于一种特定的设备。

作为一种可行的实施方式，本申请的混屏模块的设计思路是以动态库（分32位版本和64位版本）和接口的形式供调用方使用，模块本身没有任何用户界面，调用方负责用户界面的实现，32位版本供32位应用程序调用，64位版本供64位应用程序调用。

内容分发网络440，用于将目标视频流分发到多个直播观看端450。

多个直播观看端450，用于播放目标视频流。

图5为本申请实施例提供的一种基于客户端的多路视频混屏设备结构示意图，如图5所示，设备包括：

至少一个处理器501；以及，与至少一个处理器501通过总线502通信连接的存储器503；其中，

存储器503存储有能够被至少一个处理器501执行的指令，以使至少一个处理器501能够执行：

基于混屏模块启动指令，创建主进程，并在主进程中创建流提取模块、合成线程以及编码线程；

通过流提取模块在视频服务器中提取若干直播互动端的直播视频流；

通过合成线程将若干直播视频流中同一时刻的若干直播图像帧，按照预设布局合成一张目标图像帧；

基于合成的目标图像帧，得到目标图像序列；

通过编码线程将目标图像序列编码为目标视频流，并发送到内容分发网络CDN。

本申请将混屏工作转移到客户端进行，克服了在服务器进行混屏的种种困难。又通过共享内存的设置节省了大量的内存，使混屏模块即使运行在内存较小的终端上也可以支持几十路视频同时混屏。还通过增加多个CDN供应商以及选择速率较高的运营商来保证推流质量，保证了直播观看的流畅性，提升了用户的体验感。

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备、非易失性计算机存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请的实施例可以有各种更改和变化。凡在本申请实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (9)

1.一种基于客户端的多路视频混屏方法，其特征在于，所述方法包括：

混屏推流客户端基于混屏模块启动指令，创建主进程，并在所述主进程中创建流提取线程、合成线程以及编码线程；

通过所述流提取线程在视频服务器中提取若干直播互动端的直播视频流；

通过所述合成线程将若干直播视频流中同一时刻的若干直播图像帧，按照预设布局合成一张目标图像帧；

基于合成的所述目标图像帧，得到目标图像序列；

通过所述编码线程将所述目标图像序列编码为目标视频流，将所述目标视频流封装为实时消息传输协议RTMP流，并发送到内容分发网络CDN；

根据主CDN供应商所支持的运营商对应的网络速率，选择接入的运营商；

将所述运营商接入所述主CDN供应商的边缘节点；

将所述RTMP流通过所述边缘节点发送到主CDN的核心节点，以使所述主CDN核心节点将所述RTMP流分发到观看直播的若干直播观看端；

在所述主CDN供应商所支持的运营商的网络速率均小于预设阈值的情况下，接入备CDN供应商。

2.根据权利要求1所述的一种基于客户端的多路视频混屏方法，其特征在于，在通过所述流提取线程在视频服务器中提取若干直播互动端的直播视频流之后，所述方法还包括：

为提取的每个所述直播视频流创建一个子进程，并在所述子进程中创建解码线程；

通过Socket通信方式将提取的所述直播视频流发送到所述解码线程；

通过所述解码线程对每个所述直播视频流进行解码，得到若干直播图像帧序列。

3.根据权利要求2所述的一种基于客户端的多路视频混屏方法，其特征在于，在通过所述解码线程对每个所述直播视频流进行解码，得到若干直播图像帧序列之后，所述方法还包括：

在所述主进程与每个所述子进程之间均创建一块共享内存；其中，所述共享内存通过内存映射将主进程和每个子进程之间的内存进行共享；

将所述解码线程中得到的所述若干直播图像帧序列实时存储于所述共享内存中。

4.根据权利要求3所述的一种基于客户端的多路视频混屏方法，其特征在于，通过所述合成线程将所述若干直播视频流中同一时刻的若干直播图像帧，按照预设布局合成一张目标图像帧，具体包括：

通过所述合成线程，在所述共享内存中获取每个直播视频流对应的直播图像帧序列，并将所述直播图像帧序列按照时间轴进行对齐；

基于调用指令，调用对应的预设布局；

将对应于同一时刻的所有直播图像帧，按照所述预设布局合成为一张目标图像帧；其中，所述预设布局用于指示每张所述直播图像帧在所述目标图像帧中的位置和尺寸。

5.根据权利要求4所述的一种基于客户端的多路视频混屏方法，其特征在于，将对应于同一时刻的所有直播图像帧，按照所述预设布局合成为一张目标图像帧，具体包括：

基于预设映射方法，将同一时刻的所有直播图像帧分别映射到所述预设布局中的对应区域，得到一张目标图像帧；

其中，所述预设映射方法至少包括以下任意一项或多项：像素点抽样映射方法、插值映射方法。

6.根据权利要求4所述的一种基于客户端的多路视频混屏方法，其特征在于，所述基于调用指令，调用对应的预设布局，具体包括：

接收来自直播主导者的调用指令；其中，所述调用指令中包含对应的预设布局；

根据所述调用指令调用所述对应的预设布局，并按照所述预设布局对所述直播图像帧进行合成；

在直播过程中，若接收到来自所述直播主导者的新的调用指令，则根据所述新的调用指令调用新的预设布局，以使当前时刻之后的所述目标图像帧以新的预设布局进行显示。

7.根据权利要求1所述的一种基于客户端的多路视频混屏方法，其特征在于，通过所述编码线程将所述目标图像序列编码为目标视频流，具体包括：

将所述合成线程中得到目标图像帧按照时间顺序进行排列，得到所述目标图像序列，并发送到所述编码线程中；

通过所述编码线程，对所述目标图像序列进行编码，得到目标视频流。

8.一种基于客户端的多路视频混屏系统，其特征在于，所述系统包括：

视频服务器，用于接收并存储若干直播互动端的直播视频流；

混屏推流客户端，用于基于混屏模块启动指令，创建主进程，并在所述主进程中创建流提取线程、合成线程以及编码线程；通过所述流提取线程在视频服务器中提取若干直播互动端的直播视频流；通过所述合成线程将若干直播视频流中同一时刻的若干直播图像帧，按照预设布局合成一张目标图像帧；基于合成的所述目标图像帧，得到目标图像序列；通过所述编码线程将所述目标图像序列编码为目标视频流，将所述目标视频流封装为实时消息传输协议RTMP流，并发送到内容分发网络CDN；

所述混屏推流客户端还用于，根据主CDN供应商所支持的运营商对应的网络速率，选择接入的运营商；将所述运营商接入所述主CDN供应商的边缘节点；将所述RTMP流通过所述边缘节点发送到主CDN的核心节点，以使所述主CDN核心节点将所述RTMP流分发到观看直播的若干直播观看端；在所述主CDN供应商所支持的运营商的网络速率均小于预设阈值的情况下，接入备CDN供应商；

内容分发网络CDN，用于将所述目标视频流分发到若干直播观看端。

9.一种基于客户端的多路视频混屏设备，其特征在于，所述设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有能够被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行根据权利要求1-7任一项所述的一种基于客户端的多路视频混屏方法。

Images