首先我最近在做一个视频直播的功能（正在谈的项目有这个功能，但是还没谈好），还有一个多人视频的demo（demo是为了竞标，三五个人能正常使用就行了。）
然后在这之前一点直播经验都没有的我有点方。各种百度解决问题。然后找到了一种ffmpeg+nginx的解决方案。后来又看了一些直播的知识，看到一个帖子说的挺好的，虽然帖子最后居然是个打广告的。。
前期的叙说我是看明白了，并且信了。然后因为不是一个平台，我也不知道怎么保存这个帖子，所以就粘贴了一份啊，先附上这个文章的链接：
RTMP，WebRTC，UDP 三种互动直播方案的优劣比较
正文
据《 2017 年中国直播行业研究报告》显示，直播行业用户人数达到了 4.2 亿，同比增速超过 50%，整体直播市场的总营收达到 304.5 亿元，比去年同期增长近 39%。
直播作为一种新兴社交方式，已然成为一项互联网基础应用，也成为技术大牛们探索更高效轻量的技术方案的新阵地。
由于用户对社交互动的强烈需求，“互动直播”已成为直播发展趋势。通过视频连麦，用户之间可以进行视频互动，达到更深层次的超越语言文字的交流。
那么互动直播是怎样实现的呢？主要有以下几种可以实现的技术方案：
基于RTMP 和 CDN 技术的连麦
基于 WebRTC（P2P）与旁路直播的连麦
基于低延时网络的连麦
那这三种技术方案该如何权衡选择呢？它们又有何优劣呢？
基于 RTMP 技术的连麦
当有连麦者时，则主播端和连麦端，都分别推一路 RTMP 流到 CDN，CDN 再将这两路 RTMP 流发送给观众端，观众端将两路 RTMP 流合成为一个画面。
RTMP 是基于 TCP 的标准协议，与 CDN 架构兼容，对客户来说在现有单向直播架构上，接入成本比较低，但是缺点也很明显：
主播与连麦者交互时，声音会产生干扰，形成回音；
播与连麦者进行交互，在 CDN 中传输延时较大；
观众端要接收两条视频流，带宽、流量消耗过大，并且两路视频流解码播放，耗费CPU等资源也非常多。
基于 WebRTC 方式的连麦
WebRTC 是 Google 公司的开源技术，降低了音视频通信的接入门槛。也有公司采用该项技术实现连麦。主播与连麦 用户采用 P2P 方式进行交互，然后在主播端进行混流，然后在 CDN 上进行混流，发送到观众端。
WebRTC 的好处在于用户体验好，不需要安装东西，分享一个链接就可以看。
但这套方案需要主播端上传两路视频：一路 P2P 与连麦者进行交互，一路使用 RTMP 推到 CDN。还要下载一路视频：连麦者P2P发送过来的交互数据。对主播端带宽需求较高。
另外，主播端需要进行多路视频的编码、解码，又对主播端设备配置要求较高。而由于主播端和连麦者经过 CDN 合并成一路，无法实现主播端和连麦者视频大小窗口切换。
基于低延时网络的连麦
基于 UDP 的私有协议与 RTMP 相比具有先天的优势，它是面向无连接的，避免了 TCP 做网络质量控制所需要的开销，能够做到比较低的延迟。
但是私有协议的兼容性不好，如果采用该方案也需要解决一系列的技术问题：
UDP 的可靠性传输如丢包重传、网络抖动的处理
网路拥塞的控制算法
在全球节点的部署与智能调度
各种端的全面支持
而以上问题都是在短期内很难实现的。
基于 RTMP 和 CDN 技术的连麦方案，对于产品来说非常可靠稳定，但可靠的同时延时也在增大，且使用两路 RTMP 推流拉流既耗带宽又耗 CPU。基于 WebRTC P2P 方式的连麦，接入门槛低，用户体验好，却对主播端带宽及设备配置要求较高。基于低延时网络的连麦看起来很美，但私有协议的兼容性令人头大。
