How to understand the HTTP-FLV live broadcast module nginx-http-flv-module implemented based on nginx-rtmp-module module

The content of this article is about how to understand the HTTP-FLV live broadcast module nginx-http-flv-module based on the nginx-rtmp-module module. It has certain reference value and friends in need can refer to it. I hope it helps you.

Currently, many individuals and manufacturers are preparing to commercialize this module. According to feedback from netizens, there are already live broadcast websites using this module abroad. The most famous manufacturer preparing for commercial use is Huawei. Netizens and manufacturers have reported many bugs. After repairs, the function has become more and more stable. I would like to express my gratitude.

2018-06-04: A CDN manufacturer officially launched nginx-http-flv-module, using RTMP mode, turning on gop_cache configuration (turning off the interleave configuration, there will be lag or no sound when turning it on) , currently we don’t know how to fix it), their customers include Inke and Weihou.

2018-06-28: An online video manufacturer officially launched nginx-http-flv-module, using HTTP-FLV method, without enabling gop_cache configuration. It has not been fully activated yet, waiting. Observe stability.

2018-07-28: In response to the needs of some netizens, rpm installation packages for RHEL6 (CentOS 6) and RHEL7 (CentOS 7) have been provided, see nginx-http-flv-module -packages.

            Function comparison between nginx-http-flv-module and nginx-rtmp-module:

Function	nginx-http-flv-module	nginx-rtmp-module	Remark
HTTP-FLV	√	×	nginx-http-flv-module supports HTTPS-FLV
GOP Cache	√	×
vhost	√	×
Omit listen configuration	√	x
JSON style stat	√	x
RTMP 302	Beta	×	nginx-http-flv-module as server or client

2018-03-09 Update:

In recent times, the stability of the module has been mainly tested on different platforms. Currently, no problem has been found when playing this part. Due to conditions, it has not been tested except for the FreeBSD platform. Windows 7. Both Debian 7.x and macOS Sierra have been tested. Since Nginx officially does not support Windows very well and does not use the most powerful IOCP interface on the Windows platform (select is used), the operating efficiency on the Windows platform is not very high. , manifested in the long waiting time for push streaming, 3s, and the first screen time is very long, 4s. The number of clients is limited due to the selection itself, and the default is 1024. The one with the shortest push streaming waiting time and first screen time is macOS Sierra. When tested on this machine, it basically pushed and opened within seconds. I paid special attention last night. When compiling under macOS Sierra, both SO_REUSEPORT and TCP_FASTOPEN are supported. The former allows each sub-process of Nginx to listen and has a dedicated accept queue, which solves the thundering herd effect; the latter The actual data is already carried when SYN is initiated, instead of transmitting the actual data after the handshake is completed. Pushing and opening in seconds may be related to these two options. However, macOS Sierra does not support binding a process to a CPU, so there may be overhead in process context switching, and the efficiency may not be as good as Linux when the system load is heavy. Since macOS Sierra is a company computer, no stress test was performed. My laptop is installed with Debian 7.x. Because the kernel version is lower, the two options supported on macOS Sierra are not supported. During the test, the push waiting time and the first screen time were between Windows 7 and macOS Sierra. When tested on the server (system CentOS 6.4, supporting SO_REUSEPORT but not TCP_FASTOPEN), it was similar to that on macOS Sierra, but considering the server's CPU The performance is much more powerful, so macOS Sierra performs best when the load is not high. Since macOS Sierra is updated from Mac OS X, and the bottom layer of Mac OS X was originally developed based on FreeBSD, it is speculated that the performance on FreeBSD should also be good.

In addition, I recently tried to add the function of converting RTMP 302 redirection to HTTP 302 redirection. Since many players do not support RTMP 302 redirection, the function of supporting HTTP 302 redirection is basically standard. Tested VLC is supported. At present, the function is basically completed, but the troublesome part is that when using the sending interface of the HTTP framework, the linked list will form a loop after playing for a long time, so the progress cannot be continued and it has not been updated to github. The following is the main rtmp configuration snippet of nginx and the HTTP 302 redirection screenshot during VLC playback: the push stream is pushed on the application named hls (FFmpeg does not support RTMP 302 redirection, so it can only be pushed to hls).

application myapp {

rewrite '^/myapp/(.*)' '/hsl/$1';

}

1.HTTP 302 Brief diagram of redirection packet capture

2. HTTP 302 redirection packet capture details diagram

##2018-03- 15 Update:

Some netizens reported that the on_play command cannot be used. After debugging, it is because there is a problem with the order of the added ngx_http_flv_live module. It is now modified to bypass it through some status modifications without changing the order of the modules. , and then call some of these functions later to ensure that the functions are consistent with the original nginx-rtmp-module.

2018-03-16 Update:

The CORS (cross-domain) function proposed by some netizens is now available. The HTTP-FLV reply data no longer uses hard coding, but uses part of HTTP. The framework code has been rewritten. In addition, there is a problem with the on_connect function and it is temporarily unavailable, waiting for repair.

Updated on 2018-03-18: The problem of

on_connect has been fixed.

2018-03-20 update:

Fixed the bug that the corresponding on_connect and on_play could not be found because the application to be searched was not in the first server block. After checking, it was because there was no match. to the correct server configuration, fixed.

Updated on 2018-03-22:

A long time ago, some netizens suggested that when idle_streams is set to off (the default is on), using HTTP-FLV to play pull will fail. This has been fixed.

2018-03-25 update:

Some netizens used flv.js to play the live stream pulled by nginx-http-flv-module and found a bug: when (1) the Nginx version used The number is 1.13.9, (2) the player is flv.js, (3) when playing the pull stream, it will not be played. After investigation, it is because flv.js sends the HTTP header "Connection: keep-alive" , when nginx-http-flv-module initiates a request to the upstream, the downstream request usually returns before the upstream request has returned. However, Nginx has deleted an r->blocked judgment since version 1.13.1, and " Connection: keep-alive" causes ngx_http_finalize_request to call ngx_http_set_keepalive. This function will call the registered cleanup function to close the downstream request, causing playback to fail. already fixed. It was during the process of debugging this bug that I found that when

nginx-http-flv-module turned on the gop_cache configuration item, flv.js was different from other mainstream players (such as vlc) In comparison, the first screen time is the fastest with almost no delay. The pull source used is the live broadcast source of Hong Kong Satellite TV: rtmp://live.hkstv.hk.lxdns.com/live/hks.

Updated on 2018-03-27:

I just changed some code and there was a bug, which is really annoying. Recently, in response to some netizens' requests for the function of adding customized HTTP headers, the sending function was modified. I tried again to introduce the filter interface of Nginx's HTTP framework, but it still failed, so I simply and crudely picked out the last filter module and header_filter module. Removed a lot of unused code. The official stable version of Nginx, nginx-1.12.2, is used for compilation on github. As a result, some netizens reported today that the compilation failed. After checking, it happened that these macros that could not be found were added to nginx-1.11.10, which I have been using since I modified nginx-rtmp-module, and the version used by netizens was lower. It just can't be compiled, it has been fixed.

2018-03-29 Update:

A few days ago, some netizens reported that when using nginx-1.13.1 and above versions to compile with nginx-http-flv-module, use flv. js will fail to play the pull stream. See the 2018-03-25 update. The problem has been fixed. There is also a problem of pushing the stream first and then using flv.js to play it. It is a bug that can be easily fixed. The problem has been fixed. Latest version of Nginx and a slightly older version (nginx-1.11.10) have been tested.

2018-04-05 record:

This time is not an update:) Yesterday, some netizens reported that when using flv.js to play push streams, they could not be played. I thought nginx-http-flv -The module has a problem again. I tested it myself and compiled it with the latest nginx-1.13.10. There is no problem in playing push and pull streams. I also compiled it with the official stable version nginx-1.12.2 and there is still no problem. , when I was preparing to see what went wrong in the evening, a netizen reported that the browser limited the number of flv.js. He was using Chrome. According to the test, a single browser could only open 6 flv.js. I used Firefox to test it at noon today. After a while, it was the same problem. The seventh flv.js could not be played. Then I opened VLC to play it, and there was no problem. From this, I can confirm that it is not a problem with nginx-http-flv-module. However, this is very important information. There is a limit to the number of browsers that support flv.js playback. Chrome and Firefox both have a limit of 6. Other browsers have not been tested.

Updated on 2018-04-06:

The previous statistical data has not included the accepted number and output of http-flv live broadcast, and it has been added now. Now the support for flv.js has been stable. The following is a screenshot of using flv.js to play:

A commercial manufacturer reported that when the video source is pure video, no matter what playback method is used There is no problem with the playback connection, but the video data has not been received. After debugging, it was found that there was a bug in the logic of judging pure audio, which caused nginx-http-flv-module to loop infinitely in the interface for sending audio and video data. Now it is repair.

Updated on 2018-04-14:

Some netizens reported yesterday that when the gop_cache option is turned on, push streaming will cause memory leaks. It has been found that the gop cache module allocation is not released when the push flow is turned off. Caused by memory, fixed. In addition, according to feedback from netizens, there is a problem with the on_connect and on_play commands in multi-process mode. Please do not use these two commands in multi-process mode for the time being until they are fixed.

Updated on 2018-04-15:

A commercial manufacturer reported that the memory would continue to grow during the random flash test, and it was suspected that there was a memory leak. During debugging at night, it was confirmed that there was indeed a memory leak, and it was due to This was caused by not releasing the memory pool in the ngx_http_request_t structure, which has been fixed.

Updated on 2018-04-21:

Some netizens reported that in multi-process mode, on_play is used for authentication operations, but when pushing, the local relay (sub-process that accepts the push) Pushing the stream to other child processes) will also perform on_play authentication, which is unreasonable (but not actually a bug) because authentication has been performed before. Now the on_play operation of the local relay has been removed. nginx-http-flv-module does not care what on_play is used for, but considering that the local relay should no longer perform on_play operations, the modified code is relatively simple and recovery is easy. , so modify it like this temporarily. In addition, the stress test crash problem reported by netizen @qqzzzx has been partially fixed. The remaining problem is that there will be a memory leak after the stress test group is disconnected. After the fix, it will be updated to github.

2018-04-25 update:

The stress test crash problem has been fixed, and the possible problem of excessive CPU usage has also been solved. The stress test has been for more than 1 hour (srs -Bench's own test video, 500 HTTP-FLV and 200 RTMP), no problems have been found yet, welcome to report bugs.

Updated on 2018-05-12:

Some netizens reported that turning on the gop_cache option would cause stress testing to consume a lot of memory in some cases. It is not sure if there is a memory leak. The stress test cannot be reproduced many times. Netizens pointed out that it is easier to reproduce the stress test tool and the server if they are not on the same host. It is indeed easier to reproduce the stress test in this way. However, if the memory consumption is relatively large, stop the stress test, and then repeat the stress test and the number of concurrency remains unchanged. The memory will not increase, which proves that it is not a memory leak problem. After repeatedly checking the source code, I guessed that when sending the GOP, the GOP data was put into the sending ring array at once. Since Nginx is asynchronous and non-blocking, Nginx may not actually send the data from the ring array to network (for example, when the network bandwidth between the server and the client is insufficient), the allocated memory cannot be recycled immediately, and after the GOP is actually sent, the allocated memory is no longer released (in the memory pool, and with It has nothing to do with the connection, only the configuration structure). Subsequent data transmission is not like the GOP data that is sent all at once, so the recycled memory cannot be fully used and a large part is idle. Now modify the gop cache module to use its own independent memory pool, and release this memory pool after the GOP is sent.

2018-05-14 update:

Fixed a memory leak bug introduced in the 2018-05-12 update. The code was incomprehensible for a long time, and then problems occurred as soon as it was changed. Condition. Fix the bug that the high version of gcc compilation project fails (I checked online, gcc-7.x.x will check whether the switch case has fall through when adding certain compilation options), but I don’t have a very high version of gcc at hand. , so there may still be some undiscovered compilation errors, and we are currently waiting for replies from netizens.

Updated on 2018-05-16:

During the day, I compiled and installed gcc-7.2.0 and found all the fall through compilation warnings (which are regarded as errors in Nginx compilation options). Bug fixed.

2018-05-18 record:

This is not an update. In the 2018-05-12 update, I guess it will be special to turn on the gop_cache option during the stress test (the tool used is srs-bench). The reason for consuming memory. After checking the log tonight, I found that the previous guess was not the main reason. It can be seen from the log that Nginx always receives 128 bytes of data. If the chunk_size configuration item is not specified in the configuration, the default is 4096 bytes. That is to say, after the server sends the Set Chunk Size protocol control message, the client The client did not respond to the Set Chunk Size protocol control message, so the server has continued to use the previous 128 bytes. In the worst case, it will cause nginx-http-flv-module to allocate memory to package the data after receiving the data. Using (4096 RTMP header maximum size) so many bytes of space to pack 128 bytes of data wastes 32 times more data. Use ffmpeg for comparison testing. ffmpeg will respond to the Set Chunk Size protocol control message, so it will not cause memory waste. An issue has been submitted to the author of SRS (Simple-RTMP-Server). I will update nginx-http-flv-module's handling of this exception when I have time.

Updated on 2018-05-20:

The problem of particularly memory consumption in some cases has been fixed. If the usage is still very large, it may be due to the secondary reason mentioned above. Caused.

2018-06-14 update:

Fixed a problem reported by netizens. The value of the ngx_stat_active parameter was incorrect after running for a period of time. It was found that it was caused by repeated subtraction operations and has been fixed. , does not affect normal function use.

Updated on 2018-06-19:

Synchronized the bug fixes in several pull requests of nginx-rtmp-module. Basically, they are some obvious bugs. No major modifications. Sync over. In addition, the function of directly pushing fmp4 has been added to nginx-http-flv-module. Tonight, it has been implemented to directly push pure video fmp4 to browsers that support MSE (Media Source Extensions, currently not supported by Safari on iOS). Play in, and the audio will be added later.

2018-06-25 update:

The basic function of pushing fmp4 has been basically completed. Some netizens pushed a PR that supports stat in JSON format. It has been merged. I tried it and found it very good. A small bug was also fixed.

2018-06-29 update:

Modify the original rtmp information in the stat to http-flv. In view of the fact that two manufacturers have officially commercialized RTMP (turn on gop_cache) and HTTP-FLV. (without gop_cache enabled), milestone version 1.2.4 was released.

2018-07-09 Update:

Fixed 3 small bugs: when turning on the DASH function, it may cause an infinite loop because the data read from the file is 0; repair the xml method The problem that the version number of nginx-http-flv-module cannot be displayed in the stat (PR from a netizen); fix the bug of returning 405 (Method Not Allowed) when the HEAD request does not configure flv_live locations

The above is the detailed content of How to understand the HTTP-FLV live broadcast module nginx-http-flv-module implemented based on nginx-rtmp-module module. For more information, please follow other related articles on the PHP Chinese website!