CN111372012A

CN111372012A - 一种软件定义视频流矩阵系统及其实现方法

Info

Publication number: CN111372012A
Application number: CN202010458095.7A
Authority: CN
Inventors: 杨丰羽; 刘盾; 杨皓; 唐学怡; 杨书焓; 董精松; 黄信云; 沈余银; 陆万霞; 高竟
Original assignee: Chengdu Chinamcloud Technology Co ltd
Current assignee: Chengdu Chinamcloud Technology Co ltd
Priority date: 2020-05-27
Filing date: 2020-05-27
Publication date: 2020-07-03
Anticipated expiration: 2040-05-27
Also published as: CN111372012B

Abstract

本发明涉及一种软件定义视频流矩阵系统及其实现方法，该系统包括至少一个输入端子、至少一个打包器、至少一个渲染模块以及一个导播模块；和或，至少一个或多个自定义模块,所述输入端子、打包器、渲染模块、导播模块和各自定义模块彼此之间通过以太网通信，并建立耦合通道或通信协议，用于完成输入端子、打包器、渲染模块、导播模块和自定义模之间的调度进而组合出不同的流调度系统，本发明提供一个开放性的视频流矩阵系统，可以根据需要自行调用相应的功能模块，从而组建出不同的流调度系统。

Description

一种软件定义视频流矩阵系统及其实现方法

技术领域

本发明涉及多媒体软件领域，具体涉及一种软件定义视频流矩阵系统及其实现方法。

背景技术

视频流矩阵是一种可以输入多个视频流，同时输出多个视频流的设备，它有多个输入端子和输出端子：主要用于实现，使某个输入端子的视频流，能够从某个特定的输出端子输出，因此视频流矩阵实现的是流的调度的功能。传统的视频流矩阵有两类：一类是在台内，做基带层面的流的调度（SDI/HDMI 信号的输入和输出）；另一类是 IP 流的调度，常称作 IP 流矩阵，基带信号会在台内先做编码，封装，然后再通过以太网输入到 IP流矩阵，同样可从IP 流矩阵某个指定的输出端子输出 IP 流。

以目前使用较多的 IP流矩阵来说，这样的一台设备通常在出厂的时候就确定了输入端子和输出端子的数量。也有厂商使用包含多块网卡的通用服务器方案实现，希望能够从软件层面，给予输入端子和输出端子的数量更灵活的选择。但遗憾的是，目前所见的方案，均为单节点方案，无法应对 5G 时代，大量的流媒体需要输入IP流矩阵的场景：比如 1000个输入端子这种场景。

视频切换台是一种和视频流矩阵很类似的产品，但他们也是有区别的：（1）通常，视频流矩阵不会对从输入端子进入的视频流做任何的处理，而视频切换台会对从输入端子进入的视频流做一些简单的包装：比如在视频流上面叠加字幕、台标等，更有甚者，可将两个输入端子的视频流，同时显现在一个画面里面，输出到输出端子；（2）通常，视频切换台的输出端子比输入端子要少。和视频流矩阵一样，视频切换台也分为：（1）通常在台内或导播车里使用的，对基带做切换的视频切换台；（2）部署在本地服务器或者云端的，对 IP 流做切换的切换台，这类常被称为云导播台。

这两个产品虽然很类似，但一直被定义为两个独立的设备或者产品，这大大降低了用户在使用时候的灵活性：常见的方式是，将视频流矩阵的输出端子和切换台的输入端子相连接。当需要使用切换台的时候，把想要输入切换台的流，从视频流矩阵的输入端子，调度到和切换台的输入端子相连的矩阵的输出端子。这样的使用方式会使得视频流矩阵的多个输出端子始终被占用，或者，当不需要使用切换台的时候，需要重新连接，极度不灵活。当接入视频流矩阵的流越来越多的时候，手动调度将工作量巨大。智能辅助的调度，越来越成为一种刚需。

发明内容

本发明的目的在于克服现有技术的不足，提供一种软件定义视频流矩阵系统及其实现方法，提供一个开放性的视频流矩阵系统，可以根据需要自行调用相应的功能模块，从而组建出不同的流调度系统。

本发明的目的是通过以下技术方案来实现的：

一种软件定义视频流矩阵系统，该系统包括：

至少一个输入端子、至少一个打包器、至少一个渲染模块以及一个导播模块；

和或，至少一个或多个自定义模块；

所述输入端子、打包器、渲染模块、导播模块和各自定义模块彼此之间通过以太网通信，并建立耦合通道或通信协议，用于完成输入端子、打包器、渲染模块、导播模块和自定义模之间的调度进而组合出不同的流调度系统。

进一步的，所述输入端子、打包器、渲染模块、导播模块和各自定义模块均表现为一个运行在集群中的服务模块。

进一步的，所述集群通过 kubernetes来管理，输入端子、打包器、渲染模块、导播模块和各自定义模块运行时均表现为kubernetes集群管理下的一个Pod。

进一步的，所述kubernetes的master节点部署在一台服务器上， kubernetes的worker节点部署在另一台服务器上，或者仅部署一台服务器，使Pod全部运行在master节点上。

进一步的，所述任意两模块之间的调度是通过kubernetes中集群中的一个service和一个与之对应的调度模块实现的，该调度模块需要使用kube-admin权限的帐号运行，由此可以访问到kuberntes集群的API，可以创建自定义模块和删除Pod。

进一步的，所述自定义模块包括语音模块、人脸识别模块、流审核模块、输出延迟模块、扇出模块和导播模块中的一个或多个。

一种软件定义视频流矩阵实现方法，所述方法如下：

S1：在一个服务器集群中部署至少一个输入端子、打包器、渲染模块和导播模块；

S2：根据应用需求选择性部署对应功能的自定义模块；

S3：建立输入端子、打包器、渲染模块、导播模块和各自定义模块之间的以太网耦合通道或通信协议，用于完成任意模块之间的调度；

S4：当需要组建流调度系统时，根据需求调用相应的模块组成流调度系统。

进一步的，所述集群通过 kubernetes来管理，所述流调度系统组建时，通过kubernetes中集群中的一个service和一个与之对应的调度模块实现的，该调度模块需要使用kube-admin权限的帐号运行，由此可以访问到kuberntes集群的API，可以创建新的自定义模块和删除输入端子、打包器、渲染模块、导播模块和已经创建的自定义模块。

进一步的，所述kubernetes的master节点部署在一台服务器上， kubernetes的worker节点部署在另一台服务器上，或者仅部署一台服务器，使输入端子、打包器、渲染模块、导播模块和已经创建的自定义模块全部运行在 master 节点上。

进一步的，所述自定义模块是指根据需求创建的功能模块。

本发明的有益效果是：

1）强集群调度技术带到IP流矩阵中，以支持传统构架无法实现的海量输入端子和输出端子的需求，并支持弹性拓展；

2）构架高度模块化，让模块和模块之间尽可能地去耦合，让矩阵能够通过动态地使用模块实现无数种组合方式，即是软件定义流的调度和处理逻辑；

3）打破了视频流矩阵和切换台产品的边界，将二者的系统均进行拆分，得到一些共用和非共用的模块，而这些拆分出来的模块，通过任意组合，能实现不同的矩阵的形态。

4）由于流矩阵变成了模块的动态组合，当设计一些新的模块（比如智能模块）加入到矩阵，能够为矩阵添加智能自动调度的功能，让矩阵充满无限的可能性。

附图说明

图1为本发明的系统示意图。

具体实施方式

下面结合具体实施例进一步详细描述本发明的技术方案，但本发明的保护范围不局限于以下所述。

如图1所示，一种软件定义视频流矩阵系统，该系统包括：

至少一个输入端子、至少一个打包器、至少一个渲染模块以及至少一个导播模块；

和或，至少一个或多个自定义模块；

也就是说本发明中的最小系统是由一个输入端子、一个打包器、一个渲染模块、一个导播模块组成的流调度系统，输入端子、打包器、渲染模块、导播模块彼此之间通过以太网通信，并建立耦合通道或通信协议，用于完成各模块之间的调度进而组合出流调度系统。

作为一个开放性系统，本系统还包括一个或多个自定义模块，输入端子、打包器、渲染模块、导播模块和各自定义模块彼此之间通过以太网通信，并建立耦合通道或通信协议，用于完成任意两模块之间的调度进而组合出不同的流调度系统。

作为一种优选实施例，输入端子、打包器、渲染模块、导播模块和各自定义模块均表现为一个运行在集群中的服务模块。集群通过 kubernetes来管理，每个输入端子、打包器、渲染模块、导播模块和各自定义模块运行时均表现为kubernetes集群管理下的一个Pod。kubernetes的master节点部署在一台服务器上， kubernetes的worker节点部署在另一台服务器上，或者仅部署一台服务器，使Pod全部运行在master节点上。任意两模块之间的调度是通过kubernetes中集群中的一个service和一个与之对应的调度模块实现的，该调度模块需要使用kube-admin权限的帐号运行，由此可以访问到kuberntes集群的API，可以创建自定义模块和删除Pod，这里的Pod是指输入端子、打包器、渲染模块、导播模块和已经创建的自定义模块。

更为优选的，本发明中包括至少一个或者多个调度模块，调度模块也表现为一个Pod ，只是运行的权限更高，因为它需要能和 kubernetes 系统通信，创建和销毁其他模块的 Pod。

Pod 里面的容器若是实现具体的功能，比如 Pod 里面的容器若实现的是输入端子的功能，我们可以称这个 Pod 为输入端子 Pod 。（这些实现具体功能的模块的 Pod，在kubernetes 里面，我们使用默认的权限运行。）

Pod 里面的容器若实现调度功能，我们可以称这个 Pod 为调度Pod，调度 Pod 可以有多个，通过 kubernetes 的 service 功能做负载均衡，对外表现成一个 “调度服务”。（调度 Pod 需要使用 kube-admin 权限，因为它需要和 kubernetes 系统通信，创建和销毁功能模块的 Pod。）

也就是说我们使用kubernetes来管理集群，每个模块运行的时候，均表现为kubernetes集群管理下的一个Pod。我们尽可能地把“调度逻辑”暗藏在Pod之间的组合关系里面，改变组合关系，则改变了调度逻辑，由此可以借助kubernetes的高可用性，实现高可用的调度系统。

我们使用kubernetes来管理集群，我们使用一台服务器来部署kubernetes的master节点，另一台服务器来部署kubernetes的worker节点（也可以只使用一台机器，让Pod全部运行在master节点上）。调度服务为kubernetes中集群中的一个service和一个与之对应的调度模块。这个Pod需要使用kube-admin权限的帐号运行，由此可以访问到kuberntes集群的API，可以创建和删除Pod。当用户需要创建某种模块的组合结构的时候，实际上是通过这个“调度服务”，创建和想要结构关联的Pod运行，这个非常容易实现，这里不予赘述。

作为一种优选实施例，自定义模块包括但不限于语音模块、人脸识别模块、流审核模块、输出延迟模块、扇出模块或者智能模块。

例如：

当用户需要一个10个输入端子5个输出端子的视频流矩阵的时候，则需要在集群中创建10个“输入端子”模块，和5个“打包器”模块。当要进行调度的时候，是直接访问“打包器”模块，控制其去拉去某个输入端子分发出来的流。

当用户需要一个带紧急切换功能的视频流矩阵的时候，可以为每个“输入端子”模块，对应地创建一个“流审核模块”，“打包器”会自动检查“输入端子”是否有对应的“流审核模块”，并从“流审核模块”获取实时的审核信息，可根据条件紧急切换为某个作为垫片的“输入端子”的流。

当用户需要导播功能的时候，可在创建输入端子的同时，创建一个导播模块，若希望能够分发到多个不同的CDN服务，还可以创建扇出模块，用于将打包器输出的流推到多个CDN服务。

输入端子模块：这个Pod里面包含两个容器：一个容器里面是ffmpeg，另一个容器为一个流媒体服务器。输入端子实现的功能是拉取源流，并将其发布到Pod内的流媒体服务器，用于在集群内做二次分发。这个过程中ffmpeg需要确保不会进行转码，只进行转封装。

打包器：这个Pod包含两个容器：一个流媒体服务器和一个基于ffmepg开发的程序。我们简要说明后者的功能：后者表现为一个restserver，通过HTTP请求，控制其从输入端子拉流，重新打包发布到Pod内的流媒体服务器。需要注意，换流的时候要考虑GOP边界切换。后者还会请求和输入流相关的其他服务，比如流审核服务等，判断是否其他服务，也需要对应的切换输入流（即切换连接的输入端子）。

人脸识别模块：这个Pod里面包含一个容器，容器内为一个基于ffmepg开发的程序，它可定时抽取视频帧率，送到“第三方人脸识别服务”（比如百度，阿里），或者自建的“人脸识别服务”。另外，该程序还表现为一个websocketserver，与其建立连接之后，将能从websocket拿到实时的识别结果。

语音识别模块：这个Pod里面包含一个容器，容器内为一个基于ffmepg开发的程序，它可解码音频，转换为下游识别软件所需的采样率和通道数，送到下游识别软件或服务识别。另外，该程序还表现为一个websocketserver，与其建立连接之后，将能从websocket拿到实时的识别结果。

流审核模块：这个Pod里面包含一个容器，容器内为一个基于ffmepg开发的程序，它可解码视频和音频，对视频抽帧，对音频转换为下游审核软件或者服务要求的格式，送到下游识别软件进行审核。另外，该程序还表现为一个websocketserver，与其建立连接之后，将能从websocket拿到实时的审核结果。

导播模块：这个Pod里面包含两个容器，其中一个容器为一个流媒体服务器，其中一个容器内为一个基于ffmepg开发的程序，它可解码多个视频流，可对这多个视频流进行叠加（画中画），可叠加台标和字母，并编码输出一路流到Pod内部的流媒体服务器。

扇出模块：这个Pod里面包含一个容器，容器内为一个基于ffmepg开发的程序，它将输入流转封装输出到多个不同的目标地址。

一种软件定义视频流矩阵实现方法，方法如下：

S2：根据应用需求选择性部署对应功能的自定义模块；

作为一种优选实施例，集群通过 kubernetes来管理，流调度系统组建时，通过kubernetes中集群中的一个service和一个与之对应的调度模块实现的，该调度模块需要使用kube-admin权限的帐号运行，由此可以访问到kuberntes集群的API，可以创建新的自定义模块和删除输入端子、打包器、渲染模块、导播模块和已经创建的自定义模块。

作为一种优选实施例，kubernetes的master节点部署在一台服务器上，kubernetes的worker节点部署在另一台服务器上，或者仅部署一台服务器，使输入端子、打包器、渲染模块、导播模块和已经创建的自定义模块全部运行在 master 节点上。

作为一种优选实施例，自定义模块是指根据需求创建的功能模块。

以上所述仅是本发明的优选实施方式，应当理解本发明并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文所述构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本发明的精神和范围，则都应在本发明所附权利要求的保护范围内。

Claims

1.一种软件定义视频流矩阵系统，其特征在于，该系统包括：

和或，至少一个或多个自定义模块；

2.根据权利要求1所述的一种软件定义视频流矩阵系统，其特征在于，所述输入端子、打包器、渲染模块、导播模块和各自定义模块均表现为一个运行在集群中的服务模块。

3.根据权利要求2所述的一种软件定义视频流矩阵系统，其特征在于，所述集群通过kubernetes来管理，输入端子、打包器、渲染模块、导播模块和各自定义模块运行时均表现为kubernetes集群管理下的一个Pod。

4.根据权利要求3所述的一种软件定义视频流矩阵系统，其特征在于，所述kubernetes的master节点部署在一台服务器上， kubernetes的worker节点部署在另一台服务器上，或者仅部署一台服务器，使Pod全部运行在master节点上。

5.根据权利要求4所述的一种软件定义视频流矩阵系统，其特征在于，任意两模块之间的调度是通过kubernetes中集群中的一个service和一个与之对应的调度模块实现的，该调度模块需要使用kube-admin权限的帐号运行，由此可以访问到kuberntes集群的API，可以创建自定义模块和删除Pod。

6.根据权利要求1所述的一种软件定义视频流矩阵系统，其特征在于，所述自定义模块包括语音模块、人脸识别模块、流审核模块、输出延迟模块、扇出模块和导播模块中的一个或多个。

7.一种实现权利要求1-6中任一项所述的软件定义视频流矩阵实现方法，其特征在于，所述方法如下：

S2：根据应用需求选择性部署对应功能的自定义模块；

8.根据权利要求7所述的一种软件定义视频流矩阵实现方法，其特征在于，所述集群通过 kubernetes来管理，所述流调度系统组建时，通过kubernetes中集群中的一个service和一个与之对应的调度模块实现的，该调度模块需要使用kube-admin权限的帐号运行，由此可以访问到kuberntes集群的API，可以创建新的自定义模块和删除输入端子、打包器、渲染模块、导播模块和已经创建的自定义模块。

9.根据权利要求8所述的一种软件定义视频流矩阵实现方法，其特征在于，所述kubernetes的master节点部署在一台服务器上， kubernetes的worker节点部署在另一台服务器上，或者仅部署一台服务器，使输入端子、打包器、渲染模块、导播模块和已经创建的自定义模块全部运行在 master 节点上。

10.根据权利要求9所述的一种软件定义视频流矩阵实现方法，其特征在于，所述自定义模块是指根据需求创建的功能模块。