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 25th October 2022, 18:03   #8681  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,770
Quote:
Originally Posted by benwaggoner View Post
Gotcha.

It's not like SDR is more "real" pixels than HDR, it's just been the primary EOTF (Electro-optical transfer function) for the first decades of digital video. But gamma is a psychovisual optimization every bit as much as the PQ curve, just with simpler math that isn't optimal for a broader dynamic range.

It's really hard to work with HDR without a 10-bit HDR display and HDR-enabled tools, because what you see is not what you get. Encoders that are tuned for SDR aren't optimal for HDR, and vise versa. Optimal SDR needs lower QPs near black as code value steps are much more visible at the low end than the high end in SDR. HDR is much more perceptually uniform, and benefits from different optimizations like --hdr10-opt which would make near-dark look really bad if applied to SDR.
Yeah, it's sometimes difficult to grasp the idea that the PC monitor can fool you big time with HDR encodes..

My thinking was more or less around the fact that for example aq-mode 3 has not been recommended for HDR encodes because it will start allocating bits into all the wrong places. Now if this new automatic method uses all modes as it seems necessary, things could go quite wrong. A movie like Blade Runner 2049 might be a good test since it has both ends of the spectrum.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is online now   Reply With Quote
Old 25th October 2022, 21:45   #8682  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,828
Quote:
Originally Posted by Boulder View Post
My thinking was more or less around the fact that for example aq-mode 3 has not been recommended for HDR encodes because it will start allocating bits into all the wrong places. Now if this new automatic method uses all modes as it seems necessary, things could go quite wrong. A movie like Blade Runner 2049 might be a good test since it has both ends of the spectrum.
Gotcha.

Lots of algorithms assume perceptual uniformity across code values, so the difference between 16 and 17 is as important as between 234 and 235. And while that's not true for SDR, it is true for PQ, so I've seen non-SDR optimized algorithms that work better with PQ than SDR. However, if an algorithm has a low-luma bias for SDR, it will work quite a bit worse with HDR.

Hopefully the algorithm either ignores dark bias, or is adaptive based on the color space being encoded.

In the early years of HDR encoding, we fundamentally encoded everything as if it were SDR, avoiding any SDR-optimized tuning, and it worked okay. Later we got stuff like --hdr10-opt which specifically optimizes for HDR.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 26th October 2022, 08:13   #8683  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 492
x265 v3.5+57
Built on October 26, 2022, GCC 12.2.0

https://bitbucket.org/multicoreware/.../branch/master


DL :
https://www.mediafire.com/file/9ohiddzw2yftl7w
Barough is offline   Reply With Quote
Old 26th October 2022, 10:47   #8684  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,885
MABS included a patch which should be commited soon in the x265 repo.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 26th October 2022, 12:52   #8685  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,770
Quote:
Originally Posted by benwaggoner View Post
Later we got stuff like --hdr10-opt which specifically optimizes for HDR.
I'm afraid this optimization is just adjusting QP offsets, for example this small snippet of a code. From what I gather, any luma level related aq-mode would be doing similar things on top or before that, which cannot be good practice.

Code:
if (param->bHDR10Opt)
                        {
                            uint32_t sum = lumaSumCu(curFrame, blockX, blockY, param->rc.qgSize);
                            uint32_t lumaAvg = sum / (loopIncr * loopIncr);
                            if (lumaAvg < 301)
                                qp_adj += 3;
                            else if (lumaAvg >= 301 && lumaAvg < 367)
                                qp_adj += 2;
                            else if (lumaAvg >= 367 && lumaAvg < 434)
                                qp_adj += 1;
                            else if (lumaAvg >= 501 && lumaAvg < 567)
                                qp_adj -= 1;
                            else if (lumaAvg >= 567 && lumaAvg < 634)
                                qp_adj -= 2;
                            else if (lumaAvg >= 634 && lumaAvg < 701)
                                qp_adj -= 3;
                            else if (lumaAvg >= 701 && lumaAvg < 767)
                                qp_adj -= 4;
                            else if (lumaAvg >= 767 && lumaAvg < 834)
                                qp_adj -= 5;
                            else if (lumaAvg >= 834)
                                qp_adj -= 6;
                        }
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is online now   Reply With Quote
Old 26th October 2022, 13:42   #8686  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,333
Build a release of current version with Patman mods.

https://github.com/jpsdr/x265/releases
__________________
My github.
jpsdr is offline   Reply With Quote
Old 26th October 2022, 16:28   #8687  |  Link
Stereodude
Registered User
 
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
Quote:
Originally Posted by jpsdr View Post
Build a release of current version with Patman mods.

https://github.com/jpsdr/x265/releases
Thanks for the builds. Sorry if this is a dumb question, but what's the difference between the standard build and the AVX2 builds? The standard one shows it has AVX2 enabled.
Stereodude is offline   Reply With Quote
Old 26th October 2022, 17:02   #8688  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,333
Standard is build with no specific arch instruction (for the C code part), so it will run on "any" CPU. The AVX2 build is build specifying AVX2 arch CPU instruction (for the C code part), so, it can't run on CPU without at least AVX2.
__________________
My github.
jpsdr is offline   Reply With Quote
Old 26th October 2022, 19:22   #8689  |  Link
LeXXuz
21 years and counting...
 
LeXXuz's Avatar
 
Join Date: Oct 2002
Location: Germany
Posts: 716
Quote:
Originally Posted by jpsdr View Post
Build a release of current version with Patman mods.

https://github.com/jpsdr/x265/releases
Thanks a lot for this.
LeXXuz is offline   Reply With Quote
Old 26th October 2022, 20:00   #8690  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,828
Quote:
Originally Posted by Boulder View Post
I'm afraid this optimization is just adjusting QP offsets, for example this small snippet of a code. From what I gather, any luma level related aq-mode would be doing similar things on top or before that, which cannot be good practice.
Yes, it is exactly doing QP offsets for psychovisual improvements. IIRC, it's based on an IEEE paper from the mid 2010s. It's a pretty basic implementation with room for further enhancements, certainly. It can wind up raising QPs in the darks a little too much.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 27th October 2022, 16:56   #8691  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,333
As i've said, i have some concern about possible flickering issue with sbrc. One possible "fix" would be some kind of "fuzzy" logic, but it's not always possible, another, easier to put is to have an hysteresis.

In my mod branch, i've made a patch to allow the possibility of an hysteresis in sbrc decision. Limit/range of hysteresis is for now totaly "out of the blue", no idea what to put (relative like i've done, static...).
No build made yet, your thoughts about it : https://github.com/jpsdr/x265/commit...20b89f8e78f255

Also, your thoughts about another possible sbrc tweak : add (another...) switch to allow X265_AQ_EDGE : X265_AQ_EDGE_BIASED instead of X265_AQ_EDGE : X265_AQ_EDGE_BIASED_SBRC.

Waiting your feedback...
__________________
My github.
jpsdr is offline   Reply With Quote
Old 27th October 2022, 17:04   #8692  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,333
Just thought !!!
Can sbrc be ported back to x264 ??? I don't think this feature exist.
If i'm so over it, it's because i found the idea (with some minor adjustments ) realy interesting !
__________________
My github.
jpsdr is offline   Reply With Quote
Old 27th October 2022, 17:05   #8693  |  Link
ShortKatz
Registered User
 
Join Date: Aug 2018
Location: Germany
Posts: 126
Is there something special with --mcstf ? I'm getting a crash if I try to use it with my custom build HandBrake.

Edit: OK, all-clear. That is just a bug in the current code.
This patch does fix the crash: https://mailman.videolan.org/piperma...er/013521.html

Edit2: I think I will never use --mcstf for whole movies. This option does increase the encoding time for me 7 times.

Last edited by ShortKatz; 27th October 2022 at 20:22.
ShortKatz is offline   Reply With Quote
Old 27th October 2022, 22:57   #8694  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,828
Quote:
Originally Posted by jpsdr View Post
Just thought !!!
Can sbrc be ported back to x264 ??? I don't think this feature exist.
If i'm so over it, it's because i found the idea (with some minor adjustments ) realy interesting !
There is a TON of great x265 features that should be back ported to x264. I know MCW contributed a lot of patches from x265 back, but not a lot made it into main. I would so love to have CSV logging, for example. And I know that code was contributed to x265 at least seven years ago.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 27th October 2022, 23:18   #8695  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,885
New upload: x265 3.5+57-4d2890fe4

[Windows][GCC 12.2.0][32/32XP/64 bit] 8bit+10bit+12bit

News since v3.5+39:
Code:
   --[no-]sbrc                   Enables the segment based rate control, using its scene statistics. Default disabled

   --[no-]mcstf                  Enable GOP based temporal filter. Default 0
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 28th October 2022, 08:38   #8696  |  Link
LeXXuz
21 years and counting...
 
LeXXuz's Avatar
 
Join Date: Oct 2002
Location: Germany
Posts: 716
Quote:
Originally Posted by jpsdr View Post
As i've said, i have some concern about possible flickering issue with sbrc. One possible "fix" would be some kind of "fuzzy" logic, but it's not always possible, another, easier to put is to have an hysteresis.
Haven't noticed anything so far. What kind of flickering would that be and where possible to look out for?
LeXXuz is offline   Reply With Quote
Old 28th October 2022, 15:44   #8697  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,333
Possible situation...
If the calculated value is at the threshold value, check here.
__________________
My github.
jpsdr is offline   Reply With Quote
Old 28th October 2022, 18:11   #8698  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,333
I've also added the option to use AQ-MODE 5 instead of AQ-MODE 1 in sbrc, and... i've made a build, it's on my github.
So you can play with both experimental options i've added...
__________________
My github.
jpsdr is offline   Reply With Quote
Old 29th October 2022, 09:20   #8699  |  Link
LeXXuz
21 years and counting...
 
LeXXuz's Avatar
 
Join Date: Oct 2002
Location: Germany
Posts: 716
Quote:
Originally Posted by jpsdr View Post
I've also added the option to use AQ-MODE 5 instead of AQ-MODE 1 in sbrc, and... i've made a build, it's on my github.
So you can play with both experimental options i've added...
M'kay, sbrc was worth a shot. I've seen that flickering now. Unbearable.
Not sure if aq-mode 5 + sbrc would change anything on that.

I guess I will test a little more with just aq-mode 4 and 5 now. aq-mode 3 does improve faint details in very dark scenes slightly where aq-mode 2 fails, even with generous CRF values of 18 and below. The opening scene of Thor (2011) is one of these rare cases where x265 doesn't spend enough bits with aq-mode 1/2 for that scene and the result looks awful. Even CRF 16 with the Very Low preset +rskip and -sao didn't change anything on that.

But I think aq-mode 3 just wastes too much bits in general compared to the other aq-modes. Even clips with no dark scenes at all get much bigger than with mode 2, which I don't quite understand to be honest.
LeXXuz is offline   Reply With Quote
Old 29th October 2022, 15:19   #8700  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,333
Sure flickering is because of sbrc ? I was just talking of a rare theoretical possible situation sbrc may produce...
But if it's because of that, the hysteresis option may help, it's for that case i've made it.
__________________
My github.
jpsdr 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 08:25.


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