接上篇-nginx-http-flv-module更新说明（一）

blog：https://blog.csdn.net/winshining/article/details/74910586

github: https://github.com/winshining/nginx-http-flv-module

简介：目前已有数百star，数家企业已经在线上使用，其中有一家是华为，欢迎star。

2017-09-18更新：

反向代理和负载均衡的功能已经基本可用，但是之前并为考虑到如果推流数很多，例如1000路推流，这可能对服务器造成沉重的负担。那为什么HTTP协议使用反向代理和负载均衡没有这个问题呢？那是因为HTTP请求占用的带宽很有限，负载瞬时可能很高，但是不会太持久。

2017-10-07更新：

虚拟主机功能已基本可用，即可以像HTTP配置那样配置server_name了，由于可以通过虚拟主机查找配置，所以不再支持参数srv=index，添加了一个参数port，如果不指定，默认为1935，用于指定以该port查找推流对应的配置。通用URL变为：http://example.com[:port]/dir?[port=xxx&]app=xxx&stream=xxx

2017-11-10更新：

RTMP的302重定向已基本可用，但是由于很多播放器不支持重定向，所以该功能很受限，目前只有JW Player测试通过，VLC无法解析返回的重定向信息，其他播放器没有测试过。关于RTMP的302重定向，可以参考Adobe的官网里的application.redirectConnection部分说明：https://helpx.adobe.com/adobe-media-server/ssaslr/application-class.html。

设置如下：在server块或者application块中添加配置，假设推流时的app为myapp，要重定向到test，保持流的名称不变：

rewrite '^/app/(.*)' '/test/$1';

这样，就可以在本机上将推流或者播放都从app重定向到test上。

如果要推流到其他主机，则可以设置为：

rewrite '^/app/(.*)' rtmp://otherhost:otherport/otherapp/$1;

这样，就可以将本机上的推流或者播放都重定向到其他主机上，这也是一种负载均衡的方法。

PS：不太愿意将rewrite分支merge到master上，毕竟受限太多，功能有点鸡肋。 2017-11-12更新： 今天在笔记本上进行压力测试，用的是srs给的测试工具，而它不支持推mp4文件流，只支持flv格式，结果一测试就出现问题，HTTP方式播放无法正常运行，查了下代码，已经修复bug。

2017-11-22更新：

有网友提到同时使用HTTP和RTMP方式直播时，停止RTMP方式播放会导致HTTP方式播放也停止，这个bug几天前测试的时候已经发现，不过最近由于工作比较忙，没来得及改，今天修复了这个bug。 2017-12-10更新： 评论中有网友指出不知道如何使用HTTP方式播放直播流，可以查看github上的README.CN.md（https://github.com/winshining/nginx-http-flv-module/blob/master/README.CN.md），这个文件是中文说明，README.md是英文说明。这两天专门更新了一下这两个文件，没有添加新的功能。测试截图如下，其中网页是用RTMP方式播放，VLC是HTTP方式播放：

插个使用flv.js播放的截图（2018-04-06）：

2017-12-30更新： 2017年最后一次更新，由于之前已经提及为什么反向代理和负载均衡在实际生活中不太实用，所以已经把README文件里的反向代理和负载均衡的说明删除了，不过代码还没有删除，后续会陆陆续续删除。对于评论中有网友提到的问题，有些还没修复，我很抱歉，平时上班比较忙，年底连续上了12天班，通宵1晚，所以来不及修复问题。有兴趣的网友可以自己hack代码，代码风格是严格按照nginx的官方要求格式写的，我自认为看着还行，至于有些逻辑问题，我也没搞太清楚，只知道那样写没问题。 最后，最近重写了http-flv直播的功能，组装数据和发送全部使用HTTP的框架，不再使用一些“裸露”的组装数据的方法，如"HTTP/1.1 200 OK"CRLF，发送也使用ngx_http_send_header和ngx_http_output_filter完成，不再使用自定义的发送函数，为什么有这个想法，源于nginx从1.3.9版本后原生支持HTTP的chunked传输，没有必要再自己搞一套组装和发送chunked数据的方法，并且对于非chunked传输，nginx的HTTP模块更不在话下，所以干脆全部用nginx的HTTP框架了。 最后，上面说的代码不会提交了，因为我发现有人fork代码后，又删除了fork，然后在自己的代码里加了些我的项目里的代码，尽管改了变量名什么的，还是看得出痕迹。BSD-2-Clause开源协议本来要求很简单，你修改，再发布甚至商用，LICENSE文件里署上原作者信息即可。这点都办不到，那我也只能小心眼了。 2018-01-02更新： 反向代理和负载均衡的代码已经从master分支删除，vhost分支与master分支代码是一样的，upstream分支还保留有反向代理和负载均衡的代码，有需要的可以查看这个分支，后续不再维护这两个功能。 2018-01-03更新： 感谢一些网友指出nginx-http-flv-module因为nginx的版本变更造成不能编译的问题，目前已经把一些已发现的兼容问题修复了，测试到最旧的nginx版本是1.2.6，考虑到nginx-1.2.6已经是2012年的版本了，所以绝大多数情况下应该不会使用比它更旧的版本，所以不再测试nginx-http-flv-module和更旧的nginx版本的兼容性了。 2018-01-12更新： 最近使用srs-bench（https://github.com/ossrs/srs-bench）推流测试nginx-http-flv-module的稳定性，发现在播放测试视频第三遍时（偶尔第一遍、第二遍）会出现CPU使用率暴增，nginx不接受任何服务，播放器画面静止不动的问题（我用过的播放器都会出现这问题，所以不是播放器的问题）。经调试，发现是在释放已使用的链表（并不是释放内存，是把内存链表链入一个free指针）时，无限循环了，即已使用的链表形成了环。后来确认是重复释放已使用的链表造成的问题，修改代码后，播放测试视频十几遍（半个多小时）没再出现问题，代码已经更新。谨慎猜测nginx-rtmp-module也有此问题，但是没有测试过。

2018-02-07更新： 有网友提交代码了，包括定时输出日志和FCPublish等命令的处理，代码已经合并。另外有网友在服务器上试用，32GB的内存6个小时耗尽，显然有内存泄漏，目前已经修复。不得不佩服nginx-rtmp-module的原作者，内存链表使用了引用计数器，分配和释放对计数器的操作避免了多次释放造成链表环的形成。还修复了一个因为GOP缓存数目为2时，会造成瞬间发送数据的速率太高，造成播放器来不及接收数据，进而造成播放卡顿的bug。用wireshark抓包可以看出有'TCP Window Full'的问题，经查造成此问题的原因就是播放器来不及接收数据。

2018-02-27更新： 有网友提出想在Windows上运行带有nginx-http-flv-module的nginx，而我之前一直将重心放在Linux上，并且Mac OS X上也能编译通过，但是没怎么测试，昨晚在Windows上编译时，发现好多编译错误，并且如果开启了“chunked on;”配置项，播放会崩溃，现一并修复了这些bug，非常感谢网友们的测试与建议。