Does min-cu-size=8 hurt quality?.

[F3low]

Hi,

I've had that command enabled for everything to force 1920x1080p on some videos.

Thanks.

[microchip8]

No, but on 1080p, a lot of people use cu-size of 32. 64 is mostly beneficial for UHD

[F3low]

No, but on 1080p, a lot of people use cu-size of 32. 64 is mostly beneficial for UHD

Would changing 8 to 32 improve quality? what does this option do exactly?.

[Blue_MiSfit]

Don't get confused between --ctu and --min-cu-size

https://x265.readthedocs.io/en/default/cli.html#cmdoption-min-cu-size

You probably don't want to mess with this. Use the presets. 8 is the default for everything except ultrafast.

It sets the minimum possible coding unit size. The HEVC standard lets you go as small as 8x8 and the encoder will do this when it makes sense.

If you force this to be higher then you can go faster in some cases because you don't even evaluate 8x8. In practice, you will usually want to have some 8x8 CUs though, so forcing the encoder to never consider this is a bad idea.

--ctu on the other hand is a super important setting. The default (64) makes sense most of the time. Lower values can preserve a bit more fine detail in still images and can be more parallel (since you're processing a larger number of smaller CUs), but the 64x64 CU is a HUGE deal in HEVC and helps a ton overal for most content, especially 4K, and especially when you compare clips in motion vs still images. The reduction in blocking is great!

I suggest always leaving this at 64 unless you need to go fast, in which case you should be using the presets anyway :)

[F3low]

Don't get confused between --ctu and --min-cu-size

https://x265.readthedocs.io/en/default/cli.html#cmdoption-min-cu-size

You probably don't want to mess with this. Use the presets. 8 is the default for everything except ultrafast.

It sets the minimum possible coding unit size. The HEVC standard lets you go as small as 8x8 and the encoder will do this when it makes sense.

If you force this to be higher then you can go faster in some cases because you don't even evaluate 8x8. In practice, you will usually want to have some 8x8 CUs though, so forcing the encoder to never consider this is a bad idea.

--ctu on the other hand is a super important setting. The default (64) makes sense most of the time. Lower values can preserve a bit more fine detail in still images and can be more parallel (since you're processing a larger number of smaller CUs), but the 64x64 CU is a HUGE deal in HEVC and helps a ton overal for most content, especially 4K, and especially when you compare clips in motion vs still images. The reduction in blocking is great!

I suggest always leaving this at 64 unless you need to go fast, in which case you should be using the presets anyway :)

:thanks: I don't usually mess with commands. --min-cu-size 8 was suggested to me on this forum because I was having trouble upscaling some videos to 1080p.

Though I don't understand this: Note

All encoders within a single process must use the same settings for the CU size range. --ctu and --min-cu-size must be consistent for all of them since the encoder configures several key global data structures based on this range.

By consistent, doesn't that mean it should be ctu=32 min-cu-size=32 / instead of ctu=64 min-cu-size=8?.

[MeteorRain]

That means if you choose 64/8 for one encoder inside a running process (a running process is an individual program process, refer to OS text book if you don't know), you can't run another encoder within the same process with different settings.

For example you have a tool called a.exe that internally initialize x265 encoder with mincu=8, then you can't internally initialize another x265 encoder with mincu=16. You have to run another a.exe to encode in a different cu size.

If you run x265.exe, then if you run x265 with mincu=8, and you want to make another encode with mincu=16, you have to run another x265.exe. Hope this is clear.

[Blue_MiSfit]

By consistent, doesn't that mean it should be ctu=32 min-cu-size=32 / instead of ctu=64 min-cu-size=8?.

No. It only applies to a special case where you're using a special app that runs multiple x265 instances in parallel. You're not doing this, so don't worry about it. Just use the defaults :)

[F3low]

Thanks guys :)