[HEVC] x265.EXE: mingw builds

[x265]

C:/mingw/media-autobuild_suite-master/build32/x265-hg/source/common/threading.h:220:42: error: 'InitializeConditionVariable' was not declared in this scope

Bad changes. InitializeConditionVariable() needs Windows Vista at least. With -DCMAKE_CXX_FLAGS="$CFLAGS -D_WIN32_WINNT=0x0600" builds fine but does not run in WinXP.

I'm sorry that it's come to this, but we need to utilize condition variables for optimum efficiency and robustness. x265 utilizes extreme levels of parallelism, and we need to prevent issues that come when code isn't thread safe (race conditions that are difficult to debug). Unfortunately, Windows XP doesn't support condition variables. Working around this limitation in order to continue to support Windows XP would be costly and inefficient. As x265 is an open source project, it's conceivable that someone could write an implementation of that class that works correctly on XP, but it's a maintenance headache to have multiple sync primitives for a single platform.

[Selur]

@x265: What was the last XP compatible revision? (This would be interessting for those who are stuck with Windows XP for one or the other reason)

[x265]

@Selur: Every build up to 3 days ago (prior to c0155c7bb6ca "threading: introduce ThreadSafeInteger class") should be XP compatible.

[Selur]

Since I see no way to read the version number from the git hash -> To what version number does that translate (0.8+98-4fdcea7426f1; I'm asking for the bold-human-readable part )?

[Marchand]

x265-0.8.185-highbitdepth-icl14.0-64 2014-Mar-20 19:54:27
x265-0.8.185-highbitdepth-msvc2012-64 2014-Mar-20 19:54:27
x265-0.8.185-msvc2012-64 2014-Mar-20 19:54:27

x265-0.8.195-highbitdepth-icl14.0-64 2014-Mar-22
x265-0.8.195-highbitdepth-msvc2012-64 2014-Mar-22
x265-0.8.195-icl14.0-64 2014-Mar-22
x265-0.8.195-msvc2012-64 2014-Mar-22

x265-64bit-2014-03-20
x265-32bit-2014-03-20

[DarrellS]

I believe that x265_0.8+131 was the last build that worked for me.

I tried the new DivX265.exe CLI today and it blows this x265 encoder out of the water. 3200x1800 Files that I was trying to encode were encoding at right around 2 fps and the same file encoded at 7 fps with the DivX265.exe encoder. I had to cut my large format files down to one frame at .245 encoded to 24 or 25p. I don't have to do that with the DivX265.exe encodes. The DivX265.exe encoder accepts the uncompressed 3200x1800 avi as is from Virtualdub by pipe. The x265.exe encoder does not.

The Multicoreware x265.exe encoder is nowhere near ready for prime time. 3200x1800 is close to x264 performance right now with the DivX265.exe encoder.

[LigH.de]

@ Selur:

If I go back to patch 6526 (8dbcfae4dffc), the last patch before introducing ThreadSafeInteger, cmake calls it v0.8+149. I'll build and upload this one...
__

@ DarrellS:

Different encoders may have a different complexity and a different optimization level, and therefore a different requirement of RAM. But they will also have a different efficiency in quality per bitrate. Comparing speed and memory consumption alone is not very useful.

It reminds me on the comparisons between different hardware-accellerated AVC encoders (Nvidia CUDA or intel QuickSync based). They were fast (running in highly parallelized GPGPUs). They were RAM preserving (using video memory for frame storage). But they were also quite ugly when the bitrate was not ample (due to the "Reduced Instruction Set Computing", they lack of more complex features to find similarities across many frames and only produced Baseline Profile like video streams). The funny part was, x264 with a very fast preset could easily beat them in both speed (with 8 threads) and quality at a similar bitrate, being able to use features of the Main and High Profile.
__

@ all:

Do you know what to do to make "Large Address Aware" builds with GCC? It seems to be "just" a linker option (--large-address-aware)? But I could not find a string with "linker options" in any cmake file (which I don't understand anyway, but I was curious).

[Selur]

cmake calls it v0.8+149. I'll build and upload this one...

Thanks for the info!

Do you know what to do to make "Large Address Aware" builds with GCC? It seems to be "just" a linker option?

the ld option should be '--large-address-aware', but be sure to only use it on x86 (not on 64bit) builds, since it's a x86 only option.
( isn't it the default?)

[LigH.de]

The flag "--large-address-aware" is for the linker ld; I am not even sure if this linker is used at all, reading through the files generated by cmake, or if GCC is able to "link implicitly". The MSYS Makefiles preparation does not even report checking for a linker; but "ld.exe" does appear in some *.cmake configuration files.

Unfortunately, if I try to add the option to CMAKE_EXE_LINKER_FLAGS, it is passed to the call of g++.exe instead of ld.exe and causes an error message about being an unknown flag; and no other script contains any reference to ld.exe, except msys/CMakeFiles/{version}/CMake*Compiler.cmake

Reading further, I found that this option has to be combined to "-Wl,--large-address-aware" to have it passed through g++ to ld. Unfortunately, I don't know where to add it correctly. The file msys/CMakeFiles/cli.dir/build.make already contains several "-Wl,..." flags in the g++ line for different targets. With good luck, both are handled. With bad luck, one of them will be ignored.

Yet, it seems to work somehow. The EXE is flagged as LAA.

Now the final downer:

The LAA flag doesn't matter on a 32 bit OS like Windows XP. The process will still have at most 2 GB RAM available. And if I have a 64 bit Windows, why care for a 32-bit x265 at all?

Nice experiment. But Windows XP keeps being an obsolete base for the video encoding of the future.

[Selur]

Nice experiment. But Windows XP keeps being an obsolete base for the video encoding of the future.

2GB and even 4GB memory restrictions are a real limit if it comes to resolutions in the 4k and 8k and above region, so yes it's 32bit OSs in general which are not suited for such high resolutions

[LigH.de]

x265_0.8+149-8dbcfae4dffc_GCC482_Win32_8bpp_LAST-XP.7z (no LAA, doesn't help anyway).

[Selur]

Thanks!

[rogerdpack]

C:/mingw/media-autobuild_suite-master/build32/x265-hg/source/common/threading.h:220:42: error: 'InitializeConditionVariable' was not declared in this scope

Bad changes. InitializeConditionVariable() needs Windows Vista at least. With -DCMAKE_CXX_FLAGS="$CFLAGS -D_WIN32_WINNT=0x0600" builds fine but does not run in WinXP.

I'm sorry that it's come to this, but we need to utilize condition variables for optimum efficiency and robustness. x265 utilizes extreme levels of parallelism, and we need to prevent issues that come when code isn't thread safe (race conditions that are difficult to debug). Unfortunately, Windows XP doesn't support condition variables. Working around this limitation in order to continue to support Windows XP would be costly and inefficient. As x265 is an open source project, it's conceivable that someone could write an implementation of that class that works correctly on XP, but it's a maintenance headache to have multiple sync primitives for a single platform.

Hmm...this makes a bit painful for distributors who want to distribute (for instance) ffmpeg with libx265 support, but also still support XP.
Just throwing this out there, but maybe x265 can use pthread style condition variables then it be compiled against win32-pthreads project or what not, when needed. Or something like that.
Thank you.
-roger-

[El Heggunte]

<!-- snip -->

Hmm...this makes a bit painful for distributors who want to distribute (for instance) ffmpeg with libx265 support, but also still support XP.

Just throwing this out there, but maybe x265 can use pthread style condition variables then it be compiled against win32-pthreads project or what not, when needed. Or something like that.
Thank you.
-roger-

Assuming that you are correct: please post your ideas to the x265 mailing list,

x265-devel@videolan.org , because it may take "too long" until Tom reads this thread again

[vhelp]

x265_0.8+149-8dbcfae4dffc_GCC482_Win32_8bpp_LAST-XP.7z (no LAA, doesn't help anyway).

sorry to be a bother, but.. i thought xp versions had stopped, per post # 1381. the last working version i have for window xp is 'x265_0.6+324-237bf6667405.exe' on this desktop pc. the one on my memory stick in only slightly higher, by a few builds. anyway. i was trying this version to have a look at the speed improvement being discussed in the other thread. anyway. am not able to get this version working. gives me the following error:

'--preset' is not recognized as an internal or external command, operable program or batch file.

still using these commands (below) on my AMD dual core system, and fastest i can get w/ the 0.6+324 build (using the script below) is 1.24fps speed.

--preset ultrafast --input-res 720x480 --fps 23.976 --frame-skip 0 --frames 100 --crf 17 --input - -o "video.hm10"

[DarrellS]

I don't believe that presets were recognized until around November or December. If you dig through the posts, you find both Selur and x265 posting settings for what would end up being presets in later builds.

Nevermind, here is a text file that I copied.

ultrafast:
Code:
--ctu 32 --tu-intra-depth 1 --tu-inter-depth 1 --me 0 --subme 0 --merange 24 --no-rect --no-amp --max-merge 1 --early-skip --fast-cbf --no-tskip --bframes 4 --b-adapt 0 --rd 0 --no-signhide --no-lft
superfast:
Code:
--ctu 32 --tu-intra-depth 1 --tu-inter-depth 1 --me 1 --subme 1 --merange 24 --no-rect --no-amp --max-merge 1 --early-skip --fast-cbf --no-tskip --bframes 4 --b-adapt 0 --rd 0 --no-signhide --no-lft
veryfast:
Code:
--tu-intra-depth 1 --tu-inter-depth 1 --me 1 --subme 1 --no-rect --no-amp --max-merge 2 --early-skip --fast-cbf --no-tskip --bframes 4 --b-adapt 0 --rd 0
faster:
Code:
--tu-intra-depth 1 --tu-inter-depth 1 --me 1 --subme 1 --no-rect --no-amp --max-merge 2 --early-skip --bframes 4 --b-adapt 0 --rd 0
fast:
Code:
--tu-intra-depth 1 --tu-inter-depth 1 --me 1 --subme 1 --no-amp --max-merge 2 --rd 0
medium:
the x265 defaults
slow:
Code:
--tu-intra-depth 1 --tu-inter-depth 1 --max-merge 3 --no-tskip --bframes 4 --b-adapt 2 --rd 1
slower:
Code:
--tu-intra-depth 2 --tu-inter-depth 2 --max-merge 4 --no-tskip --rc-lookahead 20 --bframes 5 --b-adapt 2 --ref 3
veryslow:
Code:
--rc-lookahead 30 --bframes 9 --b-adapt 2 --ref 5
placebo:
Code:
--merange 124 --rc-lookahead 60 --bframes 16 --b-adapt 2
Last edited by Selur; 2nd Nov 2013 at 04:34. Reason: missing 0

[LigH.de]

i thought xp versions had stopped, per post # 1381.

Well, yes ... version 0.8+149-8dbcfae4dffc is the last that may be XP compatible because the following patch introduced the thread-safe integer class which uses a Windows feature first available in the Vista kernel.

The CLI option "--preset" was already available in e.g. version 0.6+282, even before your last version 'x265_0.6+324-237bf6667405.exe'. And of course, presets are still supported in version 0.8+X.

Furthermore, I can confirm that version 0.8+149-8dbcfae4dffc works in Windows XP SP3 Pro german in a VirtualBox. If it doesn't for you, there may be reasons beyond x265.
__

I just realized:

Do you try to run

--preset ultrafast --input-res 720x480 --fps 23.976 --frame-skip 0 --frames 100 --crf 17 --input - -o "video.hm10"

at the command line? Well, instead, you should see this as a snippet for another program (maybe VirtualDub's "External encoders..." feature) which serves x265 with raw YUV video.

A full command line for x265 should start with "x265.exe", and instead of the "-" for the input file, it should have a *.yuv file (or a *.y4m file, where you don't need the input-res option). Or you can use avs4x265 to serve an AviSynth script's video output into x265.

[DarrellS]

I couldn't get 147 or 149 to encode on XP. 131 was the last build that I could use. I also tried using the presets that were said to be released back then but had no luck. I had to use x265's or Selur's commands. It may have been that I was trying to run the superfast preset which I believe was left out of the first preset build.

[LigH.de]

I just wondered about trying to use the intel C++ compiler as well.

And rejected this idea before trying.

It produces well optimized code only if the compiler runs on an intel CPU. Which I don't have available due to costs.

[El Heggunte]

<Semi-OT>

I found this today on github...It looks completely different from the Multicoreware one and it's written in plain C.

A windows build is available here for testing.

</Semi-OT>

I have a feeling that there's going to be 5 variations of x265, and they are all going to race to become the best x265.

[El Heggunte]

@rogerdpack — many THANKS for joining the pesky mailing list ,

and yes you were right, now all that we need is an implementation

On Tue, Mar 25, 2014 at 4:44 PM, Jason Garrett-Glaser <jason@x264.com>
wrote:

> On Tue, Mar 25, 2014 at 10:32 AM, Steve Borho <steve@borho.org> wrote:

>> On Tue, Mar 25, 2014 at 11:25 AM, Roger Pack <rogerdpack2@gmail.com>
wrote:

>>> Hello. I noticed in a recent discussion that seemingly windows xp
>>> support had been "dropped" to clean up code:
>>>
>>>
https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?goto=newpost

>>
>> I would describe the situation more as we needed to use a
>> synchronization primitive (condition variable) in order to prevent
>> deadlocks and that primitive is not supported on XP. This wasn't a
>> code cleanup, it was fixing a serious race hazard.

>
> x264 supports condition variables on XP just fine.

I see that now in win32thread.c around line 117, thanks for the pointer.

So it is definitely possible to mimic a condition var on XP. Any
volunteers to adapt this to our threading.h?

--
Steve Borho

[dimokami]

Hi everybody. Help please, trying encoding but start from version 0.7 x265 stoped encoding. Try with ffmpeg pipe to x265 versions took from here x265.ru and try all versions that works on my system Windows 8 32bit. From here http://chromashift.org/x265_builds/ http://builds.x265.eu/ commandline wrote that this version of OS don't accepted. What I can do?

[LigH.de]

Could you please quote the exact error message? Did you possibly try to run a 64-bit x265 on a 32-bit Windows 8?

[dimokami]

This is on all version from 0.7 Try build 0.4 everything fine. My system Windows 8 32bit.
My commandline. I try different, but even on this simple the same problem.

cmd /s /c ffmpeg -i 1.avs -s 720x480 -r 29.97 -f rawvideo - | x265.exe --input-res 720x480 --fps 29.970 --bitrate 450 --output "video.hm10" --input -

[Selur]

seeing that you use a 32bit System, Avisynth and x265 you might want to have an eye on your memory consumption, might be that you run out of memory,...

[dimokami]

How to check this? how I can see it even don't get to max and just breakout. And swap file set in automatic mode.

I tryid encode file to avi, and then put from ffmpeg to x265 and the same problem.

[Selur]

Swap file only helps if a single application is not using more than 2GB RAM.
I attached up-do-date 32bit statically compiled x265 version 0.8+233 x265. (compiled with MinGW)
try if those work

[dimokami]

No the same problem at 20-40 frames process stops.

[Selur]

Have you tried without using avisynth?

[dimokami]

Checked the same. I tried this on two different systems on one set Windows 8 32bit on another Windows 8.1 32bit and the same problem.