基于SRS的审查/鉴黄/播控技术方案之一：软矩阵

直播的播出控制本质上也是一个控制系统，完善的控制系统必须由采样（截图）、识别（鉴黄）、控制（延播、切换和踢流）三个系统组成。本文描述了控制（切换）部分，在SRS的实现方案。...



直播的播出控制本质上也是一个控制系统，完善的控制系统必须由采样（截图）、识别（鉴黄）、控制（延播、切换和踢流）三个系统组成。本文描述了控制（切换）部分，在SRS的实现方案。

直播的控制（切换）有多种方式，一种是切换台，一种是软矩阵。在广电中，切换台用得最多，在多个源之间切换，属于图像级别的切换，切换台输出到编码器编码输出。而软矩阵一般是在编码器中，多路输入和多路输出之间切换，也可以在服务器上实现，多路流送往不同的服务器。

管理员切换时，需要观看数据源，然后切换，不是随意切换。譬如当前的镜头是观众席，管理员看到开始铲球时，要切换到赛场上的镜头。从准备切换，到实际切换的时间，就是控制系统的响应时间。

切换台优点就是响应时间非常短，系统非常实时，眼睛看到的画面，和编码器输出的画面是一致的。缺点就是需要专门的硬件设备，成本也非常高昂。在互联网中，还没有使用切换台的先例，太贵了。

软矩阵（编码器方案），响应时间比切换台要高，比软矩阵（服务器方案）要低。因为需要重新编码，所以软矩阵（编码器方案）支持的路数有限。目前一些编码器厂商，有些支持软矩阵，都只支持几路或十几路切换。

软矩阵（服务器方案），响应时间是最慢的，通常是一个gop以上。不需要重新编码，所以这个方案能支持非常多路流切换，适合云平台部署。SRS上实现的就是这种方案。适合cdn和视频云厂商实现。

SRS的Edge支持推流（publish）和拉流（play）两种方式，这两种方式都可以实现软矩阵。SRS的配置是基于vhost的，所以需要新增Rewrite，应用在某些流上，如果匹配到了流，则回源时使用特殊的配置；利用HTTP-API对外提供接口，修改Rewrite的配置；然后使用PersistenceConfig存储变更。

SRS的publish Edge，适合做推送形式的软矩阵，将流送到不同的源站；SRS的play Edge，适合做拉流时的软矩阵，CDN在回源时，从不同的源站取流。两种方式都可以实现上千路流的软矩阵切换。

BMS已经实现，开发周期是一周，上线发布周期一个月左右。

    关注 SRS