You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
RTMP acknowledge overflow causes the encoder to stop streaming #730
ACK SIZE refers to the number of bytes that the PEER should send an Acknowledge message after receiving. In other words, it indicates the number of bytes that the PEER has received.
RTMP is 32, which means it is 4 bytes long, but it does not explicitly state how overflow should be handled, whether it is int32 or uint32.
5.3. Acknowledgement (3)
The client or the server sends the acknowledgment to the peer after
receiving bytes equal to the window size. The window size is the
maximum number of bytes that the sender sends without receiving
acknowledgment from the receiver. The server sends the window size to
the client after application connects. This message specifies the
sequence number, which is the number of the bytes received so far.
0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sequence number (4 byte) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 shows the payload for the protocol message 'Acknowledgement'.
sequence number: 32 bits
This field holds the number of bytes received so far.
Previously, the bitrate of videos was very low, such as 100kbps, so there would be no overflow issue with these 4 bytes. Now, the bitrate is 80 to 100 times higher, which easily leads to overflow. Some encoders have different rules for handling this overflow, causing them to receive incorrect values and mistakenly assume that the server has not acknowledged, resulting in re-streaming.
Play a stream with a bitrate of 8Mbps using Flash player, set the ack size to 10*1024*1024, and print out the acknowledge messages sent by the Flash player.
`ack=1` indicates an acknowledge message.
`seq` is the sequence number, which represents the number of bytes received by the client.
`sent` is the number of bytes displayed as transmitted by the server.
[2017-01-06 11:23:30.321][warn][13607][114][35] ack=1, seq=0x500ac2, sent=0x5766fb, diff=482361
[2017-01-06 11:23:35.493][warn][13607][114][35] ack=1, seq=0xa0192a, sent=0xa0f73a, diff=56848
[2017-01-06 11:23:39.153][warn][13607][114][35] ack=1, seq=0xf0229e, sent=0xf4e6bb, diff=312349
[2017-01-06 11:23:43.197][warn][13607][114][35] ack=1, seq=0x140241e, sent=0x140499e, diff=9600
The ack size is set to 10*1024*1024, which means an acknowledge message should be sent after the player has played 10MB of data.
For a flash player, the interval between sending messages, which is the difference in seq, is 0xa0192a-0x500ac2=5246568=5*1024*1024, which means it sends approximately half of the ack size.
Subsequently, it sends acknowledgements after receiving 5.002307891845703MB and 5.0003662109375MB, which is roughly half of the window size.
The respective values are: 5.00229549407959, 5.0017194747924805, 5.00152587890625.
Therefore, it can be confirmed that the behavior of the flash player is to send an acknowledge confirmation message to the server when it receives more than 1/2 of the ack size (window size).
This number has no basis and there is no comment explaining its source.
In nginx-rtmp, the ack is sent when it exceeds the ack window (unlike Flash, which sends it when it exceeds half the window).
The overflowing data is padded with either 32 bits or 31 bits, which is significantly different from what flash sends. If we directly set it to zero, it can match, just like in nginx-rtmp, where it is set to zero when it exceeds 0xf0000000.
In addition, some encoders do not send an ack size (usually indicating that they do not need to send an acknowledge confirmation message), but they still want the server to send a confirmation message. Therefore, it is necessary to support configuration that can change the ack size for both input and output.
Activity
winlinvip commentedon Jan 6, 2017
Gao Sheng has encountered something similar, but did not explain it clearly: #598
TRANS_BY_GPT3winlinvip commentedon Jan 6, 2017
Play a stream with a bitrate of 8Mbps using Flash player, set the ack size to
10*1024*1024, and print out the acknowledge messages sent by the Flash player.The
ack sizeis set to10*1024*1024, which means an acknowledge message should be sent after the player has played 10MB of data.For a flash player, the interval between sending messages, which is the difference in
seq, is0xa0192a-0x500ac2=5246568=5*1024*1024, which means it sends approximately half of theack size.Subsequently, it sends acknowledgements after receiving
5.002307891845703MB and5.0003662109375MB, which is roughly half of the window size.The following messages are:
The respective values are:
5.00229549407959,5.0017194747924805,5.00152587890625.Therefore, it can be confirmed that the behavior of the flash player is to send an acknowledge confirmation message to the server when it receives more than 1/2 of the ack size (window size).
TRANS_BY_GPT3winlinvip commentedon Jan 6, 2017
Regarding the server side, my colleague has tested two of them:
Once these two thresholds are exceeded, the server will reset the counter to 0.
NGINX-RTMP code: https://github.com/arut/nginx-rtmp-module/blob/c0bf381d10de05c135f913921c58272838d5e1ee/ngx_rtmp_handler.c#L275
This number has no basis and there is no comment explaining its source.
In nginx-rtmp, the ack is sent when it exceeds the ack window (unlike Flash, which sends it when it exceeds half the window).
TRANS_BY_GPT3winlinvip commentedon Jan 6, 2017
About the handling of flash player overflow, the log is as follows:
The overflowing data is padded with either 32 bits or 31 bits, which is significantly different from what flash sends. If we directly set it to zero, it can match, just like in nginx-rtmp, where it is set to zero when it exceeds 0xf0000000.
TRANS_BY_GPT3winlinvip commentedon Jan 6, 2017
This problem has only two solutions:
acknowledgeexceeds0xf0000000, it is set to zero.acknowledgemessage if it exceeds half of theack size.Supported in version 2.0.225.
TRANS_BY_GPT3for #730, refine code to decode the acknowledge message
for #730, reset ack follow flash player rules. 2.0.225
for #730, merge srs2
for #730, support config in/out ack size. 3.0.13
winlinvip commentedon Jan 6, 2017
In addition, some encoders do not send an ack size (usually indicating that they do not need to send an acknowledge confirmation message), but they still want the server to send a confirmation message. Therefore, it is necessary to support configuration that can change the ack size for both input and output.
Supported in 3.0.13.
TRANS_BY_GPT3remove test code for #730
For #730, remove the test code. 2.0.234
For #730, remove the test code. 2.0.234
[-]RTMP acknowledge 溢出导致编码器停止推流[/-][+]RTMP acknowledge overflow causes the encoder to stop streaming[/+]