djatom / x265-amod

DJATOM's mod for x265 encoder

x265 HEVC Encoder - DJATOM's Mod

Main purpose of creating own mod is additional functionality that most likely will not be accepted to mainstream repo. Mod's features:

• XLENGTH y4m tag support
• extended progress line, including elapsed/estimated remaining encode time, estimated file size, etc
• Avisynth scripts reader (with possibility to supply external avisynth library, UTF8-aware loader on Windows 1903 and newer)
• Vapoursynth scripts reader (with support of external vsscript library and output node selection)

Read: Online documentation | Download: releases

x265 is an open source HEVC encoder. See the developer wiki for instructions for downloading and building the source. x265 is free to use under the GNU GPL and is also available under a commercial license

x265-amod's Issues

Differentiate between master branch and patches

Please, use a double number in the version such as what is master branch and what changes are yours.

Example:

X265-3.5+104 is original plus changes +15, so the version becomes x265-3.5+104+15.

fps display in the progress text should better be instant ?

Hello @DJATOM !

Currently the progress text of x265 shows important information, all calculated properly, but it seems that fps is calculated as average from the beginning:

fps = (nb of frames processed since beginning) / (time elapsed since beginning).

This gives a idea of the global behavior in the process.

However, fps is a bench-marking information. It has to reflect current status of processing speed.
Let's say, there is suddenly another process launched on the computer, then the fps should almost immediately drop. But it doesn't because the fps is a long term average here. So, I suggest:

fps = (nb of frames processed on a sliding window, or in a buffer) / (time used to process those frames)

That of course, is in my humble opinion.
And thanks always for the great work!

Request for AviSynth support

I would like to request AviSynth support, direct support without lavf.

https://github.com/msg7086/x265-Yuuki-Asuna

msg7086/x265-Yuuki-Asuna#11

Remove rounding to 0.1 for aq-str in CLI

x265-aMod/source/common/param.cpp

Line 1989 in 4c4aee0

x265_log(param, X265_LOG_INFO, "AQ: mode / str / qg-size / cu-tree : %d / %0.1f / %d / %d\n", param->rc.aqMode,

Support for VS API v3

Unfortunately StaxRip hasn't updated yet to v4.

Would you please create a release with v3 support too?

performance difference between toolchain

Sorry for bothering
but I am wondering if there is any performance difference between LLVM and GCC on new architect like znver3 ?

Dolby Vision support

The --dolby-vision-rpu and --dolby-vision-profile options may not work ...

LA_A006_C008_4K_HDR_HEVC_staxrip.log

Compile Error with llvm-mingw 13

with latest llvm-mingw, it failed to build on Windows
https://github.com/mstorsjo/llvm-mingw/releases/tag/20211002
give the error
mingw32-make: *** [Makefile:135: all] Error 2

Ryzen 3700x optimized x265? Which one should I use?

I notice there's x265...znver1.exe and x265...znver2.exe

Are these ryzen optimized builds? If so, which one should I use for a Ryzen 3700x?

strange tag in encoding settings

Hi @DJATOM, also @Patman86

This happens with both @DJATOM and @Patman86 latest builds. There is a tag appearing in Mediainfo's "Encoder Settings" of encoded files. It seems there is a syntax problem with it:

scenecut-aware-qp=0conformance-window-offsets

What does this tag mean?
scenecut-aware-qp=0 has a meaning, OK.
conformance-window-offsets is undocumented 😕
scenecut-aware-qp=0conformance-window-offsets appears so to be a mistake 😕

Here are the parameters used in the encoding process:
--crf 18 --output-depth 10

Complete command line:
"C:\Program Files\StaxRip\Apps\Encoders\x265\x265.exe" --reader-options library="C:\Program Files\StaxRip\Apps\FrameServer\AviSynth\AviSynth.dll" --crf 18 --output-depth 10 --output "C:\Temp\_StaxRip\TimecodeSample25Fps_Chapts_temp\TimecodeSample25Fps_Chapts basic_out.hevc" "C:\Temp\_StaxRip\TimecodeSample25Fps_Chapts_temp\TimecodeSample25Fps_Chapts basic.avs"

Here is the complete encoding section of Mediainfo (look at last line or line before last):

cpuid=1111039 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1280x720 / interlace=0 / total-frames=1960 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / 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 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=4 / scenecut=40 / hist-scenecut=0 / 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=0 / 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 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / selective-sao=4 / early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=18.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / 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=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / 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 / 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 / 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 / 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

This can be reproduced easily! Please check! Thanks!!

Question

Hello,
i have CPU family "Comet Lake" and i use StaxRip which file i should use:

x265-x64-v3.5+68-aMod-gcc12.2.1-opt-haswell.exe
x265-x64-v3.5+68-aMod-gcc12.2.1-opt-nehalem.exe
x265-x64-v3.5+68-aMod-gcc12.2.1-opt-sandybridge.exe
x265-x64-v3.5+68-aMod-gcc12.2.1-opt-skylake.exe
x265-x64-v3.5+68-aMod-gcc12.2.1-opt-znver1.exe
x265-x64-v3.5+68-aMod-gcc12.2.1-opt-znver2.exe
x265-x64-v3.5+68-aMod-gcc12.2.1-opt-znver3.exe
x265-x64-v3.5+68-aMod-gcc12.2.1.exe

Compiling Error with Visual Studio

After adding the new AQ mode, compiling with Visual Studio ends with error 'c1061 compiler limit blocks nested too deeply'. With GCC there is no problem compiling. param.cpp cause the problem.

--limit-refs default value for Medium preset

Hello,

since your build is the only one compatible with StaxRip at the time, so that it can't be exchanged, I would like to ask, if you want to fix a bug in x265, that exists for a very long time.
Personally I don't care, because I know this bug and I always use the Slow preset, but maybe you wanna fix it though.

According to the Preset table and parameter description --limit-refs's default value should be 3, but for Medium preset it is set to 1.
I created an issue, but nothing happens. Then I created a pull request, but again nothing happens and I doubt, that something will happen.

😁 So it's up to you...

Enable --dhdr10-info option

Please enable --dhdr10-info support when compiling the codec.
x265 [info]: HEVC encoder version 3.4+62-5b977e9ed [DJATOM's Mod]
x265 [info]: build info [Windows][GCC 10.2.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [warning]: --dhdr10-info disabled. Enable HDR10_PLUS in cmake.

At the end of encoding, error is returned with exit code: -1073740940 (0xC0000374) (in StaxRip)

[System Environment]
Windows : Windows 10 Home x64 19042.746
CPU : Intel(R) Core(TM) i5-7300HQ CPU @ 2.50GHz

Hi,

I deployed the most recent release x265-x64-v3.4+55-aMod-gcc10.2.1+opt.7z(x265-x64-v3.4+55-aMod-gcc10.2.1.exe) to be called from StaxRip 2.1.7.1 Beta, and I encounter the following error message at the end of encoding.

------------------------ Error Video encoding ------------------------
Video encoding returned error exit code: -1073740940 (0xC0000374)
It's unclear what the exit code means, in case it's a COM error then it possibly means:
HRESULT where exception occurred: 0xC0000374

The command was as follows (with [...] being the abbreviation for the path):

[...]\x265.exe --crf 18 --output-depth 10 --hist-threshold 0.01 --output [...]\test_1audio_new_out.hevc [...]\test_1audio_new.vpy

(x265 took vpy as a direct input.)

And the vpy file was as follows:

import os, sys
import vapoursynth as vs
core = vs.get_core()

sys.path.append(r"[...]\VS\Scripts")
core.std.LoadPlugin(r"[...]\ffms2.dll", altsearchpath=True)
clip = core.ffms2.Source(r"[...]\test_1audio.mkv", cachefile=r"[...]\test_1audio_temp\temp.ffindex")
clip.set_output()

During the whole process, I couldn't observe any memory leak (albeit casually).

What could be the cause?

(BTW, can you please support 8-bit and 12-bit encoding as well? 😄)

---

ADDED:

1. I ran the same command on CMD, but hevc itself encodes successfully.
2. For comparison, I called @Patman86's most recent x265 build x265M-test_seek_avs_and_vpy.zip from within StaxRip 2.1.7.1 Beta, and had no problems unlike your build.

Well, is this an issue with StaxRip? Since I don't have in-depth knowledge regarding this matter, I can't figure out. Can you please take a look?

---

Update:

I think I figured out the cause: it was UPXing. (ver 3.96)
I tried un-UPXing x265-x64-v3.4+55-aMod-gcc10.2.1.exe and the problem is gone.
But if I re-UPX it, the same error occurs in StaxRip.

Is issuing different exit codes (uncompressed vs UPXed) normal usually?
If so, maybe this is to taken care of by StaxRip.

But considering that StaxRip has not experienced this kind of issues so far with UPXed binaries (your previous binaries and @Patman86's many binaries including the above mentioned x265 in x265M-test_seek_avs_and_vpy.zip, ffmpeg, MP4Box, aomenc, etc.) I'm pretty much suspicious that there's something with x265-x64-v3.4+55-aMod-gcc10.2.1.exe.

Warped AR for direct vpy input produced by DGSource

Direct vpy input by DGSource, seems to warp the aspect ratio of the output hevc file, although the input resolution is correctly provided by the vpy file according to the log. (But the SAR is reversed.)

x265 3.4+65-aMod(GCC10.2.1) DJATOM

D:\Utilities\StaxRip\Apps\Encoders\x265\x265.exe --crf 27 --output-depth 10 --output D:\Downloads\test_1audio_temp\test_1audio_DGSource_x265-direct-input_out.hevc D:\Downloads\test_1audio_temp\test_1audio_DGSource_x265-direct-input.vpy

vpy  [info]: 1920x1080 fps 24000/1001 i420p8 sar 9:16 frames 0 - 2478 of 2479
vpy  [info]: using 4 parallel requests
raw  [info]: output file: D:\Downloads\test_1audio_temp\test_1audio_DGSource_x265-direct-input_out.hevc
x265 [info]: HEVC encoder version 3.4+65-2ce978dd9 [DJATOM's Mod]
...

The vpy file itself is very simple.

import os, sys
import vapoursynth as vs
core = vs.get_core()

sys.path.append(r"D:\Utilities\StaxRip\Apps\Plugins\VS\Scripts")
core.std.LoadPlugin(r"D:\Utilities\StaxRip\Settings\Plugins\Dual\DGDecNV\DGDecodeNV.dll")
clip = core.dgdecodenv.DGSource(r"D:\Downloads\test_1audio_temp\test_1audio.dgi", deinterlace=0, fieldop=0)
clip.set_output()

See the log here:
test_1audio_DGSource_x265-direct-input_staxrip.log

OTOH, if I pipe the vpy via vspipe, this issue does not occur.

Here's the log:
test_1audio_DGSource_vspipe_staxrip.log

Please see these results on my Google Drive.

For comparison, I switched the source filter to StvG's latest ffms2 build, but with this source filter, even direct vpy input does not raise this problem.

This time the SAR is not warped.

vpy  [info]: 1920x1080 fps 24000/1001 i420p8 sar 1:1 frames 0 - 2478 of 2479

Can you please take a look into this?