The condition for this bug to occur is: ATC is enabled, and the streaming end is disconnected and then reconnected.
The reason is: ATC is enabled, and the timestamp is reset (meaning the streaming end did not continue from the previous timestamp). Because the SrsSource cache contains some SH packets with the previous streaming timestamp (which is much larger than the newly pushed timestamp), this causes the queue duration calculation to be negative. As a result, the consumer wait condition is not triggered for a long time.

TRANS_BY_GPT3

This is indeed a problem, but the solution is not to directly free SH and metadata. SRS has a function called reduce_sequence_header, which means that if the encoder pushes duplicate SH to the server, the server can choose not to send it to the client. This function is designed to accommodate some clients that may crash when receiving duplicate SH [facepalm].

You can think of other ways to fix this problem, such as modifying the timestamp. In any case, SH cannot be freed, it needs to be cached in order to support SH deduplication functionality.

TRANS_BY_GPT3

Hmm, actually there is another similar issue, which is that the timestamp of the client itself is not incremental. In the ATC mode, there may also be a problem where the condition is not triggered.
In this case, a common solution is to modify the trigger condition of the condition. In ATC mode, if the duration is less than 0, the condition can be triggered immediately.

TRANS_BY_GPT3

Based on your work, I made some slight modifications and updated the version and README.
👍 Thanks~

TRANS_BY_GPT3

The purpose of this ATC mode is to expose the timestamp issue without making any modifications to the timestamp. However, with the changes you made, this goal can still be achieved, and the tolerance is even higher. Great job~ It improves robustness without compromising the original intention of ATC.

TRANS_BY_GPT3