[HEVC] x265.EXE: mingw builds

[LigH.de]

Furthermore, instead of ffmpeg, there is also avs4x265. It automatically calls an x265.exe in the same directory with required parameters to establish a pipe for raw YUV video.

avs4x265 --bitrate 450 --output video.hm10 1.avs

But I can't exclude the possibility that your call crashes due to unhandled bugs in the rate control. I never used "--bitrate", only "--crf", so I don't know from my own experience if very unrealistic target bitrates may cause crashes.

[dimokami]

I tried pipes from here http://forum.doom9.org/showthread.php?t=160383 http://forum.doom9.org/showthread.php?t=169607 All pipes wrote in comandeline that problem to write on 26 frame. I tried change by trim function to another frames and the same problem. CRF the same problem

[LigH.de]

But the video source is decodable beyond frame 26?

[dimokami]

Yes, everything fine. I even encoded it in avi and the try encode avi with ffmpeg and x265 but the same problevm

[vhelp]

@ LigH.de, i resolved the --preset issue. my gui's .ini file had a typo when i updated it that custom compiled encoder you posted in post # 1397. also, just to confirm, there is noticeable speed improvement, from 1.24fps (06+324) to 3.40fps (08.149) build. i used the same script posted in post # 1395.

i do not use that avs4x265 app. never could get it working when i did try it. anyway. in case it helps others get the x265.exe encoder working on their system, (i hear some are still having trouble) here is the complete script i use in my gui encoder. i also have to use it exactly the same in a dos console window, assuming all necessary apps are in the same folder:

cmd /c avs2yuv.exe c:\video.avs -raw - | x265.exe --preset ultrafast --input-res 720x480 --fps 23.976 --frame-skip 0 --frames 100 --crf 17 --input - -o video.hm10

the script above never fails. it is all i need when i want to quickly run a test of each x265.exe build.

the issue from post # 1395 has been resolved.

hopefully, someone will figure out how to get around the compiler requirements for windows xp, so users like me, who still live on it can continue participating in these utilities and discussions. thanks go to whomever compiled that version in post # 1391.

[LigH.de]

i do not use that avs4x265 app. never could get it working when i did try it.

Strange. It does the same as avs2yuv and piping with all parameters. You just don't have to type most of the parameters which describe the YUV video being piped, it will add them in its own call of x265. The used AviSynth script has to be the very last parameter, all preceding ones are passed to x265 (except one which selects a specific x265.exe to be called, if present).

cmd /c avs4x265.exe --preset ultrafast --frame-skip 0 --frames 100 --crf 17 -o video.hm10 c:\video.avs

thanks go to whomever compiled that version in post # 1391.

You're welcome. And if there will be a volunteer who is going to adapt the thread-safe solution from x264 into x265, as Dark Shikari offered, x265 may be XP compatible again some day...

[El Heggunte]

......
And if there will be a volunteer who is going to adapt the thread-safe solution from x264 into x265, as Dark Shikari offered, x265 may be XP compatible again some day...

The "volunteer" should be Steve Borho himself --- since it was he who created the incompatibility between x265 and Windows XP, thanks to MCW's stubborn and irrational "fidelity" to Visual C++ and CMake

Currently, the real problem is not even x265, but FFmpeg ---

--- it's quite stupid to break this latter because of only one *sub-pre-alpha* library.

http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=1889

[LigH.de]

Well, you know, everyone wants to be a pioneer, but not everyone can cope with wet boots when falling from the bridge.

Due to the public development, x265 may already have more attention than desired. Compared to that, schweinsz' Next Generation Web Codec is developed by a "one-man army". Less noise, fine. But progress on its own pace. I'll be curious to compare "when it's done".

[El Heggunte]

Well, you know, everyone wants to be a pioneer,

That's not true, period. Using myself as an example:
eight months ago, I had no intentions to compile and release MinGW builds of x265.exe,
but someone had to start the trend.

but not everyone can cope with wet boots when falling from the bridge.

Not sure of what you tried to say... Too bad my knowledgebase about the
idiomatic expressions in English is far from being comprehensive ¬¬

Anyway, I can't help noticing there seems to exist some kind of "weird solidarity" among certain developers...

[Marchand]

x265-0.8.234-highbitdepth-icl14.0-64 2014-Mar-27 21:25:45
x265-0.8.234-icl14.0-64 2014-Mar-27 21:25:45
x265-0.8.236-highbitdepth-msvc2012-64 2014-Mar-27 21:25:45
x265-0.8.236-msvc2012-64 2014-Mar-27 21:25:45

[LigH.de]

Regarding the wet boots, I mean that pioneers in software development should be able to handle temporal issues like bugs and broken workflows with less whining and more trust in the developers fixing them soon when they are told about it with convincing reasons and verbose details; just similar to military pioneers which are the first in little known areas to prepare access for the following troops, and should expect to stand in the water while building a bridge sometimes, knowing that it is no reason to complain, but part of the task they chose, a useful task for the following troops who don't need to get their boots wet thanks to the bridges the pioneers built.

tl;dr: If you can't handle occasional problems, wait until it's finished.

[El Heggunte]

^ Thanks for the UN-convincing reply, now me thinks you should try to become a lawyer, or work with advertising

[LigH.de]

What an insult! I am way too honest for both...

[LigH.de]

You can build the 16 bit version of x265 simply by checking the HIGH_BIT_DEPTH option in CMAKE.

I wonder why this option was not available in the CMake GUI while configuring the Win32 build. Might depend on a fresh clone vs. an often updated? — I manually added it as BOOL flag.

Check, configure, generate. Build. Hope the result is the expected.

Interesting that the stripped 16bpp binaries are smaller than the stripped 8bpp binaries. Possibly because they do not yet have as many different CPU-optimized ASM paths in parallel.

[Acesn8s]

@ LigH.de, i resolved the --preset issue. my gui's .ini file had a typo when i updated it that custom compiled encoder you posted in post # 1397. also, just to confirm, there is noticeable speed improvement, from 1.24fps (06+324) to 3.40fps (08.149) build. i used the same script posted in post # 1395.

i do not use that avs4x265 app. never could get it working when i did try it. anyway. in case it helps others get the x265.exe encoder working on their system, (i hear some are still having trouble) here is the complete script i use in my gui encoder. i also have to use it exactly the same in a dos console window, assuming all necessary apps are in the same folder:

cmd /c avs2yuv.exe c:\video.avs -raw - | x265.exe --preset ultrafast --input-res 720x480 --fps 23.976 --frame-skip 0 --frames 100 --crf 17 --input - -o video.hm10

the script above never fails. it is all i need when i want to quickly run a test of each x265.exe build.

the issue from post # 1395 has been resolved.

hopefully, someone will figure out how to get around the compiler requirements for windows xp, so users like me, who still live on it can continue participating in these utilities and discussions. thanks go to whomever compiled that version in post # 1391.

with respect mate i don't see the wisdom n waiting for someone to come up with a fix 4 something that was invented b4 the wheel was. thats like putting a ferrari engine n a 57 chevy. support 4 Windows XP runs out in 10 days so ur pc will b at risk after that with no more updates/security. y not upgrade 2 windows 7 and b done with it ? then u could expieriment wih the new builds as they r compliled.

[El Heggunte]

!-- SNIPP --

As a foreigner from the 3rd World, I'm glad to see my English is much better than yours

[El Heggunte]

Post #1 has been updated.

[LigH.de]

I wouldn't mind you adding my MediaFire folder there too. I won't upload daily, but probably several times a week.

[Acesn8s]

!-- SNIPP --

As a foreigner from the 3rd World, I'm glad to see my English is much better than yours

a foreigner is exactly right or else you would have known, we are lazy and abbreviate words .
but i wouldn't expect a foreigner to know anything about english shortcuts. besides
i was pointing out an obvious fact about vhelp's pc status. wtf does that have
anything to do with my english or the post ? does the truth hurt mate ? that would explain
your defensive post that is completely irrelevant to the thread or the post, you should first make some
since before you start giving english lessons to the country where it originated from.
besides that from the looks of ur name, talking to you in person someone would need a
translator to understand your english.

[El Heggunte]

As Alexander Noe would say,

[LigH.de]

What he says?

Sorry, I know neither this Anime nor Alex' famous speeches...
__

P.S.:

At the moment, MSYS builds work only with WINXP_SUPPORT enabled. Which is neither useful for Win64 builds, nor necessary for Win32 builds that don't care about supporting an "obsolete" OS.

The emulated ConditionVariable code (based on x264) is often slightly faster than the native kernel function, so Steve decided to use it by default, but possibly forgot to remove a dependency with the WINXP_SUPPORT configuration flag.

[DarrellS]

I ran a test of all the modern builds on the front page (couldn't run LigH.de latest since the link to his builds was removed) with a 720p clip and bat file I have in a test folder and was shocked at the speeds I was getting with the 64-bit builds on Windows 7. The Chromashift builds were the slowest at 38.38 fps. The European guy's was the fastest at 51.28 fps. The Russian guy's was second fastest at 48.26 fps and LigH.de's came in 3rd at 47.14.


I wonder why I waited so long to switch to Windows 7 when looking at these speeds. I did run a new 32-bit encoder (not from x265), trying to use the same settings as these 64-bit x265 encoders and it gave me an error that it didn't understand --preset ultrfast and said it was exiting but a finished file popped up almost instantly. Not sure what to make of that. If mkvmerge somehow had the last file still in it's memory since it was the same name.

480, 1280x720 frames in 10 seconds seems pretty darned fast to me from an old Q6600 with 4GB of memory. What is even more incredible is those 480 frames were only 184KBs. It is very efficient at taking 8 frames that are very similar and turning them into a 20 second clip. Animators, video game creators and websites like VirtuaGirlHD are going to love this new compression.

I'll lower the QP from 24 to 21 and see if it makes any difference and I'll also run some 4096x2160 4K clips. The last 30 second 4K clip that I created was 1,813KB in size.


* Sorry for not using the respected names but they're not listed.


EDIT: El Heggunte, I ran the same file using the 32-bit build you posted and it encoded at 39.95 fps. Slightly better than the Chromashift build.

[El Heggunte]

I ran a test of all the modern builds on the front page (couldn't run LigH.de latest since the link to his builds was removed)

Too bad you still haven't learned there exists a thing called "bookmarks"
Anyway, the link to the Mediafire folder of the unofficial Micro$oft employee is back.

with a 720p clip and bat file I have in a test folder and was shocked at the speeds I was getting with the 64-bit builds on Windows 7. The Chromashift builds were the slowest at 38.38 fps. The European guy's was the fastest at 51.28 fps. The Russian guy's was second fastest at 48.26 fps and LigH.de's came in 3rd at 47.14.


I wonder why I waited so long to switch to Windows 7 when looking at these speeds. I did run a new 32-bit encoder (not from x265), trying to use the same settings as these 64-bit x265 encoders and it gave me an error that it didn't understand --preset ultrfast and said it was exiting but a finished file popped up almost instantly. Not sure what to make of that. If mkvmerge somehow had the last file still in it's memory since it was the same name.

480, 1280x720 frames in 10 seconds seems pretty darned fast to me from an old Q6600 with 4GB of memory. What is even more incredible is those 480 frames were only 184KBs. It is very efficient at taking 8 frames that are very similar and turning them into a 20 second clip. Animators, video game creators and websites like VirtuaGirlHD are going to love this new compression.

I'll lower the QP from 24 to 21 and see if it makes any difference and I'll also run some 4096x2160 4K clips. The last 30 second 4K clip that I created was 1,813KB in size.


* Sorry for not using the respected names but they're not listed.


EDIT: El Heggunte, I ran the same file using the 32-bit build you posted and it encoded at 39.95 fps. Slightly better than the Chromashift build.

There is a 64-bit build below. However this has no importance at all, what really matters is,

FFmpeg is back to where it belongs \o/

[LigH.de]

Removed from where? I can't remember how many times I linked to my HEVC folder on MediaFire in this or the other thread about x265.

And no, I am not employed by Microsoft. My usually low bank account is the proof.
__

P.S.:

Why do you reveal all the mailing list subscribers? Doesn't that violate some privacy rules? Not all subscribers there are also responsible developers, so I don't know any sensible reason why someone would like to know how to send each of them emails directly.

[DarrellS]

New tests...

Input - 4096x2160 avi, fps 25000/1000, i420

Europe______x265_64bit-2014-03-29........................ / encoded 750 frames in 153.97s (4.87 fps), 355.70 kb/s / 1.29 MB 352 kbps
El_Heggunte_x265-64-bit_0.8+248-6f7b323061dc............. / encoded 750 frames in 156.01s (4.81 fps), 355.70 kb/s / 1.29 MB 352 Kbps
LigH.de_____x265_0.8+243-9b378e860ddb_GCC482_Win64_8bpp.. / encoded 750 frames in 157.40s (4.76 fps), 355.70 kb/s / 1.29 MB 352 kbps
Chromashift_x265-0.8.243-msvc2012-64 .................... / encoded 750 frames in 162.77s (4.61 fps), 355.70 kb/s / 1.29 MB 352 kbps
Russia______x265_0.8+243_x64_8bpp................. ...... / encoded 750 frames in 167.53s (4.48 fps), 355.70 kb/s / 1.29 MB 352 kbps


If someone can tell me how to use the encoder that LigH linked to, I'll test it but I can't make heads or tails out of it. It seems like it might rely on other files to work which would make it totally useless to me (without a working command argument it's already useless to me).


Here is the command argument used in Virtualdub for all the latest x265 encoders (couldn't seem to get a .bat file to work with the 4096x2160 resolution)...

--preset ultrafast --qp 21 --input-res %(width)x%(height) --fps %(fps) - -o "%(tempvideofile)"

[LigH.de]

Which encoder did I link to?

avs4x265? ... Well, what more than an example command line can I give you to explain how to use a command line tool? No, you can't operate that with your mouse pointer. It is useful for batch files, though, it helps piping the video output of AviSynth scripts to your x265 encoder so you don't need to store huge YUV or Y4M files. It adds all the required video attribute options you would have to specify explicitly if you used avs2yuv instead.

Give me a specific example: Which script, which x265 options, maybe which names of several versions of x265 (you will probably have them renamed or in subdirectories while comparing them), and I will help you making a batch file that runs a sequence of encodes from either one or several AviSynth scripts to HEVC video streams using either one or several x265.exe versions.

[DarrellS]

The one at doom9? Sorry, my mistake. It was Selur that linked to Kurtnoise who linked to...

http://www.mediafire.com/download/4kcziqf43au3jf8/x265_c_20140325.7z

I'll try the batch file again later cause I think my problem was that I did not have Avisynth installed on my Windows 7 drive. I could maybe get the x265 build above to work also if I dig through my folders from last spring or early summer when we were working with the other x265 encoder to find a working batch file for it. I'd rather work forward though instead of working in the past

[El Heggunte]

Yet another build:

if(WIN32)
   option(WINXP_SUPPORT "Make binaries compatible with Windows XP" OFF)
          if(MINGW)
             if(X64)
                add_definitions(-D_WIN32_WINNT=_WIN32_WINNT_VISTA)
             endif(X64)
          endif(MINGW)
   if(WINXP_SUPPORT)
      add_definitions(-D_WIN32_WINNT=_WIN32_WINNT_WINXP)
   endif()
endif()

[DarrellS]

x265 encoder will not accept 4096x2160 y4m as input from my batch files so all my tests will be run through Virtualdub's external encoder (which is where I would use them anyway).

x265_0.8+246-3f78e639d9ce_x64_8bpp / encoded 750 frames in 166.94s (4.49 fps), 355.70 kbps / 1.29 MB 352 kbps

[Selur]

@DarrellS: using raw input instead of y4m should work