背景

当下视频直播如此红火，打造一个在线直播间涉及到哪些技术呢/p>

视频直播由主播的直播端以及观众的观看端组成。一个简单的观看端最起码应包含播放器以及聊天室。下面就围绕这两大模块来讲述相关技术。

视频直播，可以分为视频采集、前处理、编码和封装、传输、解封装和解码、播放这几个环节。

直播端通过硬件设备采集音视频数据，经过前处理以及编码、封装后，还要传输到观看端。这一步一般交由CDN接力完成。推流端会把视频流推到源站，CDN从源站拉流，拉流成功后编码封装成不同的格式提供各观看端播放。简单示意图如下：

( 络引用图片)

接下来讲一下观看端的基本要求：

多终端观看

观看稳定、不卡顿

延迟低、高并发

多终端观看

首先明确需要支持的终端，有移动端APP（iOS、Android）、移动端浏览器、小程序、PC浏览器、PC 客户端。对于PC浏览器，一般支持到IE8。并且，由于Chrome浏览器默认屏蔽Flash，所以在PC浏览器中采用的策略为：优先在兼容H5的浏览器使用H5播放，否则降级使用Flash播放。两者支持的直播播放视频格式差异如下：

Flash支持rtmp或 http-flv 直播播放。延时~3秒。

H5支持M3u8直播播放。延时~15秒。

观看稳定、不卡顿

造成视频直播卡顿的原因可能是多方面的，涉及到直播端、 络、观看端。

直播端

主要问题有硬件配置太低、推流参数配置问题、音视频时间戳不同步。可以通过以下措施解决：

升级硬件、软件设置，提高兼容性和容错率 ( 这部分是硬装，必须有好的装备才能有好的推流质量啊 )。

使用硬编硬解方案，充分利用GPU加速。

降低视频码率，选择流畅、标清画质或者使用动态码率推流。

络

主要问题有 络抖动、拉流服务器与观看端链路过长，可以通过以下措施解决：

选用稳定的运营商 络并合理布局CDN节点。

使用充足的 络带宽。

观看端

在 络上观看视频，缓冲区就是在你看视频时提前储存部分视频数据，当数据到达一定的量后再播放画面，使得播放更流畅。若设置得过小，在 络不稳定时就无法流畅地连续播放；若设置过大则会累积时延。所以要设置一个适中的缓冲区。

延时低、高并发

我们知道，视频其实是由一帧一帧的图像构成的，RTMP基于TCP不会丢包，所以当 络状态差时，服务器会将包缓存起来。等 络状况好了，就一起发给观看端，导致观看端累积太多视频帧数据，延时随时间增长而增加。对于这个问题，除了上文提及的设置适当的缓冲区长度外，还可以增加追帧和丢帧操作实现播放追赶。

Flash代码：

videojs修改bufferTime=0.01

链接:https://pan.baidu.com/s/1_-xB7O1O36pEkEEW9024zA
密码:3r6u

H5代码：

另外，如果用到FLV.js播放视频，可以开启它的Worker特性，多进程解析优化延迟 ，并减少buffer。

聊天室

即时聊天IM服务既要保证实时性，可靠性，又要抗住高并发。在实现过程中我们使用以下方法解决。

1、传输模式优先选择 WebSocket，若不支持则降级为轮询。

2、Node.js 服务器因消息并发大导致性能低下。

通过以下方案极大的优化了聊天室的稳定性和可靠性。

（1）使用命名空间的功能

命名空间的作用就是把消息限定在一定范围内传播。对于一些不需要全局接收的消息就加上命名空间，可以极大的节约资源的传输。

（2）聊天消息队列

观众进入聊天室房间会广播登录消息，比如房间内同时有2W人，每个人登录要对房间内所有人广播”我”登录了，相当于发送了2W条消息。若并发量大，对服务器性能要求极高。使用聊天队列消息分批显示可以防止同时处理大量消息，提高处理性能。

（3）服务器弹性伸缩

祭出最后的大招，能优化的已经极力优化了，那剩下的事情就是配置服务器弹(jia)性(fu)伸(wu)缩(qi)。

3、掉线重连机制。

掉线会触发disconcent 事件，监听它再创建socket连接即可。心跳检查即定时发送一次消息，保持连接状态。