Nope.Would be there a way to get 1.2.2 with the 1.3.0 GUI?
Can you provide 1.2.2 and 1.3.0 logs?1.3.0 > AO 1 / visible worse quality / same size
Nope.Would be there a way to get 1.2.2 with the 1.3.0 GUI?
Can you provide 1.2.2 and 1.3.0 logs?1.3.0 > AO 1 / visible worse quality / same size
How are you determining that the quality is lower?- AQ 1 worse quality by the same size as 1.2.2
Code: Select all
x265 [info]: frame I: 1196, Avg QP:16.57 kb/s: 27821.44
x265 [info]: frame P: 13409, Avg QP:17.77 kb/s: 9970.44
x265 [info]: frame B: 51219, Avg QP:21.42 kb/s: 2582.55
x265 [info]: Weighted P-Frames: Y:0.9% UV:0.8%
x265 [info]: consecutive B-frames: 9.7% 1.7% 1.7% 1.7% 85.1%
[19:55:57] mux: track 0, 65824 frames, 1496480741 bytes, 4546.78 kbps, fifo 2048
Code: Select all
x265 [info]: frame I: 1196, Avg QP:16.57 kb/s: 27821.44
x265 [info]: frame P: 13409, Avg QP:17.77 kb/s: 9970.44
x265 [info]: frame B: 51219, Avg QP:21.42 kb/s: 2582.55
x265 [info]: Weighted P-Frames: Y:0.9% UV:0.8%
x265 [info]: consecutive B-frames: 9.7% 1.7% 1.7% 1.7% 85.1%
[19:57:04] mux: track 0, 65824 frames, 1496480741 bytes, 4546.78 kbps, fifo 2048
Are strong-intra-smoothing and rect disabled in the presets because they reduce image quality, or is it because these options increase encoding time with little benefit? From my brief testing adding "strong-intra-smoothing=0:rect=0" increases the size of the encodes.BradleyS wrote: ↑Mon Jan 06, 2020 4:32 pm We already do so in the case of strong-intra-smoothing for one.
In this case, the commit message is probably most helpful: https://github.com/HandBrake/HandBrake/ ... b9e678cc37
"We have received numerous reports about x265 in HandBrake 1.3.0 creating ~30% larger files with no perceived quality gain, and have confirmed this to be true in most cases. This appears to be the result of x265 recently switching to use aq-mode 2 by default. This change makes the behavior of the official presets more closely match that of HandBrake 1.2.2 and earlier. This seems to be the best course of action both technically and for the user experience until the default aq-mode improves."
Perhaps aq-mode 2 makes sense for some material (such as low bit rate, same as strong-intra-smoothing) but it seems to be worse—or at least not better enough to warrant the overhead—for high quality encodes.
FWIW:BradleyS wrote: ↑Mon Jan 06, 2020 5:06 pm strong-intra-smoothing is what it sounds like, a bilinear smoothing filter on intra frames to limit bit rate spikes. Intra frames being of course, what other frames are based on. It's basically reducing the quality of your video before you even start encoding.
(emphasis mine, it does look relevant, even though I have no clue what the corner reference samples are specifically)https://x265.readthedocs.io/en/default/cli.html#cmdoption-strong-intra-smoothing wrote:
Enable strong intra smoothing for 32x32 intra blocks. This flag performs bi-linear interpolation of the corner reference samples for a strong smoothing effect. The purpose is to prevent blocking or banding artifacts in regions with few/zero AC coefficients. Default enabled
Thank you, this was very informative.BradleyS wrote: ↑Mon Jan 06, 2020 5:06 pm strong-intra-smoothing is what it sounds like, a bilinear smoothing filter on intra frames to limit bit rate spikes. Intra frames being of course, what other frames are based on. It's basically reducing the quality of your video before you even start encoding. You don't want this for high quality encodes, but it can lead to more consistent bit rates with lower quality encodes that would be smooth anyway. It's a bad default for HandBrake's presets, and I'd say not very wise in general.
rect on the other hand is disabled in the official presets because it doesn't provide enough benefit for the speed hit. When we created HandBrake's H.265 presets, x265's medium preset wasn't very impressive quality-/performance-wise and while the slow preset was better, it was really slow. Disabling rect gave a major speed increase while retaining the other benefits of the slow preset. This still seems to be the case years later; slow is about 2.4x slower than medium: https://handbrake.fr/docs/en/latest/tec ... mance.html
Code: Select all
fps size QP options
x265 slow 8.107 0.00% 24.09
8.585 +0.19% 24.08 merange=32
10.594 +0.74% 24.09 rect=0
15.550 +0.96% 24.15 ctu=32
20.998 +1.49% 24.15 rect=0:ctu=32
22.091 +1.69% 24.15 rect=0:ctu=32:merange=32
8.613 -18.2% 24.47 aq-mode=1
22.334 -16.9% 24.61 aq-mode=1:rect=0:ctu=32
23.705 -16.7% 24.61 aq-mode=1:rect=0:ctu=32:merange=32
Code: Select all
fps size QP options
x264 veryfast 208.941 +4.22% 22.12
88.937 +3.95% 22.14 lookahead-threads=1
90.989 +3.72% 22.14 lookahead-threads=1:threads=6
veryslow 26.157 +2.13% 24.31 ref=3:bframes=6
20.124 +2.25% 24.31 lookahead-threads=1:ref=3:bframes=6
10.229 +1.77% 24.31 lookahead-threads=1:threads=6:ref=3:bframes=6
Tune Grain will lead to much higher bitrate, can be a few times higher and much slower encoding.
I'm not after identical quality. I assume they are close enough, so it is more about encoding speed and file size. I've added QP to the numbers if it means anything at all.
Code: Select all
fps size QP
x265 ultrafast 130.206 -34.48% 26.53
superfast 76.380 -27.69% 25.90
veryfast 29.539 -16.57% 24.56
faster 29.273 -16.66% 24.56
fast 26.671 -15.69% 24.50
medium 18.766 -9.72% 24.15
slow 8.034 0.00% 24.09
slower 2.329 +1.71% 24.26
veryslow 1.358 +1.23% 24.27
placebo 0.833 +4.24% 24.30