「直播」这个概念，相信大家都不陌生，简单来说就是通过终端设备进行音视频采集，再通过网络上传至服务器，最终推送至相应播放地址供人观看的一种方式。这种通过音视频传达信息的表现形式，相较于传统的图文信息，更加生动形象，可传达的内容也更加丰富。因此，无论是电商带货，还是教育授课，通过直播，都有了更好的推广方式。

大家在享受直播带来的信息爆炸时，是否对直播的发展历程有过好奇呢？这里，我们一起看看直播的场景和方案是如何一步步演变的；作为一站式智能视频云服务商，七牛云直播场景的最佳实践方案是怎样的。

直播方式的演进

早在 2016 年左右，随着移动互联网的兴起，移动通信技术以及音视频技术的逐渐成熟，音视频直播场景开始步入大众视野。从最开始比较火热的游戏直播，再到后续推出的娱乐秀场直播，都迅速占领了各大平台的首页。当时的直播场景，主播和观众之间交互简单，没有音视频层面的交互需求，对实时性要求也不高，一般情况下 3-5s 左右的延时是在可接受范围内的。

因此，其主要直播实现方式是通过 OBS 或者移动端上的推流 SDK 将音视频数据通过 RTMP 推送到流媒体服务上，然后进行 CDN 分发，最后观众端通过播放器进行拉流观看。

虽然直播形式比较简单，但是结合 IM 和播放器等技术，从主播端到观众端形成了完整的闭环，在此中间还可以插入三鉴、直播内容落存储等服务，有着非常不错的普适性。所以在前几年，无论是秀场直播，还是游戏直播，大家普遍都会通过这种方式来实现。

之后，直播的娱乐性要求提高，主播直播、观众拉流观看的方式已不足以满足业务的需要，两个角色需要能够进行更进一步的沟通，所以推出了观众可以上麦的直播形式，观众可以向主播申请上麦，并进行音视频通话。在这种需求下，传统的推流 SDK 已经不能满足该场景的实现了。

因此便出现了支持客户端合流的 RTC SDK，通过 RTC SDK 在客户端将主播和上麦观众的画面进行合流，再通过流媒体服务、CDN 等一系列分发方式推送给观众。

这种实现方式虽然满足了观众上麦的需求，但是从上图可以看出，该方式需要终端设备进行客户端合流，增加了推流终端的设备功耗的同时对推流终端设备的性能也有了一定的要求。

很显然，这不是一个最佳的实践方案。

随着直播互动需求的日益增强，主播和观众的交互更加多样化，甚至主播之间都有了交互的需求，比如直播 PK 的场景。这样客户端合流方案所特有的弊端就变的更加明显且不可忽略。

既然有客户端合流的方案，那么就对应的存在服务端合流的技术方案。

服务端合流，顾名思义，是将服务端作为媒体数据的路由转发端，将参与互动的一端的媒体数据转发到其他端，同时，由于服务端可以获取到各端的音视频媒体数据，也就可以更方便进行合流以及 RTMP 转发的工作。这种方案很大的改善了对推流终端设备要求过高的问题。

如上图所示，QRTC 代表实时音视频通话的服务端，负责媒体数据的转发，以及 RTMP 直播流的推送，该方案通过服务端合流的方式，减少了客户端合流所带来的编码损耗，既解决了客户端合流对设备性能有要求的弊端，又可以灵活的控制 RTMP 流的合流和转发等操作。因此，服务端合流的技术已经成为了目前最为推荐的直播场景实现方式。

如何实现直播场景

正如上所述，需求的不断创新推动了音视频技术的发展，而音视频技术的发展又为需求的创新提供了更多的可能，从最开始的游戏直播、秀场直播、观众可上麦的直播等传统直播场景，到当下十分火热的 PK 直播场景，再到近期兴起的小房间连麦直播场景，都完美地将当下所能利用的技术具像化地呈现到大众视线。

那么，以当下最新的技术，要如何快速的搭建出一套完整的直播场景呢？这里，我们以七牛云「实时音视频产品」作为技术支撑，来看看七牛云实时音视频是如何以一种最佳的方式来实现当下比较火热的几种直播场景。

1. 直播 PK 场景

直播 PK 场景，即两个主播之间进行带有竞技导向的连麦互动，在主播 PK 过程中，他们各自的粉丝不仅仅作为旁观者，还是各自主播背后的支持者，通过打赏、点赞等方式参与其中，以最终获得 PK 积分的多少来判定 PK 的结果。这种玩法的好处是显而易见的，PK 在拉近了主播和粉丝距离的同时，也使得观众变得更加积极，直播间气氛更加活跃，也更能刺激粉丝消费。此外，两个主播之间也可以相互导量，从而获取更多的粉丝。

 那么，想要实现直播 PK 场景，都有哪些方案，会用到哪些技术呢？

 从技术演进上来看，直播 PK 场景的技术实现方式大体上有两种，一种是通过推流 SDK + 播放器 SDK 来实现；另一种是通过 RTC SDK + 播放器 SDK 来实现。

对于第一种实现方式，主播端需要同时集成推流 SDK 和播放器 SDK，在用推流 SDK 推流的过程中，同时使用播放器 SDK 拉流，以此来实现 PK 的效果，但由于 RTMP 的直播流时延本身较长，所以需要同时对推流 SDK 和播放器 SDK 做出特殊的优化，如减小推流端 gop 的大小，减小播放器缓冲 buffer 的大小等。在经过一系列优化后，才能够基本达到一个 PK 的效果。

该方式虽然可以实现预期场景，但是这种技术实现的缺点也是显而易见的。比如我们把播放端的 buffer 调的尽可能小，在网络条件不好的情况下，就很容易出现卡顿的现象。另外，由于推流 SDK 只是一个单向的推流服务，不会过多的考虑双向场景下的回声消除，所以这种方式也比较容易产生回声的现象。

也是基于上述的原因，这并不是一个合适的实现方式，因此，使用这种方式实现直播 PK 场景的用户虽然有，但并不多。

对于第二种实现方式，由于 RTC 本身就是以实时音视频通话为主要目的的技术产物，具有超低延时的特性，对于音频 3A、抗弱网能力都提供了比较成熟的解决方案，同时 RTC 服务端合流的方案也趋于成熟，不再对客户端有过高的性能要求，而基于服务端合流的方案优势，也可以很方便的实现 RTMP 直播流的转推。

所以这种方式天然的就比较适合用来实现直播 PK 的场景，这也是我们比较推荐的实现方式。

那么，直播 PK 场景具体是如何通过 RTC SDK 和播放器 SDK 来实现的呢，下面我们通过两张图来了解一下具体的实现方式：

首先，PK 前，主播单独直播场景的数据传输链路如下：

按照步骤拆解开来，主要有如下几步：

1. 两位主播分别通过  RTC SDK 创建自己的房间，并发布音视频媒体流。

2. 主播通过「开启单路转推」的方式，将本地采集的音视频媒体流以 RTMP 的形式推送到流媒体服务。

3. RTMP 直播流经由 CDN 分发，观众端通过播放器 SDK 进行拉流观看。

当两位主播需要进行 PK 时，数据传输链路如下：

 从直播切换到 PK，其核心步骤有如下几步：

1. 主播 A 经由业务服务器向主播 B 发起 PK 请求，主播 B 同意后，两位主播「开启跨房媒体转发」，将各自的音视频媒体流转发到与之 PK 的主播所在的房间，跨房媒体转发成功后，两位主播便可在自己的房间订阅到远端主播的音视频媒体流。

2. PK 主播订阅到远端的媒体流后，「创建合流转推任务，停止单路转推任务」，将自己和远端主播的音视频流通过云端合流转码的方式进行混合，并以 RTMP 的形式推送到流媒体服务，通过 CDN 进行分发，将合流任务的直播流推送给拉流端观众。

3. PK 结束后，两位主播「停止各自的跨房媒体转发」，同时「创建单路转推任务，停止合流转推任务」，将自己的音视频流以 RTMP 的形式推送到流媒体服务，并通过 CDN 分发给观众。

4. 直播结束，离开房间。

 从上述步骤可以看出，整个过程并不是那么复杂，主要的需要功能点有两个：「跨房媒体转发」和 「CDN 转推」。

当然，对于 RTC SDK + 播放器 SDK 的实现方式，也有一些需要特别注意的地方，由于该方案是基于 RTC CDN 转推来实现的单直播和 PK 直播的切换，那么如何保证单直播和 PK 直播切换过程中的速度和平滑度，就成了优化体验至关重要的问题。

对于切换的速度，可以利用「抢流的机制」来解决。抢流是指两路直播流争抢同一个流地址的推流权限，通常在一定的规则下，其中一路成功获取推流权限后，另外一路会被终止掉，通过这样单路转推和合流转推直播流抢流的方式，就可以保证切换的速度。

对于切换的平滑度，由于引入了抢流的机制，出于流媒体服务对推流节点负载均衡的评估，可能会出现两路直播流被推送到不同的节点，导致拉流端拉流观看回源的过程中概率性出现已有 gop 被重复播放的现象，这将严重影响到切换的平滑度。为了解决这个问题，可以对回源拉流的逻辑进行优化，对已接收到的包进行编号，同时对已编号且重复的视频帧进行丢弃处理，进而达到了消除画面回退，平滑切换的目的。

经过上述优化，直播 PK 连麦的切换过程，在抢流机制以及合理的 gop 配置情况下，可以做到更加平滑顺畅，实现秒级切换的效果。

2. 传统直播场景

 直播 PK 场景虽然很火热，但是并不能取代传统的直播场景，那么传统的直播场景实现又是如何与时俱进的呢？基于上述直播 PK 场景的实现，不难看出，「RTC SDK + 播放器 SDK 结合使用的方式，具有很强的可扩展性」，完全可以替代早期的方案来实现传统的直播场景：

 单主播直播场景，如电商直播，可通过 RTC SDK 单路转推的方式替换推流 SDK 进行 RTMP 直播流的推送，观众端通过播放器 SDK 拉流播放。

直播连麦的场景，如可上麦的秀场直播，和直播 PK 场景类似，上麦观众通过加房间发布音视频的方式上麦，主播订阅后，通过单路转推和合流转推的切换来实现 RTMP 直播流的推送，观众端通过播放器 SDK 拉流播放。

合流直播的场景，如游戏直播（游戏画面和主播画面结合），可通过 RTC SDK 合流转推的方式进行 RTMP 的推送，观众端通过播放器 SDK 拉流播放。

 3. 小房间连麦直播场景

 近几年，受到大环境影响，很多人不得不居家办公，居家网课等。这便带动了另一种直播场景的出现。那就是「通过小房间连麦实现的直播场景」，这种场景多见于教育和婚恋等领域。和传统的秀场直播 PK 玩法相比，这种场景不需要播放器 SDK，对观众人数有一定的限制，同时也需要观众频繁上下麦。

以婚恋场景来举例，有的场景是红娘和待相亲对象在线上交流，观众在观看的过程中，可以根据自己的意向选择是否上麦做更进一步的了解，这种场景对观众端的实时性以及上下麦的灵活性有着很高的要求，那么观众端通过 RTMP 拉流观看显然就不是很合适了。

对于这种小房间连麦的直播场景，可以使用纯 RTC 的方式来实现，观众可以通过 RTC 加入房间订阅的方式进行直播的观看，在需要上麦时，随时发布自己的音视频媒体流来和对方进行沟通。实现过程的数据传输链路可以参考下图：

未上麦观众通过订阅的方式观看远端主播和上麦观众的音视频流，同时可以随时上麦参与互动；上麦观众发布自己的音视频流，订阅主播和其他上麦观众的音视频流，同时也可以随时停止上麦的动作，转换身份为观众。整个逻辑「仅通过对音视频流的发布和订阅即可实现」，控制操作很灵活，实现起来对于 RTC SDK 来说，也是非常简单的。

总结 

以上，就是通过「七牛云实时音视频」产品，来实现常见直播场景的方式。

随着音视频技术的不断发展，从编码到传输再到分发，整个音视频处理链路的技术都变得越来越成熟，这也使得越来越多的想法都有了被实现的可能。直播场景的实现，万变不离其宗，核心逻辑是依赖 「RTC 的房间交互能力」实现实时音视频通话，再结合「跨房媒体转发」和「CDN 转推」的功能实现直播流的（合流）推送。

随着直播场景的不断推陈出新，七牛云也将继续探索新兴直播连麦场景的实现。