基于nginx-rtmp-module模块实现的HTTP-FLV直播模块nginx-http-flv-module（三） - 好文

接上一篇《基于nginx-rtmp-module模块实现的HTTP-FLV直播模块nginx-http-flv-module（二）
<https://blog.csdn.net/winshining/article/details/79492099>》内容。

项目地址：https://github.com/winshining/nginx-http-flv-module
<https://github.com/winshining/nginx-http-flv-module>，欢迎大家下载测试，返回bug和提交PR。

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块配置时也没有问题。

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 <https://github.com/arut/nginx-rtmp-module/pull/1124>
中找到原因，如果在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
<https://github.com/winshining/nginx-http-flv-module/pull/73>
，在GOP缓存模块中，缓存链表头等变量空间使用了独立的内存池，在关闭连接时，先释放了这个内存池，再回收缓存链表时，再引用这些链表头就会崩溃。

2018-10-08更新：

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

2018-10-10更新：

有网友反馈在ngx_rtmp_init_session中存在初始化失败后不会释放已经分配的内存池的问题，经提醒，发现ngx_http_flv_live_init_session中也有同样的问题，一并修复了。不过这个问题几乎不可能发生，在内存耗尽的情况下才可能出现。

2018-10-18更新：


发现一个可能引起崩溃的bug，不过到现在为止还没有人反馈过这个问题，relay模块中的ngx_rtmp_relay_close函数，在发布端断开连接后，会将与它关联的订阅者逐个关闭，这些订阅者的连接的context是用一个链表链在一起的，关闭一个连接后会通过next指针找到下一个连接的context。原生的代码可能出现问题，因为关闭连接后会销毁内存池，而这个context是这个内存池中的一个对象，内存池销毁后，如果这块内存没被重新分配，那么侥幸还能获取它的next指针，如果这块内存已经被重新分配，那么这个context就已经无效了，访问就会崩溃。这是
nginx-rtmp-module <https://github.com/arut/nginx-rtmp-module>
本身存在的一个问题。现改为关闭连接之前，先获取下一个context，存在一个临时变量中，再关闭连接，这样就避免了循环时依赖可能已经无效的context的next指针了。

2018-11-02更新：

        nginx-rtmp-module <https://github.com/arut/nginx-rtmp-module>
对纯音频支持有瑕疵，当开启wait_video或者wait_key时，无法播放，因为一直试图等待视频数据，nginx-http-flv-module
<https://github.com/winshining/nginx-http-flv-module>修复了此问题。

2018-11-09更新：

有网友反馈使用比较低版本（1.8.x）的Nginx <http://nginx.org>
编译会出现错误（至于为什么还用这么低版本的Nginx我不太清楚），经测试还不只一处有兼容性的问题，一并都修复了。

2018-11-12更新：


一个厂商反馈json格式的stat解析有问题，100%复现，与我自己推流的比较发现，其推流的audio解析信息缺失，导致双引号缺失，解析错误，已经修复。

2018-11-22更新：

有个网友反馈使用非常新的gcc（8.2.0）版本编译nginx-http-flv-module
<https://github.com/winshining/nginx-http-flv-module>会失败，见issue #82
<https://github.com/winshining/nginx-http-flv-module/issues/82>
，已修复。注意，gcc-8.2.0编译版本1.15.x以下的Nginx <http://nginx.org>也会失败。

2019-01-05记录：


不是更新，只是记录:)早就有重构模块调用顺序的想法，因为ngx_http_flv_live_module现在是请求“见到”的第一个模块，很多本来应该由后续模块处理的逻辑可能因为某些原因被ngx_http_flv_live_module“放弃”掉了，尽管这个请求本来在后续的模块看来是合法的。例如处理回调的模块ngx_rtmp_notify_module现在位于ngx_http_flv_live_module后面，后者本来不用关心前者处理的细节，但是现在由于模块的位置关系，使得ngx_http_flv_live_module要介入它后面的模块的一些处理细节，使得它的处理逻辑很复杂又不易被理解。这段时间正在将ngx_http_flv_live_module放到一个合适的位置，涉及的代码比较多，需要一段时间，修改完后会merge到master分支上。

2019-02-02更新：

        很久没有更新了，春节前最后一次更新。最近几天有网友反馈on_update在使用HTTP-FLV方式播放时有问题，见issue #85
<https://github.com/winshining/issues/85>
，一直无法复现，后来将on_play和on_play_done加上才复现了崩溃。原因有点莫名其妙，大概意思是ngx_rtmp_netcall_module中一个指针置为NULL了，但是调用ngx_rtmp_netcall_disconnect时这个指针却不是NULL，而是0x0A，调试了大半天都没找到原因，确定这个指针不是在已销毁的内存池中，加了个计数，计数为0时再置为NULL；另外，on_update也确实有问题，
nginx-rtmp-module <https://github.com/arut/nginx-rtmp-module>
把ngx_rtmp_session_t结构体指针挂在结构体ngx_connection_t的data指针上，而Nginx <http://nginx.org>
原生的HTTP模块中是把ngx_http_request_t结构体指针挂在ngx_connection_t的data指针上的，所以执行ngx_rtmp_notify_update函数时，从data拿出来的数据是ngx_http_request_t指针，而不是ngx_rtmp_session_t指针，造成访问一些数据会崩溃。测试暂时没有问题了，已更新代码。

2019-02-13更新：

        春节前一个美国网友反馈了一个bug，见issue #86。
<https://github.com/winshining/nginx-http-flv-module/issues/86>
经过调试发现服务器监听IPv6地址时，如果客户端是IPv4地址，服务器接收到请求时，会将IPv4地址映射成为IPv6地址。但是如果HTTP模块监听的是IPv4地址，而RTMP模块监听的是IPv6地址，HTTP模块带过来的地址格式不会被映射成IPv6地址，造成比较协议族+端口+地址时失败。

2019-02-23记录：

        接2019-01-05记录，模块调用顺序已经调整好，已经合并到master分支，简单测试没发现问题，欢迎试用并反馈问题。

2019-03-14更新：

        修复了JSON风格的stat解析错误问题，感谢网友的PR。发布版本1.2.6，欢迎测试并反馈问题。

2019-04-23更新：

        之前测试HTT-FLV的客户端（VLC或者flv.js）使用的HTTP协议一直都是HTTP/1.1，后来有网友反馈回复的数据老是有问题，见
issue #99 <https://github.com/winshining/nginx-http-flv-module/issues/99>
（但并不是标题所说的原因），每次回复FLV头时总是多一些数据，查看了一下是chunked结构，但是一直没复现出来。直到昨晚使用curl并且指定--http1.0选项，发现发送的数据是chunked结构，但是Transfer-Encoding:
chunked这个HTTP头是HTTP/1.1引入的，HTTP/1.0并不支持，之前没有区分HTTP/1.0和HTTP/1.1，也就是说客户端使用HTTP/1.0协议，服务器只要配置了chunked_transfer_encoding
on;，就会回复chunked数据，而没有考虑协议版本的问题，造成客户端不解析回复的数据，直接存储了。问题已经修复。网友反馈的情况是：

flv.js<--Nginx(HTTPS proxy)<--Nginx(HTTP-FLV)<--Nginx(RTMP)<--RTMP(publish)

出现这个问题的原因应该是proxy和后端的服务器之间使用的是HTTP/1.0协议。

2019-05-07更新：


有网友反馈使用HTTP-FLV时，播放器无法解析metadata，但是视频是可以播放的，用wget或者curl下载播放链接并保存为文件，二进制打开后发现metadata似乎多了一些数据，跟RTMP播放抓包的数据对比发现没有差异，好久才回过神来RTMP播放抓的包里是完整的RTMP数据包，也就是说除了metadata以外，还有RTMP的basic
header，chunk message
header，这两部分在HTTP-FLV播放时是不应该发送给客户端的，最新的代码已经去掉并验证通过（RTMP和HTTP-FLV）。隐约想起来去年就有网友反馈使用flv.js播放时，会出现不能解析的AMF格式的错误，当时没引起重视，应该就是这个错误，使用flv.js测试也没问题了。

其他文章：

基于nginx-rtmp-module模块实现的HTTP-FLV直播模块nginx-http-flv-module（一）
<https://blog.csdn.net/winshining/article/details/74910586>

基于nginx-rtmp-module模块实现的HTTP-FLV直播模块nginx-http-flv-module（二）
<https://blog.csdn.net/winshining/article/details/79492099>

热门工具换一换