直播平台搭建与相关资料

采用nginx+hls/rtmp+video.js方式

搭建过程如下

1、下载nginx-rtmp-module： git clone https://github.com/arut/nginx-rtmp-module.git

2、安装nginx： wget http://nginx.org/download/nginx-1.8.1.tar.gz tar -zxvf nginx-1.8.1.tar.gz cd nginx-1.8.1 ./configure --prefix=/usr/local/nginx --add-module=../nginx-rtmp-module --with-http_ssl_module
make && make install add-module为下载的nginx-rtmp-module文件路径。 安装时候可能会报错没有安装openssl，需要执行命令： yum -y install openssl openssl-devel

3、修改nginx配置文件： vi /usr/local/nginx/conf/nginx.conf rtmp {

server {   
 
    listen 1935;  #监听的端口 
 
    chunk_size 4000;   
       
        
    application hls {  #rtmp推流请求路径 
        live on;   
        hls on;   
        hls_path /usr/share/nginx/html/hls;   
        hls_fragment 5s;   
    }   
}

}

hls_path需要可读可写的权限。

修改http中的server模块： server { listen 81; server_name localhost;

#charset koi8-r; 

#access_log  logs/host.access.log  main; 

location / { 
    root   /usr/share/nginx/html; 
    index  index.html index.htm; 
} 

#error_page  404              /404.html; 

# redirect server error pages to the static page /50x.html 
# 
error_page   500 502 503 504  /50x.html; 
location = /50x.html { 
    root   html; 
}

启动nginx /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf

整理的资料与相关描述如下

### 完整过程
```
视频采集->rtmp
视频前处理->美颜
编码->H.264
视频后处理->水印
推流
CDN分发
终端解码
渲染
```

### 各个流程分析
```
采集，iOS是比较简单的，Android则要做些机型适配工作，PC最麻烦各种奇葩摄像头驱动，出了问题特别不好处理，建议放弃PC只支持手机主播，目前几个新进的直播平台都是这样的。

前处理，现在直播美颜已经是标配了，80%的主播没有美颜根本没法看。美颜算法需要用到GPU编程，需要懂图像处理算法的人，没有好的开源实现，要自己参考论文去研究。难点不在于美颜效果，而在于GPU占用和美颜效果之间找平衡。GPU虽然性能好，但是也是有功耗的，GPU占用太高会导致手机发烫，而手机发烫会导致摄像头采集掉帧，可能原因是过热会导致CPU降低主频。

编码，肯定要采用硬编码，软编码720p完全没希望，勉强能编码也会导致CPU过热烫到摄像头。硬编码兼容性又是一个大坑，android上要有人去填。编码要在分辨率，帧率，码率，GOP等参数设计上找到最佳平衡点。

传输，自己做不现实，交给CDN服务商吧，也就是贵了点，相信有志于做直播平台改变世界的你不差钱。假设2WPCU大约每月带宽费用100万左右，因为清晰流畅的720p要1.5mbps左右。CDN只提供了带宽和服务器间传输，发送和接收端的网络连接抖动缓冲还是要自己写的。不想要卡顿，必然要加大缓冲，会导致延迟高，延迟高影响互动性，要做权衡。

解码，也肯定要硬解码，目前手机普遍支持硬解了，只是android上还是有兼容性大坑要填。

渲染，这个难点不在于绘制，而在于音画同步，目前几个直播做得都不好。

此外音频还有几个坑要填，比如降噪，音频编码器的选择，各种蓝牙耳机，各种播放模式的适配等，如果你想做主播和观众连线聊天，还有个回声消除问题。

以上是媒体模块，还有信令控制，登录、鉴权、权限管理、状态管理等等，各种应用服务，消息推送，聊天，礼物系统，支付系统，运营支持系统，统计系统等。

后台还有数据库，缓存，分布式文件存储，消息队列，运维系统等。
```

### 容易发现的问题
```
PC、Android、iOS三大平台（一般互联网创业项目标配）
每个平台要做2种端：面向客户的直播端，和面向主播的推流端（标配x2）
视频编码涉及非常多的技术参数和细节（领域特殊技术）
完整的礼物系统、支付系统、运营系统、任务系统（不亚于一般页游项目）
即时聊天IM服务（弹幕，既要保证实时性，又要抗住高并发）
视频推流拉流链路依赖第三方CDN（超越一般创业项目的运维成本）
因为涉及钱的问题，经常与各种黑暗势力斗争（色情、广告、刷小号、刷充值、告侵权、DDoS等等）
```
 
### 系统层次结构  
最上层为各个设备平台的推流与播放器  
中间层为视频直播、录播、转码、鉴权、内容审核  
最底层为各类计算服务、存储、CDN、数据分析

需要在推流端上传尽可能高的画质，
在拉流端根据网络情况实时转码

推流需要鉴权

实现
```
采集端根据平台考虑不同的解决方案,
pc使用OBS(https://obsproject.com/、https://www.douyu.com/cms/zhibo/201311/13/250.shtml)
移动设备使用各自平台的解决方案
```
## 即构科技
```
https://doc.zego.im/CN/210.html
```

PC端专业的视频采集软件主要有Adobe 的Flash Media Live Encoder，FFMPEG，直播大师，VLC等少数几款

现有移动设备推流及前、后处理、编解码：
https://github.com/pili-engineering


一、直播的技术架构：直播视频采集SDK（PC/IOS/Anddroid）——直播CDN（直播流分发加速）——直播视频播放器SDK（PC/IOS/Android）

二、音视频处理的一般流程：数据采集→数据编码→数据传输(流媒体服务器) →解码数据→播放显示1、数据采集：摄像机及拾音器收集视频及音频数据，此时得到的为原始数据涉及技术或协议：摄像机：CCD、CMOS拾音器：声电转换装置（咪头）、音频放大电路2、数据编码：使用相关硬件或软件对音视频原始数据进行编码处理（数字化）及加工（如音视频混合、打包封装等），得到可用的音视频数据涉及技术或协议：编码方式：CBR、VBR编码格式视频：H.265、H.264、MPEG-4等，封装容器有TS、MKV、AVI、MP4等音频：G.711μ、AAC、Opus等，封装有MP3、OGG、AAC等3、数据传输：将编码完成后的音视频数据进行传输，早期的音视频通过同轴电缆之类的线缆进行传输，IP网络发展后，使用IP网络优传输涉及技术或协议：传输协议：RTP与RTCP、RTSP、RTMP、HTTP、HLS（HTTP Live Streaming）等控制信令：SIP和SDP、SNMP等4、解码数据：使用相关硬件或软件对接收到的编码后的音视频数据进行解码，得到可以直接显示的图像/声音涉及技术或协议：一般对应的编码器都会带有相应的解码器，也有一些第三方解码插件等5、播放显示：在显示器（电视、监视屏等）或扬声器（耳机、喇叭等）里，显示相应的图像画面或声音涉及技术或协议：显示器、扬声器、3D眼镜等  

三、常见的视频直播相关协议：1、RTMP(Real Time Messaging Protocol，实时消息传送协议)RTMP是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。它有三种变种：1）、工作在TCP之上的明文协议，使用端口1935；2）、RTMPT封装在HTTP请求之中，可穿越防火墙；3）、RTMPS类似RTMPT，但使用的是HTTPS连接；RTMP协议是被Flash用于对象、视频、音频的传输。这个协议建立在TCP协议或者轮询HTTP协议之上。RTMP协议就像一个用来装数据包的容器，这些数据既可以是AMF格式的数据，也可以是FLV中的视音频数据。一个单一的连接可以通过不同的通道传输多路网络流，这些通道中的包都是按照固定大小的包传输的。2、RTSP(Real Time Streaming Protocol，实时流传输协议)RTSP定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP提供了一个可扩展框架，数据源可以包括实时数据与已有的存储的数据。该协议目的在于控制多个数据发送连接，为选择发送通道如UDP、组播UDP与TCP提供途径，并为选择基于RTP上发送机制提供方法。RTSP语法和运作跟HTTP/1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。代理服务器的缓存功能也同样适用于RTSP，并且因为RTSP具有重新导向功能，可根据实际负载情况来切换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。3、RTP(Real-time Transport Protocol，实时传输协议)RTP是针对多媒体数据流的一种传输层协议，详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通系统（配合H.323或SIP），使它成为IP电话产业的技术基础。RTP是建立在UDP协议上的，常与RTCP一起使用，其本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性，只管发送，不管传输是否丢包，也不管接收方是否有收到包。RTP 实行有序传送，RTP中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，如在视频解码中，就不需要顺序解码。4、RTCP(Real-time Transport Control Protocol，实时传输控制协议）RTCP是RTP的配套协议，为RTP媒体流提供信道外的控制。RTCP和RTP一起协作将多媒体数据打包和发送，定期在多媒体流会话参与者之间传输控制数据。RTCP的主要功能是为RTP所提供的服务质量（QoS）提供反馈，收集相关媒体连接的统计信息，例如传输字节数，传输分组数，丢失分组数，单向和双向网络延迟等等。网络应用程序可以利用RTCP所提供的信息来提高服务质量，比如限制流量或改用压缩比小的编解码器。  

四、直播下的聊天室功能1、直播的场景下，除了视频直播还有一块就是聊天功能，观众打开一个直播房间时，也就自动进入了一个聊天室，观众可以发文字发表情进行互动，道具打赏也是基于聊天室的接口做上去的。2、聊天室和群聊的功能类似，两者的区别是：聊天室的场景下，用户进入后才能看到聊天信息，群成员信息，退出后再进来就看不到之前的历史消息了。3、聊天室其实是im即时通讯中的一个功能，im主要能实现一对一聊天、群聊、聊天室3种场景。

//避坑须知：
//使用video.js需要低版本，本文为5.5.3，较高版本无法播放rtmp
//同时在未使用stream key，也就是房间号的时候，拉流也无法播放，此处坑了较长时间
//最后，必须发布才能播放
//可是使用此地址测试【rtmp://live.hkstv.hk.lxdns.com/live/hks1】

测试页面代码如下

<!DOCTYPE HTML>
<html>  
  <head>  
  <title>视频直播</title>  
  <meta charset="utf-8">  
  <link href="http://vjs.zencdn.net/5.5.3/video-js.css" rel="stylesheet">  
  <!-- If you'd like to support IE8 -->  
  <script src="http://vjs.zencdn.net/ie8/1.1.1/videojs-ie8.min.js"></script>  
</head>  
<body>  
  <h1>直播测试</h1>  
 <video id="my-video" class="video-js" controls preload="auto" width="640" height="300"  
 poster="" data-setup="{}">  
    <source src="rtmp://live.hkstv.hk.lxdns.com/live/hks1" type="rtmp/flv">  
    <p class="vjs-no-js">播放视频需要启用 JavaScript，推荐使用支持HTML5的浏览器访问。  
      To view this video please enable JavaScript, and consider upgrading to a web browser that  
      <a href="http://videojs.com/html5-video-support/" target="_blank">supports HTML5 video</a>  
    </p>  
 </video>  
 <script src="http://vjs.zencdn.net/5.5.3/video.js"></script>  
</body>  
</html>