With a little additional patch to enable function exports from the EXE in GCC builds too (not only MSVC), here are the first "All-In-One" x265.exe v1.7+298 which could also be linked as if they were DLLs (in theory yet, to be tested):
x265 1.7+298-523540864864 AIO (GCC 4.8.2)
x265 1.7+298-523540864864 AIO (GCC 4.9.2)
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 1,831 to 1,860 of 2222
Thread
-
-
Another "comprehensive" weekly build:
x265 1.7+338-8023786c5247 (GCC 4.8.2)
x265 1.7+338-8023786c5247 (GCC 4.9.2) -
my buildbot is back (automated GCC 5.2.0 / YASM 1.3.0 builds):
https://encoder.pw/x265/
webfrontend will be back soon too.
As always: don't trust any foreign binaries.
need something more experimental? https://encoder.pw/daala/Last edited by x265.cc; 23rd Jul 2015 at 15:55. Reason: Updated GCC to version 5.2.0
encoder.pw buildbot is NOT affiliated with, endorsed, or sponsored by the
x265 development team, MultiCoreWare Inc, Xiph.Org Foundation nor VideoLAN organization. -
^ Thank you for your comeback.
__
Eventually, new builds from me, I waited a bit longer, but it was worth it: Main12 now supports some degree of assembler optimization completely (at least up to SSE2-4 and AVX1), and just recently got a new table of "lambda" values (no clue what it means, but it seems to be important for a sane bitrate control).
x265 1.7+371-24c1ee516d13 (GCC 4.8.2)
x265 1.7+371-24c1ee516d13 (GCC 4.9.2)
And some results to compare:
8 bit | 10 bit | 12 bit (each ~6..7 MB, only default parameters except bit depth)
The video source is a 720p Y4M with 12 bit color depth, rendered with VapourSynth out of a sequence of 1440 TIFFs in RGB48, originally in 4K UHD resolution, scaled down in 16 bit-per-component YUV 4:4:4 before reducing to 12 bit-per-component YUV 4:2:0.Last edited by LigH.de; 24th Jul 2015 at 06:14.
-
New builds with MinGW-w64 patch for multi-threaded stats file output:
x265 1.7+382-7c83f7755422 (GCC 4.9.2)
x265 1.7+382-7c83f7755422 (GCC 5.2.0) -
GCC 5.2.0 appears to produce considerably faster executables than GCC 4.9.2 for legacy CPUs.
Here some brief statistics on an AMD Phenom-II X4 (max. used SIMD: SSE2) based on quick benchmarks (best of 3) with foreman.y4m in PAL CIF:
GCC 4.9.2: slow = 4.97 fps; slower = 1.64 fps; veryslow = 0.99 fps; placebo = 0.52 fps
GCC 5.2.0: slow = 5.45 fps; slower = 1.74 fps; veryslow = 1.07 fps; placebo = 0.55 fps -
Its a smaller difference on Pentium G3220 (no AVX/AVX2 instructions), 720p video, preset fast, x265_1.7.382:
GCC 5.2.0 - 12,4325 fps (average of 4 runs)
GCC 4.9.2 - 12,3975 fps (average of 4 runs)
I also did test with build 1.7.374, same video and settings:
GCC 5.2.0 - 12,315 fps (average of 4 runs)
ICC - 12,06 fps (average of 4 runs)
MSVC - 12,3075 fps (average of 4 runs).
For some reason Intel's compiler produces the slowest build for my Intel CPU?! And just for the record, last month I benchmarked Cyberfox x64 (web browser), AMD and Intel optimized builds and AMD build compiled with MSVC compiler was faster compared to Intel optimized build (ICC compiler, I think).
It seams that Intel does not like its budget CPUs. :P -
The more time x265 spends in assembler optimized routines, the less obvious the differences between C compilers get. Your differences will have been smaller mostly because of the 720p dimensions, I bet.
Comparing substantially different compilers is a different issue, though. Quite probable that the ICC requires a minimum architecture to crow (e.g. assuming bigger cache sizes than physically available may make some optimizations counterproductive). -
My webfrontend is back..
https://encoder.pw/ Automatic MinGW (patched, GCC 5.2 / Yasm 1.3) builds.
afaik it should offer the most up2date binaries atm.encoder.pw buildbot is NOT affiliated with, endorsed, or sponsored by the
x265 development team, MultiCoreWare Inc, Xiph.Org Foundation nor VideoLAN organization. -
-
Last edited by alkoon; 5th Aug 2015 at 00:59.
-
-
It may be more elaborate, but you may want to build the multilib executables to combine 8 + 10 + 12 bit encoder routines into one EXE. Don't forget to strip, that saves a few MB. And 7-zip will compress such large 3-in-1 files a lot more efficiently than ZIP with its small LZ window (only 32 or 64 KB, I believe).
-
I already have 7.zip
check this link : http://im85.gulfup.com/f6seFJ.png
as I said I can't run and it's like unknow software!
and I have another question, How did you use H265 to encode MP4 format, did you used MKVTool to convert .HEVC to MP4 ?
-
These are not my builds. I never distributed a file "x265[gcc]_1.7+374_64-8bit.zip", neither an "x265_64-8.exe"; blame those who made them... Furthermore, if there is any error message, please quote it as exactly as possible. Help us to help you, tell us facts, don't let us guess and assume.
MP4 files are multiplexed using MP4Box.Last edited by LigH.de; 5th Aug 2015 at 02:28.
-
-
What do you mean unknowned software?
It's a command-line driven program with no interface, you need a GUI (i use Hybrid with latest builds but there are plenty of others described in the software section).
You could also use a command prompt, but you'd really need to be familiar with the encoder's options and requirements.Last edited by Macadamia; 5th Aug 2015 at 09:40. Reason: typo
-
encoder.pw buildbot is NOT affiliated with, endorsed, or sponsored by the
x265 development team, MultiCoreWare Inc, Xiph.Org Foundation nor VideoLAN organization. -
Due to a merge to prepare the coming v1.8 milestone:
x265 1.7+399-cbdefdfca877 (GCC 4.9.2)
x265 1.7+399-cbdefdfca877 (GCC 5.2.0) -
Another "merge with stable":
x265 1.7+424-996ebce8c874 (GCC 4.9.2)
x265 1.7+424-996ebce8c874 (GCC 5.2.0) -
Is there a version history/changelog of x265 anywhere sorted by revision number? There is one of x264 since the very beginning.
-
https://bitbucket.org/multicoreware/x265/commits/all
Also available inside the Hg Workbench of TortoiseHG (Mercurial as context menu extension for the Windows Explorer). -
That doesn't display the version numbers.
I meant something like x265 1.7.420 421 422 423 etc. like the x264 changelog http://x264.nl/x264/changelog.txt -
Calculating the version+patch format is a bit elaborate if you don't use hg to manage the version dependencies; there are milestone builds from which each commit increases the patch number. I don't know any other site which keeps track of "patch number related to hash".
-
Weekly build, "merge with stable".
x265 1.7+433-60f30d2ead26 (GCC 4.9.2)
x265 1.7+433-60f30d2ead26 (GCC 5.2.0) -
Another "merge with stable", including several bug fixes and some even faster AVX2 routines.
x265 1.7+470-86e9bd7dd192 (GCC 4.9.2)
x265 1.7+470-86e9bd7dd192 (GCC 5.2.0) -
Similar Threads
-
help - how to compile latest "nightly" ffmpeg for win32 (XP) with mingw
By hydra3333 in forum ProgrammingReplies: 32Last Post: 20th May 2017, 00:33 -
x265 vs x264
By deadrats in forum Video ConversionReplies: 71Last Post: 10th Jan 2016, 06:14 -
ffdcaenc (an upgrade to dcaenc)
By El Heggunte in forum AudioReplies: 22Last Post: 9th Dec 2014, 06:09 -
MulticoreWare Annouces x265/HEVC Mission Statement
By enim in forum Latest Video NewsReplies: 4Last Post: 9th Aug 2013, 22:09 -
New PC Build(s)
By thedeificone in forum ComputerReplies: 6Last Post: 25th May 2010, 16:57