精华内容
下载资源
问答
  • nginx-rtmp-module

    2020-03-03 16:40:32
    windows环境下,编译好的nginx-rtmp-module模块。本地已测试,可直接播放视频流。
  • 本文后续的内容将在这里更新:《基于nginx-rtmp-module模块实现的HTTP-FLV直播模块nginx-http-flv-module(二)》。注意:下文的配置很多已经不能用了,因为现在的实现跟早期的实现相差有点大。而为了看到整个项目的...

          本文后续的内容将在这里更新:《基于nginx-rtmp-module模块实现的HTTP-FLV直播模块nginx-http-flv-module(二)》注意:下文的配置很多已经不能用了,因为现在的实现跟早期的实现相差有点大。而为了看到整个项目的变迁史,所以保留了下来,下文的更新中提到了为什么有些配置项不能再使用的原因。现在使用的配置可查找下文中的README.CN.md。另外,除非你确实知道README中配置文件例子里的各个配置项的意义,否则请不要擅自删除配置项,以避免出现不正常的问题。配置文件例子在大多数场景下已够用。

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

          近几年直播行业火爆,开源的直播软件解决方案有SRS(Simple-RTMP-Server)和nginx-rtmp-module,前者是国人发起的一个优秀的开源项目,目前国内很多公司都使用它作为直播解决方案,由C++编写;后者依赖Nginx,以第三方模块的方式提供直播功能,由C编写。SRS采用多线程方式(经网友提醒更正:是单线程+协程方式),性能优秀,经受住了众多场景的考验,但是SRS3已经闭源(更正:是有一段时间闭源了,现在又开源了);nginx-rtmp-module是采用多进程方式,Nginx的性能优秀,但是据网友测试,同为单进程条件下,nginx-rtmp-module的性能不如SRS,并且nginx-rtmp-module的作者已经很久没有更新版本了,支持的功能也有限,例如不支持HTTP方式的FLV直播,而这是国内直播行业普遍采用的方式;再如推流不支持upstream,无法分布式部署功能;还有饱受诟病的播放响应延迟时间很长的问题(即俗称的不能秒播)等。

          我在nginx-rtmp-module的基础上实现了基于HTTP方式的FLV直播功能,支持GOP缓存,减少了首屏时间;支持流式和chunked两种HTTP响应格式;修复nginx-rtmp-module没有listen配置项时,推拉流失败的问题;解决nginx-rtmp-module已知的bug,见nginx-http-flv-module,欢迎下载测试和反馈bug,也欢迎提PR。有问题或者建议,可以加Q群:711969608详聊,注意:进群请先查看群说明和群公告,编译问题(除了一些确实是因为兼容问题不能编译的),能通过README和wiki解决的配置问题请优先自行解决,回复问题不是群友的义务,因为绝大多数群友有自己的工作。目前已经有很多个人和厂商准备将本模块商用。据网友反馈,国外已经有直播网站在使用这个模块。国内准备商用的厂商有华为,中兴(网友告知,未确认)等。另外据网友反馈,EasyDSS和EasyNVR也集成了本模块的功能。网友和厂商陆续反馈过不少bug,修复后功能已经越来越稳定,在此表示感谢。

    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-module nginx-rtmp-module 备注
    HTTP-FLV × nginx-http-flv-module支持HTTPS-FLV
    GOP缓存 ×  
    VHOST功能 ×  
    省略listen配置 见备注 nginx-rtmp-module必须至少有一个listen选项
    JSON风格的stat x  
    纯音频支持 见备注 nginx-rtmp-module开启wait_video或者wait_key选项后不能正常工作

          如果不想推流,可以用一个现成的直播地址rtmp://live.hkstv.hk.lxdns.com/live/hks。

    典型的nginx.conf如下:

    worker_processes  4; #Nginx开启4个子进程,子进程个数最好跟CPU的核心数一样
    worker_cpu_affinity 0001 0010 0100 1000; #CPU的mask,子进程使用它来绑定CPU核心,避免进程切换造成性能损失

    error_log logs/error.log error; #错误日志位置和日志级别,如果使用默认编译选项,位置为/usr/local/nginx/logs/error.log,error表示只打印错误日志

    events {
        worker_connections  1024; #Nginx处理的最大连接数
    }

    http {
        include       mime.types;
        default_type  application/octet-stream;

        keepalive_timeout  65;

        server {
            listen       80; #Nginx监听的HTTP请求端口

            location / {
                root   /var/www; #HTTP请求URL映射到服务器的位置
                index  index.html index.htm; #HTTP请求优先请求的文件,如http://localhost/,如果有index.html在/var/www目录下,那么请求的是/var/www/index.html
            }

            error_page   500 502 503 504  /50x.html; #如果遇到这些HTTP请求错误,Nginx返回50x.html的内容
            location = /50x.html {
                root   html; #因为/配置了root /var/www,所以这儿html对应的是/var/www/html,所以50x.html的路径是/var/www/html/50x.html
            }

            location /live {
                flv_live on; #当HTTP请求以/live结尾,匹配这儿,这个选项表示开启了flv直播播放功能
                chunked  on; #HTTP协议开启Transfer-Encoding: chunked;方式回复,已废弃,使用标准的chunked_tranfer_encoding代替
            }
        }
    }

    rtmp_auto_push on; #因为Nginx可能开启多个子进程,这个选项表示推流时,媒体流会发布到多个子进程
    rtmp_auto_push_reconnect 1s;
    rtmp_socket_dir /tmp; #多个子进程情况下,推流时,最开始只有一个子进程在竞争中接收到数据,然后它再relay给其他子进程,他们之间通过unix domain socket传输数据,这个选项表示unix domain socket的路径

    rtmp {
        out_queue   4096;
        out_cork    8;
        max_streams 64; #Nginx能接受的最大的推流数

        server {
            listen 1935; #Nginx监听的RTMP推流/拉流端口,可以省略,默认监听1935

            application myapp {
                live on; #当推流时,RTMP路径中的APP(RTMP中一个概念)匹配myapp时,开启直播
                gop_cache on; #开启GOP(Group of Picture)缓存,播放器解码时,收到一个完整的GOP才会开始播放,这个是减少播放延迟的选项
                pull rtmp://live.hkstv.hk.lxdns.com/live/hks; #如果懒得推流,那可以用这个,香港卫视的直播推流

            }

            #以下配置项已废弃

            application app1 {

                proxy_pass rtmp://host(ip or domain name)[:host]/app2; #将推流反向代理到上游服务器,并将app1自动转化为app2

                #proxy_pass rtmp://backend; #将推流反向代理到上游服务器,见upstream配置

            }
        }

        server {

            listen 1935;

            server_name *.test.com; #或者www.test.*/www.test.com

            application myapp {

                live on;

                gop_cache on;

            }

        }

        #以下配置项已废弃,原因在下文更新中

        upstream backend {

            #开启负载均衡

            server host1:port1;

            server host2:port2;

        }
    }

    启动Nginx,在vlc播放器中以“网络”方式打开媒体,填入http://localhost/live?stream=hks(已废弃)即可。

    通用URL(已废弃):http://example.com[:port]/dir?[srv=index&app=xxx&]stream=xxx。

    如果http配置块里的监听端口不是80(默认),那么必须加上:port,如:8080。

    如果rtmp配置块里有多个server配置块,如果想要播放的流的配置是在第二个server配置块中,那么必须加上srv=1(从0开始计数)。

    如果rtmp配置块中的某个server块下有多个application配置块,如果想要播放的流的APP(RTMP中的一个概念)的名称是test,那么必须指明app=test,stream对应的是推流的名称。

    推流的通用命令:ffmpeg -i -re xxx.mp4(或者与RTMP兼容的媒体文件)-vcodec copy -acodec copy -f flv rtmp://example.com[:port]/app/stream,后面也可以像HTTP的URL那样加参数,目前没仔细研究过,如果想推流到myapp,那么app换成myapp,stream随便取名,播放的时候跟它保持一致就可以。

    其他的见nginx-rtmp-module的wiki说明。

    测试效果图如下:

     

    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,这个文件是中文说明,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推流测试nginx-http-flv-module的稳定性,发现在播放测试视频第三遍时(偶尔第一遍、第二遍)会出现CPU使用率暴增,nginx不接受任何服务,播放器画面静止不动的问题(我用过的播放器都会出现这问题,所以不是播放器的问题)。经调试,发现是在释放已使用的链表(并不是释放内存,是把内存链表链入一个free指针)时,无限循环了,即已使用的链表形成了环。后来确认是重复释放已使用的链表造成的问题,修改代码后,播放测试视频十几遍(半个多小时)没再出现问题,代码已经更新。

    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,非常感谢网友们的测试与建议。

    其他文章:

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

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

    展开全文
  • nginx-rtmp-module-master

    2020-12-23 20:40:43
    nginx-rtmp-module-master
  • 由于《基于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-module nginx-rtmp-module 备注
    HTTP-FLV × nginx-http-flv-module支持HTTPS-FLV
    GOP缓存 ×  
    vhost ×  
    省略listen配置 x

     

    JSON风格的stat x  
    RTMP 302 Beta × 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(三)

    展开全文
  • nginx-rtmp-module-master.zip
  • nginx-rtmp-module-1.2.1.zip

    2021-02-09 21:03:04
    nginx-rtmp-module-1.2.1.zip
  • nginx-rtmp-module-1.2.1.tar.gz
  • 直播系统开发:基于Nginx与Nginx-rtmp-module
  • nginx-rtmp-module-vagrant:基于nginx-rtmp-module,ffmpeg和html video元素的HTTP实时流(HLS)服务器
  • nginx-rtmp-docker:使用Nginx的Docker映像,使用nginx-rtmp-module模块进行实时多媒体(视频)流传输
  • win7+VS2015编译好的带nginx-rtmp-module模块的Nginx 64位
  • nginx:ubuntu 14.04安装nginx包含并使用pcre openssl zlib源码添加nginx-rtmp-module模块
  • 直播系统开发 基于Nginx与Nginx-rtmp-module,从搭建到应用再到解决方案,详细阐释直播系统的搭建 由浅入深,wei初学者提供详细指导,为开发者答疑解惑 仅供大家交流学习使用
  • 通过nginx扩展nginx-rtmp-module实现流媒体直播服务器,接收RTMP协议的视频流数据,附带基于hls的web测试程序。
  • ffmpeg+nginx-rtmp-module+flv监控展示全量资源,包含ffmpeg、编译后的nginx-rtmp-module、flv.min.js、前端展示代码,内含操作文档
  • Nginx,Nginx直播组件nginx-rtmp-module-master。含源代码。
  • 直播系统开发 基于Nginx与Nginx-rtmp-module,从搭建到应用再到解决方案,详细阐释直播系统的搭建 由浅入深,未初学者提供详细指导,为开发者答疑解惑
  • <div><p>Could you please explain key advantages for this module over nginx-rtmp-module? Are they comparable at all? Could I use them both at the same time? And I would very appreciate you if you ...
  • nginx-rtmp-module:为rtmp flv和hls添加hevc(增加支持H265)
  • redhat7 部署nginx 并且集成nginx-rtmp-module时用到的gcc 相关 及其他rpm
  • 直播系统开发:基于Nginx与Nginx-rtmp-module 201902出版,全书203页。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,710
精华内容 684
关键字:

nginx-rtmp-module