采用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>