Skip to content

add do not sleep wait state #171

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

Conversation

jumperson
Copy link
Contributor

@jumperson jumperson commented Feb 10, 2022

notice: #170 should be merged before merging this PR.

I added State.wait which doesn't call sleep.

There are cases in State.wait where it is not necessary to call Thread.sleep .

For example
https://github.com/natario1/Transcoder/blob/main/lib/src/main/java/com/otaliastudios/transcoder/internal/codec/Decoder.kt#L120

Call Thread.sleep in State.wait slows down the process when trimming the beginning
Fixes #169

@natario1
Copy link
Member

Thanks @jumperson , I like the idea but how are you deciding when to use Wait(false) or Wait(true)? I don't see a pattern.
Also I wonder if some of these Wait(false) could just be Retry.

@jumperson
Copy link
Contributor Author

@natario1 Thanks for reply.
I think the default behavior is Wait(false) . This is because even in the case of Wait, MediaExtractor.advance () is called and the state changes.
I think to call Thread.sleep is good only for if the document can read that Sleep is needed, such as INFO_TRY_AGAIN_LATER.

@natario1 natario1 marked this pull request as ready for review August 11, 2024 19:44
@natario1 natario1 mentioned this pull request Aug 12, 2024
@natario1
Copy link
Member

Merged via #202 , I needed to fix conflicts and do minor changes. Thanks!

@natario1 natario1 closed this Aug 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Trimming the start position slows transcode
2 participants