A couple of x265 related questions

[asw3]

First I want to apologize if the questions are for the newbie forum, I wasn't sure.

So my understanding regarding x264 vs x265 was that you would get a smaller file for roughly the same quality / higher quality for roughly the same file size at the expense of a longer encode time with x265 compared to x264.

I ran a bunch of test encodes of a ~1 minute clip taken from a MakeMKV file from the Once Upon a Time in America 1080p BD, all other settings are the same in Hanbrake except 264 10-bit vs 265 10-bit (these are CRF 20 encodes).

Original file MediaInfo:

General
Format                      : Matroska
Format version              : Version 4
File size                   : 166 MiB
Duration                    : 57 s 766 ms
Overall bit rate mode       : Variable
Overall bit rate            : 24.2 Mb/s
Writing application         : Lavf58.29.100
Writing library             : Lavf58.29.100
ErrorDetectionType          : Per level 1

Video
ID                          : 1
Format                      : AVC
Format/Info                 : Advanced Video Codec
Format profile              : High@L4
Format settings             : CABAC / 2 Ref Frames
Format settings, CABAC      : Yes
Format settings, Reference  : 2 frames
Format settings, GOP        : M=1, N=10
Codec ID                    : V_MPEG4/ISO/AVC
Duration                    : 57 s 724 ms
Bit rate mode               : Variable
Width                       : 1 920 pixels
Height                      : 1 080 pixels
Display aspect ratio        : 16:9
Frame rate mode             : Constant
Frame rate                  : 23.976 (24000/1001) FPS
Color space                 : YUV
Chroma subsampling          : 4:2:0
Bit depth                   : 8 bits
Scan type                   : Progressive
Default                     : Yes
Forced                      : No

The comparison numbers:

[Attachment 68056 - Click to enlarge]

From the screenshot the file size to quality (VMAF) between the two is roughly the same, especially the slower the preset goes, even though the encode times have increased. This is the opposite of what I expected. It seems there is a noticeable difference in the Superfast file size for seemingly the same quality (at least in this specific clip), but people usually recommend a lot slower presets. Obviously I have to be missing something here, I'm assuming the common notion that you get the same quality at a smaller file probably has something to do with custom arguments? Or maybe just one test file doesn't give representative results? I guess now that I'm looking at everything maybe I would get a smaller file size if I ran the encodes with a fixed bitrate? Any clarification would be appreciated.

And one more question - I looked at the MediaInfo of the releases of a group who does excellent (for my needs) film encodes - roughly 2-3GB per 1 hour. Now for different films they use different settings understandably, but the strange thing is I tried making a 1 to 1 argument copy from one of their releases for a film I have (modern digital camera no noise film), and while the MediaInfo came out exactly the same settings-wise right down to the writing library (with the exception that my encode has numa-pools=12 which theirs doesn't have nothing regarding numa-pools at all, so any tips on how to remove this entirely?), my encode came with way WAY higher Overall bit rate (and hence huge file size) than theirs, which baffles me since they used a CRF17 setting.

Encode trying to emulate:

General
Format                      : Matroska
Format version              : Version 4
File size                   : 5.68 GiB
Duration                    : 2 h 28 min
Overall bit rate            : 5 490 kb/s

Video
ID                          : 1
Format                      : HEVC
Format/Info                 : High Efficiency Video Coding
Format profile              : Main 10@L4@Main
Codec ID                    : V_MPEGH/ISO/HEVC
Duration                    : 2 h 28 min
Bit rate                    : 5 053 kb/s
Width                       : 1 920 pixels
Height                      : 804 pixels
Display aspect ratio        : 2.40:1
Frame rate mode             : Constant
Frame rate                  : 23.976 (24000/1001) FPS
Color space                 : YUV
Chroma subsampling          : 4:2:0 (Type 0)
Bit depth                   : 10 bits
Bits/(Pixel*Frame)          : 0.137
Stream size                 : 5.23 GiB (92%)
Writing library             : x265 3.5+1-f0c1022b6: 10bit
Encoding settings           : cpuid=2 / frame-threads=3 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x804 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=24 / keyint=240 / gop-lookahead=0 / bframes=8 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / no-sao / no-sao-non-deblock / rd=4 / selective-sao=0 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=17.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=3 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=1 / chromaloc-top=0 / chromaloc-bottom=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / no-opt-cu-delta-qp / aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass
Default                     : Yes
Forced                      : No
Color range                 : Limited
Color primaries             : BT.709
Transfer characteristics    : BT.709
Matrix coefficients         : BT.709

My 1 min test encode:

General
Format                      : Matroska
Format version              : Version 4
File size                   : 136 MiB
Duration                    : 1 min 0 s
Overall bit rate mode       : Variable
Overall bit rate            : 18.9 Mb/s

Video
ID                          : 1
Format                      : HEVC
Format/Info                 : High Efficiency Video Coding
Format profile              : Main 10@L4@Main
Codec ID                    : V_MPEGH/ISO/HEVC
Duration                    : 1 min 0 s
Width                       : 1 920 pixels
Height                      : 1 080 pixels
Display aspect ratio        : 16:9
Frame rate mode             : Constant
Frame rate                  : 23.976 (24000/1001) FPS
Color space                 : YUV
Chroma subsampling          : 4:2:0 (Type 0)
Bit depth                   : 10 bits
Writing library             : x265 3.5+1-f0c1022b6:[Windows][GCC 10.2.0][64 bit] 10bit
Encoding settings           : cpuid=1111039 / frame-threads=3 / numa-pools=12 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=24 / keyint=240 / gop-lookahead=0 / bframes=8 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / no-sao / no-sao-non-deblock / rd=4 / selective-sao=0 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=17.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=3 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=1 / chromaloc-top=0 / chromaloc-bottom=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / no-opt-cu-delta-qp / aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass
Default                     : Yes
Forced                      : No
Color range                 : Limited
Color primaries             : BT.709
Transfer characteristics    : BT.709
Matrix coefficients         : BT.709

I know 1 min vs. full duration but doubt this can skew the results that much. Why the huge difference in bitrate/size?

Thank you.

[johns0]

Movies with a lot of action usually take a lot more bitrate than slow moving ones,simple as that,also grain and other effects take up bitrate.

[ProWo]

Another info:
The x264 CRF range and the x265 CRF range isn't the same.

[asw3]

Thank you for the responses.

I'm comparing encodes of the same clips, not between different films. While I've posted one example of the second comparison, I actually tried multiple encodes and could never ever get the bitrate to go down as low as the group release (again, encoding the same film), even in the most non-intensive scenes, including in direct scene comparisons. So I know that more intensive scenes take more bitrate. The question I'm asking is why have same settings for the same film/clips given vastly different end result in terms of bitrate/size?

Any way to equalize the CRF's between the two then? Or for a direct comparison you just have to use average bitrate encodes? Also doesn't the comparison that shows the same relative VMAF quality mean that the CRF's also work roughly the same in terms of output?

I still don't get if my notion of same relative quality but smaller file size is just wrong, or I should be doing something else in the encoder if I want to achieve this. If you get roughly the same results as x264, why even bother with x265's higher encode times?

[ProWo]

Any way to equalize the CRF's between the two then?

h.265 (hevc) CRF: The default is 28, and it should visually correspond to libx264 video at CRF 23, but result in about half the file size.
Read:
https://trac.ffmpeg.org/wiki/Encode/H.265
https://trac.ffmpeg.org/wiki/Encode/H.264

[asw3]

I'm assuming this also applies for Handbrake/StaxRip?
Also why does the VMAF stay the same for the same CRF value then? Wouldn't a CRF28 x265 give way lower VMAF compared to CRF23 x264?

[asw3]

I did another quick comparison, encodes of the same clip:

x264 10-bit, Preset: Medium, CRF 23, VMAF = 89.6720
x265 10-bit, Preset: Medium, CRF 28, VMAF = 84.7396

So it doesn't seem that the quality remains the same. It's even obvious just looking at the clips, for example the x265 encode has completely removed the noise, while it is still kept in the x264 one.

[buzz1891]

"but the strange thing is I tried making a 1 to 1 argument copy from one of their releases for a film I have, .. my encode came with way WAY higher Overall bit rate " - most likely they apply some video filtering before encoding. Or their source is noticeably different from yours.

The real advantage of x265 vs x264 lies in range of low - very_low bitrates. For big ones it's low-to-nothing. Once I did some tests for highly dynamic/detailed video, 1080/30p encoded at 3Mbps(~0.050bpf), 2 pass vbr. Contenders were: h.264 from Adobe Media Encoder, x264, x265. Results are quite telling: