-
单主播直播视频流处理流程：
单主播直播时，直接根据该主播流地址向CDN服务器推流即可。观众端获取该主播拉流地址拉取视频。
-
PK直播视频流处理流程：
PK直播比单主播复杂很多，以下有三种实现方案，分别展开讨论，并分析优缺点。
方案一：
视频流不合并，观众端拉取两路流同时播放。这种方案观众端承担大部分工作。
优点： a. 实现简单。只需在直播间多加一个播放器就能解决 b. 延迟低。推拉流过程无太多中转，网络等外部条件正常情况下，延迟率与单主播模式相近 c. 无需额外消耗服务端资源
缺点： a. 对观众端设备要求高。观众端需同时播放两路视频，流的解码、音视频同步等工作翻倍。主播端此时也是作为观众端，推流的同时还需拉取pk对方的流。 b. 观众端带宽翻倍。同时拉取两路流，要保证正常播放，需更高的网速 c. 无法保证两路流同步。两路流分开推，分开拉，相互独立无同步操作。同步强依赖网络 d. 设备处理强度大，发热严重
方案二：
主播端完成合流操作。主播端拉取到PK对方直播流后解码与本地采集重新编码构造RTMP包推流。此时观众端只需拉取合成后的一路流
优点： a. 可保证两路流的同步问题 b. 无需额外消耗服务端资源
缺点： a. 对主播端设备要求较高，短时间内需处理拉流、合流、推流工作，主播端设备需较高性能 b. 主播端与观众端存在明显延迟。观众端拉取的流是主播端先拉pk对方流、合流、推流三个步骤完成后拉取的结果。延迟率受设备处理性能和网络影响不可控 c. 设备处理强度大，发热严重
方案三：
服务端合流中转分发。主播端照常需要拉取PK对方的直播流，但合流过程放在了服务器端处理。另开服务器完成合流，完成后向CDN服务器推流，保证观众端不切换拉流地址
优点： a. 可保证两路流的同步问题 b. 减轻客户端设备的处理压力，规避不同性能设备带来的处理延迟问题 c. 客户端处理简单，只需主播端多拉次流播放即可
缺点： a. 需服务端配合完成合流、中转工作 b. 主播端与观众端存在延迟，但延迟比方案二低。主播端推流有一步先推流到合流服务器再推到CDN服务器，多一个中转环节，多一层延迟
总结：
方案一：不合流方案。基本不考虑使用，写个直播PK Demo还行，稍微有点用户量就无法保证观众端不同层次配置设备的处理能力以及网络、设备发热问题
方案二：主播端合流。该方案算一个折中方案，也具备一定的适用场景。该方案有两个大缺陷：第一，要求主播端具备高性能设备；第二，主播端与观众端延迟稍大。对于第二点，PK玩法主要是保证PK主播双方同步，个人觉得主播与观众间的延迟个人觉得还是可以接受。低于缺陷一，自营主播，可以很容易从源头解决主播端设备性能问题
方案三：从各方面来说，方案三都是很好的方案，适合大播放量业务。作为一个Android开发来说我是挺乐意的，因为复杂工作都在服务端。
鉴于方案三的优越性，以及方案三本身的技术难度较高，所以衍生出很多第三方合流SDK，如声网，声网主要处理环节如下图：
上图中信令服务器主要起到的作用就是在PK特定节点(开始PK、结束PK、转码、合流等)通知客户端执行相应操作，信令的准确性与到达率直接影响到各个环节的执行情况
声网服务器有一个channel(频道)的概念，为每一次PK提供一个channelId，加入同一个频道成功之后再转码、设置推流地址 声网实现服务端合流方案主要分以下几步操作：
-
初始化
RecEngine -
注册回调事件监听
-
加入频道
-
设置转码
-
设置推流地址 如下图：
- 为什么有第四步设置转码 推流设备多种多样，采集的视频格式、分辨率、码率、帧率也不尽相同。所以，为了适应不同的设备和网络环境，推流到声网服务器时需要重新统一转码参数后推流。保证在转码时可生成多个分辨率的资源，以兼容不同的设备
