FFmpeg scaler flags: full_chroma_inp, full_chroma_int, accurate_rnd ?

[pachura]

Hello,

I am downscaling some 4K videos to 1080p with FFmpeg.
Both input and output should be standard H.264 - 8-bit, YUV 4:2:0.

I'm not quite sure if I understand the meaning of the following scaler flags - could you help me with these?

• full_chroma_inp - this forces scaler to treat the input as full YUV 4:4:4, right? So it doesn't make sense to use it in my case?
• full_chroma_int - this is about using the full YUV 4:4:4 for internal processing when rescaling? Would it change anything if I apply -pix_fmt yuv420p afterwards anyway?
• accurate_rnd - "Enable accurate rounding". I assume it is somewhat slower but more precise mode? Which would result in a slightly sharper result?

Thanks!

[pandy]

Hello,

I am downscaling some 4K videos to 1080p with FFmpeg.
Both input and output should be standard H.264 - 8-bit, YUV 4:2:0.

I'm not quite sure if I understand the meaning of the following scaler flags - could you help me with these?

• full_chroma_inp - this forces scaler to treat the input as full YUV 4:4:4, right? So it doesn't make sense to use it in my case?
• full_chroma_int - this is about using the full YUV 4:4:4 for internal processing when rescaling? Would it change anything if I apply -pix_fmt yuv420p afterwards anyway?
• accurate_rnd - "Enable accurate rounding". I assume it is somewhat slower but more precise mode? Which would result in a slightly sharper result?

Thanks!

More or less true (ffmpeg documentation is quite vague on this) - IMHO without those flags you may expect quality loss.

[pachura]

More or less true (ffmpeg documentation is quite vague on this) - IMHO without those flags you may expect quality loss.

Hmmm. If my input is YUV 4:2:0, I think adding full_chroma_inp is unnecessary... I guess this flag is useful when doing RGB<->YUV conversions or when using YUV444 colorspace...

I've found some discussions on the subject here and here, but it's all so confusing

[pandy]

More or less true (ffmpeg documentation is quite vague on this) - IMHO without those flags you may expect quality loss.

Hmmm. If my input is YUV 4:2:0, I think adding full_chroma_inp is unnecessary... I guess this flag is useful when doing RGB<->YUV conversions or when using YUV444 colorspace...

I've found some discussions on the subject here and here, but it's all so confusing

Spent 20 minutes, do some tests and judge by yourself... In my opinion those flags deliver higher visual quality at relatively small speed penalty.

[pachura]

Spent 20 minutes, do some tests and judge by yourself... In my opinion those flags deliver higher visual quality at relatively small speed penalty.

Did that.

In my case - when both input and output are yuv420p - the following settings produce binary-identical output files:

-sws_flags spline+accurate_rnd+full_chroma_int+full_chroma_inp -pix_fmt yuv420p
-sws_flags spline+accurate_rnd+full_chroma_int                 -pix_fmt yuv420p
-sws_flags spline+accurate_rnd                                 -pix_fmt yuv420p

...which more or less confirms my assumptions.

[pandy]

Spent 20 minutes, do some tests and judge by yourself... In my opinion those flags deliver higher visual quality at relatively small speed penalty.

Did that.

In my case - when both input and output are yuv420p - the following settings produce binary-identical output files:

-sws_flags spline+accurate_rnd+full_chroma_int+full_chroma_inp -pix_fmt yuv420p
-sws_flags spline+accurate_rnd+full_chroma_int                 -pix_fmt yuv420p
-sws_flags spline+accurate_rnd                                 -pix_fmt yuv420p

...which more or less confirms my assumptions.

Well... knowing ffmpeg a bit i can say only one thing - perhaps they fixed some issues and some behaviour before non-default is now default but my observations on ffmpeg way before rev 3 leaded me to conclusion to use those flag as integral part of any resize on ffmpeg.
And one question - are you observing speed difference for those flags? If not then it may explain lack of difference between tries - perhaps they are active by default (so you could replace + sign with - sign and check how ffmpeg behave with explicitly disabled flags).
I will be not surprised if those flags are now active by default.