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. |
12th February 2015, 00:50 | #1701 | Link |
Registered User
Join Date: Jan 2010
Posts: 709
|
I'd suggest an quantizer-related modifier for deblock's, psy's and aq's strengths.
ie usually at low quant (let's say 12-) and at high quant (35+) psy-rd and psy-rdoq will attempt to better maintain fine detail that is yet well retained at low quants and will not at high quant even with psy, but instead decrease quality a lot (specially at high quant). differently aq and deblock will be even more useful and effective from low quant to high quant. maybe for psy a gauss-like curve with peak at about 23/24, for aq a log-like one and for deblock an exp-like one. as for quant reference may can be take the first frame of the gop or the prev/reference I/P or the frame itself.
__________________
powered by Google Translator Last edited by Motenai Yoda; 12th February 2015 at 00:53. |
12th February 2015, 01:03 | #1702 | Link | |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,558
|
Quote:
The benefit and drawback is the same as the difference between 4:2:0 and 4:4:4 in general: Better color resolution, important for low-resolution and computer-generated video, but requires more space and doesn't really have any hardware decoding support. Last edited by foxyshadis; 12th February 2015 at 01:10. |
|
12th February 2015, 01:49 | #1703 | Link | |
Registered User
Join Date: Dec 2012
Posts: 197
|
Quote:
Psy weighs towards original energy, so it's inherently self-limiting at low-quantization. Do you have proof of how further limiting psy at low QP is helpful? AQ weighs towards a SSIM-friendly output and effectively moves bits away from edges and towards flat regions. SSIM as a metric isn't quantization dependent, low QP flat regions still need help to prevent banding inherent in 8bit coding, and at high QPs, edges are blurry enough as it is. I'm not sure if there's anything to change unless you're proposing a fundamentally different RD metric. |
|
12th February 2015, 09:46 | #1705 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
|
Ladies and gentlemen, this is x265 v1.5:
x265 1.5+9-7a42ca02d198 Time to clean my archive from v1.2 builds... |
12th February 2015, 10:07 | #1706 | Link |
Registered User
Join Date: Dec 2014
Posts: 240
|
@LigH
One question...using Main10 profile. Is that big difference between last 1.4.544 and 1.5.9 or you meant it like between initial 1.4 and 1.5?
__________________
AMD Ryzen 9 5950X, 32GB DDR4-3200 CL16, RTX 3060, 2TB NVMe PCIE4.0, NAS with 8x16TB HDD |
12th February 2015, 20:06 | #1710 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
Do you see the issue in which weighted P-frames are not used according to the log?
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0% It stopped working at some point but I thought it was fixed. I also have this issue with my own VS2010 builds.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
13th February 2015, 01:05 | #1711 | Link |
Registered User
Join Date: Jul 2014
Posts: 115
|
Congratulations! I believe number 1.5 is really like a milestone like 1.0 and 2.0. Lets hope that with it the ERA OF HEVC and x265 further massive popularization will be associated.
So that anytime you google x264 vs x265 results would be separated into past (when you could call x265 an early adoptive) and Current where x265 is a full grown encoder which you can use without fear nor thinking that maybe you need to wait hence it's experimental now and future builds will be totally different. Speaking about psy-rd default values (0.3). is it safe to assume that encoding PC game captured videos (like left 4 dead) you can set from 0.5 to 1.0 due to everything is unrealistic anyways? Last edited by Ajvar; 13th February 2015 at 17:09. |
13th February 2015, 09:12 | #1713 | Link | |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,558
|
Quote:
|
|
13th February 2015, 11:14 | #1714 | Link |
Registered User
Join Date: Dec 2014
Posts: 240
|
Congrats to x265 team.
With last 1.4 and with 1.5, I found preset SLOW, with DEBLOCK -3:-3 and with CRF18 completely sufficient for my 1080p encodes (bluray backups), with excellent visual quality and more than 50% size down. (i.e.: Godzilla (2014) - x264 placebo CRF20 - 5.0GB, x265 settings above - 2.1GB - audio just copied)
__________________
AMD Ryzen 9 5950X, 32GB DDR4-3200 CL16, RTX 3060, 2TB NVMe PCIE4.0, NAS with 8x16TB HDD Last edited by jlpsvk; 13th February 2015 at 11:16. |
13th February 2015, 17:20 | #1715 | Link | |
Registered User
Join Date: Jul 2014
Posts: 115
|
True but I'm not experienced as much as others here to make judges. Plus even though I have fast computer my hands are not well trained to do multiple comparison encodings very fast.
Quote:
|
|
13th February 2015, 20:58 | #1716 | Link |
Registered User
Join Date: Dec 2012
Posts: 197
|
I recently tested 'tune fast-decode' and it looked, well, about as bad as expected.
I seem to recall the HM encoder heuristically disabling slice level SAO in upper-hierarchy b-frames (note: my mind may have made this up). What if x265 does something similar with deblock and SAO to make 'fast-decode' less of pyrrhic victory? |
14th February 2015, 08:11 | #1717 | Link |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,558
|
I didn't find it reducing that effect at all; edges are still sharp, they just move in weird ways, and don't always follow the motion. At reasonable crf values the effect is very slight and only noticeable by flipping back and forth frame-by-frame, though it rises as the crf does. You still have to use something like MVFlowBlur to introduce motion blur to reduce the strobe effect.
|
14th February 2015, 12:43 | #1718 | Link | |
Registered User
Join Date: Jul 2014
Posts: 115
|
Quote:
|
|
14th February 2015, 13:56 | #1719 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
|
Comparison between 1.4 and 1.5:
first of all, with a silly encoding like: Main10 profile, Level-5, WPP Streams: 34, frame threads: 2, pool: 4, Internal BitDepth: 10, CTU Size: 64, RQT depth inter: 1 RQT depth intra: 1, ME: hex, range: 57, subpel: 2, merge: 2, keyframe min: 23, max: 250, scenecut: 40, lookahead: 20, bframes: 4, badapt: 2, b-pyramid: 1, weightp: 1, weightb: 1, refs: 3, rate control: CRF 25, AQ-Strength: 1.0, CUTree: 1, tools: rd=3 on a 4K content (file master upscaled) 23,976 fps progressive, it took quite the same with 1.5 version (I mean, encoding time), but on playback, 1.5 version was very slight. On a 6 core AMD without GPU acceleration (not supported by nvidia gtx650) with 6 MB of cache and 3.4 GHz, 1.4 version was not playable, while 1.5 version was just a bit jerky, so that's a very good performance boost. As to the quality, they look the same, but I made some test in order to see differences with defaults settings: Encoding with: --crf 25 --profile main10 --preset medium Video lenght: 24 minutes Resolution: 3840x2160 (file master upscaled) fps: 23,976 progressive 1.4 version: 1013 MB -- 1.5 version: 724 MB Detail loss? Not at all! (or should I say "more or less"? xD) Screen: https://mega.co.nz/#!SUljXCwL!bU_BSc...NSO0gCs66ifp_I Borders around the right ear on the second image are a little bit worst in 1.5 version. Plus, there is a little bit haloing in 1.5 version, but it's just a little bit. As to the blocking on the dark background, it's the same both in 1.4 and 1.5 due to crf 25 setting. Anyway... c'mon, 24 minutes at 4K resolutions, 10bit, 23,976 with a watchable quality in just 724 MB it's a very good thing. So... very good improvement with this new version 1.5. I think we are getting closer and closer to a good codec By the way, I know it's still early to talk about it, but... how about an Open CL x265 encoding? It would speed everything up. |
15th February 2015, 01:30 | #1720 | Link |
Registered User
Join Date: Oct 2012
Location: Akron, OH
Posts: 491
|
The latest Handbrake nightly includes x265 1.5. For my first experiment with HEVC, I encoded a 35GB Blu-ray movie using the default settings and CRF 18 Slow. Took over two hours on a 4790K running at 4400, but the resulting file was less than a GB in size with no discernible quality loss. Very, very impressive.
Next step is to see how high I can go with CRF without losing visible quality. Last edited by jkauff; 15th February 2015 at 01:33. |
Thread Tools | Search this Thread |
Display Modes | |
|
|