直播-PK连麦

单主播直播视频流处理流程

如上图，主播端向CDN服务器推流，推流地址假定为rtmp://xxx。观众端观看该主播时，拿到该主播的观看地址（假设地址为xxx.flv）直接拉流即可。

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主播双方同步，个人觉得主播与观众间的延迟个人觉得还是可以接受。低于缺陷一，自营主播，可以很容易从源头解决主播端设备性能问题

方案三：从各方面来说，方案三都是很好的方案，适合大播放量业务,因为复杂工作都在服务端。