x265 HEVC Encoder

[maroders2]

At preset slower, the only way to increase speed is to buy new hardware. Settings would maybe get you a fraction of a frame increase in speed. Real speed increases can only be done by sheer horsepower.

What is your current processor?

I have a cheap r5 3600 and i will change it in the future.
I want to have a good quality of the picture, which would not lose much x264. The speed is in second place, but I would like to have at least 2 fps so as not to encode 20 hours for one movie


--bframes 16

I read in the documentation that in the case of -bframes 16, the encoder itself chooses the one it needs. I also found other settings here on the forum, although I admit that I don't quite understand how to use them.
I heard the advice to start with a slow preset many times, I started with this, but then I started randomly adding other settings:)

[maroders2]

What do you think about the QxR team's BDRips?
I know that BDRips are not the best of quality, but they are ready for use. My PC doesn't meet my needs right now, so I might start building a home movie collection of their BDRips.

[RanmaCanada]

What do you think about the QxR team's BDRips?
I know that BDRips are not the best of quality, but they are ready for use. My PC doesn't meet my needs right now, so I might start building a home movie collection of their BDRips.

Discussion of piracy is not allowed here.

[benwaggoner]

I have a cheap r5 3600 and i will change it in the future.
I want to have a good quality of the picture, which would not lose much x264. The speed is in second place, but I would like to have at least 2 fps so as not to encode 20 hours for one movie
For 1080p, pretty much any modern enthusiast chip can do >>2 fps. My Ryzen 7900X3D was doing 4.6 fps with high quality no frame-threading 4K encoding last night. It probably could do >12 with stock --preset slower at 1080p.

I read in the documentation that in the case of -bframes 16, the encoder itself chooses the one it needs.
Correct, but the time taken to determine the right B-frame pattern increases exponentially with the maximum number. 8 is really all you need with typical film/video content, and there's many better speed/quality options to do before raising b-frames makes. sense.

I also found other settings here on the forum, although I admit that I don't quite understand how to use them.
I heard the advice to start with a slow preset many times, I started with this, but then I started randomly adding other settings:)
Yeah, lots of people have lots of opinions about the right settings, for. different kinds of content with different encoding goals. The defaults are a pretty reasonable middle ground to start with unless there are some specifics you are tuning for.

Admittedly, my default command line for 4K HDR encoding is... 995 characters without file paths. But that's the result of eight years of evolution with the backing of a team that leverages lots of data analysis over hundreds of different variants to narrow down the right ones for a specific class of content for a specific use case.

[vadlerg]

Setting --level-idc is sometimes a useful option. For example, it sets the VBV parameters according to the idc level selected, so it is not necessary to specify the VBV parameters in the command line separately.
If I set a specific idc level and use the --dynamic-rd command line option, dynamic-rd is complaining that VBV is not set so it will disable the use of the option.
Dynamic-rd not recognizing that VBV is set already was fixed some times ago (https://forum.doom9.org/showthread.php?p=1982450#post1982450) if I remember correctly.

Would it be possible to upstream the fix again?

An another question: --aq-auto is not implemented in the latest builds anymore only in @jpsdr (https://forum.doom9.org/member.php?u=19714) builds available as far as I see. Is there any particular reason for the -aq-auto vanishing?

[Boulder]

An another question: --aq-auto is not implemented in the latest builds anymore only in @jpsdr (https://forum.doom9.org/member.php?u=19714) builds available as far as I see. Is there any particular reason for the -aq-auto vanishing?

--aq-auto has never been in the mainline, it only exists in mods.

[benwaggoner]

We've made a number of substantial improvements to x265 in the past few weeks. x265 documentation can be found here... http://x265.readthedocs.org/en/default/

Tom
MulticoreWare
Wow, I just realized we've hit the 10th anniversary of the HEVC forum!

[vadlerg]

Wow, I just realized we've hit the 10th anniversary of the HEVC forum!

Happy 10th anniversary :)
I think default link is to master https://x265.readthedocs.io/en/master/.

[badshah]

Hi friends,
I'm trying to encode a home video which is a few hours long. while it takes only 1 hour to encode to x264, it's showing 24 hours+ as ETA for encoding to x265.
I'm using MeGUI. both x264 and x265 settings are ""very Slow" High/Main @ 4.1. Resolution 1080p. rest all is default.
I tried staxrip and handbrake as well and both are showing similar ETA.
kindly suggest how do I speed up x265 encoding.

Thank you.

[FranceBB]

kindly suggest how do I speed up x265 encoding.

That's a bit too vague as there's no magical setting to speed things up.
Please note that x265 is much more demanding than x264 as they're two very different encoders that output two very different codecs in the end.
The first thing we need to know, though, is if your CPU is already at 100% usage on all cores and what CPU you have.
If it's not, then we might have some settings to speed things up, but if it is, then I'm afraid you're gonna have to sacrifice compression performances in favor of speed.

[Boulder]

In x265, preset veryslow is much more veryslower than in x264. Preset slower is just as good, and even then there are tweaks like --no-amp --limit-refs 3 to speed things up.

[filler56789]

Hi friends,
I'm trying to encode a home video which is a few hours long. while it takes only 1 hour to encode to x264, it's showing 24 hours+ as ETA for encoding to x265.
I'm using MeGUI. both x264 and x265 settings are ""very Slow" High/Main @ 4.1. Resolution 1080p. rest all is default.
I tried staxrip and handbrake as well and both are showing similar ETA.
kindly suggest how do I speed up x265 encoding.

Thank you.

IF you have two or more desktops or laptops, you could give a try to the distributed-encoding feature of RipBot264.😐

[badshah]

Thank you Boulder & filler.
I dont have multiple pcs. someone told me about tdarr, but didnt tell me much, only said it takes 5-15 mins for him to encode a 3hr duration, 50gb file. is that a cloud based encoder?
are there any cloud based encoders which can work faster like this?

[benwaggoner]

Thank you Boulder & filler.
I dont have multiple pcs. someone told me about tdarr, but didnt tell me much, only said it takes 5-15 mins for him to encode a 3hr duration, 50gb file. is that a cloud based encoder?
are there any cloud based encoders which can work faster like this?
Any segmenting encoder can do something like that given access to enough cores and instances. And that's easiest and most affordable to do in the cloud. 15 min on 20 instances has about the same cost as 5 hours on one instance for a service handling multiple jobs like that simultaneously.

[excellentswordfight]

Thank you Boulder & filler.
I dont have multiple pcs. someone told me about tdarr, but didnt tell me much, only said it takes 5-15 mins for him to encode a 3hr duration, 50gb file. is that a cloud based encoder?
are there any cloud based encoders which can work faster like this?
Im not familiar with tdarr, but from the looks of it is that it can be hosted in the cloud, although it seems to be more targeted for "private cloud", i.e you run it on your own hardware.

From the looks of it, it also doesnt do chunk/distributed encoding, so its more doing multiple files/steps across multiple servers/computers. The speed most likely comes from it supporting GPU-encoding, that can be extremely fast compared to x265.

As for your speed question, start by using faster presets, you wont sacrifice that much of going up to 'slow'. For preset 'medium' and above you will start to see some noticeable drop from the slower presets so if thats still to slow you might wanna look at GPU-encoders instead.

In general, if you are encoding UHD with HEVC, and want the best possible quality (i.e. x265 with at least preset 'slow') it will take hours to encode titles, you wont get much more than about 5fps with current consumer hardware, there is no way around that without chunk-encoding in the cloud (or I guess you can also do it across multiple high-end-pcs at home with e.g. rippbot). If you want at least real-time encoding speeds, GPU-encoders (Intel QuickSync or Nvidia nvenc) is the way to go.

[RanmaCanada]

Hi friends,
I'm trying to encode a home video which is a few hours long. while it takes only 1 hour to encode to x264, it's showing 24 hours+ as ETA for encoding to x265.
I'm using MeGUI. both x264 and x265 settings are ""very Slow" High/Main @ 4.1. Resolution 1080p. rest all is default.
I tried staxrip and handbrake as well and both are showing similar ETA.
kindly suggest how do I speed up x265 encoding.

Thank you.

What is your system specs please? x265 very slow as Boulder said is extremely slow, even on my 5800x I average 2fps so a 2 hour movie would take a day (24 hours).

[FranceBB]

Any segmenting encoder can do something like that given access to enough cores and instances. And that's easiest and most affordable to do in the cloud. 15 min on 20 instances has about the same cost as 5 hours on one instance for a service handling multiple jobs like that simultaneously.

Yes, but it becomes really tricky when you have to output a precise, fixed closed GOP every time.
I've been doing some experiments with Avisynth and x26x in the cloud recently, I think it's time to post some results and I'll open a thread about it, but I always worked on a single instance which led to either some high costs and short processing time or some very reduced costs but very long processing times.

(more on that next week)

[LigH]

Current proposed patches shall fix a quality issue related to SBRC (when committed)...

[Selur]

Is interlaced encoding broken?
using:

x265 [info]: HEVC encoder version 3.5+111-c40c3d799
x265 [info]: build info [Windows][GCC 13.2.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2

and
ffmpeg -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "G:\TestClips&Co\files\interlaceAndTelecineSamples\interlaced\bff.m2v" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p10le -strict -1 -vsync 0 -top 1 -flags +ildct+ilme -f yuv4mpegpipe - | x265 --input - --output-depth 10 --y4m --profile main10 --limit-modes --no-early-skip --no-open-gop --opt-ref-list-length-pps --crf 18.00 --opt-qp-pps --cbqpoffs -2 --crqpoffs -2 --limit-refs 0 --ssim-rd --psy-rd 2.50 --rdoq-level 2 --psy-rdoq 10.00 --aq-mode 0 --deblock=-1:-1 --limit-sao --no-repeat-headers --interlace bff --range limited --colormatrix bt470bg --sar 8:9 --output "G:\Output\2023-11-23@15_58_44_6310_01.265"
Note the '--interlace bff', MediaInfoLib - v23.10 reports:
MediaInfo.exe g:\Output\2023-11-23@15_58_44_6310_01.265
General
Complete name : g:\Output\2023-11-23@15_58_44_6310_01.265
Format : HEVC
Format/Info : High Efficiency Video Coding
File size : 2.78 MiB
Frame rate : 29.970 FPS
Writing library : x265 3.5+101-d2711b887:[Windows][GCC 12.2.0][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=5 / numa-pools=32 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=720x480 / interlace=2 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-eob / no-eos / no-hrd / info / hash=0 / temporal-layers=0 / no-open-gop / min-keyint=25 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=0 / scenecut=40 / no-hist-scenecut / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-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 / ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=0 / limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=-1:-1 / sao / no-sao-non-deblock / rd=3 / selective-sao=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.50 / psy-rdoq=10.00 / no-rd-refine / no-lossless / cbqpoffs=-2 / crqpoffs=-2 / rc=crf / crf=18.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=0.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=255 / sar-width / : / sar-height=8:9 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=5 / chromaloc=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 / 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-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 / 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 / no-mcstf / no-sbrc

Video
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L3@Main
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate : 29.970 (30000/1001) FPS
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Writing library : x265 3.5+101-d2711b887:[Windows][GCC 12.2.0][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=5 / numa-pools=32 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=720x480 / interlace=2 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-eob / no-eos / no-hrd / info / hash=0 / temporal-layers=0 / no-open-gop / min-keyint=25 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=0 / scenecut=40 / no-hist-scenecut / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-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 / ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=0 / limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=-1:-1 / sao / no-sao-non-deblock / rd=3 / selective-sao=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.50 / psy-rdoq=10.00 / no-rd-refine / no-lossless / cbqpoffs=-2 / crqpoffs=-2 / rc=crf / crf=18.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=0.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=255 / sar-width / : / sar-height=8:9 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=5 / chromaloc=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 / 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-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 / 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 / no-mcstf / no-sbrc
Color range : Limited
Matrix coefficients : BT.470 System B/G
so no interlacing, and ffmpeg reports:
ffmpeg version N-112813-g1c3b13b9f7-gc961ac4b0c+1 Copyright (c) 2000-2023 the FFmpeg developers
built with gcc 13.2.0 (Rev2, Built by MSYS2 project)
configuration: --pkg-config=pkgconf --cc='ccache gcc' --cxx='ccache g++' --ld='ccache g++' --extra-cxxflags=-fpermissive --extra-cflags=-Wno-int-conversion --disable-autodetect --enable-amf --enable-bzlib --enable-cuda --enable-cuvid --enable-d3d11va --enable-dxva2 --enable-iconv --enable-lzma --enable-nvenc --enable-zlib --enable-sdl2 --enable-ffnvcodec --enable-nvdec --enable-cuda-llvm --disable-doc --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libdav1d --enable-libaom --disable-debug --enable-fontconfig --enable-libass --enable-libbluray --enable-libfreetype --enable-libmfx --enable-libmysofa --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libwebp --enable-libxml2 --enable-libzimg --enable-libshine --enable-gpl --enable-avisynth --enable-libxvid --enable-libopenmpt --enable-version3 --enable-librav1e --enable-libsrt --enable-libgsm --enable-libvmaf --enable-libsvtav1 --enable-mbedtls --extra-cflags=-DLIBTWOLAME_STATIC --extra-libs=-lstdc++ --extra-cflags=-DLIBXML_STATIC --extra-libs=-liconv --disable-w32threads
libavutil 58. 32.100 / 58. 32.100
libavcodec 60. 34.100 / 60. 34.100
libavformat 60. 17.100 / 60. 17.100
libavdevice 60. 4.100 / 60. 4.100
libavfilter 9. 13.100 / 9. 13.100
libswscale 7. 6.100 / 7. 6.100
libswresample 4. 13.100 / 4. 13.100
libpostproc 57. 4.100 / 57. 4.100
Input #0, hevc, from 'g:\Output\2023-11-23@15_58_44_6310_01.265':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt470bg/unknown/unknown, top first), 720x480 [SAR 8:9 DAR 4:3], 25 fps, 29.97 tbr, 1200k tbn
so interlaced, but tff not bff.

Cu Selur

Ps.: to be sure my Vaporusynth script doesn't cause the problem, I also used:
ffmpeg -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "G:\TestClips&Co\files\interlaceAndTelecineSamples\interlaced\bff.m2v" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p10le -strict -1 -vsync 0 -top 1 -flags +ildct+ilme -f yuv4mpegpipe - | x265 --input - --output-depth 10 --y4m --profile main10 --limit-modes --no-early-skip --no-open-gop --opt-ref-list-length-pps --crf 18.00 --opt-qp-pps --cbqpoffs -2 --crqpoffs -2 --limit-refs 0 --ssim-rd --psy-rd 2.50 --rdoq-level 2 --psy-rdoq 10.00 --aq-mode 0 --deblock=-1:-1 --limit-sao --no-repeat-headers --interlace bff --range limited --colormatrix bt470bg --sar 8:9 --output "J:\tmp\2023-11-23@17_26_19_0110_01.265" and got the same result.

[LigH]

Does x265 report any warning in its console output while encoding?

Also there is a little version difference between your x265 info report and the "Writing library" metadata.

[Selur]

ffmpeg -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "G:\TestClips&Co\files\interlaceAndTelecineSamples\interlaced\bff.m2v" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p10le -strict -1 -vsync 0 -top 1 -flags +ildct+ilme -f yuv4mpegpipe - | x265 --input - --output-depth 10 --y4m --profile main10 --limit-modes --no-early-skip --no-open-gop --opt-ref-list-length-pps --crf 18.00 --opt-qp-pps --cbqpoffs -2 --crqpoffs -2 --limit-refs 0 --ssim-rd --psy-rd 2.50 --rdoq-level 2 --psy-rdoq 10.00 --aq-mode 0 --deblock=-1:-1 --limit-sao --no-repeat-headers --interlace bff --range limited --colormatrix bt470bg --sar 8:9 --output "G:\Output\2023-11-23@15_58_44_6310_01.265"
y4m [info]: 720x480 fps 30000/1001 i420p10 sar 8:9 unknown frame count
raw [info]: output file: G:\Output\2023-11-23@15_58_44_6310_01.265
x265 [info]: HEVC encoder version 3.5+111-c40c3d799
x265 [info]: build info [Windows][GCC 13.2.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [warning]: Support for interlaced video is experimental
x265 [info]: Main 10 profile, Level-3 (Main tier)
x265 [info]: Thread pool created using 32 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 5 / wpp(8 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
x265 [info]: Interlaced field inputs : bff
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias : 25 / 250 / 40 / 5.00
x265 [info]: Cb/Cr QP Offset : -2 / -2
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 0.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-18.0 / 0.60
x265 [info]: tools: limit-modes rd=3 ssim-rd psy-rd=2.50 rdoq=2 psy-rdoq=10.00
x265 [info]: tools: rskip mode=1 signhide tmvp b-intra strong-intra-smoothing
x265 [info]: tools: deblock(tC=-1:B=-1) sao
x265 [info]: frame I: 1, Avg QP:19.12 kb/s: 11329.87
x265 [info]: frame P: 37, Avg QP:20.97 kb/s: 9996.83
x265 [info]: frame B: 112, Avg QP:25.53 kb/s: 2837.19
x265 [info]: Weighted P-Frames: Y:27.0% UV:21.6%

encoded 150 frames in 2.05s (73.17 fps), 4659.85 kb/s, Avg QP:24.37
=> "x265 [warning]: Support for interlaced video is experimental"

F:\Hybrid\64bit>x265 --version
x265 [info]: HEVC encoder version 3.5+111-c40c3d799
x265 [info]: build info [Windows][GCC 13.2.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2

F:\Hybrid\64bit>MediaInfo.exe G:\Output\2023-11-23@15_58_44_6310_01.265
General
Complete name : G:\Output\2023-11-23@15_58_44_6310_01.265
Format : HEVC
Format/Info : High Efficiency Video Coding
File size : 2.78 MiB
Frame rate : 29.970 FPS
Writing library : x265 3.5+111-c40c3d799:[Windows][GCC 13.2.0][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=5 / numa-pools=32 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=720x480 / interlace=2 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-eob / no-eos / no-hrd / info / hash=0 / temporal-layers=0 / no-open-gop / min-keyint=25 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=0 / scenecut=40 / no-hist-scenecut / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-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 / ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=0 / limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=-1:-1 / sao / no-sao-non-deblock / rd=3 / selective-sao=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.50 / psy-rdoq=10.00 / no-rd-refine / no-lossless / cbqpoffs=-2 / crqpoffs=-2 / rc=crf / crf=18.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=0.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=255 / sar-width / : / sar-height=8:9 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=5 / chromaloc=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 / 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-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 / 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 / no-mcstf / no-sbrc

Video
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L3@Main
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate : 29.970 (30000/1001) FPS
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Writing library : x265 3.5+111-c40c3d799:[Windows][GCC 13.2.0][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=5 / numa-pools=32 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=720x480 / interlace=2 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-eob / no-eos / no-hrd / info / hash=0 / temporal-layers=0 / no-open-gop / min-keyint=25 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=0 / scenecut=40 / no-hist-scenecut / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-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 / ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=0 / limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=-1:-1 / sao / no-sao-non-deblock / rd=3 / selective-sao=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.50 / psy-rdoq=10.00 / no-rd-refine / no-lossless / cbqpoffs=-2 / crqpoffs=-2 / rc=crf / crf=18.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=0.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=255 / sar-width / : / sar-height=8:9 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=5 / chromaloc=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 / 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-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 / 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 / no-mcstf / no-sbrc
Color range : Limited
Matrix coefficients : BT.470 System B/G

F:\Hybrid\64bit>ffmpeg -i G:\Output\2023-11-23@15_58_44_6310_01.265
ffmpeg version N-112813-g1c3b13b9f7-gc961ac4b0c+1 Copyright (c) 2000-2023 the FFmpeg developers
built with gcc 13.2.0 (Rev2, Built by MSYS2 project)
configuration: --pkg-config=pkgconf --cc='ccache gcc' --cxx='ccache g++' --ld='ccache g++' --extra-cxxflags=-fpermissive --extra-cflags=-Wno-int-conversion --disable-autodetect --enable-amf --enable-bzlib --enable-cuda --enable-cuvid --enable-d3d11va --enable-dxva2 --enable-iconv --enable-lzma --enable-nvenc --enable-zlib --enable-sdl2 --enable-ffnvcodec --enable-nvdec --enable-cuda-llvm --disable-doc --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libdav1d --enable-libaom --disable-debug --enable-fontconfig --enable-libass --enable-libbluray --enable-libfreetype --enable-libmfx --enable-libmysofa --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libwebp --enable-libxml2 --enable-libzimg --enable-libshine --enable-gpl --enable-avisynth --enable-libxvid --enable-libopenmpt --enable-version3 --enable-librav1e --enable-libsrt --enable-libgsm --enable-libvmaf --enable-libsvtav1 --enable-mbedtls --extra-cflags=-DLIBTWOLAME_STATIC --extra-libs=-lstdc++ --extra-cflags=-DLIBXML_STATIC --extra-libs=-liconv --disable-w32threads
libavutil 58. 32.100 / 58. 32.100
libavcodec 60. 34.100 / 60. 34.100
libavformat 60. 17.100 / 60. 17.100
libavdevice 60. 4.100 / 60. 4.100
libavfilter 9. 13.100 / 9. 13.100
libswscale 7. 6.100 / 7. 6.100
libswresample 4. 13.100 / 4. 13.100
libpostproc 57. 4.100 / 57. 4.100
Input #0, hevc, from 'G:\Output\2023-11-23@15_58_44_6310_01.265':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt470bg/unknown/unknown, top first), 720x480 [SAR 8:9 DAR 4:3], 25 fps, 29.97 tbr, 1200k tbn

Cu Selur

[Br4twurscht]

Hi together,

normally I'm using StaxRip for my encodings and was always happy. HDR10 was added from the source automatically and I could focus on filters, audio and some x265 settings. But now I wanted to try encodes with dolby vision and doesn't get it working.

Firstly, I wanted to ask a question for general understanding. Will the dv metadata be used in the encoding process of x265 in that way, that it has influence on the encoding result itself? Or is the dv metadata "only" added additionally to the stream afterwards and will then be interpreted by the decoder? Or in other words, assuming a dv source and doing one encoding with the rpu file and one without, would the target stream be the same?

Secondly, I wanted to ask if there are guides how to handle the dv stuff for the encoding. I tried this guide https://github.com/staxrip/staxrip/wiki/Encoding-Dolby-Vision-with-StaxRip-using-x265 and experimented by myself, but run always in an error like
x265 [INFO]: HEVC encoder version 3.5+147+17-e8947f740 [Mod by Patman]
x265 [INFO]: build info [Windows][MSVC 1937][64 bit] 10bit
x265 [INFO]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [FLAW]: Dolby Vision requires VBV settings to enable HRD.
x265 [FLAW]: x265_encoder_open() failed for Enc,
x265 [WARN]: Dolby Vision RPU count is greater than frame count in x265
x265 [INFO]: VES muxing with Dolby Vision RPU file successful in x265
aborted at input frame 1, output frame 0 in x265

I read a little bit in the DDVT Thread, but this gave me the impression, that the dv stuff can be muxed and demuxed into/from the container. So, this led me to qustion #1 and I'm still more confused than at the beginning...

Greetings
Br4twurscht

[RanmaCanada]

Hi together,

normally I'm using StaxRip for my encodings and was always happy. HDR10 was added from the source automatically and I could focus on filters, audio and some x265 settings. But now I wanted to try encodes with dolby vision and doesn't get it working.

Firstly, I wanted to ask a question for general understanding. Will the dv metadata be used in the encoding process of x265 in that way, that it has influence on the encoding result itself? Or is the dv metadata "only" added additionally to the stream afterwards and will then be interpreted by the decoder? Or in other words, assuming a dv source and doing one encoding with the rpu file and one without, would the target stream be the same?

Secondly, I wanted to ask if there are guides how to handle the dv stuff for the encoding. I tried this guide https://github.com/staxrip/staxrip/wiki/Encoding-Dolby-Vision-with-StaxRip-using-x265 and experimented by myself, but run always in an error like
x265 [INFO]: HEVC encoder version 3.5+147+17-e8947f740 [Mod by Patman]
x265 [INFO]: build info [Windows][MSVC 1937][64 bit] 10bit
x265 [INFO]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [FLAW]: Dolby Vision requires VBV settings to enable HRD.
x265 [FLAW]: x265_encoder_open() failed for Enc,
x265 [WARN]: Dolby Vision RPU count is greater than frame count in x265
x265 [INFO]: VES muxing with Dolby Vision RPU file successful in x265
aborted at input frame 1, output frame 0 in x265

I read a little bit in the DDVT Thread, but this gave me the impression, that the dv stuff can be muxed and demuxed into/from the container. So, this led me to qustion #1 and I'm still more confused than at the beginning...

Greetings
Br4twurscht

DV is proprietary, and basically what you need to do is follow the information in the DDVT Thread. You do not encode in DV.

https://forum.doom9.org/showthread.php?t=182311

It's a mess.

[Br4twurscht]

Ok, thx. Then I try my luck with the DDVT.

[benwaggoner]

What's the best source for a multi depth Mac OS ARM x265 binary with all the latest and greatest ARM optimizations?

Last I checked the Xcode version was all messed up and required manual patching. I was never able to get that to work for >8-bit.

It appears the brew version is from 2022!

==> x265: stable 3.5 (bottled), HEAD
% brew info x265
H.265/HEVC encoder
https://bitbucket.org/multicoreware/x265_git
/opt/homebrew/Cellar/x265/HEAD-0b75c44 (11 files, 11.8MB) *
Built from source on 2022-10-20 at 12:33:05
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/x/x265.rb
License: GPL-2.0-only
==> Dependencies
Build: cmake ✔
==> Options
--HEAD
Install HEAD version
==> Analytics
install: 20,013 (30 days), 59,842 (90 days), 198,356 (365 days)
install-on-request: 229 (30 days), 537 (90 days), 1,652 (365 days)
build-error: 16 (30 days)

[qyot27]

MacPorts (https://ports.macports.org/port/x265/details/)? There is a highdepth variant*, and from what I can tell when looking at the portfile, it doesn't look like it's pinned to a release tarball, so it probably is pulling the latest git HEAD as a snapshot tarball and going from there.

*which you'd enable by tacking '+highdepth' onto the install command.

[benwaggoner]

MacPorts (https://ports.macports.org/port/x265/details/)? There is a highdepth variant*, and from what I can tell when looking at the portfile, it doesn't look like it's pinned to a release tarball, so it probably is pulling the latest git HEAD as a snapshot tarball and going from there.

*which you'd enable by tacking '+highdepth' onto the install command.
That worked!

% x265 --version
x265 [info]: HEVC encoder version 3.5+40-0b75c44c1
x265 [info]: build info [Mac OS X][clang 14.0.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: NEON

That said 3.5+40 quite a while ago, and I think lacks a lot of the NEON optimizations. We've already hit at least 3.5+110. Any suggestions on how to get a more recent branch?

[qyot27]

Ah, yeah it looks like it is set to a particular release after all, although I'm not seeing exactly where they're grabbing 3.5+40-0b75c44c1 from, because the Portfile is set to 3.4, and none of the videolan x265 branches are fresh enough to even approach that.

But there might be a solution to edit the Portfile to use a newer version locally and use that. I haven't done so myself (that I can remember, anyway), but the page on the MacPorts Trac is here:
https://trac.macports.org/wiki/howto/Upgrade

There's also this part of the documentation that describes the Port Groups function that interfaces with Github:
https://guide.macports.org/chunked/reference.portgroup.html

So my guess is that the necessary change would be to select a different Github repository that mirrors x265*, and set the version to the most recent commit. Adjust the checksums/size fields to match what those should be for something like that (like this one did when bumping to 3.4 (https://github.com/macports/macports-ports/commit/fd29c3a9a0e32afb2b7ffe7fcc688021f9a5c337)), and then attempt to build it again.

*most of the videolan mirror network repos aren't synced with bitbucket either. I have one I used a few months ago to refresh the Yuuki patchset (https://github.com/qyot27/x265/commits/main), for example; it's only missing the 4 latest commits.

[benwaggoner]

x265 v3.5+115
https://www.mediafire.com/file/ftoufvn6cjvz90n
Apropos of the above, do you have the ability to compile a Mac OS ARM build ;)?

[Barough]

Sorry, it's not possible to do that with m-ab-s.

Sent from my SM-S908B via Tapatalk

[qyot27]

Apropos of the above, do you have the ability to compile a Mac OS ARM build ;)?

https://www.mediafire.com/file/ees2cmznwfig4m8/x265_macos_arm_build.tar.xz/file

It seems to compile okay using AppleClang 14 on Monterey.

[benwaggoner]

https://www.mediafire.com/file/ees2cmznwfig4m8/x265_macos_arm_build.tar.xz/file

It seems to compile okay using AppleClang 14 on Monterey.
Awesome thanks! And it sure did the trick. 4K slower Encoding speeds on a M1 Pro are at least a third faster than my brew 3.5+20 build.

MacPorts made a 32-bit no-asm version for some horrible reason; I didn't even bother to benchmark that.

[Ritsuka]

x265 arch check was broken, it printed 32-bit even on 64-bit ARM versions, actually there is no way to run a macOS 32-bit executable on macOS these days.
Unfortunately there are a lot of repositories stuck on the last "official" x265 version. And some websites like phoronix.com still uses 3.4 in their x86_64 vs ARM benchmarks.

[Hellboy.]

I see some people show this with their encode:

x265 [info]: frame I: 54, Avg QP:13.82 kb/s: 18717.13
x265 [info]: frame P: 1128, Avg QP:15.83 kb/s: 13458.52
x265 [info]: frame B: 6031, Avg QP:20.85 kb/s: 5528.32
x265 [info]: Weighted P-Frames: Y:2.0% UV:1.5%
encoded 7213 frames in 396.22s (18.20 fps), 6867.22 kb/s, Avg QP:20.01

What is "Avg QP"? That mean something for the quality of the encode? Lower or higher is better?
Thanks

[LigH]

QP is the "Quantizer Parameter". Imagine it as a divider to reduce the variety of color component values. The higher the quantizer, the less accurate the storage of the video, the more obvious the loss gets, visible in video artifacts like blocking, ringing around edges, banding in smooth color ramps. Lower values help keeping better quality, but that requires more bitrate because the stored values are more variable, so less of them can be reduced to an "almost the same as somewhere else" (visual redundancy).

The x264 and x265 encoders do not apply a constant quantizer to all frames, except you use a parameter which enforces that; in general (in 1 pass CRF mode or in 2-pass mode with a target size), they use a metric called "Rate Factor" which tries to keep the visual loss caused by the encoding below a specific threshold, which allows the quantizer to vary a bit in relation to the complexity of the video content.

[Hellboy.]

There is some "Avg QP" number that encoders try to achieve? Example: Like below 20.

[LigH]

Only if you enforce that by an additional parameter (which may lead to the resulting bitrate exceeding your expectations).

--qpfile <string> Force frametypes and QPs for some or all frames
Format of each line: framenumber frametype QP
QP is optional (none lets x265 choose). Frametypes: I,i,K,P,B,b.
QPs are restricted by qpmin/qpmax.

-q/--qp <integer> QP for P slices in CQP mode (implied). --ipratio and --pbration determine other slice QPs

--qpmax <integer> sets a hard upper limit on QP allowed to ratecontrol. Default 69

In general, though, the rate control algorithm is allowed to vary quantization values as required by the video content.

[Hellboy.]

Using higher number on these settings always translate in better quality? (For Blu-ray content with 8,000Bitrate or more and knowing that the encode is going to take more time.) (Slow crf17)

bframes
rc-lookahead
subme

I ask because higher preset use higher numbers and a lot of encoders use slow preset with higher numbers.

[LigH]

Not certainly.

B frames are useful in 2-pass encoding to achieve a lower average QP of I and P frames because they often use less bitrate, but use a higher QP themselves by default (I/P/B ratios) because their loss is only visible for a brief time and does not propagate much through time (in contrast to the loss of a P frame sequence). In a CRF encoding they don't improve quality, only help reducing the output size. Also there are hardware decoders which are limited in features. A range of 1-3 consecutive B frames is rather safe. In case of more than 2, enable the B frame pyramid so their weighting is distributed better.

The rate control lookahead also does not help much in the CRF case because there is no rate control on top to alter the target rate factor, you set it constant. It is more important in 2-pass with a target size and in 1-pass with a rather constant average bitrate.

A finer motion estimation is helpful in general. But there is no guarantee for exceptional cases where less than the maximum would already be enough.

[benwaggoner]

B frames are useful in 2-pass encoding to achieve a lower average QP of I and P frames because they often use less bitrate, but use a higher QP themselves by default (I/P/B ratios) because their loss is only visible for a brief time and does not propagate much through time (in contrast to the loss of a P frame sequence). In a CRF encoding they don't improve quality, only help reducing the output size. Also there are hardware decoders which are limited in features. A range of 1-3 consecutive B frames is rather safe. In case of more than 2, enable the B frame pyramid so their weighting is distributed better.
Are there decoders outside of optical disc that are limited to three? I've been using up to 8 on a very wide variety of streaming players for a decade, without any compatibility issues.

The rate control lookahead also does not help much in the CRF case because there is no rate control on top to alter the target rate factor, you set it constant. It is more important in 2-pass with a target size and in 1-pass with a rather constant average bitrate.
Lookahead absolutely can help CRF if the VBV limit it hit (--vbv-bufsize and --vbv-maxrate set, which is required to set a Profile and Level for device compatibility). When the VBV limit would be hit, more lookahead lets the encoder smooth out the bitrate fluctuation, and thus moderate the worst-case QP spike/quality hit.

RAM permitting, rc-lookhead=keyint provides optimal quality, although there are diminishing returns past 50 or so.

A finer motion estimation is helpful in general. But there is no guarantee for exceptional cases where less than the maximum would already be enough.
Yeah, like a lot of quality/speed tradeoff parameters, you're doing stuff that makes it slower for all content that will only help some content. The higher the bitrate, the less likely there will be any visible changes.

[LigH]

Are there decoders outside of optical disc that are limited to three? I've been using up to 8 on a very wide variety of streaming players for a decade, without any compatibility issues.

Maybe early Apple mobile and Quicktime decoders ... surely improving over time.

[benwaggoner]

Maybe early Apple mobile and Quicktime decoders ... surely improving over time.
I'm quite confident that all devices in active use in the last decade (no one is still using the original iPhone!) support up to five b-frames.

[Hellboy.]

(For Blu-ray 1080p content with 8,000Bitrate or more, Slow crf17)

I change ctu=64 to ctu=32.
Is there any other setting that is recommended to change? Maybe "merange" from 57 to 25, i see sometimes that setting is lowered.
Thanks.

[Boulder]

(For Blu-ray 1080p content with 8,000Bitrate or more, Slow crf17)

I change ctu=64 to ctu=32.
Is there any other setting that is recommended to change? Maybe "merange" from 57 to 25, i see sometimes that setting is lowered.
Thanks.

--no-sao and --rskip 2 --rskip-edge-threshold 2 will retain more details.

[LigH]

New upload: x265 3.5+114-74abf80c7 (https://www.mediafire.com/file/d9pxofte208sq4m/x265_3.5+114-74abf80c7.7z/file)

[Windows][GCC 13.2.0][32/32XP/64 bit] 8bit+10bit+12bit

[FranceBB]

Thanks for the updated builds and for still targeting Windows XP, you're the only one left who's still doing it! :)

[tormento]

I am testing PSNR, SSIM and VMAF metrics. Many switches, that were suggested to have higher quality encodes, give worse PSNR, SSIM and even VMAF scores.

How much can I trust synthetic and perceptive metrics?

Do you have any better metric to suggest me?

P.S: I am using FFMetrics (https://github.com/fifonik/FFMetrics).

[LigH]

No objective metric (calculated from a difference of clips) is equal to a subjective opinion gathered in a survey among a bunch of people.

[tormento]

among a bunch of people.
As I can't summon one thousand people in my room every time I need a reference, is VMAF good enough or there is something better?

[LigH]

AFAIR: PSNR is rather simple and easy to confuse; SSIM is a bit better but compares only single frames, like PSNR; VMAF is even more advanced, even takes some temporal development into account. I do not yet know any better objective metric than VMAF.

As a more subjective modification, I don't know how to rate psycho-visual enhancements in comparison, how encoders apply them. But I am pretty sure that they exist for a good reason. And they are best rated while watching the movie at usual speed, not frame by frame, not with a magnifier, not with a difference calculation.