随着移动网络网速的提升与资费的降低，视频直播作为一个新的娱乐方式已经被越来越多的用户逐渐接受。特别是最近这几年，视频直播已经不仅仅被运用在传统的秀场、游戏类板块，更是作为电商的一种新模式得到迅速成长。
云直播提供的推流方式有两种：
-
1）一是通过集成SDK的方式进行推流（用于手机端开播）；
-
2）另一种是通过RTMP协议向远端服务器进行推流（用于PC开播端或专业控台设备开播）。
除去推拉流，该云平台也提供了云通信（IM即时通讯能力）和直播录制等云服务，组成了一套直播所需要的基础服务。
这种推拉流架构的逻辑原理是这样的：
-
1）主播端和用户端分别与云直播的互动直播后台建立长连接；
-
2）主播端通过UDT私有协议向互动直播后台推送音视频流；
-
3）互动直播后台接收到音视频流后做转发，直接下发给与之建立连接的用户端。
这种推拉流方式有几点优势：
-
1）只需要在客户端中集成SDK：通过手机就可以开播，对于主播开播的要求比较低，适合直播业务快速铺开；
-
2）互动直播后台仅做转发：没有转码，上传CDN等额外操作，整体延迟比较低；
-
3）主播端和用户端都可以作为音视频上传的发起方：适合连麦、视频会话等场景。
之前介绍了通过手机SDK推拉流的直播方式，看起来在手机客户端中观看直播的场景已经解决了。
那么问题来了：如果我想要在H5、小程序等其他场景下观看直播，没有办法接入SDK，需要怎么处理呢？
这个时候需要引入一个新的概念——旁路推流。
旁路推流指的是：通过协议转换将音视频流对接到标准的直播 CDN 系统上。
目前云直播开启旁路推流后，会通过互动直播后台将音视频流推送到云直播后台，云直播后台负责将收到音视频流转码成通用的协议格式并且推送到CDN，这样H5、小程序等端就可以通过CDN拉取到通用格式的音视频流进行播放了。
目前蘑菇街直播旁路开启的协议类型有HLS、FLV、RTMP三种，已经可以覆盖到所有的播放场景，在后续章节会对这几种协议做详细的介绍。
推拉流架构3：RTMP推流
随着直播业务发展，一些主播逐渐不满足于手机开播的效果，并且电商直播需要高保真地将商品展示在屏幕上，需要通过更加高清专业的设备进行直播，RTMP推流技术应运而生。
我们通过使用OBS等流媒体录影程序，对专业设备录制的多路流进行合并，并且将音视频流上传到指定的推流地址。由于OBS推流使用了RTMP协议，因此我们称这一种推流类型为RTMP推流。
我们首先在云直播后台申请到推流地址和秘钥，将推流地址和秘钥配置到OBS软件当中，调整推流各项参数，点击推流以后，OBS就会通过RTMP协议向对应的推流地址推送音视频流。
这一种推流方式和SDK推流的不同之处在于音视频流是直接被推送到了云直播后台进行转码和上传CDN的，没有直接将直播流转推到用户端的下行方式，因此相比SDK推流延迟会长一些。
优势主要是：
-
1）可以接入专业的直播摄像头、麦克风，直播的整体效果明显优于手机开播；
-
2）OBS已经有比较多成熟的插件，比如目前蘑菇街主播常用YY助手做一些美颜的处理，并且OBS本身已经支持滤镜、绿幕、多路视频合成等功能，功能比手机端强大。
劣势主要是：
-
1）OBS本身配置比较复杂，需要专业设备支持，对主播的要求明显更高，通常需要一个固定的场地进行直播；
-
2）RTMP需要云端转码，并且本地上传时也会在OBS中配置GOP和缓冲，延时相对较长。
高可用架构方案：云互备
业务发展到一定阶段后，我们对于业务的稳定性也会有更高的要求，比如当云服务商服务出现问题时，我们没有备用方案就会出现业务一直等待服务商修复进度的问题。
因此云互备方案就出现了：云互备指的是直播业务同时对接多家云服务商，当一家云服务商出现问题时，快速切换到其他服务商的服务节点，保证业务不受影响。
直播业务中经常遇到服务商的CDN节点下行速度较慢，或者是CDN节点存储的直播流有问题，此类问题有地域性，很难排查，因此目前做的互备云方案，主要是备份CDN节点。
目前蘑菇街整体的推流流程已经依赖了原有云平台的服务，因此我们通过在云直播后台中转推一路流到备份云平台上，备份云在接收到了直播流后会对流转码并且上传到备份云自身的CDN系统当中。一旦主平台CDN节点出现问题，我们可以将下发的拉流地址替换成备份云拉流地址，这样就可以保证业务快速修复并且观众无感知。即时通讯开发
视频直播数据流解封装原理
介绍流协议之前，先要介绍我们从云端拿到一份数据，要经过几个步骤才能解析出最终需要的音视频数据。
第一步：解协议。
协议封装的时候通常会携带一些头部描述信息或者信令数据，这一部分数据对我们音视频播放没有作用，因此我们需要从中提取出具体的音视频封装格式数据，我们在直播中常用的协议有HTTP和RTMP两种。
第二步：解封装。
获取到封装格式数据以后需要进行解封装操作，从中分别提取音频压缩流数据和视频压缩流数据，封装格式数据我们平时经常见到的如MP4、AVI，在直播中我们接触比较多的封装格式有TS、FLV。
第三步：解码音视频。
到这里我们已经获取了音视频的压缩编码数据。
我们日常经常听到的视频压缩编码数据有H.26X系列和MPEG系列等，音频编码格式有我们熟悉的MP3、ACC等。
之所以我们能见到如此多的编码格式，是因为各种组织都提出了自己的编码标准，并且会相继推出一些新的议案，但是由于推广和收费问题，目前主流的编码格式也并不多。
获取压缩数据以后接下来需要将音视频压缩数据解码，获取非压缩的颜色数据和非压缩的音频抽样数据。颜色数据有我们平时熟知的RGB，不过在视频的中常用的颜色数据格式是YUV，指的是通过明亮度、色调、饱和度确定一个像素点的色值。音频抽样数据通常使用的有PCM。
第四步：音视频同步播放。
最后我们需要比对音视频的时间轴，将音视频解码后的数据交给显卡声卡同步播放。