基于nginx-rtmp-module模块实现的HTTP-FLV直播模块nginx-http-flv-module(二)

      由于《基于nginx-rtmp-module模块实现的HTTP-FLV直播模块nginx-http-flv-module(一)》内容已经很长,所以后续的更新将记录在这儿。非常感谢网友们的测试反馈和代码提交!项目地址:https://github.com/winshining/nginx-http-flv-module。有问题或者建议,可以加Q群:711969608详聊,进群请先查看群说明和群公告,编译问题(除了一些确实是因为兼容问题不能编译的),能通过README和wiki解决的配置问题请优先自行解决,回复问题不是群友的义务,因为绝大多数群友有自己的工作。目前已经有很多个人和厂商准备将本模块商用,据网友反馈,国外已经有直播网站在用这个模块。国内准备商用的厂商中有华为,中兴(网友告知,未确认),另外据网友反馈,EasyDSS和EasyNVR也集成了本模块的功能。网友和厂商陆续反馈过不少bug,修复后功能已经越来越稳定,在此表示感谢。

项目演示视频:使用nginx-http-flv-module搭建简易直播环境

注意:GitHub主页README里配置文件例子中的各个配置项,除非你确实知道它们的含义,否则请不要擅自删除配置项,以避免出现各种不正常的问题。配置文件例子在大多数场景下已够用。

2020-03-10:两年前在Q群和其他一些地方统计过商用本模块的个人和公司数量,现在数量已不少,不再统计。

2018-06-04:一家CDN厂商正式上线nginx-http-flv-module,使用RTMP方式,开gop_cache配置(关闭interleave配置,打开会卡顿或者没有声音,目前暂时不知如何修复(注,这个bug已经修复)),他们的客户包括映客和微吼。

2018-07-28:应一部分网友的需求,已经提供RHEL6(CentOS 6)和RHEL7(CentOS 7)的rpm安装包,见nginx-http-flv-module-packages

2019-07-26:有个俄罗斯网友维护了一个Nginx以及Nginx第三方模块的软件仓库,nginx-http-flv-module最近被收录,所以我不再维护上述的安装包,详情请见github主页的README/README.CN。

2019-11-25:经一些网友反馈,该repo已不能使用,反馈给repo创建者,一直没回复,已从README中剔除该repo的使用说明。

2020-03-10:上述的俄罗斯网友回复该repo不能使用的原因是网站要收费,但是Red Hat Enterprise Linux 8平台目前还是免费的,有需要的可以查看PR112

2018-10-28:现在nginx-htt-flv-module还有一个问题,多进程模式下,接收到publish的进程auto_push到另外的进程时,如果配置里存在多个server块,当请求的是非第一个server块时,可能造成播放失败,这是因为auto_push依靠unix domain socket通信,但是unix domain socket没有端口信息,所以,当播放和发布在不同的进程上时,由于auto_push无法判断查找的是哪个server块(默认是第一个),播放会失败。单进程没有这个问题,因为单进程没有auto_push,多进程模式下,只有一个server块配置时也没有问题。

2019-06-24:上述几个问题都已经解决,测试过一段时间,暂时没有复现问题;多进程模式下auto_push效率低下的问题也已经解决,详情见高性能流媒体服务器nginx-http-live-module

        nginx-http-flv-module与nginx-rtmp-module的功能对比:

功能nginx-http-flv-modulenginx-rtmp-module备注
HTTP-FLV×nginx-http-flv-module支持HTTPS-FLV
GOP缓存× 
vhost× 
省略listen配置x

 

JSON风格的statx 
RTMP 302Beta×nginx-http-flv-module作为服务器或者客户端

2018-03-09更新:

最近这段时间主要在不同平台测试模块的稳定性,目前播放这一块没发现问题,由于条件限制,除了FreeBSD平台没测试过,Windows 7,Debian 7.x和macOS Sierra都测试过了,由于Nginx官方对Windows支持不太好,没用Windows平台最强大的IOCP接口(使用的select),所以导致Windows平台上运行效率不太高,表现在推流等待时间长,3s+,首屏时间很长,4s+,select本身原因限制客户端个数,默认是1024。推流等待时间和首屏时间最短的是macOS Sierra,本机上测试时基本上是秒推秒开。昨晚专门注意了一下,在macOS Sierra下编译时,SO_REUSEPORT和TCP_FASTOPEN两项都支持,前者让Nginx的每个子进程都可以listen,都有一个专门的accept队列,解决了惊群效应;后者则是在发起SYN时就已经携带实际数据,而不是握手完毕后再传输实际数据。秒推秒开可能跟这两个选项有关。但是macOS Sierra并不支持将某个进程绑定到某个CPU上,所以可能进程上下文切换会有开销,系统负载较大时可能效率不如Linux。由于macOS Sierra是公司的电脑,所以未做压力测试。我的笔记本装的是Debian 7.x,因为内核版本较低,所以macOS Sierra上支持的两个选项都不支持。测试时推流等待时间和首屏时间都介于Windows 7和macOS Sierra之间,在服务器上测试时(系统CentOS 6.4,支持SO_REUSEPORT但是不支持TCP_FASTOPEN)跟macOS Sierra上差不多,但是考虑到服务器的CPU性能强大得多,所以负载不高情况下,macOS Sierra的表现是最好的。由于macOS Sierra是从Mac OS X更新来的,而Mac OS X的底层最初是在FreeBSD基础上开发的,所以推测在FreeBSD上的表现应该也不错。

另外最近在尝试添加RTMP 302重定向转HTTP 302重定向的功能,由于很多播放器不支持RTMP 302重定向,但是支持HTTP 302重定向的功能基本上是标配,实测VLC是支持的。目前功能基本上已经完成,但是困扰的地方还是使用HTTP框架的发送接口时,链表在长时间播放后会形成环,所以进展不下去了,没有更新到github上。下面是nginx的rtmp主要配置片段和VLC播放时的HTTP 302重定向截图:其中推流是在名为hls的application上推的(FFmpeg也不支持RTMP 302重定向,所以只能往hls推)。

application myapp {

    ...;

    rewrite '^/myapp/(.*)' '/hsl/$1';

}

 

1.HTTP 302重定向抓包简略图

 

2.HTTP 302重定向抓包详情图

2018-03-15更新:

有网友反馈on_play指令不能使用,经调试,是因为加入的ngx_http_flv_live模块的顺序有问题,现修改为不改变模块顺序的前提下,经过一些状态的修改绕过它,后续再调用其中的一些函数,以保证与原来的nginx-rtmp-module的功能一致。

2018-03-16更新:

部分网友们提出的CORS(跨域)功能已经可用,HTTP-FLV的回复数据不再使用硬编码,而是使用部分HTTP框架的代码重写了。另外,on_connect功能有问题,暂时不能用,等待修复。

2018-03-18更新:

on_connect的问题已经修复。

2018-03-20更新:

修复因为要查找的application不在第一个server块中造成找不到对应的on_connect和on_play的bug,经查是由于没有匹配到正确的server配置,已修复。

2018-03-22更新:

很久之前有网友提出过设置idle_streams为off(默认为on)时,使用HTTP-FLV方式播pull会失败,现已修复。

2018-03-25更新:

有网友使用flv.js播放nginx-http-flv-module拉的直播流,发现一个bug:当(1)使用的Nginx版本号为1.13.9,(2)播放器为flv.js,(3)播放pull的流时,会出现无法播放的情况,经查是因为flv.js发送了HTTP头“Connection: keep-alive”,nginx-http-flv-module在向上游发起请求时,下游请求一般在上游请求还没有返回时就已经返回,但是Nginx从版本1.13.1起,删除了一个r->blocked判断,而“Connection: keep-alive”导致ngx_http_finalize_request调用ngx_http_set_keepalive,这个函数会调用注册的cleanup函数来关闭下游的请求,导致播放失败。已经修复。也正是在调试这个bug的过程中,发现nginx-http-flv-module在打开gop_cache配置项的情况下,flv.js跟其他主流的播放器(如vlc)相比,首屏时间是最快的,几乎没有延迟,使用的pull源是香港卫视的直播源:rtmp://live.hkstv.hk.lxdns.com/live/hks

2018-03-27更新:

顺手改点代码就有bug,真是恼火。最近为了响应一些网友要求添加定制的HTTP头的功能,修改了发送功能,再次尝试将Nginx的HTTP框架的filter接口引入,还是失败了,所以简单粗暴地把最后一个filter模块和header_filter模块挑出来,删除了很多用不上的代码。github上编译用的是Nginx官方的稳定版本nginx-1.12.2。结果今天有网友反馈编译不过去,经查刚好这几个找不到的宏是在我从修改nginx-rtmp-module就一直使用的nginx-1.11.10中加入的,而网友用的版本低一些就编译不过去,已经修复。

2018-03-29更新:

前几天有网友反馈使用nginx-1.13.1以及以上的版本与nginx-http-flv-module一起编译时,使用flv.js播放pull流会失败,见2018-03-25更新,结果修复了那个问题,又出了先推流,然后使用flv.js播放会失败的问题,真是随手改出bug,问题已经修复,最新版本的Nginx和稍微旧一些的版本(nginx-1.11.10)都已经测试通过。

2018-04-05记录:

这次不是更新:)昨天有网友反馈使用flv.js播放推流时,一直播放不了,我还以为nginx-http-flv-module又出问题了,自己测试了一下,用最新的nginx-1.13.10一起编译,播放推流和拉流都没问题,又用官方的稳定版nginx-1.12.2一起编译,还是没问题,晚上准备看看哪儿出问题的时候,网友反馈是浏览器限制了flv.js的数量,他用的是Chrome,据测试单浏览器只能开6个flv.js,今天中午我用Firefox测试了一下,也是同样的问题,第7个flv.js播放不了,然后开VLC播放,没有问题,由此可以确认不是nginx-http-flv-module的问题。不过这是个很重要的信息,浏览器对flv.js的播放支持是有数量限制的,Chrome和Firefox的限制数量都是6个,其他浏览器未测试。

2018-04-06更新:

之前的统计数据一直没有把http-flv直播的accepted数量和输出计入,现已添加。现在对flv.js的支持已经稳定,下面是使用flv.js播放的截图:

一个商用厂商反馈视频源是纯视频时,不管使用什么播放器,播放连接没问题,但是一直接收不到视频数据,经调试发现是因为判断纯音频的逻辑有bug,导致nginx-http-flv-module在发送音视频数据的接口中无限循环了,现已修复。

2018-04-14更新:

有网友昨天反馈开启gop_cache选项时,推流会导致内存泄露,已查明是推流关闭时没有释放gop cache模块分配的内存造成的,已修复。另外,据网友反馈,多进程模式下,on_connect和on_play指令有问题,暂时别在多进程模式下用这两个指令,等待修复。

2018-04-15更新:

一个商用厂商反馈随机闪断测试时,内存会不断增长,怀疑有内存泄露,晚上调试时确认确实有内存泄露,是由于没有释放ngx_http_request_t结构中的内存池造成的,已修复。

2018-04-21更新:

有网友反馈多进程模式下,使用on_play进行鉴权操作,但是在推流的时候,本地relay(接受推流的子进程将流推给别的子进程)也会执行on_play鉴权,这是不太合理的(但是其实并不算bug),因为之前已经进行过鉴权了。现在将本地relay的on_play操作去掉了,nginx-http-flv-module并不关心on_play用来做什么,但是考虑到本地relay不应该再执行on_play操作了,修改的代码也比较简单,恢复也很容易,所以先暂时这样修改。另外网友@qqzzzx 反馈的压测崩溃的问题已经修复一部分,现在还存在的问题是压测群断后会有内存泄露的问题,修复后会更新到github上。

2018-04-25更新:

压力测试崩溃的问题已经修复,捎带解决了可能出现的CPU使用率过高的问题,已压力测试1个多小时(srs-bench自带的测试视频,500路HTTP-FLV和200路RTMP),暂未发现问题,欢迎反馈bug。

2018-05-12更新:

有网友反馈开启gop_cache选项,某些情况下压力测试会特别耗费内存,不确定是不是有内存泄露。压测多次不能复现,网友提示压测工具和服务器不在同一主机上比较容易复现。按照这种方式压测果然比较容易复现,但是出现耗费内存比较大的情况下,停止压力测试,然后再次压力测试且并发数不变,内存不会增长,证明不是内存泄露的问题。后来反复查看源代码后,猜想是因为发送GOP的时候,一次性将GOP数据放入发送环形数组中,由于Nginx是异步非阻塞的,所以Nginx不一定会马上将数据从环形数组中真正发送到网络(如服务器和客户端之间的网络带宽不足的情况下),造成已分配的内存不能马上循环使用,而且真正发送完GOP后,已分配的内存不再释放(在内存池中,并且与连接无关,只跟配置结构体有关)。后续的数据传输不像GOP数据是一次性全部发送,所以导致回收的内存不能被充分使用,有很大一部分闲置了。现将gop cache模块修改为使用自己独立的内存池,等GOP发送完后,释放这个内存池。

2018-05-14更新:

修复了一个2018-05-12更新引入的内存泄露的bug,属于代码久了看不懂,然后一改就出问题的情况。修复高版本gcc编译工程失败(在网上查了一下,gcc-7.x.x在添加了某些编译选项时,会检查switch的case是否有fall through)的bug,不过我手头没有很高版本的gcc,所以可能还存在一些没被发现的编译错误,目前正等待网友的回复。

2018-05-16更新:

白天编译安装了gcc-7.2.0,找出了所有的fall through编译警告(Nginx的编译选项中被视为错误),已修复bug。

2018-05-18记录:

这次不是更新,2018-05-12更新中我猜想压力测试(使用的工具是srs-bench)时开启gop_cache选项会特别耗费内存的原因,今晚经过查看日志,发现之前的猜想其实不是主要原因。从日志中可以看到Nginx在接收数据时一直都是128字节,而在配置中如果没有指明chunk_size配置项时,默认是4096个字节,就是说服务器发送Set Chunk Size协议控制消息后,客户端并没有响应Set Chunk Size协议控制消息,所以服务器一直沿用之前的128字节,最糟糕的情况下,会导致nginx-http-flv-module在接收到数据后,分配内存对数据进行打包时,用(4096+RTMP头最大大小)这么多字节的空间来打包128字节的数据,白白浪费了32倍多的数据。使用ffmpeg进行对比测试,ffmpeg是会响应Set Chunk Size协议控制消息的,所以不会造成内存浪费。已经给SRS(Simple-RTMP-Server)的作者提issue了。后续有空我会更新nginx-http-flv-module对这种异常的处理。

2018-05-20更新:

某些情况下特别耗费内存的问题已经修复,如果耗费使用量还很大,那么可能是由上面说的那个次要原因引起的了。

2018-06-14更新:

修复一个网友反馈的问题,ngx_stat_active参数在运行一段时间后值不正确,经查是由于重复减去操作造成的,已修复,不影响正常功能使用。

2018-06-19更新:

同步了几个nginx-rtmp-module的pull requests里的bug修复,基本上都是一些很明显的bug,大的修改没同步过来。另外,目前在nginx-http-flv-module基础上添加了直接推送fmp4的功能,今晚已经实现直接推送纯视频的fmp4到支持MSE(Media Source Extensions,目前iOS上的Safari不支持)的浏览器中播放,后续会将音频一起加上。

2018-06-25更新:

推送fmp4的基本功能已经基本完成。有网友推了支持JSON格式的stat的PR,已经合并,试用了下,感觉非常不错,另外修复了一个小bug。

2018-06-29更新:

将stat中原有的rtmp信息修改为http-flv,鉴于已经有两个厂商分别正式商用RTMP(开启gop_cache)和HTTP-FLV(不开gop_cache),发布了里程碑版本1.2.4。

2018-07-09更新:

修复了3个小bug:开启DASH功能时,有可能因为从文件中读取的数据为0导致无限循环;修复xml方式的stat中不能显示nginx-http-flv-module的版本号的问题(网友的PR);修复HEAD请求没有配置flv_live的locations时返回405(Method Not Allowed)的bug。

2018-07-20更新:

修复了一个日志记录bug,刚好把client和server对调了。

2018-07-30更新:

修复一个潜在的导致内存泄露的问题和一个与nginx-1.15.2编译出错(高版本的Linux内核支持SO_REUSEPORT(详情见2018-03-09更新),nginx-1.15.2修改了一个函数的参数类型)的问题。

其他文章:

基于nginx-rtmp-module模块实现的HTTP-FLV直播模块nginx-http-flv-module(一)

基于nginx-rtmp-module模块实现的HTTP-FLV直播模块nginx-http-flv-module(三)

相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页