云导播的技术实现和玩法

云导播台的概念和功能、云导播台的应用、技术方案的实现、衡量指标、潜在难点

一、云导播台的概念和功能

我们先来直观的看下案例，这个截图中的视频是最近比较火的英雄联盟的赛事，我们从直播流的4个片断进行了拼接，为了更突出拼接的边界采用了立体旋转等拼接方式，下面是其中一个画面的截图，有观众席和游戏精彩画面的直播流。

那么作为一场赛事直播，技术人员从中看到了什么？

第一， 直播流在切换，解说员的流和现场的流在切换；

第二， 三路直播流的混合，游戏界面、两名选手直播流的无缝 布局；

第三， 转场特效，从现场到游戏界面的直播流切换功能之间

第四， 贴图+3路直播流混流，以及贴图动画

第五， 背景图+2路直播流布局+布局动画特效+多路混音（两导播流串联）

那为了业务上达到这种效果，导播台要做什么呢？

实际上传统导播台的幕后工作场景是这样的:

左上角是导播间，一般它距离现场说非常近的，专业的导播人员通过操作台控制素材库中的流和现场直播流进行切换，让右下角观众观看的直播流发生变化。

现在阿里云云导播的操作界面是这样的:

以上是阿里云导播台的SAAS页面，用来验证我们的SAAS接口，用来做一些简单的切换。根据我们提供的是SAAS接口，用户可以做自己的导播台的页面或者流程。

云导播最重要的特点是在云端，所以，第一，它可以进行远程操作，无论现场在哪里，导播人员都可在任何场地任何移动设备进行导播切流操作。第二，在云端可以无人操作。直播播单编排好后，可配置各种自动监控报警，自动备份，自动恢复紧急预案等等，无需进行传统的人工操作。

云导播的功能，从业务上看，我们把他分成简单、常用、复杂、辅助、特有这几类：

最简单的功能包括：加台标、图片、水印等等；

最常用的功能包括：切视频流和切视频文件。自动切换和手动切换【节目单，滚动播放和轮播】，文字以及跑马灯等。

最复杂的功能包括：虚拟场景，抠图，转场特效和多布局混流【含混音】等。

辅助导播功能包括：素材库、PVW/PGM、预热和旁路延迟输出、紧急切换等。

阿里云特有功能包括：

云的基本功能：防攻击／容灾／分布式多机房部署／断流秒级恢复等

ET字幕，语音翻译实时字幕

可扩展的动态实时素材【诸如H5页面实现比分，实时弹幕等】，这是基于导播台的二次开发，实时素材直接合成到直播流中去。

多个云导播台可以串联。

二、云导播台的应用

一、游戏

把游戏导播门槛和成本的降低，不需要设备，使得任何一场游戏直播都有可能为一场活动性的赛事直播。

让游戏玩家和游戏解说分开，玩家专注游戏。

播单功能可以让主播无需时刻在线，也即无需时刻的良好网络状况，录制的游戏视频可以循环利用。

结合点播的视频编辑，使用云导播台，可以制作一个个人网络电台。

结合视频云的转推功能，可以让一场直播分发到不同的直播平台的房间进行跨平台直播，增加流量。

二、活动

今年天猫双11也用了云导播台，作为底层服务志愿淘Live 10*24小时直播，千牛48小时直播和线下大屏同步直播。其中线下大屏直播是在商场人流比较密集的通道，直播肯定要有精彩的瞬间来吸引过往行人，那么在大屏幕直播48小时，导播人员肯定要在不同流中找精彩画面来不停切换。

三、电视台

电台购物、播单直播等办可以为电视台提供更便捷的导播服务。播单直播是预先对媒体文件编排播放顺序，设定单个媒体文件的播放起开时间、结束时间，同时用户可根据业务需要叠加文字、图片水印， 导播服务依照编排播放次数实时产生直播媒体流。

四、在线教育

多路媒体流：PPT、教师直播流、学生直播流、教学视频、H5 教育互动，可任意编排内容布局，实时切换布局、切换视频源。

三、云导播的技术实现方案

业务功能是通过技术来实现，接下来我们来看看技术角度的功能。

第一，云导播台的云功能

依赖阿里视频云的基础架构和组件模块来保证【安全，稳定，高复用，可运营维护等】。

多机房部署。

全链路（端到端）监控和报警系统，全模块日志记录，追溯和分析等。

数据海量极速存取等【RDS／OSS】。

第二，云导播台的导播功能

通过预分配方式调度保证资源独享，稳定性

流媒体处理方式是基于LayerStack方式的混流策略，满足各种多布局多特效的功能需求。

音视频分开处理，灵活满足混音混流的需求。

云导播基本流程图:

前端创建业务场景（比如播单），然后进入到场景配置环节（输出的视频分辨率、码率是多少、编什么码、输出地址、背景色彩）、布局配置（怎么分屏、切屏）、视频源和组件配置（素材库、广告片等），完成后进入到场景应用，最后到了调度（某个机房某台机器）和流媒体处理，最后把这路流推到直播中心。

这其中，云导播台系统和直播中心的关系是它输出的结果会推给直播中心，同时直播中心也会拉一部分用户的流进行合并。

流媒体处理层包括的核心功能：

httpserver 【信令响应】。

httpclient 【异步状态回调】，每一路的状态通知给上层。

背景输出，当用户没有推流上来的时候需要背景。

多路视频源／画面／文字等混合 【混音／混画面】。

多线程读取视频源和素材。

编码，解码和输出。

流媒体处理流程：

首先网络层，从网络或本地协议读取视频源，读完需要解码，得出来是帧，这些视频帧和音频帧进行解码后处理，然后编码，得出packet，经过Mux合成，往后再经过网络或本地协议推出去实时流，或者写成本地文件。

其中混流的核心就是LayerStack混流方案，它就在视频帧处理和音频帧处理这块，用中文解释叫图层。每一个流媒体处理最后解码出来就是一帧图像，把图像和其他的流媒体处理的图像放到LayerStack中来，就完成了混流。

音视频Layer依赖其音视频源的URL做为Key来关联进行音画同步。

Blender算法是以LayerStack次序从上到下进行yuva 的alpha-blend。采用 source-alpha 的为源色的 和One-minus-source-alpha 为目标色的blender 算法。可参考glblendFunc()里面的算法。

LayerStack最后一个Layer是背景。所以输出的帧就是最后混在这背景上的图。

使用全量List来指定音视频的合并次序和显示，可根据List 来指定哪些音视频需要混或不混。

支持全量批处理和增量处理，其中全量处理： 删除全面的设置，并同时设置多个元素的Layer 同时生效。增量式处理： 仅修改某几个或者1个Layer的某些属性让它生效。

从混流方案中可以看到，业务和底层技术上音视频是分开处理的，原因是：

业务上存在仅取某源的音频或者视频的需求，比如主持人的声音在，用户看到游戏画面等场景。

技术流程上，音频和视频的编解码是各自的模块。

那么，混流的混其实是各个源的混画面、各个源的混音，最后将最终的音频和视频再进行混合。

四、衡量指标

怎么评判云导播做的好不好，我们从性能方面和能力方面来看。

性能：

切换时间：从导播人员切换指令到端上看到的画面的时间，这是最关键的。

混流后的流畅度和同步误差。

能力:

能支持多少路视频混合，取决于机器能力和算法以及方案策略。

能支持多高码率和分辨率的视频。

五、 云导播的潜在难点

1.同路流音画同步问题

由于需要进行后处理，所以视频和音频需要进行解码，然后再合并。

音频和视频的解码速度和性能，解码器内部的缓冲等不一致。

视频存在B帧概念，容易造成进去好几帧后才会开始解出第一帧。

传输过来的音视频序列化的音画交错不好。

某些非标流时间戳突变或者中途突然没有音频或者没有视频。

延迟缓冲不能太大。

2.多路流相互同步问题

各不同视频源的网络状况不一样造成同一时刻产生的帧并不是同一时刻到达服务端。

每个源的起始时间戳不一致，即不是参考同一个时间戳的。

3.网络的抖动

用户直播推流的上行抖动，会出现延迟

网络抖动会造成混流的画面卡顿，会影响同步和延迟策略。

4.机器性能问题

CPU 能够同时处理多少路流？涉及到 scale/blend/拉流等算法和策略。

主频 【代码的优化以及机器的计算能力】

核数 【代码的并行度和机器处理的并行度】

如果代码并行度不够，就不能用核数解决问题，只能用到主频，但是主频是个瓶颈，所以只能把代码并行度加高。

GPU 并行度代码和算法，40ms内要把所有的流媒体处理完成。

各种特效的算法以及数据策略等。

这些潜在的难点都是非常底层的，如果用户要自行开发云导播台，就要把这些难点逐一攻破。阿里云已经将底层封装了，用户只是使用上层服务，是不需要面对这些难点的。