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

[question] Parlallelized opus decoder #505

Open
vadimkantorov opened this issue Jun 26, 2023 · 2 comments
Open

[question] Parlallelized opus decoder #505

vadimkantorov opened this issue Jun 26, 2023 · 2 comments

Comments

@vadimkantorov
Copy link

vadimkantorov commented Jun 26, 2023

Hi!

Coming from https://github.com/enzo1982/superfast and https://www.freac.org/developer-blog-mainmenu-9/14-freac/257-introducing-superfast-conversions. Do I understand correctly that only chunked/parallelized opus encoding is implemented? Do you have any thoughts / experiments on decoding?

I found a paper on GPU-parallelized decoding of FLAC http://users.cecs.anu.edu.au/~Eric.McCreath/papers/YeMcCreathISPA2018.pdf https://github.com/Harinlen/GPUraku

Would you think this is possible? Is opus amenable to chunked decoding?

@enzo1982
Copy link
Owner

Hi!

Yes, fre:ac/BoCA only implements parallelized encoding, not decoding. The reason is that decoding already is much faster, so it didn't seem necessary to parallelize it at the time. I consider implementing parallelized decoding at some point, but in a generalized fashion, so it would work with any codec (or at least most of them). Although the expected performance benefit for file conversions should be relatively small in most cases.

Opus, like most lossy codecs, does not have completely independent frames, so you would have to implement some overlap to allow filter states to settle. Kind of similar to what SuperFast does for Opus encoding.

I've noticed that you brought up the topic at xiph/opus#289 as well and I think @rillian already gave a very good answer to most of your questions.

@vadimkantorov
Copy link
Author

Thank you for your insights :) Indeed, let's continue the discussion there, but I think your current parallelized encoding scheme with overlaps could also be of use to be outlined there!

Maybe an example program of this parallelized encoding could be contributed upstream to stock opus for posterity if you so desire :)

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

No branches or pull requests

2 participants