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 June 2019, 18:45   #6861  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
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, 19:18   #6862  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
@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, 02:01   #6863  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 447
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 02:11.
StvG is offline   Reply With Quote
Old 20th June 2019, 08:37   #6864  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
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?
__________________
Projects
x265 - Yuuki-Asuna-mod Download / GitHub
TS - ADTS AAC Splitter | LATM AAC Splitter | BS4K-ASS
Neo AviSynth+ filters - F3KDB | FFT3D | DFTTest | MiniDeen | Temporal Median
MeteorRain is offline   Reply With Quote
Old 20th June 2019, 09:24   #6865  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 447
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, 19:34   #6866  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
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, 22:10   #6867  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 128
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, 07:24   #6868  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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, 08:58   #6869  |  Link
Natty
Noob
 
Join Date: Mar 2017
Posts: 221
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, 22:44   #6870  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
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.
__________________
Projects
x265 - Yuuki-Asuna-mod Download / GitHub
TS - ADTS AAC Splitter | LATM AAC Splitter | BS4K-ASS
Neo AviSynth+ filters - F3KDB | FFT3D | DFTTest | MiniDeen | Temporal Median

Last edited by MeteorRain; 21st June 2019 at 23:04.
MeteorRain is offline   Reply With Quote
Old 23rd June 2019, 00:20   #6871  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 128
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, 05:10   #6872  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,345
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, 07:57   #6873  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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
Old 25th June 2019, 14:39   #6874  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by poisondeathray View Post
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...
What preset were you using? I'd expect that with weighted B and P prediction, a fade itself shouldn't require an increase in bitrate. And with Open GOP I'd hope the keyframe pop wouldn't be quite so harsh.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 25th June 2019, 15:23   #6875  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,345
Quote:
Originally Posted by benwaggoner View Post
What preset were you using? I'd expect that with weighted B and P prediction, a fade itself shouldn't require an increase in bitrate. And with Open GOP I'd hope the keyframe pop wouldn't be quite so harsh.

Slower , plus a few other changes . 10bit, CRF rate control

As you probably are aware, x264 and x265 have had issues with fades for a long time (probably why this option was introduced) . So I'm guessing the point of --fades was to increase the bitrate and fix the fade region (it's desired) . Without it - the banding and fade looks worse (as expected), With it, the fade looks better, bitrate increased - except for the popping

I haven't had a chance to examine in more detail or run more tests, but it's a pretty clear "pop" because of the quality change. The I frame is lower in quality. The test sequence was Lighthouses of the Pacific at the beginning . You only need to encode about 50 frames or so, it occurs 46-47 .
poisondeathray is offline   Reply With Quote
Old 25th June 2019, 15:59   #6876  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by poisondeathray View Post
As you probably are aware, x264 and x265 have had issues with fades for a long time (probably why this option was introduced) . So I'm guessing the point of --fades was to increase the bitrate and fix the fade region (it's desired) . Without it - the banding and fade looks worse (as expected), With it, the fade looks better, bitrate increased - except for the popping.
IMHO x264, x265, and Xvid as well, should have gone the way of DivX and WMV3/WVC1, regarding ~scene detection~. In both DivX and WMV, the fades generate a sequence of I-frames, and this is a non-problem when the playback device of the user doesn't care about "excessive" bitrates. Sadly it seems the FOSS developers think «the less options for the end-user, the better» :-/

Last edited by filler56789; 25th June 2019 at 16:33. Reason: damn typos :-/
filler56789 is offline   Reply With Quote
Old 25th June 2019, 18:14   #6877  |  Link
SeeMoreDigital
Life's clearer in 4K UHD
 
SeeMoreDigital's Avatar
 
Join Date: Jun 2003
Location: Notts, UK
Posts: 12,219
Quote:
Originally Posted by filler56789 View Post
IMHO x264, x265, and Xvid as well, should have gone the way of DivX and WMV3/WVC1, regarding ~scene detection~. In both DivX and WMV, the fades generate a sequence of I-frames, and this is a non-problem when the playback device of the user doesn't care about "excessive" bitrates. Sadly it seems the FOSS developers think «the less options for the end-user, the better» :-/
I could have done with something like that a few years ago when I had to generate an encode that began with a black to full colour transition over the first 125 frames (5 seconds).

In order to get rid of the horrendous blocks at the beginning of the encode, I ended up having encode the first 125 frames separately (using I and P frames).
__________________
| I've been testing hardware media playback devices and software A/V encoders and decoders since 2001 | My Network Layout & A/V Gear |
SeeMoreDigital is offline   Reply With Quote
Old 1st July 2019, 16:49   #6878  |  Link
TomV
VP Eng, Kaleidescape
 
Join Date: Jan 2018
Location: Mt View, CA
Posts: 51
Quote:
Originally Posted by filler56789 View Post
IMHO x264, x265, and Xvid as well, should have gone the way of DivX and WMV3/WVC1, regarding ~scene detection~. In both DivX and WMV, the fades generate a sequence of I-frames, and this is a non-problem when the playback device of the user doesn't care about "excessive" bitrates. Sadly it seems the FOSS developers think «the less options for the end-user, the better» :-/
That is an extremely inefficient strategy for encoding dissolve transitions.
TomV is offline   Reply With Quote
Old 1st July 2019, 22:03   #6879  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by filler56789 View Post
IMHO x264, x265, and Xvid as well, should have gone the way of DivX and WMV3/WVC1, regarding ~scene detection~. In both DivX and WMV, the fades generate a sequence of I-frames, and this is a non-problem when the playback device of the user doesn't care about "excessive" bitrates. Sadly it seems the FOSS developers think «the less options for the end-user, the better» :-/
Actually, the VC-1 encoder (and I believe the stock WMV9) would turn a transition into a sequence of P frames. It didn't have weighted prediction for B-frames so that was a lot more efficient.

Since HEVC has b-frame weighted prediction as well, that shouldn't be necessary. But rate control and motion estimation for a cross-dissolve is irreducibly tricky. Ideally the "before" and "after" frames would be defined and then forward/back proprogated via some mbtree extension.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 3rd July 2019, 00:31   #6880  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by TomV View Post
That is an extremely inefficient strategy for encoding dissolve transitions.
I know that. But it seems you don't know that it WORKS
filler56789 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 13:36.


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