如何通知nginx rtmp 直播地址结束直播流

来源：蜘蛛抓取(WebSpider) 时间：2017-11-05 01:57 标签： nginx rtmp 直播人数
博客访问： 5531469
博文数量： 757
博客积分： 2150
博客等级： 上尉
技术积分： 12991
注册时间：
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： 网络与安全
直播应用中，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秒数据。
处理累积延迟的最好方法，是客户端检测到缓冲区有很多数据了，如果可以的话，就重连服务器。
当然如果网络一直不好，那就没有办法了。
阅读(27194) | 评论(0) | 转发(2) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。FFmpeg总结（十二）用ffmpeg与nginx实现直播多路流并发播放 - 逆流的鱼yuiop - CSDN博客
博客专家
FFmpeg总结（十二）用ffmpeg与nginx实现直播多路流并发播放
请尊重分享成果，转载请注明出处，本文来自逆流的鱼yuiop，原文链接：
下载 nginx 和 nginx-rtmp源码：
编译安装：
cd nginx-1.5.10
./configure –with-http_ssl_module –add-module=../nginx-rtmp-module-master
make install
浏览器输入localhost:8010（默认80，由于其他服务在用，这里用8010），得到如下：
配置nginx支持rtmp，找到f,在http节点结束后加入rtmp节点，如下：
listen 1935;
application yuiop {
FFmpeg开始推流，先推一个直播流来直播
接下来开始看下服务器流是否可看，开始拉流播放
ffplay rtmp://xxx.xxx.xxx.xxx:1935/yuiop/live
也可以在网页端口写点js代码，也能支持播放，效果如下：
推一个流，拉一个流不过瘾，直播可是，同时有n多个流在推拉，接着来，推拉两个，很自然也成功了。
要是用我之前的例子，把直播地址，传给mediaplayer，就可以在手机上看直播了。
最后来张全家福，本地电脑和直播服务器同时看直播，有2-3秒延迟
第一时间获得博客更新提醒，以及更多android干货，源码分析，欢迎关注我的微信公众号，扫一扫下方二维码或者长按识别二维码，即可关注。 如果你觉得好，随手点赞，也是对笔者的肯定，也可以分享此公众号给你更多的人，原创不易
我的热门文章

我要回帖

更多关于 nginx rtmp 直播人数 的文章

 

随机推荐