基于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，欢迎大家下载测试，返回bug和提交PR。

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

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：上述的问题已经解决，详情见高性能流媒体服务器nginx-http-live-module。

2018-08-08更新：

        有网友反馈HTTP-FLV方式播放不能使用exec_pull，究其原因是因为HTTP-FLV请求首先都会通过ngx_http_flv_live_module的检查，才能继续往后边的流程执行（这个我一直在考虑怎么把它的执行次序调整到后边），但是在这儿没有针对exec_pull处理的逻辑，所以直接“找不到流”了，现在已经修复，但是逻辑很粗糙，凑合先用着。

2018-08-15更新：

        将压力测试程序和服务器分开在不同的服务器上进行压力测试时，发现如果服务器之间的网络带宽不够大，停止压力测试很可能造成服务器的CPU使用率为100%，原来遇到过类似的问题，是由于两次释放内存链表导致形成了链表环。修改后的代码在多次压力测试后未发现该问题（之前压测稳定后停止播放，平均不到10次，有时候4次就会复现），后续可能还需要更多的测试来验证。

2018-08-23更新：

        修复一个上次更新引入的新的bug，多次释放链表造成形成了链表环。另外更新了示例截图，分别是用JW Player，VLC和flv.js做的测试截图。

2018-09-14更新：

        修复GOP缓存模块中因为满足一定条件后释放内存池，后续再分配内存时造成崩溃的bug。这个bug是几天前有个厂商反馈的，nginx运行一段时间后会崩溃，但不是必现的，后调试产生的两个core文件发现都在同一个地方崩溃。

2018-09-22更新：

        有网友反馈使用on_connect和on_play回调命令时，有时请求会耗费很长时间才收到响应，并且Nginx的吞吐量在这期间下降很快，可能是这两个命令有什么问题，跟踪一段时间后还是找不到原因。后来在nginx-rtmp-module的pull requests中找到原因，如果在on_connect和on_play中使用了域名，nginx-http-flv-module会去解析域名，并且解析域名的接口是阻塞的。Nginx作为异步非阻塞的服务器，如果阻塞在域名解析接口上了，肯定就会导致吞吐量下降。现添加了一个配置项notify_no_resolve，默认是开启的，即不解析域名，这就要求默认情况下使用on_connect等命令时url中不能用域名，除非能保证域名解析很快，才能使用notify_no_reslove off;。但是有些网站是不接受纯IP地址访问的，所以这种情况需要用户自己根据实际情况做取舍了。

2018-09-29更新：

        有网友提交了一个PR，解决了一个比较隐蔽的bug，详情见pull request #73，在GOP缓存模块中，缓存链表头等变量空间使用了独立的内存池，在关闭连接时，先释放了这个内存池，再回收缓存链表时，再引用这些链表头就会崩溃。

2018-10-08更新：

        有网友在国庆节之前反馈了一个bug，详情见issue #72，之前一直没找到原因，现在修复了，auth_request验证会用到upstream，upstream发送信息给服务器时，会使得下游连接变得active，从而在后续的过程中一直进入不了发送函数。

2018-1