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 18th June 2019, 08:19   #6861  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,968
CRF means: Constant Rate Factor. It keeps an internal distortion metric in the encoding workflow (called "rate factor") below a threshold. But many details are part of the RF calculation, and not all represent your personal subjective quality impression perfectly. Yet, it is a much better one than PSNR and allows an easy adjustment of the quantization with some respect to the encoding complexity. But a few seemingly paradox results may happen. Heavier efforts do not always result in more efficient video stream code or visually more convenient pictures, exceptions from a general rule aren't impossible.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 18th June 2019, 15:33   #6862  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 193
welcome back LigH. Missing new builds from you. Haven't seen you for a longer time here active.
__________________
Core i9-7960X, 64GB DDR4, RTX 2070, 1TB NVMe SSD, 56TB NAS
jlpsvk is offline   Reply With Quote
Old 18th June 2019, 18:51   #6863  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 86
Quote:
Originally Posted by StvG View Post
Hey. A week ago or so I tested VS2019 builds and I had no problems when using zones. GCC builds were crashing when using zones.
Oh man. You put my hopes so high...
Tried out RC1+3 (built with VS2019) but... no luck - it still crashes for me.


Code:
Video encoding [...] failed with exit code: -1073740940 (0xC0000374)

The exit code might be a system error code: Ein Heap wurde beschädigt.

[...]
x265 [info]: HEVC encoder version 3.1_RC1+3-3bdf06e3c628
[...]
*sigh*
katzenjoghurt is offline   Reply With Quote
Old 19th June 2019, 04:19   #6864  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,984
Error disabling --hdr-opt

So, I am trying to do a lossless HDR encoding test.

Quote:
x265.exe - --y4m --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --hdr --hdr-opt -o 4K_LOSSLESS.hevc
And I get this error, which sounds like hdr-opt is getting deactivated because it is confused about the metadata?

Quote:
Output #0, yuv4mpegpipe, to 'pipe:':
Metadata:
encoder : Lavf58.27.103
Stream #0:0: Video: wrapped_avframe, yuv420p10le, 3840x2160, q=2-31, 200 kb/s, 24 fps, 24 tbn, 24 tbc
Metadata:
encoder : Lavc58.53.100 wrapped_avframe
y4m [info]: 3840x2160 fps 24/1 i420p10 unknown frame count
raw [info]: output file: D:\Octarine\foo_4k_HDR.hevc
x265 [info]: HEVC encoder version 3.1_RC1+3-3bdf06e3c628
x265 [info]: build info [Windows][MSVC 1921][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [error]: Recommended Settings for HDR: colour primaries should be BT.2020,
transfer characteristics should be SMPTE ST.2084,
matrix coeffs should be BT.2020,
the input video should be 10 bit 4:2:0
Disabling offset tuning for HDR videos
x265 [warning]: Turning on repeat-headers for HDR compatibility
Everything seems set up just fine. Any thoughts about what might be going on here?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 19th June 2019, 09:43   #6865  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,968
Quote:
Originally Posted by jlpsvk View Post
welcome back LigH. Missing new builds from you.
Ah, well ... had some issues with other projects compiled in MABS, and more work thus less spare time. And there are so many competitors now. But a "merge with stable" is a reason to publish another one.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 19th June 2019, 10:33   #6866  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,575
@benwaggoner I'd suggest patching out the feature that disables hdr-opt in certain conditions. You certainly know what you're doing and it's a one-line fix
Blue_MiSfit is offline   Reply With Quote
Old 19th June 2019, 18:08   #6867  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,984
Quote:
Originally Posted by Blue_MiSfit View Post
@benwaggoner I'd suggest patching out the feature that disables hdr-opt in certain conditions. You certainly know what you're doing and it's a one-line fix
First off, I want to know what the conditions are. I don't dismiss the possibility that I don't know what I'm doing in some aspect .
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 19th June 2019, 19:45   #6868  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 337
x265 v3.1+2-b36c03e4e771 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.1.0)

Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default
Barough is offline   Reply With Quote
Old 19th June 2019, 20:18   #6869  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,575
@benwaggoner

https://bitbucket.org/multicoreware/...cpp#lines-3316

Code:
if (p->internalCsp != X265_CSP_I420 || p->internalBitDepth != 10 || p->vui.colorPrimaries != 9 ||
            p->vui.transferCharacteristics != 16 || p->vui.matrixCoeffs != 9)
So, if any of the following are NOT true x265 will disable hdr-opt

4:2:0
10 bit
color primaries = 9 (bt2020)
transfer characteristics = 16 (smpte2084)
matrix coefficients = 9 (bt2020nc)

It does look like you're set up correctly, so no idea why this is happening.

I've found hdr-opt to be helpful for Dolby Vision Profile 5 encoding, which is incompatible with the required VUI to enable it, so I just patched out the above code block
Blue_MiSfit is offline   Reply With Quote
Old 20th June 2019, 03:01   #6870  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 107
Quote:
Originally Posted by katzenjoghurt View Post
Oh man. You put my hopes so high...
Tried out RC1+3 (built with VS2019) but... no luck - it still crashes for me.


Code:
Video encoding [...] failed with exit code: -1073740940 (0xC0000374)

The exit code might be a system error code: Ein Heap wurde beschädigt.

[...]
x265 [info]: HEVC encoder version 3.1_RC1+3-3bdf06e3c628
[...]
*sigh*
gcc:
Code:
avs2yuv_x64 -depth 10 1.avs -o - | x265-10b.exe --y4m - --level-idc 5.1 --high-tier --ref 6 --bframes 12 --rd 4 --me 3 --subme 5 --merange 57 --ipratio 1.2 --pbratio 1.1 --aq-mode 3 --aq-strength 0.95 --qcomp 0.70 --psy-rd 1.35 --psy-rdoq 1.20 --ctu 32 --rc-lookahead 60 --deblock -3:-3 --cbqpoffs 0 --crqpoffs 0 --qg-size 8 --no-rskip --no-rect --no-amp --no-sao --no-open-gop --no-early-skip --no-cutree --tu-intra-depth 4 --tu-inter-depth 4 --range limited --aud --repeat-headers --hrd --hdr-opt --colorprim bt2020 --colormatrix bt2020nc --transfer smpte2084 --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,20)" --max-cll=0,0 --input-depth 10 --chromaloc 2 --preset slower -o gcc.mkv --asm avx512 --zones 2100,3000,b=1.22/9000,10500,b=1.3/13000,13500,b=1.1/22000,22320,b=1.11/25000,25300,b=1.15 --crf 17 > gcc.txt 2>&1
Code:
y4m  [info]: 1920x1080 fps 24000/1001 i420p10 unknown frame count
raw  [info]: output file: gcc.mkv
x265 [info]: HEVC encoder version 3.1_RC1+3-3bdf06e3c628
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 10bit
...
30194 frames: 5.47 fps, 20856.40 kb/s  
30198 frames: 5.47 fps, 20855.46 kb/s  
30201 frames: 5.47 fps, 20854.86 kb/s  
30206 frames: 5.47 fps, 20853.95 kb/s  
30210 frames: 5.47 fps, 20852.97 kb/s
vs2019:
Code:
avs2yuv_x64 -depth 10 1.avs -o - | x265-10bvs.exe --y4m - --level-idc 5.1 --high-tier --ref 6 --bframes 12 --rd 4 --me 3 --subme 5 --merange 57 --ipratio 1.2 --pbratio 1.1 --aq-mode 3 --aq-strength 0.95 --qcomp 0.70 --psy-rd 1.35 --psy-rdoq 1.20 --ctu 32 --rc-lookahead 60 --deblock -3:-3 --cbqpoffs 0 --crqpoffs 0 --qg-size 8 --no-rskip --no-rect --no-amp --no-sao --no-open-gop --no-early-skip --no-cutree --tu-intra-depth 4 --tu-inter-depth 4 --range limited --aud --repeat-headers --hrd --hdr-opt --colorprim bt2020 --colormatrix bt2020nc --transfer smpte2084 --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,20)" --max-cll=0,0 --input-depth 10 --chromaloc 2 --preset slower -o vs.mkv --asm avx512 --zones 2100,3000,b=1.22/9000,10500,b=1.3/13000,13500,b=1.1/22000,22320,b=1.11/25000,25300,b=1.15 --crf 17 > vs.txt 2>&1
Code:
y4m  [info]: 1920x1080 fps 24000/1001 i420p10 unknown frame count
raw  [info]: output file: vs.mkv
x265 [info]: HEVC encoder version 3.1_RC1+3-3bdf06e3c628
x265 [info]: build info [Windows][MSVC 1921][64 bit] 10bit
...
30194 frames: 5.32 fps, 20856.40 kb/s  
30197 frames: 5.32 fps, 20855.68 kb/s  
30199 frames: 5.32 fps, 20855.23 kb/s  
30201 frames: 5.32 fps, 20854.86 kb/s  
30205 frames: 5.32 fps, 20854.18 kb/s  
30207 frames: 5.33 fps, 20853.70 kb/s  
30210 frames: 5.33 fps, 20852.97 kb/s  
                                                                                
x265 [info]: frame I:    204, Avg QP:14.97  kb/s: 33917.45
x265 [info]: frame P:   3896, Avg QP:16.17  kb/s: 26657.95
x265 [info]: frame B:  26112, Avg QP:17.10  kb/s: 20900.09
x265 [info]: Weighted P-Frames: Y:2.8% UV:0.6%
x265 [info]: Weighted B-Frames: Y:5.6% UV:0.2%
x265 [info]: consecutive B-frames: 13.6% 1.0% 2.4% 9.0% 3.2% 7.3% 3.9% 24.4% 5.8% 4.8% 4.0% 14.9% 5.6% 

encoded 30212 frames in 5669.34s (5.33 fps), 21730.49 kb/s, Avg QP:16.97
GCC build didn't output the last lines with the statistics but the last encoded frame is identical to the vs last frame. Also GCC as always is a bit faster than VS at least for me.

Edit: GCC MediaInfo and VS MediaInfo. Both has zone-count=5

Last edited by StvG; 20th June 2019 at 03:11.
StvG is offline   Reply With Quote
Old 20th June 2019, 09:37   #6871  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 622
Had anyone actually done any benchmark on x265 on GCC 8.3 and 9.1?
From past records 9preview was slower than 8 but how about now?
MeteorRain is offline   Reply With Quote
Old 20th June 2019, 10:24   #6872  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 107
Couple days ago I tested x265 compiled with gcc-7/8/9-branch and all three builds gave me the same fps (<=1%).
StvG is offline   Reply With Quote
Old 20th June 2019, 20:34   #6873  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,984
Quote:
Originally Posted by benwaggoner View Post
First off, I want to know what the conditions are. I don't dismiss the possibility that I don't know what I'm doing in some aspect .
It appears that the --lossless flag blocks --hdr-opt. Which makes total sense in retrospect, as lossless is QP 4.

So, right behavior, wrong error message.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 20th June 2019, 23:10   #6874  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 86
Quote:
Originally Posted by katzenjoghurt View Post
Quote:
Originally Posted by katzenjoghurt
Oh my.
Am I the only one having such a hard time encoding scenes with red light / red backgrounds?

[...]
Oh man. I THINK I finally found a solution for my neverending problem with red areas getting blurred and/or blocky.

People already gave me a hint to use 10bit encoding or playing around with the crqpoffs parameter. Both didn't really help.

This changed drastically now after I converted the source to YV24 colorspace and encoded it with Main 444 10.

Suddenly the crqpoffs parameter started to work wonders and setting it to -1 already brought back most of the details.


How to do it in StaxRip 1.7.0.6:
1) Click on the "AVS Filter" label. Click "Profiles".
2) Find the [Misc] section and add this line to the bottom: ConvertToYV24 = ConvertToYV24()
3) Add the Filter now via right-click -> Misc -> ConvertToYV24
4) Go into the x265 encoder settings
5) In "Basic" chose the Main 444 10 profile.
6) In "Rate Control 1" set CR QB Offset to -1.
Meh.

And now I reallize that with Main 10 444...
a) ... the contrast is too high in VLC
b) ... the video won't play at all in Windows Media Player
c) ... while it works well in Kodi and Zoom Player.

katzenjoghurt is offline   Reply With Quote
Old 21st June 2019, 08:24   #6875  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,968
x265 3.1+2-b36c03e4e771 (MSYS2, GCC 9.1.0)

New options / changes:

Code:
   --[no-]field                  Enable or disable field coding. Default disabled
   --[no-]early-skip             Enable early SKIP detection. Default enabled
   --max-merge <1..5>            Maximum number of merge candidates. Default 3
   --limit-refs <0|1|2|3>        Limit references per depth (1) or CU (2) or both (3). Default 1
   --[no-]b-intra                Enable intra in B frames in veryslow presets. Default enabled
   --[no-]fades                  Enable detection and handling of fade-in regions. Default disabled
   --max-cll <string>            Specify content light level info SEI as "cll,fall" (HDR).
   --[no-]cll                    Emit content light level info SEI. Default enabled
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 21st June 2019, 09:58   #6876  |  Link
Natty
Noob
 
Join Date: Mar 2017
Posts: 219
Quote:
Originally Posted by MeteorRain View Post
Had anyone actually done any benchmark on x265 on GCC 8.3 and 9.1?
From past records 9preview was slower than 8 but how about now?
it looks like the bug of hidden encoding settings is still there in x265-Yuuki-3.1_RC1+4-gf48f4d038+23.7z build
Natty is offline   Reply With Quote
Old 21st June 2019, 23:44   #6877  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 622
Well I observed some performance regression so I'm keeping my GCC 8.3 for now. 1-3% slower with GCC 9.1 than 8.3 on my workstation.
It could be measurement error though.

@Natty Yea 3.1 RC1+4 was not properly compiled. Will remove it soon. I've properly revised the mod branch and that should be fixed in 3.1 GA.

Last edited by MeteorRain; 22nd June 2019 at 00:04.
MeteorRain is offline   Reply With Quote
Old 23rd June 2019, 01:20   #6878  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 86
Quote:
Originally Posted by StvG View Post
[...]
I updated to the GCC build LigH posted a bit above (thx!) and it seems zones now aren't crashing for me as well any more. Hooray!!!!!

Can't explain why it worked for you but not for me before that.
katzenjoghurt is offline   Reply With Quote
Old 23rd June 2019, 06:10   #6879  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,983
Quote:
Originally Posted by LigH View Post

New options / changes:

--[no-]fades Enable detection and handling of fade-in regions. Default disabled
Thanks for the build;

Any more info or discussion on this somewhere?

Is it sort of like the --fade-compensate patch from x264 ?

Is there anyway to modulate the strength ?


1) The setting is not currently reflected in the encoder settings (as read by mediainfo)

2) on a quick test, it seems to correctly detect and increase the bitrate in the fade area... But there seems to be a slight abrupt transition as it exits out of the fade, almost like "keyframe popping", when compared to without --fades . There is an I frame placed on the --fades encode, where it was a B on the without .

Just one observation, one test, so I'll take do some other tests before before making any preliminary conclusions...
poisondeathray is offline   Reply With Quote
Old 24th June 2019, 08:57   #6880  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,968
Quote:
Originally Posted by katzenjoghurt View Post
I updated to the GCC build LigH posted a bit above (thx!) and it seems zones now aren't crashing for me as well any more. Hooray!!!!!

Can't explain why it worked for you but not for me before that.
Probably depending on details, due to the nature of the problem:

Quote:
Fix double free in zones
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH 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 09:21.


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