Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 19th March 2024, 21:37   #41  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,414
Quote:
Originally Posted by tormento View Post
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.
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 19th March 2024, 22:37   #42  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,816
Quote:
Originally Posted by Asmodian View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 20th March 2024, 12:54   #43  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 2,613
Quote:
Originally Posted by Asmodian View Post
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.
__________________
@turment on Telegram

Last edited by tormento; 20th March 2024 at 12:59.
tormento is offline   Reply With Quote
Old 20th March 2024, 13:03   #44  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 2,613
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.
__________________
@turment on Telegram
tormento is offline   Reply With Quote
Old 20th March 2024, 16:13   #45  |  Link
rwill
Registered User
 
Join Date: Dec 2013
Location: Berlin, Germany
Posts: 371
Quote:
Originally Posted by tormento View Post

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.
rwill is offline   Reply With Quote
Old 29th March 2024, 02:07   #46  |  Link
FTLOY
Friend of a friend..
 
FTLOY's Avatar
 
Join Date: Feb 2023
Posts: 289
Quote:
Originally Posted by jpsdr View Post
@tormento
From the help file:
Code:
   --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)

FTLOY is offline   Reply With Quote
Old 29th March 2024, 12:29   #47  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,752
Quote:
Originally Posted by FTLOY View Post
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.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 5th April 2024, 22:49   #48  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,816
Quote:
Originally Posted by Boulder View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 5th April 2024, 23:48   #49  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,359
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!
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 6th April 2024, 10:44   #50  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,330
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.
__________________
My github.
jpsdr is offline   Reply With Quote
Old 7th April 2024, 09:35   #51  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 2,613
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.
__________________
@turment on Telegram
tormento is offline   Reply With Quote
Old 7th April 2024, 10:00   #52  |  Link
rwill
Registered User
 
Join Date: Dec 2013
Location: Berlin, Germany
Posts: 371
Quote:
Originally Posted by tormento View Post
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.
rwill is offline   Reply With Quote
Old 7th April 2024, 10:04   #53  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,330
Quote:
Originally Posted by tormento View Post
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.
__________________
My github.
jpsdr is offline   Reply With Quote
Old 7th April 2024, 11:55   #54  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,752
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.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 20th May 2024, 03:09   #55  |  Link
FTLOY
Friend of a friend..
 
FTLOY's Avatar
 
Join Date: Feb 2023
Posts: 289
JPSDR X265 comparisons

Been doing a little bit of "testing" :-

Code:
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
__________________
RipBot264 v1.27.3 (08-06-2024)
FTLOY is offline   Reply With Quote
Old 21st May 2024, 18:56   #56  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,816
Quote:
Originally Posted by FTLOY View Post
Been doing a little bit of "testing" :-
Any interesting results so far?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 22nd May 2024, 05:59   #57  |  Link
FTLOY
Friend of a friend..
 
FTLOY's Avatar
 
Join Date: Feb 2023
Posts: 289
Quote:
Originally Posted by benwaggoner View Post
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)
__________________
RipBot264 v1.27.3 (08-06-2024)
FTLOY is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 14:01.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.