x265 HEVC Encoder

For some unknown reason Patman is still releasing builds that don't work...

x265-3.6+85+1-b5cacb584-[Mod-by-Patman]

How to contact him ???

[Kurt.noise]

Originally Posted by jpsdr

It seems i have to give up trying another gcc or clang, no one seems to know how to make a build in these cases using CMake with the script i've put on #9395.

I'm using the following script on my machine within msvc & clang tools :

cmake --fresh -B my_own_build -T ClangCL -DENABLE_SHARED=OFF -DHIGH_BIT_DEPTH=ON -DCMAKE_CXX_FLAGS_RELEASE="-flto /O2 /Ob2 /DNDEBUG -march=native" -DCMAKE_C_FLAGS_RELEASE="-flto /O2 /Ob2 /DNDEBUG -march=native" && cmake --build my_own_build --config Release --parallel

only on x64 plateform tough. That works correctly.

Originally Posted by FTLOY

For some unknown reason Patman is still releasing builds that don't work...

x265-3.6+85+1-b5cacb584-[Mod-by-Patman]

How to contact him ???

what did you dont understand what we said previously ? Stay with the last one which works for you. You wont notice any difference using the last builds. *sigh*

Originally Posted by Kurt.noise

what did you dont understand what we said previously ? Stay with the last one which works for you. You wont notice any difference using the last builds. *sigh*

I understood perfectly, "Kurt.noise" !!!

I was just simply stating that Patman is wasting his time, releasing new builds, until this is fixed.

And FYI, I think you will find I was the one that bought the x265 issues to ppl's attention.

[rwill]

Originally Posted by jpsdr

I'm trying to build under msys2 with clang. It "works", meaning it links an exe, but when i run it it's complaining abour missing dll.
Here the script i'm using:

...

I think it's missing to the linker to links some libraries, but i have no idea what command i should add, and where (only in the last or on all 3).

Well just FYI, if it links an .exe then all Symbols have been accounted for by the linker. Most likely by means of an .lib import library. If the .exe complains that a .dll cannot be found then the .dll has to be copied to somewhere in the PATH, or next to the .exe, so Windows can find it for the .exe.

Maybe one of the dependencies you link into x265 is missing its .dll dependency. Have you tried building with -DENABLE_LIBVMAF=OFF -DENABLE_VAPOURSYNTH=OFF -DENABLE_AVISYNTH=OFF ? Which libraries do these dependencies pull in? Have you checked in the shell with "ldd x265.exe" and then checked or "ldd whatever_libvmaf_is.dll" (if libvmaf is a .dll) ? There used to be this nifty tool "Dependency Walker" ( "Depends" ) to Debug '.dll Hell' on Windows but I do not know if it is still supported by the modern Windowses.

[Jamaika]

export CPPFLAGS="-D_FORTIFY_SOURCE=2 -D__USE_MINGW_ANSI_STDIO=1"
export CFLAGS="-fstack-protector-strong -mtune=generic -O2 -pipe -mthreads"
export CXXFLAGS="-fstack-protector-strong -mthreads -mtune=generic -O2 -pipe"
export LDFLAGS="-pipe -static-libgcc -fstack-protector-strong -static-libstdc++"

cd /build/x265_git-git/build/msys64_hdr10_ml/
mkdir -p 8bit 10bit 12bit

cd 12bit
make --no-print-directory clean-generated
cmake -G "MSYS Makefiles" ../../../source -DHG_EXECUTABLE=/usr/bin/hg.bat -DCMAKE_CXX_COMPILER=/local64/bin/g++.bat -DCMAKE_TOOLCHAIN_FILE=/local64/etc/toolchain.cmake -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DHIGH_BIT_DEPTH=ON -DMAIN12=ON -DENABLE_HDR10_PLUS=ON -DENABLE_LIBVMAF=ON -DENABLE_ALPHA=ON -DENABLE_MULTIVIEW=ON -DENABLE_SCC_EXT=ON
make --no-print-directory ${MAKEFLAGS}
cp libx265.a ../8bit/libx265_main12.a

cd ../10bit
make --no-print-directory clean-generated
cmake -G "MSYS Makefiles" ../../../source -DHG_EXECUTABLE=/usr/bin/hg.bat -DCMAKE_CXX_COMPILER=/local64/bin/g++.bat -DCMAKE_TOOLCHAIN_FILE=/local64/etc/toolchain.cmake -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DHIGH_BIT_DEPTH=ON -DMAIN12=OFF -DENABLE_HDR10_PLUS=ON -DENABLE_LIBVMAF=ON -DENABLE_ALPHA=ON -DENABLE_MULTIVIEW=ON -DENABLE_SCC_EXT=ON
make --no-print-directory ${MAKEFLAGS}
cp libx265.a ../8bit/libx265_main10.a

cd ../8bit
make --no-print-directory clean-generated
cmake -G "MSYS Makefiles" ../../../source -DHG_EXECUTABLE=/usr/bin/hg.bat -DCMAKE_CXX_COMPILER=/local64/bin/g++.bat -DCMAKE_TOOLCHAIN_FILE=/local64/etc/toolchain.cmake -DEXPORT_C_API=ON -DENABLE_SHARED=ON -DENABLE_CLI=ON -DHIGH_BIT_DEPTH=OFF -DENABLE_HDR10_PLUS=ON -DENABLE_LIBVMAF=ON -DENABLE_ALPHA=ON -DENABLE_MULTIVIEW=ON -DENABLE_SCC_EXT=ON -DEXTRA_LIB="x265_main10.a;x265_main12.a" -DEXTRA_LINK_FLAGS=-L. -DLINKED_10BIT=ON -DLINKED_12BIT=ON
make --no-print-directory ${MAKEFLAGS}

Why is ENABLE_SHARED ON for 8bit?

pipe?
The pipe function is declared in the header file unistd.h.
#if NO_ATOMICS

#include <sys/time.h>
#include <unistd.h>
I don't use NO_ATOMICS in x265.

# Work around longjmp interception on glibc >= 2.11, to improve binary
# compatibility. See http://code.google.com/p/webm/issues/detail?id=166
enabled linux && check_add_cflags -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0

I don't use -D_FORTIFY_SOURCE=2 -fstack-protector-strong for ffmpeg in static.

[Selur]

About the not stopping pipe input I reported, I got a reply:

We are able to reproduce it.
We are working on it, will update you once it’s fixed.

=> so there is hope, this will be fixed in a not too distant future.

Cu Selur

[john33]

Originally Posted by qyot27

Just delete the .dll.a files (or non-destructively rename them to something like .dll.a.bak). That should force it to use the static ones in lieu of flags not working.

This exactly what m_ab-s does, it renames them to .dll.a.dyn. I've done the same in MSYS2 and it works as expected.

[jpsdr]

You means, i should rename libstdc++.dll.a to libstdc++.dll.a.bak for exemple ? Just this one or more ?

Otherwise, it seems export LDFLAGS="" is doing the same thing than -DCMAKE_EXE_LINKER_FLAGS="".
They both have an effect, because if i change "-static-libgcc -static-libstdc++ -static" with "-static-libgcc -static-libstdc++" i have an error message about another dll file missing using both methods, meaning :
- "static" is necessary
- -DCMAKE_EXE_LINKER_FLAGS="" seems to work, but the link is still missing something.
I'll try the rename tips.

@Selur
When i've finished my builds, maybe you can test if the little modification i've made fix something (very unlikely, but who knows...).

[qyot27]

libc++.dll.a and libunwind.dll.a need to be changed to libc++.dll.a.bak, libunwind.dll.a.bak (or .dyn, if as mentioned above concerning what m-ab-s does; the actual suffix doesn't matter). Then you don't need to pass any flags like -static-libstdc++. And yes, LDFLAGS and CMAKE_EXE_LINKER_FLAGS should be mostly comparable, although I hit the same issue with libc++ and libunwind when building AviSynth+ with llvm-mingw for testing on ARM, and it didn't matter whether I tried using LDFLAGS or CMAKE_SHARED_LIBRARY_FLAGS (since AviSynth+ is a library, not an application); CMake still added them back in and would not use the static versions.

I never resorted to hiding/deleting the .dll.a import libraries, and just copied the relevant .dlls into the test directory alongside AviSynth.dll, but the concept is the same: you need -static if you have both .a and .dll.a versions of a library, because the linker will just prefer the shared version. But if there's ever a problem with how the linker decides whether or not to use the shared or static version of a library, just hide the shared version if you want to link against the static one.

[LigH]

Originally Posted by Selur

About the not stopping pipe input I reported, ...

Oh, bugs should be reported to an issue tracker now? The mailing list is not the primary contact anymore...

[jpsdr]

First, i made a new build.
Those who have specific issue, test, just in case, even if unlikely.

Now, with my tests to build with the gcc version provided with msys2, i'm loosing my head...
If i do this:

mkdir -p 8bit_Win32_x64_noasm

cd 8bit_Win32_x64_noasm
/G/CMakex64/bin/cmake -G "MSYS Makefiles" ../../../source -DENABLE_LIBVMAF=ON -DENABLE_SCC_EXT=ON -DENABLE_MULTIVIEW=ON -DENABLE_ALPHA=ON -DENABLE_ASSEMBLY=OFF -DENABLE_VAPOURSYNTH=ON -DENABLE_AVISYNTH=ON -DHIGH_BIT_DEPTH=OFF -DENABLE_HDR10_PLUS=OFF -DEXPORT_C_API=ON -DENABLE_SHARED=OFF -DENABLE_CLI=ON -DMAIN12=OFF -DSTATIC_LINK_CRT=ON -DENABLE_LTO=ON -DCMAKE_CXX_FLAGS_RELEASE="-fversion-loops-for-strides -funswitch-loops -fsplit-loops -ffinite-math-only -ftree-vectorize -fivopts -ftree-loop-ivcanon -ftree-loop-if-convert -floop-parallelize-all -floop-nest-optimize -fgcse-las -fgcse-sm -fmodulo-sched-allow-regmoves -fmodulo-sched -fipa-pta -Ofast -ffast-math -fomit-frame-pointer"  -DCMAKE_EXE_LINKER_FLAGS="-static-libgcc -static-libstdc++ -static"
make ${MAKEFLAGS}

or this:

mkdir -p 8bit_Win32_x64

cd 8bit_Win32_x64
/G/CMakex64/bin/cmake -G "MSYS Makefiles" ../../../source -DENABLE_LIBVMAF=ON -DENABLE_SCC_EXT=ON -DENABLE_MULTIVIEW=ON -DENABLE_ALPHA=ON -DENABLE_ASSEMBLY=ON -DENABLE_VAPOURSYNTH=ON -DENABLE_AVISYNTH=ON -DHIGH_BIT_DEPTH=OFF -DENABLE_HDR10_PLUS=OFF -DEXPORT_C_API=ON -DENABLE_SHARED=OFF -DENABLE_CLI=ON -DMAIN12=OFF -DSTATIC_LINK_CRT=ON -DENABLE_LTO=ON -DCMAKE_CXX_FLAGS_RELEASE="-fversion-loops-for-strides -funswitch-loops -fsplit-loops -ffinite-math-only -ftree-vectorize -fivopts -ftree-loop-ivcanon -ftree-loop-if-convert -floop-parallelize-all -floop-nest-optimize -fgcse-las -fgcse-sm -fmodulo-sched-allow-regmoves -fmodulo-sched -fipa-pta -Ofast -ffast-math -fomit-frame-pointer"  -DCMAKE_EXE_LINKER_FLAGS="-static-libgcc -static-libstdc++ -static"
make ${MAKEFLAGS}

the x265.exe can be run.
But this one:

mkdir -p 8bit_Win32 10bit_Win32 12bit_Win32

cd 12bit_Win32
/G/CMakex64/bin/cmake -G "MSYS Makefiles" ../../../source -DENABLE_LIBVMAF=ON -DENABLE_SCC_EXT=ON -DENABLE_MULTIVIEW=ON -DENABLE_ALPHA=ON -DENABLE_VAPOURSYNTH=ON -DENABLE_AVISYNTH=ON -DHIGH_BIT_DEPTH=ON -DENABLE_HDR10_PLUS=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DMAIN12=ON -DSTATIC_LINK_CRT=ON -DENABLE_LTO=ON -DCMAKE_CXX_FLAGS_RELEASE="-fversion-loops-for-strides -funswitch-loops -fsplit-loops -ffinite-math-only -ftree-vectorize -fivopts -ftree-loop-ivcanon -ftree-loop-if-convert -floop-parallelize-all -floop-nest-optimize -fgcse-las -fgcse-sm -fmodulo-sched-allow-regmoves -fmodulo-sched -fipa-pta -Ofast -ffast-math -fomit-frame-pointer"
make ${MAKEFLAGS}
cp libx265.a ../8bit_Win32/libx265_main12.a

cd ../10bit_Win32
/G/CMakex64/bin/cmake -G "MSYS Makefiles" ../../../source -DENABLE_LIBVMAF=ON -DENABLE_SCC_EXT=ON -DENABLE_MULTIVIEW=ON -DENABLE_ALPHA=ON -DENABLE_VAPOURSYNTH=ON -DENABLE_AVISYNTH=ON -DHIGH_BIT_DEPTH=ON -DENABLE_HDR10_PLUS=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DMAIN12=OFF -DSTATIC_LINK_CRT=ON -DENABLE_LTO=ON -DCMAKE_CXX_FLAGS_RELEASE="-fversion-loops-for-strides -funswitch-loops -fsplit-loops -ffinite-math-only -ftree-vectorize -fivopts -ftree-loop-ivcanon -ftree-loop-if-convert -floop-parallelize-all -floop-nest-optimize -fgcse-las -fgcse-sm -fmodulo-sched-allow-regmoves -fmodulo-sched -fipa-pta -Ofast -ffast-math -fomit-frame-pointer"
make ${MAKEFLAGS}
cp libx265.a ../8bit_Win32/libx265_main10.a

cd ../8bit_Win32
/G/CMakex64/bin/cmake -G "MSYS Makefiles" ../../../source -DENABLE_LIBVMAF=ON -DENABLE_SCC_EXT=ON -DENABLE_MULTIVIEW=ON -DENABLE_ALPHA=ON -DENABLE_VAPOURSYNTH=ON -DENABLE_AVISYNTH=ON -DHIGH_BIT_DEPTH=OFF -DENABLE_HDR10_PLUS=OFF -DEXPORT_C_API=ON -DENABLE_SHARED=OFF -DENABLE_CLI=ON -DMAIN12=OFF -DSTATIC_LINK_CRT=ON -DENABLE_LTO=ON -DLINKED_10BIT=ON -DLINKED_12BIT=ON -DEXTRA_LIB="x265_main10.a;x265_main12.a" -DEXTRA_LINK_FLAGS=-L. -DCMAKE_CXX_FLAGS_RELEASE="-fversion-loops-for-strides -funswitch-loops -fsplit-loops -ffinite-math-only -ftree-vectorize -fivopts -ftree-loop-ivcanon -ftree-loop-if-convert -floop-parallelize-all -floop-nest-optimize -fgcse-las -fgcse-sm -fmodulo-sched-allow-regmoves -fmodulo-sched -fipa-pta -Ofast -ffast-math -fomit-frame-pointer" -DCMAKE_EXE_LINKER_FLAGS="-static-libgcc -static-libstdc++ -static"
make ${MAKEFLAGS}

# rename the 8bit library, then combine all three into libx265.a using GNU ar
mv libx265.a libx265_main.a

ar -M <<EOF
CREATE libx265.a
ADDLIB libx265_main.a
ADDLIB libx265_main10.a
ADDLIB libx265_main12.a
SAVE
END
EOF

i have the error message "can't find libstc++-6.dll".
So i renamed libstdc++.dll.a to libstdc++.dll.a.bak.
The error message changed to "can't find libwinpthread-1.dll".
So i renamed libwinpthread.dll.a to libwinpthread.dll.a.bak.
The error message was still the same. So either the gcc provided with msys2 which is a posix version can't build x265, either it's another dll i have to rename. It's late, i stop here for now.
There is no libunwind files in the gcc provided with msys2, but there is such files in the mcf gcc and in the clang with msys2.
I'll try with mcf gcc version tomorrow.

Originally Posted by jpsdr

First, i made a new build.
Those who have specific issue, test, just in case, even if unlikely.

I'll try with mcf gcc version tomorrow.

I thought I'd try your latest attempt (3.60.85)...

I'm still getting this:-

x265 [WARN]: extra unused command arguments given <->

[jpsdr]

This is now the new way, you need --input. I was thinking of the pipe issue.

Originally Posted by jpsdr

This is now the new way, you need --input. I was thinking of the pipe issue.

I've been told by several others that this --input is now the "new norm", but what I can't understand is if this can be added to the x265 command line, or does the app developer (for RipBot264, StaxRip, Hybrid and others) will have to modify the "behind the scenes" command's.

What does it need to "input" ??

Is there an example of what needs to be done, if it is a command line entry ??

Just did a Google, and it found this:-

https://github.com/staxrip/staxrip/issues/1457

So Dendraspis is onto it for StaxRip

[Boulder]

The external app developers have to modify their applications. All in all, it's always much safer to include the parameter names in command lines as things may change but parameter names very rarely (or at least they are kept for backward compatibility).

[LigH]

A patch for the Y4M pipe has just been mentioned in the mailinglist; waiting for commit...

[Selur]

or does the app developer (for RipBot264, StaxRip, Hybrid and others) will have to modify the "behind the scenes" command's.

Hybrid always used 'x265 --input - ' for pipe input, so nothing to adjust there.

A patch for the Y4M pipe has just been mentioned in the mailinglist; waiting for commit...

Nice!

Cu Selur

[jpsdr]

I've continued my build tests. Someone even suggest my to use "-Bstatic -l<lib> -l<lib> .. -Bdynamic", to force static link, but it didn't work.
Finaly, what worked was indeed to rename...
For build with mcf version, i renamed libstdc++ and libmcfgthread.
For build with clang just libc++.

[LigH]

New upload: x265 3.6+103-85f1e34+pipefix

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

No serious changes in intel x86[-64] code. Added the patch to fix Y4M pipe handling prior to its commit.

[rwill]

What I do not understand is that there is code like this for the 'input' arg:

OPT("input") inputfn[0] = optarg;

So when one specifies --input something then inputfn[0] gets set to that.

Then there is new code like this:

#if !ENABLE_MULTIVIEW
  if (optind < argc && !inputfn[0])
    inputfn[0] = argv[optind++];
#endif

So having the input filename as one of the last trailing args on the command line is now only supported for non ENABLE_MULTIVIEW builds. I find this kind of strange as from a functionality point of view '--input' and having it 'trailing' is of no difference?