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

Support for blksize=24? #56

Open
joakimlemb opened this issue May 5, 2022 · 5 comments
Open

Support for blksize=24? #56

joakimlemb opened this issue May 5, 2022 · 5 comments

Comments

@joakimlemb
Copy link

Any chance to get support for blksize 24?

Like the windows fork has: https://github.com/pinterf/mvtools/blob/mvtools-pfmod/Sources/MVAnalyse.cpp#L161

@resistorsytrus
Copy link

If we can load avisynth 2.6 plugins, you can use it for supporting👍

@adworacz
Copy link
Contributor

Can you explain the reason for needing blocksize 24? Or any of the other odd sized blocksizes like 3,6,12, etc?

@joakimlemb
Copy link
Author

Can you explain the reason for needing blocksize 24? Or any of the other odd sized blocksizes like 3,6,12, etc?

Same reason as I would use blksize=32 vs blksize=16, speed vs quality.
There is a big jump from 16 to 32, having the option to choose any blksize in the increments of 2 (4,6,8,10,12,etc...) rather than in the power of 2 (4,8,16,32,64) would give users more options to choose from when it comes to quality vs speed.
Unless there is a valid reason why they need to be in the power of 2?

@adworacz
Copy link
Contributor

Interesting, I can see your point for greater blocksize resolution/granularity. The power of 2 blocksizes are useful as they align with how encoders partition up frames (often with blocksizes of 4 or 8, but sometimes higher), and aligning to those blocksizes can allow for directly addressing artifacts generated by those encoders.

A good example of this is the blocking artifacts generated by MPEG2 encoders, often seen on DVDs.

Modern encoders often use a variety of different blocksizes, even within the same frame, so matching blocksizes becomes less possible.

Lastly, using mod 2 blocksizes better aligns with SIMD / Vectorization instructions, as SIMD lanes are pretty much always mod 2. Using odd numbered blocksizes leads to waste in SIMD lanes. This isn't a huge deal, but it can mean that the performance differences don't scale perfectly linearly with blocksize, as a partially filled SIMD lane and a fully filled SIMD lane operate in the same number of CPU cycles.

I'll keep this in mind for my future MVTools-related work.

@joakimlemb
Copy link
Author

That makes sense, thanks for the detailed answer, I didn't consider the performance relation with SIMD optimization and block sizes, but having the data correctly aligned to match those CPU instructions makes sense with how the performance scales with the block sizes.

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

3 participants