接上篇-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上。