hevc-aq "production-ready"?

[Asmodian]

Originally Posted by tormento

Seems like the suggested autoaq 10 is lower in quality than the implementation with no parameters at all (Patman builds).

Do not use such small differences in objective metrics to define what is better quality. You have to watch it. These options are about tradeoffs, and what tradeoff looks better does not perfectly match with what optimizes VMAF, etc. Often the better optimization for apparent quality as judged by humans has a slightly lower VMAF, etc.

Codecs would be much easier to optimize if we had an objective metric that perfectly matched human perception, but sadly we do not.

[benwaggoner]

Originally Posted by Asmodian

Codecs would be much easier to optimize if we had an objective metric that perfectly matched human perception, but sadly we do not.

And whenever we get a new metric with high correlation, people start tuning their encoders for that metric and its correlation with subjective quality actually drops over time.

[tormento]

Originally Posted by Asmodian

Codecs would be much easier to optimize if we had an objective metric that perfectly matched human perception, but sadly we do not.

Benwaggoner suggested P.1203 and P.1204.

I have found a github repositori for P.1203 and P.1204.3.

It would be nice to have it in ffmpeg or in standard Windows build but I am not too optimistic about that.

[tormento]

I have just found this paragraph in VMAF paper:

We think that there is value in disregarding enhancement gain that is not part of a codec. We also believe that there is value in preserving enhancement gain in many cases to reflect the fact that enhancement can improve the visual quality perceived by the end viewers. Our solution to this dilemma is to introduce a new mode called VMAF NEG (“neg” stands for “no enhancement gain”). And we propose the following:

Use the NEG mode for codec evaluation purposes to assess the pure effect coming from compression.
Use the “default” mode to assess compression and enhancement combined.

So, I think, it can be used in a bit more flexible way.

[rwill]

Originally Posted by tormento

Use the NEG mode for codec evaluation purposes to assess the pure effect coming from compression.
Use the “default” mode to assess compression and enhancement combined.

A codec can cheat VMAF - NEG or not.

Originally Posted by jpsdr

@tormento
From the help file:

   --aq-auto                     Configure auto-AQ mode. Disabled 0 (default), <>0 enabled
                                   - Bit 1: If set to 1, enable hysteresis.
                                   - Bit 2: If set to 1, enable HDR mode => don't use biased mode on auto-AQ.
                                   - Bit 3: If set to 1, replace AQ-MODE 1 by AQ-MODE 5. Overrided by bit 2.

Value of a bit = 2^(Number/position of the bit)
8 bit data for exemple, bit 0 (LSB) to bit 7 (MSB).
So, Bit 0 -> 2^0 = 1, Bit 1 -> 2^1 = 2, etc...
So, setting bit 1 and bit 2 result in 2+4=6 value.
Setting only bit 0, so 1, will just enable aq-auto, without any other option activated (or any other bit than [1,2,3]).

This might as well be hieroglyphics from an ancient Egyptian tomb, can someone just provide an example of an x265 command.

I'm using either --aq-auto 6 or --aq-auto 10 (according to Boulder)

[Boulder]

Originally Posted by FTLOY

This might as well be hieroglyphics from an ancient Egyptian tomb, can someone just provide an example of an x265 command.

I'm using either --aq-auto 6 or --aq-auto 10 (according to Boulder)

Computers like binary things, so this is binary math with 0s and 1s. It just first confused me that the actual first bit is not used, but the three after that It's been 25 years since I had to deal with these things in this depth..which is why I didn't remember that the bit index starts from 0 so the bit index numbers are 0-7.

So by default, the 8-bit data would be 00000000 which is zero in decimal. If you flip bit number 1 to 1 to enable hysteresis, the binary data would be 00000010.

Now as jpsdr wrote, the decimal value can be calculated based on the position. Starting from left, the decimal value of each enabled bit (=1) is 128, 64, 32, 16, 8, 4, 2, 1. Here you get the terms MSB (=Most Significant Bit) and LSB (=Least Significant Bit) because the weight in the total value is very different.

So the maths for enabling just the hysteresis (i.e. SDR mode with aq-mode 1 instead of mode 5 available in the autoswitching) would be 0+0+0+0+0+0+2+0 = 2.

If you want to enable hysteresis and do an HDR encode (disabling the counter-productive luma biased modes), the binary data would be 00000110 and conversion to decimal 0+0+0+0+0+4+2+0 = 6. This is where the --aq-auto 6 comes from.

Hysteresis and aq-mode 5 replacing mode 1 in autoswitching would be done by enabling bits 1 and 3, binary data being 00001010, so the conversion is 0+0+0+0+8+0+2+0 = 10 and that is where you get --aq-auto 10.

[benwaggoner]

Originally Posted by Boulder

Computers like binary things, so this is binary math with 0s and 1s. It just first confused me that the actual first bit is not used, but the three after that It's been 25 years since I had to deal with these things in this depth..which is why I didn't remember that the bit index starts from 0 so the bit index numbers are 0-7.

So by default, the 8-bit data would be 00000000 which is zero in decimal. If you flip bit number 1 to 1 to enable hysteresis, the binary data would be 00000010.

Now as jpsdr wrote, the decimal value can be calculated based on the position. Starting from left, the decimal value of each enabled bit (=1) is 128, 64, 32, 16, 8, 4, 2, 1. Here you get the terms MSB (=Most Significant Bit) and LSB (=Least Significant Bit) because the weight in the total value is very different.

So the maths for enabling just the hysteresis (i.e. SDR mode with aq-mode 1 instead of mode 5 available in the autoswitching) would be 0+0+0+0+0+0+2+0 = 2.

If you want to enable hysteresis and do an HDR encode (disabling the counter-productive luma biased modes), the binary data would be 00000110 and conversion to decimal 0+0+0+0+0+4+2+0 = 6. This is where the --aq-auto 6 comes from.

Hysteresis and aq-mode 5 replacing mode 1 in autoswitching would be done by enabling bits 1 and 3, binary data being 00001010, so the conversion is 0+0+0+0+8+0+2+0 = 10 and that is where you get --aq-auto 10.

A very cogent explanation for a very confusing topic for those without a computer science background.

And an excellent case for just having the different bits be their own parameters! It's always a bad sign if customers have to look at a 2D table to control multiple independent variables.

[nevcairiel]

Flags are fine, but if you want to be user-friendly could offer a scheme like ffmpeg uses, and many other apps do - symbolic names.

For example:
--aq-auto hysteresis+aq5 (not a real working command)

Still relates all to the same parameter, still easily expandable, but you know what it does!

[jpsdr]

String command analysis stuff is absolutely not my thing... So i took the easy way "duplicating" an easy existing command with just a simple number.

[tormento]

Wouldn’t be just easier to feed aq with significative bit binary? I.e. 010 would be much easier to remember than mentally convert bin to dec every time.

[rwill]

Originally Posted by tormento

Wouldn’t be just easier to feed aq with significative bit binary? I.e. 010 would be much easier to remember than mentally convert bin to dec every time.

For the mentally challenged, the Windows Calculator should be able to convert binary to decimal.

[jpsdr]

Originally Posted by tormento

Wouldn’t be just easier to feed aq with significative bit binary? I.e. 010 would be much easier to remember than mentally convert bin to dec every time.

No, it was easier for me to deal with a number instead of a string, both for the parameter interface and for parameter analysis.

[Boulder]

Also in this case, I'd say that you either use --aq-auto 2, 6 or 10. Make a note of those somewhere and you'll never need to do binary math (at least in this context) again.

Been doing a little bit of "testing" :-

x265 [INFO]: HEVC encoder version 3.6+8+50-e89bec48b [Mod by JPSDR using mod by Patman]
x265 [INFO]: build info [Windows][MSVC 1928][64 bit] 10bit

or

x265 [INFO]: HEVC encoder version 3.6+8+50-e89bec48b [Mod by JPSDR using mod by Patman]
x265 [INFO]: build info [Windows][GCC 13.1.0][64 bit] 10bit


--auto-aq 0 (default x265)
x265 [INFO]: AQ: mode / str / qg-size / cu-tree      : 2 / 1.0 / 32 / 1


--auto-aq 1
x265 [INFO]: AQ: mode / str(edg) / qg-size / cu-tree : auto / 1.0(1.0) / 32 / 1


--auto-aq 2
x265 [INFO]: AQ: mode / str(edg) / qg-size / cu-tree : auto-hyst / 1.0(1.0) / 32 / 1


--auto-aq 3 (same as #2)
x265 [INFO]: AQ: mode / str(edg) / qg-size / cu-tree : auto-hyst / 1.0(1.0) / 32 / 1


--auto-aq 4
x265 [INFO]: AQ: mode / str(edg) / qg-size / cu-tree : auto-hdr / 1.0(1.0) / 32 / 1


--auto-aq 5 (same as #4)
x265 [INFO]: AQ: mode / str(edg) / qg-size / cu-tree : auto-hdr / 1.0(1.0) / 32 / 1


--auto-aq 6
x265 [INFO]: AQ: mode / str(edg) / qg-size / cu-tree : auto-hyst-hdr / 1.0(1.0) / 32 / 1


--auto-aq 7 (same as #6)
x265 [INFO]: AQ: mode / str(edg) / qg-size / cu-tree : auto-hyst-hdr / 1.0(1.0) / 32 / 1


--auto-aq 8
x265 [INFO]: AQ: mode / str(edg) / qg-size / cu-tree : auto-aq5 / 1.0(1.0) / 32 / 1


--auto-aq 9 (same as #8)
x265 [INFO]: AQ: mode / str(edg) / qg-size / cu-tree : auto-aq5 / 1.0(1.0) / 32 / 1


--auto-aq 10
x265 [INFO]: AQ: mode / str(edg) / qg-size / cu-tree : auto-hyst-aq5 / 1.0(1.0) / 32 / 1

=======================================================================================

x265 [INFO]: HEVC encoder version 3.6+2+13-9a3dac6e5 [Mod by Patman]
x265 [INFO]: build info [Windows][GCC 13.2.0][64 bit] 10bit

x265 [INFO]: AQ: mode / str / qg-size / cu-tree      : auto / 1.0 / 32 / 1

[benwaggoner]

Originally Posted by FTLOY

Been doing a little bit of "testing" :-

Any interesting results so far?

Originally Posted by benwaggoner

Any interesting results so far?

Sorry Ben, I actually haven't done any encodes, I was more interested in what the x265 commands were in reference to the --auto-aq number(s).

ATM I am using Patman's very latest build (posted yesterday)