Getting the latest x264

[Sharktooth]

DO NOT USE this thread for discussions about x264. Use the x264 development thread (http://forum.doom9.org/showthread.php?t=108570) or start a new one.

Windows builds:

DOWNLOAD
LigH's x264 (https://www.mediafire.com/?bxvu1vvld31k1) · videolan.org (https://artifacts.videolan.org/x264/)

outdated:
videolan.org (old) (http://download.videolan.org/pub/x264/binaries/) · msystem.waw.pl (http://msystem.waw.pl/x265/) · komisar.gin.by (http://komisar.gin.by/) · jeeb's site (http://fushizen.eu/) · x264.nl (http://www.x264.nl/x264_main.php)

Modified builds:
x264 t_mod (https://github.com/jpsdr/x264/releases)
(at your own risk)

Need a GUI for x264?
http://forum.doom9.org/forumdisplay.php?f=78

x264 Changelog:
See the official online Git changelog for latest information: https://code.videolan.org/videolan/x264/commits/master
Changelog by revision can be found here: http://komisar.gin.by/old/2851/x264_changelog.txt

_______________________________


AVC2AVI Revision 594 (including GUI ver. 1.2) (https://www.videohelp.com/software/avc2avi)
AVC2AVI is a tool for muxing raw h.264 streams into avi container. AVC2AVI GUI requires .NET framework 2.0

*** WARNING!!! IF YOU HAVE A x264 VERSION THAT COMES WITH AN UNINSTALLER, PLEASE UNINSTALL THAT VERSION ***

x264 VFW (no longer officially supported - mantained by third party developers):

DOWNLOAD (https://sourceforge.net/projects/x264vfw/files/x264vfw/)
(at your own risk)

Use LAV Filters for x264 playback in DirectShow-based players:
Information and download: https://forum.doom9.org/showthread.php?t=156191
or use MPC-HC with built-in LAV Filters: https://mpc-hc.org/

Use the latest Haali Media Splitter for MP4 and MKV files: http://haali.cs.msu.ru/mkv/

GUIs for CLI version:
Check this sticky: http://forum.doom9.org/showthread.php?t=129748

What is x264: x264 is a free software library and application for encoding video streams into the H.264/MPEG-4 AVC compression format, and is released under the terms of the GNU GPL.
Website: http://www.videolan.org/x264.html
H264/AVC info: http://forum.doom9.org/showthread.php?t=96059

x264 limitations: "x264 doesn't yet support the error-resilience features of baseline and extended profile, not the alternative colorspaces of high profile.
There are a few other features not supported..."

This is not an official x264 build and may not work at all, destroy all the data on your hard drive or make your house or your dog explode (i doubt it can, though...). I'm not responsible for anything that could happen - use it at your own risk.
Those builds are made for TESTING PURPOUSE ONLY.

Notes about the CLI version: Mencoder provides another way to use x264 with a commandline interface.
Mencoder builds by sherpya can be found here: http://oss.netfarm.it/mplayer-win32.php
Mplayer/Mencoder official website: http://www.mplayerhq.hu/

Other info:
Some x264 information: http://komisar.gin.by/x264info.html
x264 GIT repository (web browser): http://git.videolan.org/?p=x264.git;a=summary

Playback: MPlayer or VLC can play back x264 encoded movies.
Links to Mplayer/Mencoder are provided above and it's available for both Linux and Windows.
VLC is also a multi-platform media player and can be found here: http://www.videolan.org/
However the most convenient way to play back x264 video in Windows is LAV Filters + your_favourite_directshow_enabled_media_player (MPC-HC, etc).
If you want to edit a x264 encode with VirtualDub you should manually enable the H.264 Codec in the ffdshow's "VFW codec configuration" (decoder tab) and ensure there aren't other VFW codecs trying to decode h.264 however it's preferable to use AVIDemux.
The official AVIDemux website is: http://fixounet.free.fr/avidemux/

Encoding - "How to"s:
Doom9's x264 guide (http://www.doom9.org/gknot-main6.htm)
DeathTheSheep's x264 VFW Guide (http://forum.doom9.org/showthread.php?t=98247)
MeGUI Guide (http://forum.doom9.org/showthread.php?t=112496)
MeGUI-x264 Custom Video Profiles (http://forum.doom9.org/showthread.php?t=101813)

[bond]

1) dont use this sticky for discussion x264 issues plz
2) for new issues it might be better to start new threads and only discuss development issues in the development thread (because normally its not possible anymore to find any info by searching in 20+ pages threads)

[Doom9]

You are not allowed to post here unless you have my permission. Permission is automatically granted to Sharktooth, akupenguin (and naturally all moderators). If your nickname is not Sharktooth, akupenguin or you do not have a Doom9 team badge and post here, you will be striked for violation of rule 16.

[Sharktooth]

Read them carefully and DO NOT contact me by PM asking for help. Follow the forum rules and after searching if you cant find any answer, ask your questions in the forum.

Q1: When there will be a new build?
A: Daily. But since some time i dont build x264 for win32. So i link to external builds (usually x264.nl)

Q2: What does Summer Break mean?
A: It means, in summer, daily builds are no longer "dailies" for obvious reasons :p

Q3: Are yours official builds?
A: No, i'm not an "official" builder however the above links refers to builds.

Q4: What are the differences between "standard-SVN" builds and pathced builds?
A: Patched builds usually incorporate latest patches (beta or experimental - even from third parties and sometimes from me) that usually get committed to the SVN in the near future.

Q5: What does the MMX suffix mean? Do your builds use MMX only?
A: The MMX suffix (no longer used in the filename) means you need at least a MMX cpu to make my builds work, but if SSE/SSE2 are present they'll get used as well.

Q6: What compiler/software do you use to make your builds?
A: MingGW + GCC + YASM

Q7: I've heard the Intel compiler (ICL) produces faster binaries than GCC, why don't you use it for your builds?
A: The ICL would be faster only if the DSP routines (the ones that eat CPU cycles) weren't written in assembly language. So compiling x264 with ICL wouldn't produce any noticeably faster x264 binaries. Also ICL for windows is payware.

Q8: I've tried to encode a movie with the x264CLI and the output file is unplayable (or the CLI crashed during encoding). WTF?!?!?
A: Probably you tried to encode a 23.976 source or some other non integer FPS sources with an old x264 revision. Be sure to get an updated version and if you still have problems just use RAW output and mp4box to create a working MP4 file or check this thread (http://forum.doom9.org/showthread.php?t=100443) for a workaround.

Q9: Will the latest GeexBox/XBMC play my x264 encoded files?
A: Yes but ensure you have the very latest version. Starting from 0.98.6 it supports h.264 main profile decoding only. That means no 8x8dct and no custom matrices are supported. Later GeexBox version may be updated with the latest libavcodec and may support High-Profile.

Q10: Can i play my x264 encoded files with my modded Xbox?
A: Yes, but it depends on how much you modified your xbox. The stock xbox is equipped with a 733Mhz CPU that is not able to decode all the x264 (or AVC in general) features. If you haven't the Xbox CPU mod (the CPU gets replaced with a 1.4Ghz one) there are some guidelines you have to follow when encoding your files with x264 or other AVC encoders.
Find more info in this thread (http://forum.doom9.org/showthread.php?t=98070&highlight=xbox).

Q11: What'st the difference between VFW and CLI?
A: VFW is Video For Windows, an ancient tech created by microsoft (copying some stuff from quicktime), full of quirks and not able to support modern codecs. x264VFW is a ugly hack to make x264 work (more or less) with VFW, hence softwares like virtualdub and its modifications. The use of x264VFW is NOT recommended. x264 VFW is no longer officially supported.
CLI is a general term that means Command Line Interface. The classic console (command prompt) command which is generic and has no limitations like VFW.

Q12: What is AVC2AVI?
A: AVC2AVI is a tool to place AVC raw streams in the AVI container. It is useful for editing your encodes using VirtualDub(mod) or similar video editors that do not support the MP4 format or other formats. AVI is usually bound to VFW. The use of h.264/AVC streams in AVI is not recommended.

Q13: x264 is slow as hell, why?
A: x264 source contains tons of optimizations but being a very complex codec (more than xvid and every other Mpeg4 ASP codec) that's a perfectly normal behaviour. More quality = less speed...but thanks to those optimizations, x264 can be even blazing fast. If you want more speed do not enable all the bells and whistles and keep settings to a sane level.

Q14: Where i can get older versions of your builds?
A: I dont keep an archive of my old builds, so actually you can't get them unless someone has them mirrored somewhere. However you can get old revisions compiled by celtic druid or bobor. The links to the sites are provided in the first post.

Q15: The included MeGUI doesn't work or crashes. What can i do?
A: MeGUI is no longer included in my builds. Please uninstall x264, get and install latest MeGUI version from http://www.sf.net/projects/megui. It will automatically get a x264 build during the auto-update.

Q16: Sometimes the SVN/GIT revision is newer than the builds linked in this thread. Aren't yours daily builds?
A: Sometimes the changes in the new revisions doesn't affect the win32 builds or doesn't affect the final binaries at all. So compiling the new code revision is perfectly useless since the binaries will be exactly the same as the old one. Sometimes it can also happen i hadn't found some free time to compile new builds...

Q17: Is it possible to set an Aspect Ratio in x264 and what's Sample AR (SAR)?
A: Yes, you have to set the Sample Aspect Ratio (SAR) in the codec options. SAR is the same as Pixel Aspect Ratio (PAR) and it's different from Display Aspect Ratio (DAR).
To calculate the SAR starting from DAR you can use the following formula:
SAR (or PAR) = DAR*height/width.
More info can be found here: http://forum.doom9.org/showthread.php?t=100519
and here http://trac.videolan.org/x264/file/trunk/doc/vui.txt

Q18: Does x264 produce BluRay compliant h.264 streams?
A: Yes. Recently x264 was updated to be fully capable of producing streams playable on BluRay players. You can find a guide for BluRay encoding with x264 here: http://sites.google.com/site/x264bluray/home

Q19: Can i use VirtualDub or any other VFW based editor to encode with x264?
A: Yes, using a x264 VFW build but VFW is so obsolete and limited x264VFW is no longer mantained by the x264 devs and because VFW and AVI are not properly able to handle h.264 features without some "hacking" that could compromise compatibility, playback and/or editing.

Q20: If VFW can't handle correctly h.264, is there a software i can i use for editing in place of VirtualDub or other VFW based editors?
A: Currently there are few softwares that can do that. One is Avidemux (a free and complete editor similar to Vdub but not based on VFW) and then there are tools like mp4box and mp4creator (and relative GUIs) that can split, demux, mux and join mp4 files containing h.264 streams. MKVToolnix does the same for MKV files.

Q21: Is x264 (h.264 in general) compatible with DivX certified standalone players?
A: No. h.264 is a completely different codec and cant be played back by standalones unless specified.

Q22: Are there any other usable OpenSource h.264 encoders other than x264?
A: Yes and no. There are other OSS h.264 encoders but their development is discontinued or incomplete. However the Xvid dev team is working on Xvid AVC but they didn't release any code yet.

Q23: Is there a x264 1.0 build?
A: No, since x264 is in continuous development. The Unpatched builds may be considered more stable than the patched ones though.

Q24: Do x264 support multiprocessor systems or multicore CPUs?
A: Yes, check the --threads option usage.

Q25: What is/are the best...
A: Stop! There is no "best" as per forum rules. If you're looking for the "best" x264 options, most of the GUIs that support x264 come with a bunch of presets that will fit almost all your needs. If you're looking for the "best" h.264 encoder, then i suggest to use the forum search function and look for comparisons. However x264 is really good and can hardly be beaten by commercial encoders.

Q26: Can i use x264 for commercial purposes?
A: Yes but you need to contact MPEG-LA or Via for licensing the commercial use of a h.264 encoder since h.264 (also known as AVC or MPEG-4v10) is patented.

Q28: Where i can find more general info about h.264 and related standards?
A: Here: http://forum.doom9.org/showthread.php?t=96059

Q29: What happened to your builds and why they're no longer updated?
A: I actually switched to linux. Maybe in some time in the future my builds will be back but the builds by x264.nl i linked in the first post are almost as good as mine.

... more to come.

[Sharktooth]

AVC2AVI GUI ver. 1.2

Changelog:
1.2
- Added the Status bar
- Version now appears on the titlebar
- Added exception handling if AVC2AVI.EXE is not found

1.1
- Added FPS control
- Updated AVC2AVI.EXE to Revision 594

1.0
- First release

[Guest]

Thread cleaned up and re-stuck.

[bob0r]

xvidvideo.ru builds: http://www.xvidvideo.ru/content/category/1/4/5/

Forwards to ffdshow.

( Use http://www.xvidvideo.ru/x264-video-codec/ ? )

[hydra3333]

1st post seems to be slightly out to date "... Unpatched builds (x264.nl)"

What is the recommended place to download regular builds now ?

[sneaker_ger]

Try there: http://x264.fushizen.eu/builds/ (in the "revisionxxxx" folders, not the "rxxxx" folders or main site)

Also see http://forum.doom9.org/showthread.php?p=1630666#post1630666 and following.

[LoRd_MuldeR]

What is the recommended place to download regular builds now ?

Also here:
http://komisar.gin.by/

And there are various mirror sites, like for example:
http://www.free-codecs.com/x264_video_codec_download.htm

[mariush]

The latest builds of x264 are still hosted on http://mirror01.x264.nl

If that one breaks down, it's mirrored at http://x264.x265.net (use the links on the page for mirror02, the page is edited so that when clicking on mirror02 links you access this domain)

Future builds may be hosted on other domains, but you guys will be informed before that happens so no need to worry about it.

(for some reason the apache server crashed a few hours ago and the watchdog service didn't catch it, that's why the mirrors above were down if you checked them, should work fine now)

[LoRd_MuldeR]

r2345 has been on Komisar's site for quite a while, which is linked in the first post! But I have added a link to the builds on VideoLAN now.

[LoRd_MuldeR]

10-Bit builds, different compiler (version), different compiler settings, different patches included/excluded, different extra libraries included/excluded, different versions of extra libraries, etc. pp.

[hydra3333]

It's a bit difficult to tell (easily) what's baked into the VideoLAN build of x264 and what the changelog is.

For example, an old post on their forum confirmed it outputs raw .h264 rather than .mp4.

Any helpful hint as to where to find info about what those builds contain (eg support for avisynth input) and what it doesn't, would be most appreciated.

edit: I guess changelog is http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog

[Groucho2004]

It's a bit difficult to tell (easily) what's baked into the VideoLAN build of x264 and what the changelog is.

For example, an old post on their forum confirmed it outputs raw .h264 rather than .mp4.

Any helpful hint as to where to find info about what those builds contain (eg support for avisynth input) and what it doesn't, would be most appreciated.

edit: I guess changelog is http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog
How about using "x264 --help":

Here the current 32 Bit Videolan build:

x264 core:146 r2538 121396c
Syntax: x264 [options] -o outfile infile

Infile can be raw (in which case resolution is required),
or YUV4MPEG (*.y4m),
or Avisynth if compiled with support (yes).
or libav* formats if compiled with lavf support (yes) or ffms support (no).
Outfile type is selected by filename:
.264 -> Raw bytestream
.mkv -> Matroska
.flv -> Flash Video
.mp4 -> MP4 if compiled with GPAC or L-SMASH support (no)
Output bit depth: 8 (configured at compile time)

[hydra3333]

Well, that's a bit too easy :)

[hydra3333]

Hello. I am a linux wannabie attempting to cross-compile x264 for windows under an ubuntu VM, and have reasonable success with a vanilla build.
eg Clone from GIT then
./configure --host=i686-w64-mingw32 --enable-static --cross-prefix=/home/u/Desktop/xx/ffmpeg-windows-build-helpers-master/sandbox/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32- --prefix=/home/u/Desktop/xx/ffmpeg-windows-build-helpers-master/sandbox/cross_compilers/mingw-w64-i686/i686-w64-mingw32 --enable-strip --enable-lavf --disable-avs
Unknown option --enable-lavf, ignored
platform: X86
byte order: little-endian
system: WINDOWS
cli: yes
libx264: internal
shared: no
static: yes
asm: yes
interlaced: yes
avs: no
lavf: no
ffms: no
mp4: no
gpl: yes
thread: win32
opencl: yes
filters: crop select_every
debug: no
gprof: no
strip: yes
PIC: no
bit depth: 8
chroma format: all
However I do not know how to configure and make it with mp4/lavf support and goggling doesn't seem to provide useful answers.

One page said to clone and build gpac and then copy include files into the x264 folder
cp -R ../mpbox_gpac/gpac/include/gapc/* ./
and add this to the the x264 configure commandline
--extra-ldflags=-L../mpbox_gpac/bin/gcc --enable-mp4 --enable-mp4-output

However - could some kind soul please provide links or step by step info on how to turn
lavf: no
mp4: no into lavf: yes
mp4: yes

edit: http://forum.doom9.org/showthread.php?p=1659734#post1659734 says
You can type "./configure --help" for a list of commands. But if you want to enable external libraries like LAVF, FFMS and MP4 you will need to compile those libraries first!
For LAVF support you need ffmpeg/libav (libavcodec, libavformat, libavutils), for FFMS support you need FFMS2 and for MP4 support you need either L-SMASH or GPAC/MP4Box.
Once the required header files (.h) are in your include path and the required lib files (.a) are in your library path, the configure script will find them automatically however that didn't have the desired result.

[MasterNobody]

As you already found for lavf and mp4 support you need to compile and provide pathes for includes and libraries (with --extra-cflags="-I<path>" --extra-ldflags="-L<path>" or have pkg-config correctly configured):
- ffmpeg or libav libraries for lavf-support;
- lsmash (preferred) or gpac for mp4-support.
If even after that you didn't get desired effect than look into config.log to see why detection of this libraries failed.

[LigH]

Under Windows, you may use jb_alvarado's media-autobuild_suite to compile x264 with included libav inside an MSYS environment. I hope you can analyze their script to discover some hints how to create a matching configuration.

[hydra3333]

Thank you. I fluked mp4: yes, with this
# x264 cloned by now, and gpac is already built in mp4box_gpac
cd x264
mkdir ./gpac
chmod 777 ./gpac
echo " ------------------------- copying gpac include files ... "
cp -R -v ../mp4box_gpac/include/gpac/* ./gpac
echo " ------------------------- copying gpac_static.a file ... "
cp -v ../mp4box_gpac/bin/gcc/libgpac_static.a ../mp4box_gpac/bin/gcc/gpac_static.a
export LDFLAGS=-L../mp4box_gpac/bin/gcc/
export CFLAGS="$CFLAGS -I./gpac"
# now get on with the cross-compile
The resulting x264.exe reports a funny error though,
".\x264.exe" --thread-input --threads 8 --profile high --level 4.1 --preset fast --interlaced --tff --no-cabac --crf 18 --sar 64:45 -o "temp.h264" "input.mpg"
raw [error]: raw input requires a resolution.
x264 [error]: could not open input file `input.mpg' via any method!
As mentioned above, it looks like I also need to compile libav libraries for lavf-support and add that to LDFLAGS and CFLAGS and see if that makes a difference.
Or, since by that time I've cross-compiled ffmpeg, find out how to "link to" libavformat.a and .h files (or something like that) which hopefully may be cross-compiled as a part of ffmpeg.
I took a look at a ./configure file to see how it "detects" however it is beyond my skills for the time being.
I'll goggle pkg-config to find out what that is and hope it is compatible with Ubuntu based mingw cross-compiling.

I'll also goggle jb_alvarado's media-autobuild_suite as well as config.log.

linux newbie: and I'll also need to goggle how to put multiple paths in each of "LDFLAGS=-L" and "CFLAGS= -I" unless you can suggest it :)

[LigH]

github.com/jb-alvarado/media-autobuild_suite (https://github.com/jb-alvarado/media-autobuild_suite)

It contains heavy Windows cmd batch and bash shell scripts for installing and using a MSYS/MinGW cross compiling suite under Windows. I doubt it would run under a real Linux as a whole, but should contain good material to adapt your own workflow from.

[hydra3333]

github.com/jb-alvarado/media-autobuild_suite (https://github.com/jb-alvarado/media-autobuild_suite)
Beaut, thanks.

edit: my attempt is also 99% based on the very nice, linux cross-compiling tool from Roger Pack : https://github.com/rdp/ffmpeg-windows-build-helpers (as updated when comparing it to zeranoe's listed sources).

[jpsdr]

I've made a tutorial build for x264 here (http://forum.doom9.org/showthread.php?t=172610).
Even if it's Windows related, at least for the MSYS2 part, i think you can use all the others informations, it may help you.

[hydra3333]

Thanks.

I finally got x264 to cross-compile with gpac for .mp4 compatibility and with ffmpeg lavf libraries so that it directly accepts input like .mpg etc as input ... with the help of your examples, using ubuntu, a variation of rogerdpack's script (uses mostly latest source versions, or zeranoes, depending) and a variation of zeranoe's toolchain build script (to use the latest compiler and related stuff). It's a horrific train-wreck of a hacked up script used for debugging ... but it did work.

To me as a linux knowledge free zone, it seems that the configure file for x264 has a number of non-obvious fixed dependencies, eg things like
- pkg-config had to be copied from /usr/bin/pkg-config into the cross-compiler folder with a different name based on a cross_prefix, since the toolchain build script didn't (copy a linux-runnable pkg-config, which the configure needs to see
- setup of PKG_CONFIG_PATH and PKG_CONFIG_LIBDIR
- copying ffmpeg sources and libraries into specific folders
- copying gpac sources into a specific folder and a .a file to specific place with a specific name
- using a custom configure_flags to point to the right places

So now, to consider whether to spend the time to find out why the mp4box built via rogerdpack's script produces .mp4 files which don't behave right when played in mpc-hc, as compared to the the official mp4box; eg when playing a .mp4 and click say 3/4 down the timeline and then the audio plays but the video takes 5 seconds to catch up and start playing, whereas an .mp4 with same video and audio but produced by an older mp4box handles it just fine with no "catchup" (using the same commandline on mp4box).

[Selur]

Anyone got statically linked 8bit and 10bit x264 versions which run on Mac OS X Sierra?
Builds from http://download.videolan.org/pub/videolan/x264/binaries/macosx-x86-64/ don't work on Sierra :(

[Barough]

x264 0.148.2762 90a61ec - 8 bit & 10 bit Win32/64 Binaries
(libswscale 4.3.101)
(libavformat 57.66.102)
(ffmpegsource 2.23.0.0)
Built on Feb 17 2017, GCC v6.3.0

http://ge.tt/3gT9Eri2

https://git.videolan.org/?p=x264.git;a=summary

[Midzuki]

Time for an overdue update to post #1, me thinks.

Namely, remove the links to x264.nl and fushizen.eu.

OR add a notice informing that those sites haven't been updated since ages ago.

[LoRd_MuldeR]

Time for an overdue update to post #1, me thinks.

Namely, remove the links to x264.nl and fushizen.eu.

OR add a notice informing that those sites haven't been updated since ages ago.

You are right. I removed the defunct "x264.nl" and "doom10" links and also added an outdated notice to the "fushizen.eu" link.

(If there are any more links you'd like to see there, let me know)

[Midzuki]

Hummm, post #1 has other broken links :-/

Other posts also have broken links :-/

komisar's site hasn't been updated with the latest stable release of x264 :-/

Probably it's better to bury this thread and replace it with a brand-new sticky...

[LoRd_MuldeR]

Hummm, post #1 has other broken links :-/

I will try to fix some more of them!

Other posts also have broken links :-/

Well, I think we can't keep every link in every post up-to-date all the time. I will concentrate on the first one.

komisar's site hasn't been updated with the latest stable release of x264 :-/

Slightly outdated, yes. But I'm hoping for update soon.

It's not like there have been fundamental changes in x264 since the 2016/12 build.

[Barough]

x264 0.150.2833 df79067
Built on May 25 2017, GCC v6.3.0

https://git.videolan.org/?p=x264.git;a=summary

DL :
http://www83.zippyshare.com/v/XRwxwj4Z/file.html

[LigH]

I remember that x264 started to require NASM 2.13 (to support AVX512, I believe?) to build in the media-autobuild_suite.

[Midzuki]

I remember that x264 started to require NASM 2.13 (to support AVX512, I believe?) to build in the media-autobuild_suite.

That's correct, and it's mentioned in the changelog itself.

https://www.videohelp.com/software/x264-Encoder

[LoRd_MuldeR]

komisar's site hasn't been updated with the latest stable release of x264 :-/

Now has :cool:

[Midzuki]

Now has :cool:

õ/

Even though his builds are v. 2829 and mine are v. 2833 :)
(just like Barough's ones)

[LoRd_MuldeR]

õ/

Even though his builds are v. 2829 and mine are v. 2833 :)
(just like Barough's ones)

If you look at the commit log, you'll probably notice that in the last four commits there were no changes that effect static Win32 builds.

[komisar]

no, i am delete my message

[Morku]

Any chance to see new x264 builds in future?
Or maybe it's done as part of advanced development of x265?
http://download.videolan.org/x264/binaries/win64/
Fo some reason the 10bit release was not updated anymore.
Would be nice to now the current state of the encoder.

[sneaker_ger]

Builds are now multi-bitdepth. Use --output-depth 10

[Morku]

Didn't know that. Thanks a lot! So I am going to use videolan build.
Big thanks to komisar for the effort.

[chompy]

Hi, now that unfortunately Komisar seems to no longer update his x264 builds, could anybody please tell where could I get builds with fade compensate patch?

Thanks

[jpsdr]

Try my release on my github, but read the warning.

[chompy]

Try my release on my github, but read the warning.

Thanks, I'll have a look, but when reading your warning it's like reading chinese, I understand that something seems to be broken and you had to take some actions to handle it (I don't know if staying with ffmpeg 2.8.x has any undesirable side effect), but I don't know if I should take any further precautions.

I've also see that by default your build uses weightp=2 that had some time back problems with some buggy AVC decoder chipsets, so I've always used weightp=1 that was also improved with near weightp=2 results. Do you really recommend 2 or is 1 just fine?

[jpsdr]

It's not that something is broken, it's that the huge update blending the 8 and 10 bits code introduce so much changes, that a lot of patches need a LOT of rework to be implemented again, so, i've skipped it, but still implement the critical changes. So, my releases are not anymore directly from the master branch. At one point i've created my own branch, and to this branch implement the commits i think necessary.

My personnal point of view is that i absolutely don't care of ***#### buggy chipset because, they are buggy. Their responsability they should assume, not force things on me. Still, personnal point of view and subject which piss me off...
So, nothing realy i can recommend.

[chompy]

Thanks again, all clear now!

[masterkivat]

:confused: that means you won't provide new builds anytime soon, @jpsdr?
I've always used your builds, they process the encodes faster than the others, I have no idea why... :D
Guess I'll rely on this (http://msystem.waw.pl/x265/) website then for x264 builds. For x265 I'm using from LigH in HEVC's dedicated topic.

[jpsdr]

If you read, i'll still provide builds, but they'll not be anymore from the master branch.They'll just include what i think is realy necessary, because now i have to add the commits "at hands".
Still, it's not impossible that at one point, i'll not be able to provide builds anymore, but it's not the case yet.

[LouieChuckyMerry]

Hi, now that unfortunately Komisar seems to no longer update his x264 builds...

Happy Friday! and I hope komisar is well :) . I've been using the kmod build for several years as I find it noticeably faster than the standard build. Please, does anyone know of another modded build similar to komisar's? Thanks in advance for any help.

[LoRd_MuldeR]

Happy Friday! and I hope komisar is well :) . I've been using the kmod build for several years as I find it noticeably faster than the standard build. Please, does anyone know of another modded build similar to komisar's? Thanks in advance for any help.

There is no reasonable reason why the "kmod" x264 build should be any faster than any "vanilla" (clean) x264 build. The code in x264 where the vast majority of the CPU time is spent is heavily-optimized (hand written) assembler code. The "kmod" build does not contain any "magic" that would give you an additional speed-up out of nowhere! The only patch in "kmod" that is (remotely) related to performance is "x264_demuxer_threads.diff". And even that one does not do anything, except for allowing you to tweak the thread count for the FFMS input module - which might have an effect or not. But, unless you are using ultra-fast encoding settings, the CPU time spent in the input module should be minuscule anyway...

To make a long story short: If you came to the conclusion that "kmod" build is any faster than others, it is probably because you have been comparing different revisions of x264 and/or you have been comparing different encoding settings - which is comparing apples and oranges. I suggest that you look at the specific patches included in "kmod" build and understand what they really do. Unless you really need the "feature" enabled by these specific patches, there is absolutely no reason to use "kmod" instead of a "vanilla" build. For me it was much more important to find an up-to-date x264 build that has FFMS input and MP4 output enabled - which no build except Komisar's seems to have. Well, now Ligh's build (https://www.mediafire.com/?bxvu1vvld31k1) has too!

[jpsdr]

On my releases, i made several versions : Somes build with a posix gcc (the version you have in msys2 with "pacman") and everything is build with threading posix option, and somes build with a win32thread gcc (versison you can get here (https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/) for exemple) and everything is build win32 threading option.
For each version, i have a "standard" build, and an AVX2/Broadwell build (compiler settings option). Personnaly, never made tests, but someone who used my versions one day made a test : using the different builds on the same video with the same settings, on a Win7x64 system.
Result : win32thread was faster than posix, AVX2/Broadwell build was faster than "standard". But... differences were very slight, no more than 5% between the slowest and the fatest. So, you can have differences according "how best" the compiler optimize, because even if a lot of things are wonderfully well optimized in ASM, there still also a lot of things in pure C code, which leave rooms for optimization. Nevertheless, you'll will never hit more than a small few %.