x265 HEVC Encoder

[quietvoid]

Yea, I'm not doing any of that.

[LigH]

The media-autobuild suite supports custom patches (https://github.com/m-ab-s/media-autobuild_suite#custom-patches); unfortunately, I am not experienced enough to create them from differences between forks. But if anyone here could help making them available from Yuuki-Asuna and DJATOM mods, it might be possible to build fresh modified builds conveniently.

[Patman]

Hello everybody,

I'm having a problem creating the binary with the correct version tag. When I ask the version on the command line, it always says "unknown". What could be the reason? The source files have not been changed and HG / Git is installed. I am using GCC to compile.

[quietvoid]

Hello everybody,

I'm having a problem creating the binary with the correct version tag. When I ask the version on the command line, it always says "unknown". What could be the reason? The source files have not been changed and HG / Git is installed. I am using GCC to compile.

Revert commit d926c02/606265a, "Fix version information reporting for x265 git archival"
There might be a fix getting pushed sooner or later.

[Patman]

Revert commit d926c02/606265a, "Fix version information reporting for x265 git archival"
There might be a fix getting pushed sooner or later.

Barough compiled with the latest commit. Maybe the version.txt was pimped up by him :D

[Barough]

Barough compiled with the latest commit. Maybe the version.txt was pimped up by him :D

Nah, i haven't done anything.

[GrampaD]

x265-3.2.1+1 (https://www.mediafire.com/file/osjbu48x7t5d3fk/x265-3.2.1+1.7z/file)
x265-3.2.1+1 (UPX packed) (https://www.mediafire.com/file/c7lknofh4g6h43y/x265-3.2.1+1_%28UPX_packed%29.7z/file)


x265 [info]: HEVC encoder version 3.2.1+1-b5c86a64bbbe
x265 [info]: build info [Windows][Clang 9.0.0][64 bit] 8bit+10bit+12bit
x265 [info]: (lsmash 2.16.1)
x265 [info]: (libavformat 58.29.100)
x265 [info]: (libavcodec 58.54.100)
x265 [info]: (libavutil 56.31.100)


I have the same version of the codec, my source is MacPorts:


~> which x265

/opt/local/bin/x265


...But it's not showing 10-bit support:

~> x265 -V
x265 [info]: HEVC encoder version 3.2.1+1-b5c86a64bbbe
x265 [info]: build info [Mac OS X][clang 11.0.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2


...Is it because my hardware won't support 10-bit color? Will MacBook Pros EVER support 10-bit color?

Thanx in advance for answering :)

[sneaker_ger]

It's not about your hardware. "Your" x265 binary simply wasn't compiled with 10 bit support. You have to download a different binary or compile one yourself.

[qyot27]

Related:
https://trac.macports.org/ticket/59860

[LigH]

The media-autobuild suite supports custom patches (https://github.com/m-ab-s/media-autobuild_suite#custom-patches); unfortunately, I am not experienced enough to create them from differences between forks. But if anyone here could help making them available from Yuuki-Asuna and DJATOM mods, it might be possible to build fresh modified builds conveniently.

Can anyone help me creating diff patches out of their current repos?

[quietvoid]

Can anyone help me creating diff patches out of their current repos?

As in on top of both master branches?
You can just add a remote to your x265_git repo and do a diff on the branches:
git clone https://bitbucket.org/multicoreware/x265_git.git
cd x265_git
git remote add x265-Yuuki-Asuna https://github.com/msg7086/x265-Yuuki-Asuna.git
git remote update

# For example if you want to use the Yuuki branch
git diff origin/master x265-Yuuki-Asuna/Yuuki > x265_git-master-Yuuki-diff.patch


And you have a patch (that may be outdated in this case).
The same workflow should work for DJATOM's repo.

You'd have the origin remote (which has x265_git's branches) and whichever other remote repos you add.

[stax76]

@Barough

Do you also have a MediaFire folder for your builds?

I've created a wiki page (https://github.com/staxrip/staxrip/wiki/x265) showing which builds and mods exist.

[Barough]

@Barough

Do you also have a MediaFire folder for your builds?

I've created a wiki page (https://github.com/staxrip/staxrip/wiki/x265) showing which builds and mods exist.

@stax76

I'll PM you.

[stax76]

@stax76

I'll PM you.

I've private messages disabled.

But my mail address is on my GitHub profile (https://github.com/stax76).

[Barough]

I've private messages disabled.

But my mail address is on my GitHub profile (https://github.com/stax76).I'll have a look there when i get bk home

[EDIT]
Sent you a email

[Kurogane]

I'm trying to figure out why pmode give me this warning

x265 [warning]: Limit reference options 2 and 3 are not supported with pmode. Disabling limit reference

I'm using this basic config

--preset slow --crf 18.0 --profile main10 --output-depth 10 --pmode

When i use another preset than slow not give me this warning.

I'm using 3.4+9-g1fb7c7960

[benwaggoner]

I'm trying to figure out why pmode give me this warning

x265 [warning]: Limit reference options 2 and 3 are not supported with pmode. Disabling limit reference

I'm using this basic config

--preset slow --crf 18.0 --profile main10 --output-depth 10 --pmode

When i use another preset than slow not give me this warning.

You can see here that Limit Refs 3 is used in presets 2-6 only:

https://x265.readthedocs.io/en/master/presets.html

[Barough]

x265 v3.4+35-772bb4c84 (https://www.mediafire.com/file/s0igugnx3ydilw3/x265-3.4%252B35-772bb4c84_Win_GCC102.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/Release_3.5

[Kurogane]

You can see here that Limit Refs 3 is used in presets 2-6 only:

https://x265.readthedocs.io/en/master/presets.html

I tested in all profiles and only the one give me this error is "slow".

[Greenhorn]

The table is out-of-date/wrong. Limit-refs 1 is only used on "Slow" these days. Everything else uses 3 (slower, medium and lower) or none (veryslow/placebo.)

@kurogane: it's just saying that a setting used by the preset is incompatible with pmode. It should probably be setting it to "1" instead of disabling it entirely, but you can use both features and the slow preset all together just by setting --preset slow --limit-refs 1 --pmode.

[Boulder]

The table is out-of-date/wrong. Limit-refs 3 is only used on "Slow" these days. Everything else uses 3 (slower, medium and lower) or none (veryslow/placebo.)

@kurogane: it's just saying that a setting used by the preset is incompatible with pmode. It should probably be setting it to "1" instead of disabling it entirely, but you can use both features and the slow preset all together just by setting --preset slow --limit-refs 1 --pmode.

--preset slower applies --limit-refs 1. I'm using it right now in my encodes and I don't have any separate --limit-refs call. The info section shows this:

x265 [info]: References / ref-limit cu / depth : 4 / off / on

[Greenhorn]

--preset slower applies --limit-refs 1. I'm using it right now in my encodes and I don't have any separate --limit-refs call. The info section shows this:

x265 [info]: References / ref-limit cu / depth : 4 / off / on

Typo in my post. Woops.

[FranceBB]

For those of you that use AVID Media Composer, from version 2020.12 it's possible to link and edit H.265 files. Considering that H.265 was released more than 8 years ago, it's about time, AVID! They should have done this long time ago!! What took them so long...?! -.- Still, habemus H.265 import support at last...

[Barough]

x265 v3.4+36-5239276dd (https://www.mediafire.com/file/645v8gzgslzv1gv/x265-3.4%252B36-5239276dd_Win_GCC102.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/Release_3.5

[FranceBB]

I guess we're gonna have to wait 'till someone will upload a sample, then...

In case anyone is still interested in files produced by Iphone 12, here it is:

https://i.imgur.com/wfA1scT.png

They're indeed in Dolby Vision with the HLG profile, so BT2020nc HLG HDR 4:2:0 10bit planar in H.265.
Too bad for the VFR stuff which mobiles seem to love and everyone else in the world hates... (especially us, working in broadcast!)
I'm not in the edit room in which I have an HDR monitor and scope, so I can't tell you exactly how many nits there actually are, but Apple claims to reach 699 nits...
I think they're way too many for such a tiny sensor. From a very quick analysis, it looks like it's more or less 300 nits, which, for a mobile phone, looks quite alright.


For the records: this is from a colleague of mine who bought it, I actually went for a Google Pixel 5 in early November.

[quietvoid]

Updated my scenecut-aware-qp patch, now applies directly on Release 3.5 @ 5239276

[LigH]

Because the Yuuki mod appears to be well maintained, I tried to download and build this one alternatively in an interactive shell in MABS. Unfortunately, in contrast to the original x265 git, this modified fork apparently needs Ruby. A compatible version was found in the MSYS2 installation of MABS (2.7.0; minimum required is 1.8.0); but several include directories were missing, so cmake halted. I guess I could make it work if I knew where to include which shell variable exports?

[MeteorRain]

>tree /f D:\dev\x265-Yuuki-Asuna\include
D:\DEV\X265-YUUKI-ASUNA\INCLUDE
│ lsmash.h
│
├─avisynth
│ │ avisynth.h
│ │ avisynth_c.h
│ │
│ └─avs
│ alignment.h
│ capi.h
│ config.h
│ cpuid.h
│ minmax.h
│ posix.h
│ types.h
│ win.h
│
└─vapoursynth
VapourSynth.h
VSHelper.h
VSScript.h

You'll need those to support avs/vpy/lsmash. ffmpeg input on msvc wasn't tested.

For msvc multi lib build you need to

-DLSMASH_SOURCE_DIR=../../x265-Yuuki-Asuna/include -DEXTRA_LINK_FLAGS="/LIBPATH:../../../x265-Yuuki-Asuna/lib-msvc /LIBPATH:.."

something like that.

For gcc you just compile and make install dependencies into system directories. That includes ffmpeg, avisynth (header only), vapoursynth(header only), lsmash.

Ruby script was to compose version number, so it's not absolute necessary and can be replaced by you own code to produce your own version number. I use Ruby because I'm a Ruby developer.

It may not be easy to use yuuki mod in mabs due to extra libraries being linked.

[LigH]

One hurdle after another ... the first one looked rather low to me, as a layman:

-- Could NOT find Ruby (missing: Ruby_INCLUDE_DIR Ruby_LIBRARY Ruby_CONFIG_INCLUDE_DIR) (found suitable version "2.7.2", minimum required is "1.8.0")

If that is all cmake complains about, I guess it can be solved. Then we will see further from there.

[MeteorRain]

Says found suitable version, so I guess it's just fine? I have the mingw-w64-x86_64-ruby package installed from pacman, and it works.

[LigH]

Well, the Ruby package as such is installed, but it misses configured environment variables. Therefore cmake halts.

[MeteorRain]

That's weird. I'm getting a similar error but cmake did generate all the project files without any problem.
-- Found Nasm 2.15.05 to build assembly primitives
-- Could NOT find Ruby (missing: Ruby_LIBRARY) (found suitable version "2.7.1", minimum required is "1.8.0")
-- x265 version 3.4+13-g729a838d3+38

[LigH]

So maybe the reason is somewhere else, like the cmake command line may need more explicit parameters than the vanilla x265 multilib configuration.

...
-- Found nasm: E:/MABS/msys64/mingw64/bin/nasm.exe (found version "2.15.05")
-- Found Nasm 2.15.05 to build assembly primitives
CMake Deprecation Warning at dynamicHDR10/CMakeLists.txt:13 (cmake_minimum_required):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.

Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.


-- Found Git: E:/MABS/msys64/usr/bin/git.exe (found version "2.30.0")
-- Could NOT find Ruby (missing: Ruby_INCLUDE_DIR Ruby_LIBRARY Ruby_CONFIG_INCLUDE_DIR) (found suitable version "2.7.2", minimum required is "1.8.0")
-- x265 Release Version
-- The ASM_NASM compiler identification is NASM
-- Found assembler: E:/MABS/msys64/mingw64/bin/nasm.exe
-- Looking for strtok_r
-- Looking for strtok_r - found
CMake Error at CMakeLists.txt:637 (list):
list GET given empty list


CMake Error at CMakeLists.txt:638 (list):
list GET given empty list


-- Configuring incomplete, errors occurred!
See also "E:/MABS/x265-Yuuki-Asuna-Yuuki/build/msys64_hdr10_ml/12bit/CMakeFiles/CMakeOutput.log".
See also "E:/MABS/x265-Yuuki-Asuna-Yuuki/build/msys64_hdr10_ml/12bit/CMakeFiles/CMakeError.log".
make: *** No targets specified and no makefile found. Stop.
cp: cannot stat 'libx265.a': No such file or directory
make: *** No rule to make target 'clean-generated'. Stop.

Shall we discuss this elsewhere? A new thread here? An issue in your github repo?

[MeteorRain]

Please open an issue ticket.

EDIT:

Actually, I think you are on the wrong branch. Please switch to Asuna branch to test. Yuuki branch is not ready yet because 3.5 is not ready yet. As soon as 3.5 is tagged I'm going to revise the version generation code, which should solve the issue you are seeing.

[LigH]

:thanks:

The Asuna branch passed.

PS: OK, adding a few parameters of the modification may break the attempt, e.g. L-SMASH headers need to be found if I want to enable MP4 output...

Seems I could create a build with AVS and VPY input and MKV output, yet without LAVF input and without MP4 output. And with unknown version. To be tested...

Works with AviSynth input and MKV output.

[MeteorRain]

FYI: MKV output is not supported and is provided as best effort because one of my friends actively uses it. I was thinking maybe I should add a warning message saying it's unsupported.

If possible, please try to integrate l-smash using the flags above (post #7944).

[LigH]

Your repo does not provide an include directory, so I tried to configure the cmake flags to use the liblsmash git directory which is retrieved by MABS when building all its projects, up to ffmpeg:

-DENABLE_LSMASH=ON -DLSMASH_SOURCE_DIR=/build/liblsmash-git/

Configuring finished, make started ... all these NASM warnings are a PITA ... hmm, no. Obviously I have no clue how to point to the lsmash.h file so that it is found:

In file included from F:/MABS/x265-Yuuki-Asuna-Asuna/source/output/output.cpp:44:
F:/MABS/x265-Yuuki-Asuna-Asuna/source/output/mp4.h:8:10: fatal error: lsmash.h: No such file or directory
8 | #include <lsmash.h>
| ^~~~~~~~~~
compilation terminated.

Maybe due to:

CMake Warning:
Manually-specified variables were not used by the project:

LSMASH_SOURCE_DIR

Trying again with additional -DSPECIFY_LSMASH_SOURCE_DIR=ON

Next hurdle: I guess MABS used liblsmash somewhere but did not make and install it separately, so it is not a registered package.

F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -llsmash

Ran make install-lib and trying again without explicitly specifying lsmash directory...

Meh. Did not help. Without explicit source dir it doesn't find the header, with it it can't link the library. "It's complicated"...

[MeteorRain]

Ooooh you are using GCC.

>make install-lib
install -d /mingw64/include
install -m 644 ./lsmash.h /mingw64/include
install -d /mingw64/lib/pkgconfig
install -m 644 liblsmash.pc /mingw64/lib/pkgconfig
install -m 644 liblsmash.a /mingw64/lib

You should be able to find those 3 files in the corresponding directories, and GCC should automatically find them. Can you confirm they are there?

Try this and see if pkg-config gets you the command line.

pkg-config --libs liblsmash

[LigH]

Yes, the media-autobuild suite is based on MSYS2, MinGW, and usually GCC (could use clang if configured). And I even run the interactive shell instead of patching the automated build scripts. So I mostly profit from MABS keeping MSYS2/MinGW and GCC and all projects linked into ffmpeg up-to-date, before sometimes also experimenting interactively.

Using ./configure without extra parameters, it gets installed into /usr/local ... I guess I should add a parameter to change the prefix, because MABS uses /local64 (or /local32) as target directories.

OK, MABS requires e.g. ./configure --prefix="/local64" to install the header and library where the packages are expected. Compilation seems to be successful.

[LigH]

Last missing puzzle piece: Linking issues with libav libraries ... but ffmpeg had been built before and has been found by the compiler. So the reason must be in a different magnitude.

[ 96%] Linking CXX executable x265.exe
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x11): undefined reference to `avcodec_free_context'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x1a): undefined reference to `avformat_close_input'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x19d): undefined reference to `av_init_packet'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x1c0): undefined reference to `avcodec_receive_frame'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x1d8): undefined reference to `av_read_frame'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x1f4): undefined reference to `av_packet_unref'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x204): undefined reference to `av_init_packet'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x226): undefined reference to `avcodec_send_packet'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x23d): undefined reference to `avcodec_receive_frame'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x2a4): undefined reference to `av_packet_unref'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x2b8): undefined reference to `av_packet_unref'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x4aa): undefined reference to `avcodec_find_decoder'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x4ba): undefined reference to `avcodec_alloc_context3'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x4d3): undefined reference to `avcodec_parameters_to_context'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x4e7): undefined reference to `avcodec_open2'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x5ad): undefined reference to `av_packet_unref'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x60c): undefined reference to `av_frame_alloc'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x62e): undefined reference to `avformat_open_input'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x64b): undefined reference to `avformat_find_stream_info'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x6c9): undefined reference to `avcodec_find_decoder'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x6d8): undefined reference to `avcodec_alloc_context3'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x6f4): undefined reference to `avcodec_parameters_to_context'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x707): undefined reference to `avcodec_open2'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x72c): undefined reference to `av_dict_set'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x73f): undefined reference to `avcodec_open2'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x761): undefined reference to `av_dict_free'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x82b): undefined reference to `av_pix_fmt_desc_get'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x2c): undefined reference to `av_frame_free'
collect2.exe: error: ld returned 1 exit status

[MeteorRain]

I have no idea about that. Maybe check if the lib files are correctly found by gcc.
The error message looks like it didn't find the lib and thus missed the reference to its functions.

[DJATOM]

Undefined reference usually means that symbol is not reachable. For example, there is no library with such names supplied to the linker. Check generated build files if all needed ffmpeg libs are actually provided for linking.

[LigH]

Which are these "build files"?

[LoRd_MuldeR]

Which are these "build files"?

If a C/C++ application depends on library 'XYZ', the you will need to do two things:
At compile-time, you need to ensure that the required header files (usually .h or .hpp) for library XYZ are present in one of the directories that the compiler scans for header files.
Additional search directories for header files can be specified by adding the -I option to the CFLAGS.

At link-time, you need to ensure that library XYZ is actually linked to your binary. This is done by adding the -l option your LDFLAGS.
Note that -l automatically adds the "lib..." prefix as well as the file extension. So, in order to link against libXYZ.a, you just need to write -lXYZ.

Furthermore, you have to make sure that the library file (usually .a) is present in one of the directories that the linker scans for library files.
Additional search directories for library files can be specified by adding the -L option to the LDLAGS.

Of course you will need to build library 'XYZ' before you build your "main" application, because otherwise the required library file libXYZ.a (the "build file") has not been created yet :)

Undefined reference usually means that symbol is not reachable. For example, there is no library with such names supplied to the linker.

Yes, "undefined reference" could mean that a required library was not linked at all. Could also mean that you are linking a "wrong" version of the library which doesn't match to the header files that were used.

(If you try to link against a library, but the linker couldn't find the requested library file, it would be a different error message)

Another "fun" thing needs to be considered: Libraries can be compiled as either a "static" library (.a) or a "shared" library (.dll). Specifically on Windows, the actual symbol names differ between the "static" and "shared" libraries! Usually the header files support both variants, via #ifdef's, but default often is the "shared" variant. So, a special #define needs to be set, at compile-time, if you intend to link against the "static" library. Could also be the other way around tough :D

[DJATOM]

Which are these "build files"?

If you're using mingw (as I am), they are in the generated build folder. For example, CMakeFiles\cli.dir\linklibs.rsp. If you generated msvc project, it's somewhere in the linker options.

[LigH]

The only *.rsp files I see are objects1.rsp in 8bit/CMakeFiles/x265-shared.dir (I'm trying to make a multi-lib static build). It contains only obj files created by the basic x265 compilation.

With -DENABLE_AVISYNTH=ON in the cmake configuration, the x265.exe contains avs_ symbols; AviSynth+ headers are present in local includes.
With -DENABLE_VPYSYNTH=ON in the cmake configuration, the x265.exe contains vsscript_ symbols; libvapoursynth.a + vapoursynth[-script].pc are present in local libs[/pkgconfig].
With -DENABLE_LSMASH=ON in the cmake configuration, the x265.exe contains LSMASH_ symbols and even a version number (printed in the version console output); liblsmash{a|pc} are present in local libs[/pkgconfig].
With -DENABLE_ZIMG=ON in the cmake configuration, the x265.exe contains zimg5graph12_ symbols; libzimg.a + zimg.pc are present in local libs[/pkgconfig].

All that works without any other *.rsp files.

{libavcodec|libavdevice|libavfilter|libavformat|libavif|libavutil}.{a|pc} are present in local libs[/pkgconfig]. Apparently, with -DENABLE_LAVF=ON in the cmake configuration, cmake detects them (or would error out otherwise), so I assume ld can find them like all the other libraries (especially like lsmash and zlib). Headers and libraries should match because MABS compiled a whole ffmpeg the other day, before I tried to build x265_Asuna afterwards. Therefore I agree with:
(If you try to link against a library, but the linker couldn't find the requested library file, it would be a different error message)

The only doubt I have left: a "light" version of ffmpeg is also a part of other tools, like x264 and cyanrip; but I would like to trust in MABS not to install these system-wide and use them only in the related projects. But even if, it should only limit the selection of codecs, not make basic APIs (like e.g. avformat_close_input) completely unavailable... I guess. :o

PS: x265cli.cpp.obj and objects.a contain libav* version string format templates; lavf.cpp.obj and objects.a contain avformat_close_input. Does the command line need more extra parameters that ff libs can be linked correctly?

[qyot27]

https://github.com/msg7086/x265-Yuuki-Asuna/blob/Yuuki/source/CMakeLists.txt#L770
and
https://cmake.org/cmake/help/latest/variable/CMAKE_PREFIX_PATH.html, if necessary

[LigH]

@qyot27:

ENABLE_STATIC_LAVF should be enabled by default (if LAVF and CLI are enabled), if I read that first location correctly; I already found this option, still tried to enable it explicitly in the cmake command line parameters (-DENABLE_STATIC_LAVF=ON), but it did not help as such...

VapourSynth, LSMASH and ZIMG packages are found without CMAKE_PREFIX_PATH, and I believe libav libraries (via the "FF" package) are found too; just linking them fails for a different reason. As if they are found but not used, maybe...

[PoeBear]

What CLI option(s) should I be tweaking to help stop chroma bleed? It seems that no matter how low I go with CRF, my reds will still bleed out into neighboring areas

My options are roughly a mix of veryslow and placebo, with some other options thrown in. Here's one from a recent 1080p/HDR test:
avs2yuv.exe "Test.avs" - | "x265.exe" -D 10 --crf 14 --profile main10 --level-idc 5.1 --high-tier --preset placebo --input-depth 16 --cu-lossless --pmode --bframes 16 --qg-size 32 --frame-threads 4 --ref 6 --limit-refs 1 --merange 57 --no-amp --tskip --tskip-fast --limit-modes --no-open-gop --hrd --cbqpoffs -0 --crqpoffs -1 --no-cutree --deblock -2:-2 --psy-rd 2.50 --psy-rdoq 1.00 --qcomp .6 --aq-mode 2 --aq-strength 1.0 --ipratio 1.3 --pbratio 1.2 --vbv-bufsize 160000 --vbv-maxrate 160000 --aud --hdr10 --hdr10-opt --range limited --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50) --max-cll 602,187 --chromaloc 2 --repeat-headers --output "C:\Temp\Test.hevc" --frames 5000 --y4m -

I've tried a few numerous tweaks: amp, no-amp, pmode, no-pmode, pme, no-pme, hme instead of merange, dropping cbqpoffs/crqpoffs a bit further. All which really only affect very minor detail retention, likely due to such low CRF, but I still get color bleeds

I know my settings are a bit absurd, I'm getting around 1.2FPS on a 3900X with around 60% load, but my goal is transparency mostly, with a tiny hint of keeping speeds above 1FPS

Side question: Is there anyway to increase load usage with command line x265 without affecting PQ? Ie without using something like RipBot's distributed encoding

[FranceBB]

Chroma bleeding is actually really weird, it shouldn't really happen and I think I know why it's happening to you!
Your input is an AVS Script from what I see, which handles 4:2:0 Type 1 but not 4:2:0 Type2!
So, the chroma location is wrong, hence the "bleeding".

Can you try with:

ffmpeg.exe -i "AVS Script.avs" -vf scale=out_color_matrix=bt2020nc:out_h_chr_pos=0:out_v_chr_pos=0 -pix_fmt yuv420p16le -strict -1 -an -f yuv4mpegpipe - | x265.exe --y4m - --dither

followed by the rest of your x265 command line? This should solve the chroma bleeding problem. ;)