Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

After the bugfix for ATC is enabled, the client resetting the timestamp will cause the consumer wait condition to not trigger for a long time. #749

Closed
wants to merge 2 commits into from

Conversation

censhanhe
Copy link
Contributor

@censhanhe censhanhe commented Jan 18, 2017

After the bugfix for ATC is enabled, the client resetting the timestamp will cause the consumer wait condition to not trigger for a long time.


TRANS_BY_GPT3

@censhanhe
Copy link
Contributor Author

censhanhe commented Jan 18, 2017

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

@winlinvip
Copy link
Member

winlinvip commented Jan 18, 2017

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

@censhanhe
Copy link
Contributor Author

censhanhe commented Jan 18, 2017

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

winlinvip added a commit that referenced this pull request Jan 18, 2017
@winlinvip
Copy link
Member

winlinvip commented Jan 18, 2017

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

TRANS_BY_GPT3

@winlinvip winlinvip closed this Jan 18, 2017
@winlinvip
Copy link
Member

winlinvip commented Jan 18, 2017

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

@winlinvip winlinvip changed the title bugfix atc 开启后,由于客户端重置时间撮,会导致consumer wait condition 长时间不触发. After the bugfix for ATC is enabled, the client resetting the timestamp will cause the consumer wait condition to not trigger for a long time. Jul 29, 2023
@winlinvip winlinvip added the TransByAI Translated by AI/GPT. label Jul 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
TransByAI Translated by AI/GPT.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants