共计 1750 个字符，预计需要花费 5 分钟才能阅读完成。
每每到 618、双 11 这样的大型流动的时候，每天都有几个重要的大 v 或者品牌直播须要保障。
以往的重点场次监播形式是这么造的：
对每路直播的源流、各档转码流别离起一个 ffplay 播放窗口，再手动调整尺寸在显示器桌面进行布局，排到一屏里来监播。
这样做的毛病：
- 操作简单，手动调整画面不美观
- 不同的拉流工夫点，起播工夫有误差，画面无奈协调一致
- 当拉多路流的时候，带宽也受限制，基本上拉 3 - 4 个 2m 码率以上的流本机就会卡顿了，此时如果流有问题，就不能精确判断卡顿起源了，查看起来也比拟吃力
展现形式是这样的：
ffplay 'rtmp://stream1' & ffplay 'rtmp://stream2' & ffplay 'rtmp://stream3' & ffplay 'rtmp:/stream4' & ffplay 'rtmp://stream5' & ffplay 'rtmp://stream6' & ffplay 'rtmp://stream7' & ffplay 'rtmp://stream8'PS: 这么多的窗口，点着是挺麻烦的😓
在咱们混流生产层能力齐备后，就开始推敲怎么将它赋能在平时或者大促的直播间重保上，同时也为了更加业余、更高效的进行监播，通过了一段时间的打磨，提炼了一个简略的混流编排性能。
它的工作模式是这样的：
在这里你能够创立混流工作，并反对你在一直流的状态下做到更新工作输出信息。
将要监播的直播流地址，须要展现的文字内容、布局形式、混流输入的模板配置进行下发，就能够拉到主动编排好的直播流地址。
它当初长这个样子：
最终出现进去的混流的成果是这样的😁：
也能够是这样的：
也能够出现其余的布局形式，目前还没做的那么丰盛，不过底层能力和 api 接口是都反对的，齐全灵便布局。
在混流工作运行过程中，能够自在批改混流输出源的配置。
这种新型的监播形式，能够直观的辨别源流、各档转码流的播放成果：画面内容是否失常，有无花屏、是否卡顿？
当呈现问题时可能领导咱们疾速做出决策：
- 转码流有问题，源没有问题，疾速排查工作日志，定位是什么起因导致
- 转码流有问题，源也有问题，迅速问题源流的流详细信息，定位问题并告诉业务方进行操作
- 支流都有问题，备流没问题，告诉业务方迅速切备流
还有其余的一些有点：
- 操作简略不便，还能够记忆配置，下次间接批改
- 每个播放端只需拉一路流，节俭本地带宽
- 最多能够反对 16 路混流，一屏监播 16 路流的画面
- 一直流，轻松切换各种布局
- 一直流，轻易操作流的增加、删除、批改
- 不便分享给其他人进行播放
混流布局性能的底层实现框架：
- 定义通用的 layout 布局构造 -BasicClip
{
ClipType string `json:"clipType"`
LeftMargin int `json:"leftMargin"`
PosX *int `json:"posX"`
PosY *int `json:"posY"`
Width int `json:"width"`
Height int `json:"height"`
}在此基础上扩大出更丰盛的 BorderClip, TextClip, ImageClip 等类型，来满足不同的布局元素设计。
- 定义通用的 videoMask 构造，它能够蕴含多个 clip interface, 即各种 clip 元素，在 videoMask 中各个 clip 是同一个 layer 的，只容许在限定的尺寸中进行布局。
type VideoMask struct {
Layer int `json:"layer"`
Clips []interface{} `json:"clips"`
}- 每个输出的视频流，能够蕴含多个 videoMask, 多个 videoMask 在最终 overlay 的时候，按定义的 layer 先后顺序进行铺叠，以达到最终的预期视频布局成果。
利用场景拓展
- 什么状况下应用混流？
◦当设施不反对同时拉多路流时应用混流，比方 sip 入会的场景。
◦须要多个视频画面、多个音频流合成一个直播流时应用混流，比方会议录制（rtc 协定）场景、教育类场景（直播老师和学生的画面）、直播连麦的场景等。
总结：此次能在 618 重保期间施展它的价值，也算是有所得。心愿当前能够在日常直播、展会等其余重要直播流动中发挥作用。对于混流的产品介绍以及更多的应用场景也会在后续的文章中一一开展，敬请期待。
作者：京东科技 孟晓伟
起源：京东云开发者社区