「linux」流媒体直播服务器搭建

一、常用命令

环境:

​ docker v17.12.0.-ce

​ docker pull jrottenberg/ffmpeg

​ docker pull nginx

一、配置环境：

docker pull jrottenberg/ffmpeg
docker pull nginx

二、创建容器：

准备工作:

1. 把nginx文件传入指定路径

2. ffmpeg rtsp转换m3u8容器创建

   修正前:

docker run --name ffmpeg-livefile \
-v /etc/localtime:/etc/localtime \
-v /usr/getinfo/docker/volume/nginx-livefile/m3u8:/root/download \
jrottenberg/ffmpeg:latest -i rtsp://admin:getinfo12345@192.168.16.103:554 -codec:v libx264 -hls_time 10 -hls_list_size 0 -f hls /root/download/demo.m3u8

​ 修正后: -在tcplayer无法播放

docker run --name ffmpeg-livefile \
-v /etc/localtime:/etc/localtime \
-v /usr/getinfo/docker/volume/nginx-livefile/m3u8:/root/download \
jrottenberg/ffmpeg:latest -i rtsp://admin:getinfo12345@192.168.16.133:554 -vcodec copy -acodec copy -scodec copy -hls_time 600 -hls_list_size 0 -f hls /root/download/demo.m3u8

​ 修正后:

docker run --name ffmpeg-livefile2 \
-v /etc/localtime:/etc/localtime \
-v /usr/getinfo/docker/volume/nginx-livefile/m3u8:/root/download \
jrottenberg/ffmpeg:latest -i rtsp://admin:getinfo12345@192.168.16.133:554 -vcodec copy -acodec copy -scodec copy -level 3.0 -hls_time 10 -hls_list_size 0 -f hls /root/download/demo.m3u8

最终版本:

docker run --name ffmpeg-livefile \
-v /etc/localtime:/etc/localtime \
-v /usr/getinfo/docker/volume/nginx-livefile/m3u8:/root/download \
jrottenberg/ffmpeg:latest -i rtsp://admin:getinfo12345@192.168.16.103:554 -vcodec copy -acodec copy -scodec copy -map 0 -f hls -hls_time 2.0 -hls_list_size 0 -hls_wrap 15 /root/download/demo.m3u8

转换rtsp为rtmp

docker run --name ffmpeg-livefile \
-v /etc/localtime:/etc/localtime \
-v /usr/local/html/hls:/root/download \
jrottenberg/ffmpeg:latest -i rtsp://admin:getinfo12345@192.168.16.133:554 -vcodec copy -acodec copy -scodec copy -f flv rtmp://192.168.16.45:1935/stream/m3u8

docker 启动 nginx-rtmp并推流

docker run --name nginx-rtmp -it -p 1935:1935 -p 8080:80  alfg/nginx-rtmp

播放地址: http://vm.mecom:8080/live/test.m3u8

-re -i 1.ts  -map 0 -f ssegment -segment_format mpegts -segment_list /root/download/demo.m3u8 -segment_list_flags +live -segment_list_size 2 -segment_time 10 out%03d.ts

-re参数代表生成过程按照输入视频的实际fps，保证直播。

-segment_format mpegts 切片采用ts流，

-segment_list playlist.m3u8 生成m3u8文件，

-segment_list_flags +live表明是直播流，

-segment_list_size 2 表示playlist m3u8中包含2个切片，设置较少的数是保证客户端直播的实时性。

-segment_time 10 表示单个切片10s的时间

最后生成的切片以out***.ts的方式保存在目录中

​ // 创建后先停止容器

3.创建nginx容器

docker run --name=nginx-livefile -d -p 8080:8080 \
-v /etc/localtime:/etc/localtime \
-v /usr/getinfo/docker/volume/nginx-livefile/conf/nginx.conf:/etc/nginx/nginx.conf \
-v /usr/getinfo/docker/volume/nginx-livefile/conf/mime.types:/etc/nginx/mime.types \
-v /usr/getinfo/docker/volume/nginx-livefile/m3u8:/etc/nginx/html \
docker.io/nginx \

访问地址: 192.168.16.39/demo.m3u8

扩展知识: rtsp、rtmp、hls、http协议区别

共同点：

​ 1：RTSP RTMP HTTP都是在应用应用层。

​ 2： 理论上RTSP RTMPHTTP都可以做直播和点播，但一般做直播用RTSP RTMP，做点播用HTTP。做视频会议的时候原来用SIP协议，现在基本上被RTMP协议取代了。

区别：

​ 1：HTTP: 即超文本传送协议(ftp即文件传输协议)。

​ 2：HTTP将所有的数据作为文件做处理。http协议不是流媒体协议。

​ 3：RTMP协议是Adobe的私有协议 ,未完全公开，RTSP协议和HTTP协议是共有协议，并有专门机构做维护。

​ 4：RTMP协议一般传输的是flv，f4v格式流，RTSP协议一般传输的是ts,mp4格式的流。HTTP没有特定的流。

​ 5：RTSP传输一般需要2-3个通道，命令和数据通道分离，HTTP和RTMP一般在TCP一个通道上传输命令和数据。

用HTTP方式：

　　先通过服务器将FLV下载到本地缓存，然后再通过NetConnection的本地连接来播放这个FLV，这种方法是播放本地的视频，并不是播放服务器的视频。因此在本地缓存里可以找到这个FLV。其优点就是服务器下载完这个FLV，服务器就没有消耗了，节省服务器消耗。其缺点就是FLV会缓存在客户端，对FLV的保密性不好。

　用RTMP方式：

　　通过NetConnection连接到FMS(Flash Media Server)或Red5服务器，并实时播放服务器的FLV文件，这种方式可以任意选择视频播放点，并不象HTTP方式需要缓存完整个FLV文件到本地才可以任意选择播放点，其优点就是在本地缓存里是找不到这个FLV文件的。其优点就是FLV不会缓存在客户端，FLV的保密性好，其缺点就是消耗服务器资源，连接始终是实时的。

由以上分析可知，Http方式是本地播放，而RTMP方式是服务器实时播放.

　RTSP:

　　RTSP 1.0标准的制订者没有充分预测到互联网带宽的快速增长，以及由于IPv4地址短缺导致的NAT技术的广泛使用，还有代理服务器的大量存在，它在传输可靠性和易用性上都存在一定的缺陷。虽然各家厂商都做了一定程度的修补，比如支持RTSP over HTTP，支持NAT穿透等，但仍然于事无补。在2005之后网络视频大爆炸的几年中，RTSP 1.0并没有得到youtube, hulu, 土豆，优酷等视频服务提供商的青睐，相反，Adobe公司开发的私有流媒体技术RTMP以其优秀的易用性和富媒体的一体化集成，得到了多数视频服务提供商的追捧，成为了事实上的标准.

　　HLS(Http Living Streaming):

　　从2010年起，苹果开始在iOS设备上支持一种叫做”Live HTTP”的流媒体技术，并宣布在iOS上不会支持RTSP和Flash技术。Live HTTP本质上跟基于HTTP的文件分段下载很接近。在带宽充裕的前提下，live HTTP能够实现跟RTSP和RTMP同样的流媒体播放效果，同时得到了更好的易用性，更简单的控制。

直播应用中，RTMP和HLS基本上可以覆盖所有客户端观看，
HLS主要是延时比较大，RTMP主要优势在于延时低。

一、应用场景

.  互动式直播：譬如2013年大行其道的美女主播，游戏直播等等
   各种主播，流媒体分发给用户观看。用户可以文字聊天和主播互动。
.  视频会议：我们要是有同事出差在外地，就用视频会议开内部会议。
   其实会议1秒延时无所谓，因为人家讲完话后，其他人需要思考，
   思考的延时也会在1秒左右。当然如果用视频会议吵架就不行。
.  其他：监控，直播也有些地方需要对延迟有要求，
   互联网上RTMP协议的延迟基本上能够满足要求。

二、RTMP和延时

1. RTMP的特点如下：

1) Adobe支持得很好：
   RTMP实际上是现在编码器输出的工业标准协议，基本上所有的编码器（摄像头之类）都支持RTMP输出。
   原因在于PC市场巨大，PC主要是Windows，Windows的浏览器基本上都支持flash，
   Flash又支持RTMP支持得非常好。
2) 适合长时间播放：
   因为RTMP支持的很完善，所以能做到flash播放RTMP流长时间不断流，
   当时测试是100万秒，即10天多可以连续播放。
   对于商用流媒体应用，客户端的稳定性当然也是必须的，否则最终用户看不了还怎么玩？
   我就知道有个教育客户，最初使用播放器播放http流，需要播放不同的文件，结果就总出问题，
   如果换成服务器端将不同的文件转换成RTMP流，客户端就可以一直播放；
   该客户走RTMP方案后，经过CDN分发，没听说客户端出问题了。
3）延迟较低：
   比起YY的那种UDP私有协议，RTMP算延迟大的（延迟在1-3秒），
   比起HTTP流的延时（一般在10秒以上）RTMP算低延时。
   一般的直播应用，只要不是电话类对话的那种要求，RTMP延迟是可以接受的。
   在一般的视频会议应用中，RTMP延时也能接受，原因是别人在说话的时候我们一般在听，
   实际上1秒延时没有关系，我们也要思考（话说有些人的CPU处理速度还没有这么快）。
4) 有累积延迟：
   技术一定要知道弱点，RTMP有个弱点就是累积误差，原因是RTMP基于TCP不会丢包。
   所以当网络状态差时，服务器会将包缓存起来，导致累积的延迟；
   待网络状况好了，就一起发给客户端。
   这个的对策就是，当客户端的缓冲区很大，就断开重连。

2. HLS低延时

主要有人老是问这个问题，如何降低HLS延迟。
HLS解决延时，就像是爬到枫树上去捉鱼，奇怪的是还有人喊，看那，有鱼。
你说是怎么回事?

我只能说你在参与谦哥的魔术表演，错觉罢了。
如果你真的确信有，请用实际测量的图片来展示出来，参考下面延迟的测量。

3. RTMP延迟的测量

如何测量延时，是个很难的问题，
不过有个行之有效的方法，就是用手机的秒表，可以比较精确的对比延时。

经过测量发现，在网络状况良好时：

. RTMP延时可以做到0.8秒左右。
. 多级边缘节点不会影响延迟（和SRS同源的某CDN的边缘服务器可以做到）
. Nginx-Rtmp延迟有点大，估计是缓存的处理，多进程通信导致？
. GOP是个硬指标，不过SRS可以关闭GOP的cache来避免这个影响.
. 服务器性能太低，也会导致延迟变大，服务器来不及发送数据。
. 客户端的缓冲区长度也影响延迟。
  譬如flash客户端的NetStream.bufferTime设置为10秒，那么延迟至少10秒以上。

4. GOP-Cache

什么是GOP？就是视频流中两个I帧的时间距离。
GOP有什么影响？
Flash（解码器）只有拿到GOP才能开始解码播放。
也就是说，服务器一般先给一个I帧给Flash。
可惜问题来了，假设GOP是10秒，也就是每隔10秒才有关键帧，
如果用户在第5秒时开始播放，会怎么样？
第一种方案：等待下一个I帧，
也就是说，再等5秒才开始给客户端数据。
这样延迟就很低了，总是实时的流。
问题是：等待的这5秒，会黑屏，现象就是播放器卡在那里，什么也没有，
有些用户可能以为死掉了，就会刷新页面。
总之，某些客户会认为等待关键帧是个不可饶恕的错误，延时有什么关系？
我就希望能快速启动和播放视频，最好打开就能放！

第二种方案：马上开始放，
放什么呢？
你肯定知道了，放前一个I帧。
也就是说，服务器需要总是cache一个gop，
这样客户端上来就从前一个I帧开始播放，就可以快速启动了。
问题是：延迟自然就大了。

有没有好的方案？
有！至少有两种：
编码器调低GOP，譬如0.5秒一个GOP，这样延迟也很低，也不用等待。
坏处是编码器压缩率会降低，图像质量没有那么好。

5. 累积延迟

除了GOP-Cache，还有一个有关系，就是累积延迟。
服务器可以配置直播队列的长度，服务器会将数据放在直播队列中，
如果超过这个长度就清空到最后一个I帧：

当然这个不能配置太小，
譬如GOP是1秒，queue_length是1秒，这样会导致有1秒数据就清空，会导致跳跃。

有更好的方法？有的。
延迟基本上就等于客户端的缓冲区长度，因为延迟大多由于网络带宽低，
服务器缓存后一起发给客户端，现象就是客户端的缓冲区变大了，
譬如NetStream.BufferLength=5秒，那么说明缓冲区中至少有5秒数据。

处理累积延迟的最好方法，是客户端检测到缓冲区有很多数据了，如果可以的话，就重连服务器。
当然如果网络一直不好，那就没有办法了。