Decode MetaBlock Multithreading #14

New Issue

claunia · 2026-01-29T20:28:55Z

claunia commented

2026-01-29 20:28:55 +00:00

Originally created by @dominikhlbg on GitHub (Aug 24, 2015).

More an idea as an issue.
Every MetaBlock could decode standalone in a thread.

Now an issue.
The blocksize is stored in meta-block header. (see spec. 9.2.) But only the final uncompressed size of block. The compressed size length isn't stored. That is a problem. Because the next thread will not know the position to start parallel the decoding of next block.

Solution:
Include a store information about compression block size.

Originally created by @dominikhlbg on GitHub (Aug 24, 2015). More an idea as an issue. Every MetaBlock could decode standalone in a thread. Now an issue. The blocksize is stored in meta-block header. (see spec. 9.2.) But only the final uncompressed size of block. The compressed size length isn't stored. That is a problem. Because the next thread will not know the position to start parallel the decoding of next block. Solution: Include a store information about compression block size.

claunia closed this issue

2026-01-29 20:28:55 +00:00

claunia commented

2026-01-29 20:28:55 +00:00

@eustas commented on GitHub (Oct 6, 2015):

Hello.

Nice idea. Unfortunately, the spec is frozen now.
But, like with deflate/gzip it shouldn't be a problem: brotli format could remain intact, and some framing format could be added around it to take care of parallel encoding/decoding.

Also, these is another solution: put block length information into the preceding metadata block.
So, format will be the same, but capable encoders/decoders would benefit from parallel execution.

We will be glad to hear about results of experiments in this area.

@eustas commented on GitHub (Oct 6, 2015): Hello. Nice idea. Unfortunately, the spec is frozen now. But, like with deflate/gzip it shouldn't be a problem: brotli format could remain intact, and some framing format could be added around it to take care of parallel encoding/decoding. Also, these is another solution: put block length information into the preceding metadata block. So, format will be the same, but capable encoders/decoders would benefit from parallel execution. We will be glad to hear about results of experiments in this area.

claunia commented

2026-01-29 20:28:56 +00:00

@rdp commented on GitHub (May 22, 2017):

So include it in the next version possibly? :)

@rdp commented on GitHub (May 22, 2017): So include it in the next version possibly? :)

claunia referenced this issue

2026-01-29 20:46:17 +00:00

[PR #14] [MERGED] Allow use of inline keyword in c++/c99 mode. #588

Sign in to join this conversation.