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 26th February 2017, 12:46   #4841  |  Link
pingfr
Registered User
 
Join Date: May 2015
Posts: 185
Quote:
Originally Posted by froggy1 View Post
The presets of x265 are optimized for (very) low bitrate where at those levels, blur is preferred over other compression artifacts.
That's not my case here, quite the contrary, I'm trying to optimize for top-notch quality at a 10%~15% size/compression efficiency over x264, bitrate isn't an issue and never will be.

Quote:
Originally Posted by froggy1 View Post
That's why most have SAO and intra smoothing enabled.
Gotcha.

Quote:
Originally Posted by froggy1 View Post
Also the x265 presets haven't been optimized in a long time.
Not really helpful now is it?

Quote:
Originally Posted by froggy1 View Post
If you want to squeeze out as much detail as possible, you'll need to tweak manually (IMHO)
That's exactly what I'm doing as we speak.

Speaking of quality or should we rather call it "detail retention", I see everyone coming up with different custom deblocking values.

Some are like -1:-1 where as others recommend as far as -6:-6, is there a "best" and a "safe" value? or when is actually too much deblocking... well... "too much"?

My latest test settings are:

x265.exe --crf 21 --aq-mode 1 --ctu 64 --qg-size 32 --deblock -6:-6 --me star --bframes 8 --rc-lookahead 60 --ref 5 --b-adapt 2 --tu-intra-depth 4 --tu-inter-depth 4 --merange 92 --weightp --weightb --scenecut 40 --rd 4 --limit-ref 0 --limit-modes --tskip --rect --amp --max-merge 5 --subme 7 --b-intra --no-rskip --no-sao --no-strong-intra-smoothing in.y4m -o out.hevc
pingfr is offline   Reply With Quote
Old 26th February 2017, 12:50   #4842  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
your line looks good, except for the, IMHO, too high merange value. Even for UHD, that's overkill. As to deblocking, there's no magic value and different people prefer different values. I'm fine with -3 and even -2. also, if you're mostly encoding HD/FHD, a CTU of 32 is slightly preferred
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 26th February 2017, 12:59   #4843  |  Link
pingfr
Registered User
 
Join Date: May 2015
Posts: 185
Quote:
Originally Posted by froggy1 View Post
your line looks good, except for the, IMHO, too high merange value. Even for UHD, that's overkill.
Will lowering the --merange 92 back to a saner --merange 57 value have any significant impacts on either resulting quality (better/worse looking?) and/or compression speed (faster/slower?) and/or compression efficiency (bigger/smaller filesize?)?

Quote:
Originally Posted by froggy1 View Post
As to deblocking, there's no magic value and different people prefer different values. I'm fine with -3 and even -2.
If you were asked to justify your choices of a -3 or -2 values, how would you do so?

Quote:
Originally Posted by froggy1 View Post
also, if you're mostly encoding HD/FHD, a CTU of 32 is slightly preferred
I'm tackling with 1080p/720p encodes from Blu-Ray disc sources at the moment, however it appears all the presets recommend using a --ctu 64. I think I'll stick to that at least for now.

Edit: Also I can't find the command line switch to set a custom lookahead-slices arg.
pingfr is offline   Reply With Quote
Old 26th February 2017, 13:23   #4844  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by pingfr View Post
Will lowering the --merange 92 back to a saner --merange 57 value have any significant impacts on either resulting quality (better/worse looking?) and/or compression speed (faster/slower?) and/or compression efficiency (bigger/smaller filesize?)?
it will have a slight impact on speed. As to quality, it will be difficult to spot the difference, unless you really "stick your nose" into the picture with a microscope.

The reason I said that 97 is overkill is because with that value, the encoder may select a motion vector that's not necessarily the best one. It is a similar situation with x264 where values above 32 can actually in some cases hurt quality instead of improving it.


Quote:
If you were asked to justify your choices of a -3 or -2 values, how would you do so?
Simply, I prefer a slightly "soft" picture instead of one that jumps at me


Quote:
I'm tackling with 1080p/720p encodes from Blu-Ray disc sources at the moment, however it appears all the presets recommend using a --ctu 64. I think I'll stick to that at least for now.
Keep in mind that the presets, as I said, are optimized for 2 things. One I already mentioned (very low bitrates) while the other is at least UHD resolutions. At these resolutions, a larger CTU makes sense

Quote:
Edit: Also I can't find the command line switch to set a custom lookahead-slices arg.
I don't think it has one yet
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 26th February 2017, 13:28   #4845  |  Link
ChaosKing
Registered User
 
Join Date: Dec 2005
Location: Germany
Posts: 1,795
Quote:
Originally Posted by pingfr View Post
Will lowering the --merange 92 back to a saner --merange 57 value have any significant impacts on either resulting quality (better/worse looking?) and/or compression speed (faster/slower?) and/or compression efficiency (bigger/smaller filesize?)?
You can always test it yourself with a short sample and compare the results...

Yes the filesize will be a little bit smaller or the quality a little bit better, but it will be so small that it's not really worth it. That's why it is in the placebo preset, bcs it's sloooow
__________________
AVSRepoGUI // VSRepoGUI - Package Manager for AviSynth // VapourSynth
VapourSynth Portable FATPACK || VapourSynth Database
ChaosKing is offline   Reply With Quote
Old 26th February 2017, 14:50   #4846  |  Link
aymanalz
Registered User
 
Join Date: May 2015
Posts: 68
Quote:
Originally Posted by pingfr View Post
1920x1080.
Then I repeat, merange of 92 is insanely high. Even the default of 57 is very high.
aymanalz is offline   Reply With Quote
Old 26th February 2017, 14:53   #4847  |  Link
aymanalz
Registered User
 
Join Date: May 2015
Posts: 68
Quote:
Originally Posted by pingfr View Post
Will lowering the --merange 92 back to a saner --merange 57 value have any significant impacts on either resulting quality (better/worse looking?) and/or compression speed (faster/slower?) and/or compression efficiency (bigger/smaller filesize?)?



If you were asked to justify your choices of a -3 or -2 values, how would you do so?



I'm tackling with 1080p/720p encodes from Blu-Ray disc sources at the moment, however it appears all the presets recommend using a --ctu 64. I think I'll stick to that at least for now.

Edit: Also I can't find the command line switch to set a custom lookahead-slices arg.

1) Lowering the merange to 57 will significantly boost your encoding speed, and it is very unlikely (read, impossible) that you will notice any quality degradation.

2) CTU of 32 is good enough for 1080p, and that too will give you significant speed increase. Only much higher resolutions will benefit from CTU 64.

A couple of pages back, you were complaining about slow encoding speed, so I'm wondering why you would set these unhelpfully large values for merange especially, and CTU.

Last edited by aymanalz; 26th February 2017 at 14:55.
aymanalz is offline   Reply With Quote
Old 26th February 2017, 16:47   #4848  |  Link
littlepox
Registered User
 
Join Date: Nov 2012
Posts: 218
--ssim-rd seems to be another detail killer. May I know how to use it in near-transparent encoding?
littlepox is offline   Reply With Quote
Old 26th February 2017, 17:48   #4849  |  Link
pingfr
Registered User
 
Join Date: May 2015
Posts: 185
Quote:
Originally Posted by aymanalz View Post
Then I repeat, merange of 92 is insanely high. Even the default of 57 is very high.
Back to 57 then I guess. Thanks!
pingfr is offline   Reply With Quote
Old 26th February 2017, 17:51   #4850  |  Link
pingfr
Registered User
 
Join Date: May 2015
Posts: 185
Quote:
Originally Posted by aymanalz View Post
1) Lowering the merange to 57 will significantly boost your encoding speed, and it is very unlikely (read, impossible) that you will notice any quality degradation.
57 it is then. Case settled.

2160p = 92 merange.
1080p = 57 merange.
720p = ?? merange.

Quote:
Originally Posted by aymanalz View Post
2) CTU of 32 is good enough for 1080p, and that too will give you significant speed increase. Only much higher resolutions will benefit from CTU 64.
2160p = CTU 64.
1080p = CTU 32.
720p = CTU ??.

Quote:
Originally Posted by aymanalz View Post
A couple of pages back, you were complaining about slow encoding speed, so I'm wondering why you would set these unhelpfully large values for merange especially, and CTU.
Because... these values were the ones taken directly from the placebo presets?
pingfr is offline   Reply With Quote
Old 26th February 2017, 17:53   #4851  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
But "placebo" means "you have to believe in it to see any advantage over sensible presets". Or in other words: Rather a waste of time and energy than a visible advantage.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 26th February 2017, 17:54   #4852  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
Even 57 is probably overkill for 1080p. x264 preset placebo uses 24...
sneaker_ger is offline   Reply With Quote
Old 26th February 2017, 18:31   #4853  |  Link
pingfr
Registered User
 
Join Date: May 2015
Posts: 185
Quote:
Originally Posted by sneaker_ger View Post
Even 57 is probably overkill for 1080p. x264 preset placebo uses 24...
Isn't comparing x264 and x265 values more or less equals comparing oranges to eggs?
pingfr is offline   Reply With Quote
Old 26th February 2017, 19:09   #4854  |  Link
aymanalz
Registered User
 
Join Date: May 2015
Posts: 68
Quote:
Originally Posted by pingfr View Post
Because... these values were the ones taken directly from the placebo presets?
There is a reason they call it placebo!

Placebo: Anything of no direct benefit which nevertheless makes people feel better or benefit psychologically.
aymanalz is offline   Reply With Quote
Old 26th February 2017, 19:32   #4855  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,717
I did a small test concerning CTU 64 and 32. The source was a short scene from the first The Hobbit movie, mattes cropped and scaled down to 1280x544 with some sharpening to compensate and then very light denoising. This is what I mostly do to the material that I put on my media server.

With my default settings, which also means CTU 64, the bitrate was 3983.05 kbps and average speed 2.38 fps. With CTU 32, the bitrate was 4092.48 kbps and the average speed 2.76 fps.

I really didn't expect the bitrate to change that much at such a low resolution but it's there. The scene itself is fairly detailed, but there's also some sky etc. which could give the 64-pixel CTU something to work on.
__________________
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 26th February 2017, 19:43   #4856  |  Link
pingfr
Registered User
 
Join Date: May 2015
Posts: 185
Latest changes:

Increased --crf 18 to --crf 21.
Lowered --ctu 64 to --ctu 32.
Lowered --bframes 8 to --bframes 4.
Lowered --merange 92 to --merange 57.
Lowered --rd 6 to --rd 4.
Lowered --subme 7 to --subme 5.

I'm getting an average of 1.16 fps, my current goal is 2.00 fps.

The remaining values that are untouched are:

--qg-size 32
--deblock -6:-6
--rc-lookahead 60
--tu-intra-depth 4
--tu-inter-depth 4
--scenecut 40
--limit-ref 0
--limit-modes
--max-merge 5

Anything else I could tweak at this point to increase crunching speed without hurting either the efficiency or the quality resulted?
pingfr is offline   Reply With Quote
Old 26th February 2017, 19:48   #4857  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,717
--tu-intra-depth 3
--tu-inter-depth 3
--limit-refs 3
--max-merge 3

You won't see a visible difference but the encoding will go faster.
__________________
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 26th February 2017, 19:50   #4858  |  Link
pingfr
Registered User
 
Join Date: May 2015
Posts: 185
Quote:
Originally Posted by Boulder View Post
--tu-intra-depth 3
--tu-inter-depth 3
--limit-refs 3
--max-merge 3

You won't see a visible difference but the encoding will go faster.
Tested the suggested values, while it is true it encoded much faster at 2.48 fps and even exceeded my expectations, the water ripples from my sample clip were blocky. That's a no-go for me.

Thanks.

Last edited by pingfr; 26th February 2017 at 19:56.
pingfr is offline   Reply With Quote
Old 26th February 2017, 20:01   #4859  |  Link
aymanalz
Registered User
 
Join Date: May 2015
Posts: 68
Quote:
Originally Posted by pingfr View Post
Tested the suggested values, while it is true it encoded much faster at 2.48 fps and even exceeded my expectations, the water ripples from my sample clip were blocky. That's a no-go for me.

Thanks.

Try just the limit refs 3.

And if blocking is the only issue you saw, increase the deblocking to -3,-3 or higher. Lowering deblocking by so much from default values, probably causes...blocking.
aymanalz is offline   Reply With Quote
Old 26th February 2017, 20:01   #4860  |  Link
pingfr
Registered User
 
Join Date: May 2015
Posts: 185
Quote:
Originally Posted by aymanalz View Post
Try just the limit refs 3.
x265.exe --crf 21 --aq-mode 1 --ctu 32 --qg-size 32 --deblock -6:-6 --me star --bframes 4 --rc-lookahead 60 --ref 5 --b-adapt 2 --tu-intra-depth 4 --tu-inter-depth 4 --merange 57 --weightp --weightb --scenecut 40 --rd 4 --limit-ref 3 --limit-modes --tskip --rect --amp --max-merge 5 --subme 5 --b-intra --no-rskip --no-sao --no-strong-intra-smoothing %1 -o %~n1.hevc

x265 [info]: HEVC encoder version 2.3+9-820f4327ddac
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 5 / 5
x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 60 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-21.0 / 0.60
x265 [info]: tools: rect amp limit-modes rd=4 psy-rd=2.00 tskip signhide tmvp
x265 [info]: tools: b-intra lslices=6 deblock(tC=-6:B=-6)
x265 [info]: frame I: 3, Avg QP:22.55 kb/s: 28882.40
x265 [info]: frame P: 141, Avg QP:23.75 kb/s: 19361.90
x265 [info]: frame B: 456, Avg QP:28.24 kb/s: 6027.66
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 0.7% 0.0% 0.0% 80.6% 18.8%

encoded 600 frames in 276.47s (2.17 fps), 9275.48 kb/s, Avg QP:27.15

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 20s 0ms
Bit rate : 9 097 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.146
Stream size : 21.7 MiB (98%)
Writing library : x265 2.3+9-820f4327ddac:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=4 / tu-intra-depth=4 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-6:-6 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt
Default : Yes
Forced : No

Hard to tell.

Last edited by pingfr; 26th February 2017 at 20:09.
pingfr 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 06:09.


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