[HEVC] x265.EXE: mingw builds

[vhelp]

I did not think anyone really wants to use it on a windows xp system.

you are joking, or mad.

[El Heggunte]

I did not think anyone really wants to use it on a windows xp system.

This thread is named "[HEVC] x265.EXE: mingw builds" exactly because the X265 Project is biased towards M$VC and its respective idiocies and design flaws. Example:

On 9/12/2013 12:03 PM, Derek Buitenhuis wrote:
> I am sure I am missing some things, so any community members should
> add any I forgot.

Indeed I forgot one.


Build System
------------

People hate cmake. A lot. This is pretty much the biggest complaint I
hear
from people who poke x265. Cross compiling is a crapshoot. To get even
base features like 'make install' or 'make uninstall' or proper library
handling, you need to write mountains of custom stuff.

I understand the main point is for MSVC support, so my proposal is to do
what LLVM does and have both an autotools system, and a cmake system.
For all the perceived hate autotools gets, autoconf, automake, and
libtool
are by far the Least Bad build system in terms of handling everything
properly (library generation, versioning, cross-comiling, etc.). If I
or some other developer were to write this (it wont be a lot of code),
could I count on it actually being updated at the same time as the cmake
system?

Thoughts?

- Derek

If you want to learn how to compile XP-compatible builds in M$VC, ask Kurtnoise (one of the developers/maintainers of MeGUI).
Otherwise, you'd better stick to the GCC builds.

[El Heggunte]

You forgot to say that your MSVC builds are NOT compatible with Windows XP.

Oh, sorry. They are also not MS Windows 95 compatible.

Putting Windows XP and Windows 95 on the same boat proves you are a troll.

[x265.cc]

If you want to learn how to compile XP-compatible builds in M$VC, ask Kurtnoise

There's no black magic in targeting windows xp. (kinda ugly)

you are joking, or mad.

Windows XP => mingw build.


I've never seen an 8 GB Windows XP multicore system powerful enough for x265. Thats my opinion.

OT: Support end for win xp is april 2014.

[enim]

In DooM9 JEEB posted Daemon404's test encodes x265 samples:

divx_metrics.txt
PSNR Y:41.920 U:50.222 V:49.635 All:43.349
SSIM Y:0.98167 U:0.99311 V:0.99212 All:0.98532

x265_metrics.txt
PSNR Y:40.994 U:49.919 V:49.506 All:42.472
SSIM Y:0.97907 U:0.99258 V:0.99175 All:0.98343

LigH posted

There is no complete feature implementation yet. There is no stabe set of command line options yet. How often do you expect a GUI to follow sudden and unexpected changes in the set of encoder options? And yes: There is not even support for streaming video sources (pipe / AviSynth) yet. GUIs could not efficiently serve frames to such an encoder.

x265 expectations:
(1) PSNR 42.+++ is TOO LOW, need to be 50.+++ or way higher than that.
(2) Complete Full Features Implementation ITU-T H.265 : T-REC-H.265-201306 - in force as of now!
(3) May be few more...

[vhelp]

stdin/pipe/avisynth support should have been first priority. but it has lost its luster with me and others because of this oversight. so its useless testing x265 at this time.

wake me up when avisynth support has been added.

[Vid01]

JFYI, x265 win32/64 builds (mingw/vc11):


https://x265.cc/


As always: You should never trust non self compiled binaries.

MSVC builds are NOT compatible with Windows XP.

I note that the VC++ Redistributable for MSVC 2012 is required for these builds to run (or at least the 64-bit I tried to run). Upon attempting to execute x265.exe I receive the message: "This program can't start because MSVCP110.dll is missing from your computer. Try reinstalling the program to fix this problem."

[Selur]

wake me up when avisynth support has been added.

raw input via pipe would probably be enough, one could use avs2raw/mencoder/ffmpeg/... to decode and pipe the input,...

[LigH.de]

A little less conversation, a little more action.

Or in other words: Less flaming, more development.

There is no need to complain the compiling options of one builder, rather praise the existence of more recent builds to choose from. They are not much source-optimized yet, anyway. At least they work and allow the evaluation of a hopefully correct implementation.

Compatibility to a "legacy OS" (and XP belongs to them already) is as "urgent" as a final user interface: Not that much. With a 4K resolution target, it is not surprising to have a RAM requirement beyond the 2 or 3 GB limit of processes in a usual 32-bit OS without full LAA support (no, XP doesn't have it due to the risk of unaware drivers, and Windows 7 32-bit only with patched kernel). We are in the 64 bit OS era now. Especially regarding A/V editing and encoding.
__

P.S.: The installation of the MSVC 2012 Redistributable is required.

Using large runtime libraries will also be the reason that MSVC binaries are usually smaller than GCC binaries: They mainly call runtime library functions outside their EXE.
__

P.P.S.:

In contrast to the statement above, the RAM consumption appears to be quite conservative. I will report details about a 1080p encode later, when a first test with smaller dimensions (640x272) finished, but I expect it below 1 GB for my current options set...

[x265.cc]

In contrast to the statement above, the RAM consumption appears to be quite conservative. I will report details about a 1080p encode later, when a first test with smaller dimensions (640x272) finished, but I expect it below 1 GB for my current options set...

It's from the original "x265 Evaluators Guide 09-30-13" document. I've never tested an 1080p or 3840p encode.

[El Heggunte]

.......
I note that the VC++ Redistributable for MSVC 2012 is required for these builds to run (or at least the 64-bit I tried to run). Upon attempting to execute x265.exe I receive the message: "This program can't start because MSVCP110.dll is missing from your computer. Try reinstalling the program to fix this problem."

My XP machine already has the 2012 "vcredist" thing. The error message I get is:

...... x265.exe is not a valid Win32 application.

[x265.cc]

.......
I note that the VC++ Redistributable for MSVC 2012 is required for these builds to run (or at least the 64-bit I tried to run). Upon attempting to execute x265.exe I receive the message: "This program can't start because MSVCP110.dll is missing from your computer. Try reinstalling the program to fix this problem."

My XP machine already has the 2012 "vcredist" thing. The error message I get is:

...... x265.exe is not a valid Win32 application.

I recommend that evaluators should read the official "Evaluators Guide" first. (or if they experience problems).

[El Heggunte]

I recommend that evaluators should read the official "Evaluators Guide" first. (or if they experience problems).

I recommend that you stop blindly-believing in everything that is written by Tom Vaughan
(who clearly is a PR-oriented man).

At last, a MSVC build that doesn't crash on Windows XP

Goto post #1 (again) and look for the commit a8f6f62, compiled by the evil Evil EVIL Kurtnoise

It's safe to use it though --- unless you happen to hate him even more than I do

For the notes: x265.cc IS A TROLL, and his name had already been added to my Ignore List.

Just see how he intentionally MISquoted me:

JFYI, x265 win32/64 builds (mingw/vc11):


https://x265.cc/


As always: You should never trust non self compiled binaries.

MSVC builds are NOT compatible with Windows XP.

I had said «HIS msvc builds are not compatible with Windows XP».

Last but not least, Min Chen, a.k.a. "The X265 Man", and who was hired by MCW, uses Windows XP too.

[LigH.de]

x265 0.4.1+344-bbe95ece093f VC11-AMD64 crashes at the end, after reporting PSNR values (even though option "--no-psnr" was used), and before closing the CSV file (leaving it empty), when using the option "--ssim".

Complete command line:

x265.exe sintel_trailer_360.y4m -o sintel_trailer_360.hevc -F 3 -q 12 -b 3 --b-adapt 2 --bframe-bias 30 --ref 3 -i 240 --weightp --no-psnr --ssim --rdpenalty 1 --csv sintel_trailer_360.csv

BTW, in the doom9 forum, Kurtnoise offered publishing a patch for XP compatibility. I hope he will sooner or later read this last part of the thread, since "the troll" joined it in #538.


Anyway: Despite your marginally different opinions, I like fresh builds.
__

I was slightly wrong, it crashes even without "--ssim". Twice. Paste (with crash reports in german, but you may guess the content).

[x265.cc]

For the notes: x265.cc IS A TROLL, and his name had already been added to my Ignore List.

I'm a troll because my binaries don't support windows xp / link crt static?


And why should we use x265 but don't believe what the x265 team says?


I'm sorry if i offended you, the only thing i want and do is automaticly build x265 with MinGW (x86) / VC11 (x86-64)
for interested persons. Not more not less. No custom Windows XP build or whatever.

MinGW build is made exactly as you've done it, VC11 build is made like x265 team suggest it.

//edit: Static build is just ~200 kb bigger, i will consider to do this for the next builds as default.

[El Heggunte]

who has created this buildbot ? It's from official devs ?

I sincerelly hope his name IS NOT "Rafaël Carré":

........
-- on September 19, Rafaël Carré said he "will set up a continuous buildbot for x265 soon"

We really don't need yet another anti-XP troll, seriously:

First of all, use an operating system from this decade. I will not support Windows XP and older. This shit needs to die.

{ source: http://doom10.org/index.php?topic=1269.msg8891#msg8891 }

[Fllear]

How to use profile main-10 and level 5.1?

[x265.cc]

How to use profile main-10?

imho it must be set at compile time.

The current release of x265 is limited to a bit depth of 8-bits per sample YCbCr with 4:2:0 chroma subsampling.[1][5] x265 supports many of the features of x264 including constant QP encoding, Average Bit Rate control, and lookahead. Some features such as weighted prediction and 10 bit encoding are supported but unoptimized.

If interested.. here is a binary with 16 bits per pixel compiled with vc11 for 64bit (staticly linked).


I've just compiled it, not tested etc. (CMake -DHIGH_BIT_DEPTH=1 / /MT)

[ozok]

....
P.P.S.:

In contrast to the statement above, the RAM consumption appears to be quite conservative. I will report details about a 1080p encode later, when a first test with smaller dimensions (640x272) finished, but I expect it below 1 GB for my current options set...

Using a bit old build with my GUI, I was suprised to see that memory usage was below 500mb (working set value and not that it says much alone) during encoding a 1920x800 file (a movie trailer).

[Marchand]

Well, speaking of memory and CPU usage, I'm performing tests x265 Gui Build 89 Özok done by our colleague, which I am very grateful for the great encoder, coupled with the build file x265 x265_0.3 +594-06 c30405d308 and my PC is running on normality, without excesses. Not tested other versions after x265_0.3 +594-06 c30405d308, but I believe we are on track.

Congratulations to all those people who every day devote a few hours or minutes of your time to comment or share their ideas and the results of their tests. Thanks

[x265]

[QUOTE=El Heggunte;2274057]

I recommend that evaluators should read the official "Evaluators Guide" first. (or if they experience problems).

I recommend that you stop blindly-believing in everything that is written by Tom Vaughan
(who clearly is a PR-oriented man).

[QUOTE=El Heggunte;2269123]At last, a MSVC build that doesn't crash on Windows XP
Do you know me, El Heggunte? Did I say or do something to offend you?

Tom

[LigH.de]

MSVC11 project patch for XP compatibility by Kurtnoise in the doom9 forum

XP platforms require v110_xp as toolset instead of v110. Otherwise, applications don't run correctly on this platform.

This patch requires CMake 2.8.11 because the flag dedicated to the toolset has been fixed in this version.

[El Heggunte]

^ Yes$S , and just to be on the safe side,

I did send a copy of the text to the X265 mailing list, some minutes ago.

[DarrellS]

I haven't played with the Ming builds lately. Still waiting for input through pipe. Tired of creating intermediate files. I've played around with the DivX265.exe encoder in Virtualdub and Selur's Hybrid program since it supports stdin. Until x265 gets 10-15 fps encodes and major programs like MKVToolnix, ffmpeg and MPC-HC (which won't officially support it until MKVmerge does) then it's pretty useless for anything more than making small clips (unless you have the patience or an extra machine to encode for days).

DivX seems to be way ahead of the pack if you want to install their player and online plugin. I had problems with the audio popping though until I muxed them as .divx files instead of mkv files. Their version of mkvmerge doesn't use some of the same commands as the official mkvmerge so I have to manually mux the hevc file. I have a feeling that it won't be long until we see a Philips DivX265 certified player.

As soon as we get an official 265 mkvtoolnix build then I'll starting playing around again. Hopefully by then, x265.exe will be optimized more to get faster encodes and start supporting stdin like x264 so I can start using it in my favorite editing program, Virtualdub.


Don't understand the anti XP sentiment though. My old Q6600 XP Pro with 4GB of RAM has no problem with CPU or memory. MOF, I'd feel better if the encoder used more of my CPU and memory since there is plenty of resources to spare. Then I would know that I was getting the most out of the encoder that I could.

[-t40-]

Can please anyone tell me where to find that "x265 GUI" ?
And since it looks like the builds of that GUI are already public why no one is using this link - https://www.videohelp.com/toolsedit?newtool=1

[LigH.de]

@ DarrellS:

Oh, I was "conservative" too, using XP still on some of the older PCs I have access to. But people being interested in HEVC and 4K resolutions won't enjoy a PC which is so old that it runs better with XP instead of W7. If you want to be a pioneer in the video encoding area, you better consider using pioneer equipment...

The limited multi-core CPU consumption is probably related to the not yet perfectly optimized parallelization. Another piece in the puzzle that gets matched late into the whole picture. For now it is already honorable that parallel encoding reliably results in a correct bitstream.
__

@ -t40-:

It is probably ozok's x265GUI, I believe?

Regarding the registration of a new tool: The x265 encoder is not yet ready for the average user, therefore I would not recommend announcing its GUI; this would only attract more and more people complaining about the color of the body, while the engine is still in development.

[El Heggunte]

I partially agree, HEVC is a CPU-eater and doesn't go well with "ancient machines".
However, the available HEVC encoders still are at the SUB-pre-alpha stage , and it doesn't hurt to use them on XP-based machines.
And more importantly, since HEVC can be correctly encoded AND decoded under Windows XP....

long story short, I'm 50 y-o and really tired of still having to read all those cheap excuses for lazy (mis)configs and inefficient coding

[DarrellS]

I'd like to build a new machine but I'm on disability and have health issues that do not afford me to build a new one. I just pray that this one lasts me a few more years. If I could build one then I would probably step up to Windows 7, reluctantly. I had to step up to XP Pro when I built this machine because Windows 2000 didn't support my CPU. I've used Windows 7 before on my friends machine, although all the video programs were still 32bit. I just feel more comfortable with XP. I hate where everything is going these days. I can't use my favorite sports site anymore because it went to shit but I guess everyone with cell phones love the new sites.

[x265]

Don't understand the anti XP sentiment though.

There is no anti XP sentiment from the x265 project. I don't know who x265.cc is, or why he feels that it is ok to use that username (or register that domain name). He doesn't represent the x265 project.

Patches should be submitted to the x265 devel mailing list. All patches are reviewed by the open source community and the x265 development leads before anything is committed.

Tom

[x265.cc]

Don't understand the anti XP sentiment though.

There is no anti XP sentiment from the x265 project.

Which "anti XP sentiment"? As sysadmin i would tell you to switch before April 2014. As private person and x265.cc operator, i do not care about your operating system. The only thing i (my buildbot) _CURRENTLY_ not do is building windows xp binaries. He is also NOT building binaries for unix, linux, windows <= 5.0 and windows rt based systems. I really do not care what your operating system is.

I don't know who x265.cc is, or why he feels that it is ok to use that username

Erm, cause i'm the operator of x265.cc?

He doesn't represent the x265 project.

Have i ever stated or indicated that?

or register that domain name

Is x265 a registered trademark? Do you need explicit this domain name? Currently there are a lot of x265.tld domains registered.

If you do not want that anybody is using your project name ("x265") or your source you should register the "x265" as trademark and publish x265 as closed source. Also i hope that you've asked the x264 team if you are allowed to use there name.


So if you really have a problem with the "x265.cc" TLD / using your source code / offering binaries or programing a buildbot, (what i not really believe..) please tell me this by mail. Thanks.

btw. i've planned to change the buildbot to build windows xp binaries at weekend..