x265 HEVC Encoder

[Kurt.noise]

FrameCount from MediaInfo (https://github.com/MediaArea/MediaInfoLib/blob/abdbb218b07f6cc0d4504c863ac5b42ecfab6fc6/Source/Resource/Text/Stream/Video.csv#L209) might help you to find out this requirement...

[Selur]

For file input sure, but for scripts it's more of a hassle.
In Hybrid I either would have to run the generated scripts through vspipe or avsInfo to get the frame count during job creation or add another job which would analyze the script and adjust later subjobs. :(
Thought about it, but atm. I'm going back to an older version and see whether they fix this for the next release or not.
Seems to be too much trouble atm.

Cu Selur

Ps.: created an issue entry https://bitbucket.org/multicoreware/x265_git/issues/947/cli-y4m-pipe-input-broken-doesnt-stop

[LigH]

In contrast to vspipe and a special version of avs2yuv, ffmpeg doesn't seem to support the Y4M tag "XLENGTH" (https://forum.doom9.org/showthread.php?p=2005576#post2005576) (probably because ffmpeg prefers working as a one-pass filter, avoiding seeks). On the other hand, x265 supports it only with a modification as well.

[Selur]

Haven't tried avs2yuv with y4m output, but when using vspipe (using Vapoursynth R68):
vspipe "J:\tmp\2024-08-26@17_02_59_5110\encodingTempSynthSkript_2024-08-26@17_02_59_5110_0.vpy" - -c y4m | x265 --input - --fps 25/1 --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 --no-mcstf --range limited --colormatrix bt470bg --sar 1:1 --output "J:\tmp\2024-08-26@17_02_59_5110\2024-08-26@17_02_59_5110_02.265"
it runs without end too,...

[LigH]

Only modded x265 recognise the number of frames in a Y4M header's XLENGTH tag without the use of a --frames CLI parameter.

[Selur]

Hmm,.. strange I did build x265 with MBAS as usual, didn't know they changed the way they build x265.

[LigH]

Selur, please read the thread Modifications of x265 (https://forum.doom9.org/showthread.php?p=2005576) where it is explained more verbosely.

[Selur]

I get the patch, but ..
Was this included in the mbas builds before?
I did have to clear my build folder, but I wasn't aware I ever added a patch to x265.
I mean, these calls worked before, so I'm a bit confused.
Did x265 change, did MABS change or have I been using somehow patched x265 builds without knowing it for years on Windows and Linux?

Cu Selur

[LigH]

No, neither of these patches was ever part of MABS. There is only one to split library paths in cmake.

If there are issues now with the recent x265 builds, then they may be caused by the additional features related to multiple inputs. So there should be no important reason to use x265 newer than v3.6+3x unless you want to support specifically these new features (Alpha, MVC).

But it would probably be important to mention that there are issues handling piped input since the last additions. Reproducable tests would help.

[Selur]

Okay, I'll stick to my old builds from end of May (version 3.6+28-4b272f7154) that one worked fine.

[LigH]

I just created a quick test sequence, comparing x265 3.6+[13|35|46|56|65]. Yes, [56|65] encode eternally.
FrameCountTest.avsColorBarsHD()
Info()
Trim(0,99)
I'll write a mail to the x265-devel mailing list.

[Selur]

Thanks for looking into it.

[Guest]

I just created a quick test sequence, comparing x265 3.6+[13|35|46|56|65]. Yes, [56|65] encode eternally.
FrameCountTest.avsColorBarsHD()
Info()
Trim(0,99)
I'll write a mail to the x265-devel mailing list.

I'm not too sure if this is what I commented on about x265 a week or so ago, that it had some different instructions that don't work anymore with RipBot264 and StaxRip...and now even Hybrid.

Something needs to be done, or we'll have to keep using old builds.

[LigH]

For now ... yes, keep using old builds. New features are either not urgently needed by most casual users or don't belong to the most commonly used high-performance platform for the casual user, the intel PC.

[jpsdr]

When i'm building with clang, even trying several options supposed to fix the issue, i'm having the error message of libc++.dll missing.
I've tried to use another gcc than the Win32 version, and same thing, even trying several options supposed to fix the issue, i'm having the error message of libstdc++6.dll missing.

I'm begining to think that maybe i'm not using the proper option.
I'm adding the following in the cmake line (for gcc), but is it correct ?

-DCMAKE_EXE_LINKER_FLAGS="-static-libgcc -static-libstdc++ -static"

Or is it another command i have to put in the cmake line to add the options "-static-libgcc -static-libstdc++ -static" in the compiler ?

[Jamaika]

For gcc options 'static-libgcc', 'static-libstdc++', 'static' doesn't affect object files.
The dllexport function decides whether the object file function is static or not. The final shared function decides about creation of the .dll file.
For static the default is static-libgcc static-libstdc++.

Object files in mingw are affected by ar.exe. This is removal of dead functions. Unfortunately there is no information about what program cuts out if we use it. For example we did not add define XXX so ar.exe deleted unnecessary functions.
Without static function the -L. libraries aren't static.

[jpsdr]

So, for those building x265 without using gcc provided at http://msystem.waw.pl/x265/ what is your script ? Your cmake command line ?

[Jamaika]

The page http://msystem.waw.pl/x265/ has an old toolchain for Windows I don't use cmake, but for me it should be only static. You can do tests yourself to see if the final exe files differ.
I use https://github.com/brechtsanders/winlibs_mingw/releases/tag/11.5.0posix-12.0.0-msvcrt-r1 https://github.com/brechtsanders/winlibs_mingw/releases/download/11.5.0posix-12.0.0-msvcrt-r1/winlibs-x86_64-posix-seh-gcc-11.5.0-mingw-w64msvcrt-12.0.0-r1.zip Is there a problem with compiling the x265 library?
https://bitbucket.org/multicoreware/x265_git/commits/branch/master They depend on whether we expose all warming messages. For clang there may be slightly different functions.
I added Wall Wextra warming and got it for gcc.
threading.h:285:41: warning: comparison of integer expressions of different signedness: 'int32_t' {aka 'int'} and 'DWOR ' {aka 'long unsigned int'} [-Wsign-compare]
285 | return rt != WAIT_TIMEOUT && rt != WAIT_FAILED;
| ^

Lots of bugs in VMAF.

cudata.cpp:2131:7: warning: extra tokens at end of #endif directive [-Wendif-labels]
2131 | #endif;
| ^
cudata.h: In member function 'bool x265::CUData::setQPSubCUs(int8_t, uint32_t, uint32_t)':
cudata.h:272:112: warning: array subscript 5 is above array bounds of 'void (* [5])(uint8_t*, uint8_t)' {aka 'void (* [5])(unsigned char*, unsigned char)'} [-Warray-bounds]
272 | void setQPSubParts(int8_t qp, uint32_t absPartIdx, uint32_t depth) { s_partSet[depth ((uint8_t*)m_qp + absPartIdx, (uint8_t)qp); }
| ~~~~~~~~~~~~~~~
In file included from framedata.h:29,
from cudata.cpp:27:
cudata.h:177:15: note: while referencing 'x265::CUData::s_partSet'
177 | cubcast_t s_partSet[NUM_FULL_DEPTH]; // pointer to broadcast set functions per absolute depth
| ^~~~~~~~~
dpb.cpp: In member function 'void x265::DPB::computeRPS(int, int, bool, x265::RPS*, unsigned int, int)':
dpb.cpp:414:75: warning: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Wsign-compare]
414 | if (iterPic->m_param->numViews > 1 && layer && numNeg == iterPic->m_param->maxNumReferences - 1 && (iterPic->m_poc - curPoc) < 0)
| ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
encoder.cpp: In member function 'int x265::Encoder::encode(const x265_picture*, x265_picture**)':
encoder.cpp:2452:29: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
2452 | case 3: if (!IS_REFERENCED(frameEnc[layer]))
| ^~
encoder.cpp:2454:25: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
2454 | break;
| ^~~~~
lowpassdct.cpp: In function 'void lowPassDct8_c(const int16_t*, int16_t*, intptr_t)':
lowpassdct.cpp:61:23: warning: right shift count is negative [-Wshift-count-negative]
61 | dst[0] = totalSum >> (-1 + (X265_DEPTH - 8));
| ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
----------------------------------------------------------------------------------------------------------------
bool take(const uint32_t time_out = INFINITE)
{
DWORD rt = WaitForSingleObject(m_sem, time_out);
return rt != WAIT_TIMEOUT && rt != WAIT_FAILED;
}
----------------------------------------------------------------------------------------------------------------
#if ENABLE_MULTIVIEW
if (iterPic->m_param->numViews > 1 && layer && numNeg == (unsigned int)iterPic->m_param->maxNumReferences - 1 && (iterPic->m_poc - curPoc) < 0)
{
iterPic = iterPic->m_next;
continue;
}
#endif
----------------------------------------------------------------------------------------------------------------
// replace first coef with total block average
dst[0] = totalSum >> (1 + (X265_DEPTH - 8));

frameencoder.cpp: In member function 'void x265::FrameEncoder::vmafFrameLevelScore()':
frameencoder.cpp:2311:29: error: request for member 'm_fencPic' in '*(x265::Frame**)(&((x265::FrameEncoder*)this)->x265::FrameEncoder::m_frame)', which is of pointer type 'x265::Frame*' (maybe you meant to use '->' ?)
2311 | PicYuv *fenc = m_frame->m_fencPic;
| ^~~~~~~~~
frameencoder.cpp:2312:30: error: request for member 'm_reconPic' in '*(x265::Frame**)(&((x265::FrameEncoder*)this)->x265::FrameEncoder::m_frame)', which is of pointer type 'x265::Frame*' (maybe you meant to use '->' ?)
2312 | PicYuv *recon = m_frame->m_reconPic[0];
| ^~~~~~~~~~
----------------------------------------------------------------------------------------------------------------
#if ENABLE_LIBVMAF
if (m_param->bEnableVmaf == 1)
vmafFrameLevelScore();
#endif
----------------------------------------------------------------------------------------------------------------
#if ENABLE_LIBVMAF
void FrameEncoder::vmafFrameLevelScore()
{
for (int layer = 0; layer < MAX_LAYERS; layer++) {
PicYuv *fenc = m_frame[layer]->m_fencPic;
PicYuv *recon = m_frame[layer]->m_reconPic[0];

x265_vmaf_framedata *vmafframedata = (x265_vmaf_framedata*)x265_malloc(sizeof(x265_vmaf_framedata));
if (!vmafframedata)
{
x265_log(NULL, X265_LOG_ERROR, "vmaf frame data alloc failed\n");
}

vmafframedata->height = fenc->m_picHeight;
vmafframedata->width = fenc->m_picWidth;
vmafframedata->frame_set = 0;
vmafframedata->internalBitDepth = m_param->internalBitDepth;
vmafframedata->reference_frame = fenc;
vmafframedata->distorted_frame = recon;

fenc->m_vmafScore = x265_calculate_vmaf_framelevelscore(vmafframedata);

if (vmafframedata)
x265_free(vmafframedata);
}
}
#endif

[Guest]

So how come x265 has gone to sh*t in the last couple of weeks ??

"Someone" has stuffed it up trying something new, and it's not working.

I've been using either Patman's or jpsdr's build's with RipBot264 for a couple of months, with no issue.

Jpsdr released a newer build 3.60.65, and it errored, but the previous 3.60.35 build is fine.

Same with Patman's, build 3.6+13+1 was/is fine, but 3.6+84+2 error's, and as Patman is used exclusively with StaxRip, I thought I'd try with that, and updating to 3.6+84+2, it failed with basically the same error that RipBot shows.

As for Barough's builds, which I don't use much anymore, have the same issue in his last 2 releases.

Even Selur is complaining, and now that I see that Jpsdr is asking for help, is' obvious that for the time being, it's all gone to sh*t, and "we" have to stay with older builds, if we need to keep encoding with whatever app we choose.

And http://msystem.waw.pl/x265/ is still on 3.6+35-dd594f5, I'm waiting for their next release, to see if it's got the same problems.

I also prefer the aq auto command that both Patman & Jpsdr builds have, none of the others have it, yet.

[jpsdr]

I'm asking for help not because i have issue with x265, but just because i tried to build with another gcc version than the one provided at http://msystem.waw.pl/x265/ and i have issue with static lib link, the fact i try to build with another gcc is not related to the recent changes.

[Kurt.noise]

So how come x265 has gone to sh*t in the last couple of weeks ??

"Someone" has stuffed it up trying something new, and it's not working.

I've been using either Patman's or jpsdr's build's with RipBot264 for a couple of months, with no issue.

Jpsdr released a newer build 3.60.65, and it errored, but the previous 3.60.35 build is fine.

Same with Patman's, build 3.6+13+1 was/is fine, but 3.6+84+2 error's, and as Patman is used exclusively with StaxRip, I thought I'd try with that, and updating to 3.6+84+2, it failed with basically the same error that RipBot shows.

As for Barough's builds, which I don't use much anymore, have the same issue in his last 2 releases.

Even Selur is complaining, and now that I see that Jpsdr is asking for help, is' obvious that for the time being, it's all gone to sh*t, and "we" have to stay with older builds, if we need to keep encoding with whatever app we choose.

And http://msystem.waw.pl/x265/ is still on 3.6+35-dd594f5, I'm waiting for their next release, to see if it's got the same problems.

I also prefer the aq auto command that both Patman & Jpsdr builds have, none of the others have it, yet.
what did you call "release" here, it's not in fact. There are just some compilations from the latest commits of the main branch repository. So, its quite normal to have some problems because not all have been tested yet.

If you stay with 3.6 official release, then you wont have any issues.

[Guest]

what did you call "release" here, it's not in fact. There are just some compilations from the latest commits of the main branch repository. So, its quite normal to have some problems because not all have been tested yet.

If you stay with 3.6 official release, then you wont have any issues.

Fair enough, they are not "proper" releases, but whatever has changed, it's caught some very regular & reliable x265 modder's, off guard.

Fortunately, I do have the last working Patman & Jpsdr builds.

I guess we'll just have to wait 'til the issue is solved.

[LigH]

I'm asking for help not because i have issue with x265, but just because i tried to build with another gcc version ...

You wrote that you try to compile with clang which is not gcc.

[Guest]

You wrote that you try to compile with clang which is not gcc.

I just noticed this build (from your sig link) x265_3.6+65-3c3d03746, which is dated 2024-08-09, is this a "modded" build or basically "vanilla" ?

I am getting the same error in RipBot264, that all the others have :(

I'll have to check some of the older builds.

[LigH]

If it were a build including a modification patch, it would reveal it in its name.

I tried to build a modded version with Boulder's patch, but it failed, so I did not release that. So from me, no current build including AviSynth / Vapoursynth demuxers.

All I added since the alpha channel commits was the additional compiler flags to enable them. But they are official flags by MultiCoreWare.

[jpsdr]

After failing with clang, i tryed with another gcc, as i said in post #9421. My thought was that it would be easier to try with "just" another gcc, and then after try again with clang once i would have been able to build with another gcc.

[jfcarbel]

You won't be disappointed if you "only" go for a 7950X (not the 3D), but it's a whole new motherboard, RAM (DDR5), really good cooling IS necessary.

But if you're coming up from a 5950X, you might as well go for the 9950X, it's only a few hundred $ more...it's only money.

You could save a little overall if you get a lower chipset MB.

Yeah I debated going for the 9950x but yeah motherboards are much higher and found a good Aorus Elite for $200 and also saw some benchmarks showing the 7950x beating the 9950x in some benchmarks.

Cooling wise I use the Dark Rock Pro monster air cooler and it hits within 1-2 degrees from liquid so I prefer this.

[Guest]

Patman has just recently released another build, 3.6+85+1, and it's still got an issue....

[LigH]

Which issue did you expect it to fix? No MCW developer even replied to my bug report about the eternal pipe on the mailing list yet.

[Guest]

Which issue did you expect it to fix? No MCW developer even replied to my bug report about the eternal pipe on the mailing list yet.

I thought he might have known something that nobody else did, so I tested it...

[rwill]

I do not know why you are all so .. 'active'. x265 is open source. So instead of waiting for help, help yourself.

For example there was code like this prior to the partial MV-HEVC support in abrEncApp.cpp around line ~680 (the file which contains the cli app main encode loop):


if (m_cliopt.framesToBeEncoded && inFrameCount >= m_cliopt.framesToBeEncoded)
pic_in = NULL;
else if (readPicture(pic_in))
inFrameCount++;
else
pic_in = NULL;


This was changed to the following to support multiple views in pic_in:

if (m_cliopt.framesToBeEncoded && inFrameCount >= m_cliopt.framesToBeEncoded)
pic_in[view] = NULL;
else if (readPicture(pic_in[view], view) && view == m_param->numViews - 1)
inFrameCount++;
else if (!pic_in[view])
pic_in[view] = NULL;


The main encode loop exits if pic_in[ 0 ] is NULL.

I do not think the following in the new code is going to work:

else if (!pic_in[view])
pic_in[view] = NULL;


There are also other problems I have noticed, but I think that waiting for MCW is not an option as they might take a while to figure stuff out.

[LigH]

So instead of waiting for help, help yourself.

You seem to assume that we all are experienced C/C++ developers only because we are able to run an automated build suite... :sly:

No, I may be a studied computer scientist, but my experience is better in different languages. I don't know the project well enough.

Instead, I do expect of a professional developer team to reply at least briefly to a bug report, the minimum would be a "checked, confirmed".

So, regarding your efforts, which I may forward to the mailing list:

:thanks:

[jpsdr]

I rewrite and put on my github the part exposed by rwill, cleaner from my point of view.
The else if (!pic_in[view])
pic_in[view] = NULL; will partialy work, it's the case there is a picture, and you're not on the last view, but from my point of view it's not clean.

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.

[LigH]

All I could do is share the scripts (https://www.ligh.de/software/make_x265.zip) I am using right now, so you can compare. For me they work when called in either mingw32 or mingw64 interactive consoles in MABS, depending on the bitness. I don't know how to run all of them in one by cross-compile toolsets.

[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.

[Guest]

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]

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.

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*

[Guest]

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" !!! https://www.cosgan.de/images/smilie/boese/n045.gif

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]

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 (https://bitbucket.org/multicoreware/x265_git/issues/947/cli-y4m-pipe-input-broken-doesnt-stop), 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. :D

Cu Selur

[john33]

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]

About the not stopping pipe input I reported (https://bitbucket.org/multicoreware/x265_git/issues/947/cli-y4m-pipe-input-broken-doesnt-stop), ...

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...:eek:
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.

[Guest]

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.

[Guest]

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).