[bug] wrong flv head under debug mode

[adrianhans]

the normal FLV HEAD (46 4C 56 01) is expected to be sent every time upon request.

however, if nginx-http-flv-module is compiled with debug enabled (./configure --with-debug), the FLV HEAD is prefix with 0x64 0x0d 0x0a, which makes it
64 0d 0a 46 4c 56 01
and unrecognizable for players such as flv.js

My environment is:

• Ubuntu 14.04.5 LTS (GNU/Linux 3.13.0-65-generic x86_64)
• nginx 1.14.2
• ./configure --add-module=/var/down/nginx-http-flv-module --prefix=/usr/local/nginx --with-debug --with-http_ssl_module

the error info from flv.js is "Non-FLV, Unsupported media type". the dumped http-flv data is as below:

$ hexdump -C -n128 live1.flv
00000000 64 0d 0a 46 4c 56 01 05 00 00 00 09 00 00 00 00 |d..FLV..........|
00000010 0d 0a 12 00 01 a8 00 00 00 00 00 00 00 05 00 00 |................|
00000020 00 00 01 99 12 01 00 00 00 02 00 0a 6f 6e 4d 65 |............onMe|
00000030 74 61 44 61 74 61 03 00 06 53 65 72 76 65 72 02 |taData...Server.|
00000040 00 44 4e 47 49 4e 58 20 48 54 54 50 2d 46 4c 56 |.DNGINX HTTP-FLV|
00000050 20 28 68 74 74 70 73 3a 2f 2f 67 69 74 68 75 62 | (https://github|
00000060 2e 63 6f 6d 2f 77 69 6e 73 68 69 6e 69 6e 67 2f |.com/winshining/|
00000070 6e 67 69 6e 78 2d 68 74 74 70 2d 66 6c 76 2d 6d |nginx-http-flv-m|

[winshining]

How to reproduce it? Only adding --with-debug option?
The following are my tests:
BTW, I've always kept the option --with-debug when debugging the module since the project was created.
winshining@debian:~/desktopl/streaming$ /usr/local/nginx/sbin/nginx -V
nginx version: nginx/1.15.2
built by gcc 4.9.2 (Debian 4.9.2-10)
built with OpenSSL 1.0.1t 3 May 2016
TLS SNI support enabled
configure arguments: --with-http_auth_request_module --add-module=/home/winshining/workspace/nginx-upload-module --with-http_ssl_module --add-dynamic-module=/home/winshining/workspace/nginx-http-flv-module --with-debug

winshining@debian:~/desktopl/streaming$ wget 'http://localhost:8080/live?app=myapp&stream=mystream_99' -O test.flv
--2019-04-07 23:20:30-- http://localhost:8080/live?app=myapp&stream=mystream_99
正在解析主机 localhost (localhost)... 127.0.0.1
正在连接 localhost (localhost)|127.0.0.1|:8080... 已连接。
已发出 HTTP 请求，正在等待回应... 200 OK
长度：未指定 [video/x-flv]
正在保存至: “test.flv”

[     <=>                                                                                           ] 183,981      109K/s              ^C

winshining@debian:~/desktopl/streaming$ hexdump -C -n 128 test.flv
00000000 46 4c 56 01 05 00 00 00 09 00 00 00 00 12 00 01 |FLV.............|
00000010 a8 00 00 00 00 00 00 00 05 00 00 00 00 01 99 12 |................|
00000020 01 00 00 00 02 00 0a 6f 6e 4d 65 74 61 44 61 74 |.......onMetaDat|
00000030 61 03 00 06 53 65 72 76 65 72 02 00 44 4e 47 49 |a...Server..DNGI|
00000040 4e 58 20 48 54 54 50 2d 46 4c 56 20 28 68 74 74 |NX HTTP-FLV (htt|
00000050 70 73 3a 2f 2f 67 69 74 68 75 62 2e 63 6f 6d 2f |ps://github.com/|
00000060 77 69 6e 73 68 69 6e 69 6e 67 2f 6e 67 69 6e 78 |winshining/nginx|
00000070 2d 68 74 74 70 2d 66 6c 76 2d 6d 6f 64 75 6c 65 |-http-flv-module|
00000080

winshining@debian:~/desktopl/streaming$ wget 'http://localhost:8080/live?app=myapp&stream=mystream_1' -O test.flv
--2019-04-07 23:25:51-- http://localhost:8080/live?app=myapp&stream=mystream_1
正在解析主机 localhost (localhost)... 127.0.0.1
正在连接 localhost (localhost)|127.0.0.1|:8080... 已连接。
已发出 HTTP 请求，正在等待回应... 200 OK
长度：未指定 [video/x-flv]
正在保存至: “test.flv”

[     <=>                                                                                           ] 97,535      56.9K/s              ^C

winshining@debian:~/desktopl/streaming$ hexdump -C -n 128 test.flv
00000000 46 4c 56 01 05 00 00 00 09 00 00 00 00 12 00 01 |FLV.............|
00000010 a8 00 00 00 00 00 00 00 05 00 00 00 00 01 99 12 |................|
00000020 01 00 00 00 02 00 0a 6f 6e 4d 65 74 61 44 61 74 |.......onMetaDat|
00000030 61 03 00 06 53 65 72 76 65 72 02 00 44 4e 47 49 |a...Server..DNGI|
00000040 4e 58 20 48 54 54 50 2d 46 4c 56 20 28 68 74 74 |NX HTTP-FLV (htt|
00000050 70 73 3a 2f 2f 67 69 74 68 75 62 2e 63 6f 6d 2f |ps://github.com/|
00000060 77 69 6e 73 68 69 6e 69 6e 67 2f 6e 67 69 6e 78 |winshining/nginx|
00000070 2d 68 74 74 70 2d 66 6c 76 2d 6d 6f 64 75 6c 65 |-http-flv-module|
00000080

[winshining]

I noticed that you've used HTTPS, it is also OK:
winshining@debian:~/workspace/nginx-http-flv-module$ wget --no-check-certificate 'https://localhost/live?app=myapp&stream=mystream' -O test.flv
--2019-04-07 23:49:27-- https://localhost/live?app=myapp&stream=mystream
正在解析主机 localhost (localhost)... 127.0.0.1
正在连接 localhost (localhost)|127.0.0.1|:443... 已连接。
警告: “localhost” 的证书不可信。
警告: “localhost” 的证书颁发者未知。
已发出 HTTP 请求，正在等待回应... 200 OK
长度：未指定 [video/x-flv]
正在保存至: “test.flv”

[     <=>                                                                                           ] 65,448      37.8K/s              ^C

winshining@debian:~/workspace/nginx-http-flv-module$ hexdump -C -n 128 test.flv
00000000 46 4c 56 01 05 00 00 00 09 00 00 00 00 12 00 01 |FLV.............|
00000010 a8 00 00 00 00 00 00 00 05 00 00 00 00 01 99 12 |................|
00000020 01 00 00 00 02 00 0a 6f 6e 4d 65 74 61 44 61 74 |.......onMetaDat|
00000030 61 03 00 06 53 65 72 76 65 72 02 00 44 4e 47 49 |a...Server..DNGI|
00000040 4e 58 20 48 54 54 50 2d 46 4c 56 20 28 68 74 74 |NX HTTP-FLV (htt|
00000050 70 73 3a 2f 2f 67 69 74 68 75 62 2e 63 6f 6d 2f |ps://github.com/|
00000060 77 69 6e 73 68 69 6e 69 6e 67 2f 6e 67 69 6e 78 |winshining/nginx|
00000070 2d 68 74 74 70 2d 66 6c 76 2d 6d 6f 64 75 6c 65 |-http-flv-module|
00000080

The possible reason is that the browser you've tested didn't interpret HTTP chunked response, the response HTTP header is: Transfer-Encoding: chunked, data is of following format:

hexnumber1\r\n
data1\r\n
hexnumber2\r\n
data2\r\n
...
hexnumberN\r\n
dataN\r\n
0\r\n\r\n

So, the chunked format of FLV header is d\r\n F L V 01 05 00 00 00 09 00 00 00 00 \r\n, the hexadecimal of above is:
64 0d 0a 46 4c 56 01 05 00 00 00 09 00 00 00 00 0d 0a
It perfectly conforms to the data you've supplied, it has nothing to do with the option --with-debug.

[adrianhans]

Thanks for the help and apology for occupying your time.

I look into the problem after reading your comment and find it a complicated problem chain possibly related to either Chrome or Nginx proxy.
In my configuration, the stream data route is like:
rtmp_src -- nginx server { rtmp } -- nginx server { http flv } -- nginx server { httpS proxy } -- flv.js in chrome

The proxy seems working incorrectly with chunked data. It firstly causes chrome to throw out net::ERR_INCOMPLETE_CHUNKED_ENCODING. As a side proof, you can also get a "network error" prompt soon after the download starts if you try to directly access the http-flv address.

After a few seconds, chrome will stop showing the net::ERR_INCOMPLETE_CHUNKED_ENCODING error message in the development console, and you will be able to download the http-flv stream continuously. However, the problem still exists. Flv.js will raise the "Non-FLV, Unsupported media type" error, and "64 0d 0a 46 4c 56 01" could be seen in the downloaded .flv file, as I described in my above post.

I have no idea why chrome stop popping the error prompt after a while and pass the wrong content down. The HTTP Response Headers are all the same. I just want to note this down here and will make more update if I have time to look deeper.

[winshining]

I've never got net::ERR_INCOMPLETE_CHUNKED_ENCODING error via flv.js when directly access HTTP-FLV address. The longest time I've ever tested was about 2 hours. However, I've never tested the proxy server case, which is beyond my knowledge.

You can specify the following directive in conf file:

chunked_transfer_encoding

from on to off, then Nginx will not response with chunked data but simple binary data.
Good luck!

[winshining]

@adrianhans Hi, I reproduced the bug and fixed it. If HTTP/1.0 is used to request the playback, the format of the first package sent by server is not correct if chunked_transfer_encoding is turned on, because Transfer-Encoding: chunked is a HTTP header ONLY in HTTP/1.1 standard. Protocol used between HTTPS proxy and HTTP-FLV backend server in your test route maybe HTTP/1.0, as below:

rtmp_src -- nginx server { rtmp } -- nginx server { http flv } -(HTTP/1.0)- nginx server { httpS proxy } -- flv.js in chrome

You can fetch the latest code to test. Looking forward to your reply. Thanks!