前面我们介绍了用SRS搭建一对一通话，如果能将这个通话合成一个流，叠加视频和混音，转成RTMP流推送到直播，这就是连麦了。
如下图所示，我和志宏大神的一对一通话，可以认为是两个主播的连麦，我们可以把这两个视频画面叠加，把我们音频混音，然后转成一路RTMP流送到直播系统，比如CDN或者视频号直播：

视频合流非常非常消耗CPU，而且有很多种方式：
  • SRS+FFmpeg，SRS将WebRTC流转RTMP，FFmpeg将多路RTMP合流。优势：延迟小，音质好；缺点是命令行难度高。
  • SRS+OBS，方案和SRS+FFmpeg一样，不过用OBS来实现合流。优势：图形化界面更友好，音质好；缺点是延迟大有不同步风险较大。
  • OBS抓浏览器，OBS直接捕获浏览器窗口和电脑的音频。优势：可见即所得，依赖少；缺点是音质不如前面的方案。
下面一个个方案介绍。

SRS+FFmpeg
SRS+FFmpeg方案，我们在一对一通话的DEMO中，给出了使用FFmpeg合流的命令。如下图所示：
从这个图中，可以看到每个主播的RTMP流：

  • rtmp://192.168.3.6/live/311b0ef1
  • rtmp://192.168.3.6/live/30f66695

在这个DEMO中，我们把房间名作为了RTMP的app名称，把用户的display（昵称）作为了RTMP的stream名称。下图是播放合并的流，可以看到FFmpeg合流的延迟比较小，基本上没有不同步的问题（FFmpeg和SRS在一个局域网）。由于是直接拉的原始的RTC流，声音质量也比较好：

这个方案的缺点就是FFmpeg的命令比较复杂，调整起来不方便，不是可视化的。我们可以选择OBS代替FFmpeg做合流。
SRS+OBS
SRS将WebRTC流转成了RTMP流，而OBS可以将每个流都拉出来，非常方便的调整每个画面的位置和尺寸，如下图所示：
我们添加Media Source（媒体源），将File（文件）选项勾选掉，就可以输入RTMP的流，可以在DEMO页面中找到对应的RTMP流。

这个方案的缺点就是流的延迟变大，会造成不同步问题。如果对同步不敏感，比如不是探讨的对话，而是采访类型（主持人提问时间短，嘉宾单独说话比较久），也可以用这种方式。另外，未来如果OBS支持了更低延迟的方式，比如WebRTC拉流，那么这种方式也会比较好。
OBS
我们还可以直接用OBS捕获浏览器窗口，如下图所示：
这个方案的优势是不会造成不同步，和现有系统是完全不耦合的，完全可见即所得的方式。但由于无法调整每个画面的位置和大小，这种适合做会议转直播。另外，这种方式捕获的是电脑的扬声器和麦克风的音频，音质不如前面方案的那么好。
其他
还有一种方案，是可以将RTC的流送到MCU，比如SRS对接OWT，这样可以获得更好的质量和体验，适合有研发能力的团队。
继续阅读
阅读原文