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 %.

[LigH]

Well ... "LigH's build" just came out of the media-autobuild_suite (https://github.com/jb-alvarado/media-autobuild_suite). No further patches. I have no experience in optimizing the building process or even adding patches.

[LouieChuckyMerry]

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!

Happy Saturday! :) Thanks for your informative reply, I really appreciate it. Odds are pretty good that I did compare different versions or botch something somewhere when I checked encoding speeds, or perhaps I enjoyed one too many :D . Anyway, thanks for setting me straight.

[kuchikirukia]

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

They should add a note on videolan, since I was wondering why 10 bit looked to be two revisions behind 8.
Is this why the executable doubled in size? (and out of curiosity, why was x264-r2744-b97ae06.exe 1/5th the size of the ones before it?)

[LigH]

If you have an executable which includes two quite substantially different encoders, then you have about twice the size of code in it, yes.

Earlier versions may also not include additional code to read compressed video formats directly from media files in different containers; small builds may only support raw source formats and AviSynth.

[sneaker_ger]

The Videolan binaries didn't double in size when the multi-depth builds were introduced. Big grow usually happens when some features are added (like ffms and/or lavf input) or binary compression is deactivated.

[kuchikirukia]

Is anyone else having a problem where encoding x264 lags their computer? It's running in low process priority like it should but I'm having problems with MPC-HC taking 20 seconds to start a video and new tabs hang, and it gets worse the more threads I throw at x264.

Windows 10.

[Asmodian]

Mine doesn't slow down that much! Are you low on memory? Are you encoding to or from your OS drive? SSD or spinning disk?

[LigH]

And do you use a rather low- or uncompressed source, so reading it may already be a bottleneck?

[kuchikirukia]

No other bottlenecks. --threads 4 I'm fine. --threads 8 I'm fine. -threads 12 it chokes other things, though the encode runs fine.
i7 4790

If it's pegged at 100% util my computer acts like it's 100% util at a higher priority.

[Selur]

Anyone got a link to a current, statically linked, x264 version with libav in it that's for MacOS X ?
Latest build over at http://download.videolan.org/x264/binaries/macosx-x86-64/ is from 25-Dec-2017.

Cu Selur

[Kn0X]

Hey!

I have a question .. is http://komisar.gin.by gone or is it just down right now?
It's been down for a couple of days now. :(

[Midzuki]

Hey!

I have a question .. is http://komisar.gin.by gone or is it just down right now?
It's been down for a couple of days now. :(

His site is back.

But maybe unfortunately, since he doesn't provide fresh x264.exe builds anymore :-/

[Shevach]

In nvenc (Nvidia encoder) there is a parameter enableConstrainedEncoding. This parameter is relevant for multi-slice mode and if it's set then motion vectors are restricted to not cross slice boundaries. That mode is useful in error resilience (to constrain error temporal propagation within the boundaries of a corrupted slice) and in delivery of 360 video.
My query - is there a similar mode in libx264?

[LigH]

Hmm, I know that x265 has a choice between WPP and other parallelism modes, also a slice oriented mode. But I don't remember x264 having a choice.

[Wishbringer]

@LigH: for x264 = this?
--slices
Default: 0

Sets the number of slices per frame, and forces rectangular slices. (Overridden by either --slice-max-size or --slice-max-mbs if they are set.)
If you are encoding for Blu-ray, set this to four. Otherwise, don't use this unless you know you need to.

but imho nothing about "enableConstrainedEncoding" except:
--constrained-intra
Default: Not Set

Enable constrained intra prediction, which is required for the base layer of SVC encodes. Since Everyone ignores SVC you can likewise ignore this switch.

[LigH]

Possible, if enabling slices also ensures that MV's are constrained to each slice. I hope the developers in #x264 on Freenode know more, just asking... I'm no developer.

BugMaster mentioned a guess that --sliced-threads may have such a side-effect.

[benwaggoner]

Hmm, I know that x265 has a choice between WPP and other parallelism modes, also a slice oriented mode. But I don't remember x264 having a choice.
WPP is new and so for unique feature to HEVC. The next gen VVC (probably H.266) currently plans to not include WPP.

[sneaker_ger]

x264 r2935 Windows binaries now up on the videolan server (https://download.videolan.org/x264/binaries/).

[LigH]

Now available in my archive too: x264 0.157.2935 545de2f (compiled already 2018-09-29 but forgot to pack and upload).

Today I wanted to recompile again with updated FFMS2 and L-SMASH ... but suddenly ffmpeg fails compiling libavdevice, seems to be a GCC 8 specific issue (expecting an explicit cast to (void) in a #define).

[Dogway]

I found that current x264 builds for some reason don't include libswscale, I was going to perform some speed tests comparing it to multithreaded avs+ resizers, even if the quality is not as great. If anyone knows someone who build them specially 10bit x64 please let me know.

[LoRd_MuldeR]

I found that current x264 builds for some reason don't include libswscale

Which specific build are you referring to? :confused:

As far as I can tell, the latest Ligh, msystem.waw.pl and videolan.org builds all do include libswscale, i.e. the "resize" filter is available. See download links in first (https://forum.doom9.org/showpost.php?p=610495&postcount=1) post.

BTW: For quite some time now, there are no separate "8-Bit" and "10-Bit" builds anymore. You can set '--output-depth' at runtime now (details (https://git.videolan.org/?p=x264.git;a=commit;h=71ed44c7312438fac7c5c5301e45522e57127db4)).

[Dogway]

Thank you it works! I was testing with x264 tMod (jpsdr), x264 Ymod (YamashitaRen), x264 videolan. tMod warns about the merge between 8 and 10bit builds so I thought it was important.

[asarian]

BTW: For quite some time now, there are no separate "8-Bit" and "10-Bit" builds anymore. You can set '--output-depth' at runtime now (details (https://git.videolan.org/?p=x264.git;a=commit;h=71ed44c7312438fac7c5c5301e45522e57127db4)).

Cool. Because I was just going to 'complain' that the 10-bit versions of x264 don't appear to be compiled with OpenCL support. :)

[LoRd_MuldeR]

tMod warns about the merge between 8 and 10bit builds so I thought it was important.

Well, the person maintaining "tMod" build obviously did not bother to port all of the "custom" patches to latest x264 after the "8/10 bits unification" (Dec 2017), which was quite a big change in x264 codebase.

Instead "tMod" build seems now to be based on an old version of x264, just before the big "8/10 bits unification" happened – with a some fixes cherry-picked from x264 master...

[asarian]

P.S. Are there any advantages using LigH's x264 over the regular one? (at videolan)

[LoRd_MuldeR]

P.S. Are there any advantages using LigH's x264 over the regular one? (at videolan)

Videolan.org build does not have FFmpegSource2 support enabled.

Also latest Videolan.org build was built using GCC 6.3.0, whereas latest LigH build was built using GCC 8.2.1 – which could be faster or slower, but probably doesn't make much of a difference.

LigH build includes a somewhat newer libavformat version.

[asarian]

Videolan.org build does not have FFmpegSource2 support enabled.

Also latest Videolan.org build was built using GCC 6.3.0, whereas latest LigH build was built using GCC 8.2.1 – which could be faster or slower, but probably doesn't make much of a difference.

LigH build includes a somewhat newer libavformat version.


K, thank you!

[LigH]

It's just what the media-autobuild_suite produces, no additional changes. Look here (https://forum.doom9.org/showthread.php?p=1859975#post1859975) for download link and version details.

[asarian]

It's just what the media-autobuild_suite produces, no additional changes. Look here (https://forum.doom9.org/showthread.php?p=1859975#post1859975) for download link and version details.

Cool. Thx. I took the one from the start-post link (the one I'm encoding with now). It is dated Dec 13, 2018, so it looked pretty recent to me. :)

P.S. Yours -- apart from being compiled with a later compiler -- also appears to be a lot smaller (~14 MB vs. ~22 MB).

[LigH]

Maybe the other one forgot stripping compiler symbols.

[jpsdr]

Well, the person maintaining "tMod" build obviously did not bother to port all of the "custom" patches to latest x264 after the "8/10 bits unification" (Dec 2017), which was quite a big change in x264 codebase.

Instead "tMod" build seems now to be based on an old version of x264, just before the big "8/10 bits unification" happened – with a some fixes cherry-picked from x264 master...

Yes, toooooooo much work to port all the custom patches.
Instead, i manualy put all the fixes from the master, except things which are specific to CPU not Intel.

[Dogway]

..."8/10 bits unification" (Dec 2017), which was quite a big change in x264 codebase.

Instead "tMod" build seems now to be based on an old version of x264, just before the big "8/10 bits unification" happened – with a some fixes cherry-picked from x264 master...

Not sure if that unification is the reason but tMod build comes as the fastest for which I tested. Hopefully I don't miss much of the latest master builds.

[LoRd_MuldeR]

Not sure if that unification is the reason but tMod build comes as the fastest for which I tested. Hopefully I don't miss much of the latest master builds.

Comparing the speed of x264 builds that have not been built from the same revision (Git commit), or even comparing "vanilla" builds to builds that contain "custom" patches, won't yield much meaningful results.

(It would pretty much be a comparison of apples and oranges, because a whole lot of things may have changed between the builds you are comparing)

[Dogway]

Just comparing them seems like none of them are compiled with opencl support? Was this deprecated at some point? I was reading about it not speeding up encoding much (~3%) but that translates to hours if your plan is to encode a library.

[Groucho2004]

I was reading about it not speeding up encoding much (~3%)I did some tests with "--OpenCL" a while ago and the speedup was ~1% at best (GTX750).

[Dogway]

Is there a build to test? I just bought a GTX1070 and maybe it can be faster with current opencl enabled builds.

[Groucho2004]

Is there a build to test? I just bought a GTX1070 and maybe it can be faster with current opencl enabled builds.Most builds should have it enabled since it's the default. You have to disable it in ./configure (--disable-opencl) if you don't want it included.

[Dogway]

(compiled) builds

[Groucho2004]

(compiled) buildsHuh? :confused:

Have you tried this (https://forum.doom9.org/showthread.php?p=1859975#post1859975) or the builds from VideoHelp?

[asarian]

(compiled) builds

Both LigH's x264, and the videolan one, are compiled with OpenCL support. So, it's just a matter of running your x264 flavor command-line with --opencl or not, for the test.

[Dogway]

I tested with videolan's, Ligh's and tmod. So not sure why it doesn't work, it warns me with a:
x264 [warning]: OpenCL: not compiled with OpenCL support, disabling
Using x64 builds in 10bit mode.

edit: yes confirmed, not working in 10-bit mode, only in 8-bit.

[asarian]

I tested with videolan's, Ligh's and tmod. So not sure why it doesn't work, it warns me with a:
x264 [warning]: OpenCL: not compiled with OpenCL support, disabling
Using x64 builds in 10bit mode.

edit: yes confirmed, not working in 10-bit mode, only in 8-bit.


It just so happened Lord_Mulder explained the 10-bit thing to me this very day. :) See: no OpenCL for 10-bit (https://forum.doom9.org/showthread.php?p=1860538#post1860538)

[Dogway]

lol the very same question, I guess I clicked on the wrong thread. 8-bit encoding then it seems (with banding ;)

[jpsdr]

I'm not 100% sure so this may have to be verified, but i vaguely remember reading once (it was now a long time ago), also that opencl doesn't produce exactly the same result than pure software (a little less good).
Considering that, the fact that to compile with opencl you need to install others third-party "things", the fact that speedup is not realy significant, i personnaly don't compile with opencl in the releases i made, and don't intend to bother with.

[asarian]

I'm not 100% sure so this may have to be verified, but i vaguely remember reading once (it was now a long time ago), also that opencl doesn't produce exactly the same result than pure software (a little less good).

That would suck. Especially if the gain is allegedly only like 1%.

Considering that, the fact that to compile with opencl you need to install others third-party "things", the fact that speedup is not realy significant, i personnaly don't compile with opencl in the releases i made, and don't intend to bother with.

A reasonable position. :) It's just that, in my quest for ever-more GPU-assisted tools, OpenCL just feels right; but it may just be a placebo.

As for having to 'install' third-party "things", I don't think that's a real issue: every Windows install will come with at least a default OpenCL.dll in its path.

[Dogway]

I made a test and at slower preset I get 109fps without opencl and 113 at most with it. That's about 3%, or an extra 1h and a half of rendering content for a 24fps film for 9h at night. tMod is already 3 or 4% faster than other builds I tested so if what you say is true I guess than at equal speed I would rather use one that doesn't degrade my content. Too bad we can't have both for a 7% gain haha.

[LigH]

An OpenCL driver is usually part of the graphic driver set (like OpenGL and maybe even OpenAL).

[jpsdr]

Someone (not me... ;) ) made tests with my releases (only on the x64 versions). It says that win32 version was around 1~2% faster than posix version, and Broadwell version was around also 1~2% faster than "normal" release. Both combined, you can indeed maybe achieve 3~4%. Different build configuration can explain differences in speed, but only that. Otherwise, code is the same. I'm not sure that only difference in gcc version could produce a such difference on speed.
Out of curiosity, when you said tMod is around 3~4%, which build ? Win32 or Posix ? Normal or Broadwell ?

Ah, and about opencl, i should have said : To build with it, it seems that i need to install in the build environement some others third party things i don't know about, so, too much bother for something from my point of view is not worth it.

[Dogway]

I own a 4670K so didn't use the Broadwell build only x64 of winthread. Not sure if my earlier tests were wrong I just ran another test both in 8 and 10bit for 7000 frames and LigH's is slightly faster 2%. Maybe different content yields different speeds. I read the speed from the last line when encoding finishes I assume means average.

Source: 1080p@60fps 8-bit CRF: 24 preset: slow tune: touhou

8-bit
tmod 111.92fps 107.45fps 117.62(--no progress)
LigH 113.54fps 116.83fps
vlan 117.05fps 116.57
LigH 121.68fps (--opencl on GTX1070)
vlan 121.26fps (--opencl on GTX1070)

10-bit
tmod 65.64fps
LigH 66.10fps


On a different note I get worse results in 10-bit for the same target bitrate (same settings) and even worse quality with x265 also 10-bit, makes no sense, would like to see some quality benchmarks out there.

[asarian]

I own a 4670K so didn't use the Broadwell build only x64 of winthread. Not sure if my earlier tests were wrong I just ran another test both in 8 and 10bit for 7000 frames and Ligh's is slightly faster 2%. Maybe different content yields different speeds. I read the speed from the last line when encoding finishes I assume means average.

Source: 1080p@60fps 8-bit preset: slow tune: touhou (not using opencl)

8-bit
tmod 111.92fps
Ligh 113.54fps
Ligh 121.68fps (--opencl)

Interesting results. :) How does 'vanilla' (videolan) x264 fare, compared to those?!

[Groucho2004]

Ah, and about opencl, i should have said : To build with it, it seems that i need to install in the build environement some others third party things i don't know about, so, too much bother for something from my point of view is not worth it.I use a pretty vanilla MingW from here (https://files.1f0.de/mingw/) and I can build x264 with OpenCL support without any additional "things".

[Dogway]

Updated the benchmark. I got higher resutls on vlan build so I did a second run to average results, tmod was getting lower results so disabled progress and now it's on par with the other two.

[asarian]

Updated the benchmark. I got higher resutls on vlan build so I did a second run to average results, tmod was getting lower results so disabled progress and now it's on par with the other two.

Thanks for the comparison. The FPS drop in 10-bit encoding is pretty significant; ouch.

[LigH]

I build with a pretty generic MSYS2 / MinGW environment which is kept up-to-date by the media-autobuild_suite. If OpenCL is enabled for ffmpeg, I suppose it is enabled for x264 as well.

And my H is capital.

[Dogway]

And my H is capital.

Ok fixed!

[chompy]

Hi, is there any updated build patched with fade-compensate (last was jpsdr's x264 t_mod r2932)? Thanks

[jpsdr]

In a few days, if everything goes well...

[chompy]

In a few days, if everything goes well...

Great :thanks:

[jpsdr]

I'm also working, nice and slow, to implement almost all the t_mod patches to the real r2969 version, not the "special" version i'm using for now.
Almost, because there is two patches i'll not implement : the avi output and the audio support. These patches are big and very difficult, but the most critical issue, is that they are using deprecated ffmpeg functions, needing a too old version of ffmpeg not compatible anymore with actual real r2969 version.
And i have no idea/skill/knowledge for updating these patches which need to be rewritten with actual ffmpeg functions.

[chompy]

I'm also working, nice and slow, to implement almost all the t_mod patches to the real r2969 version, not the "special" version i'm using for now.
Almost, because there is two patches i'll not implement : the avi output and the audio support. These patches are big and very difficult, but the most critical issue, is that they are using deprecated ffmpeg functions, needing a too old version of ffmpeg not compatible anymore with actual real r2969 version.
And i have no idea/skill/knowledge for updating these patches which need to be rewritten with actual ffmpeg functions.

Nice, lots of thanks again for your work!

[jpsdr]

I've finsihed implemening all the patches (even the "audio" and "avi ouput") of the tmod version on the last real r2970 version, avaible on my github on t_mod_New, builds are in progress, release soon.
Quick test seems ok, but i'm not using all the tmod features (the "audio" part for exemple, i'm not using it, so not tested...).

[jpsdr]

Done, i've released builds of the t_mod_New version, it's avaible on my github.

[Gser]

Done, i've released builds of the t_mod_New version, it's avaible on my github.

What exactly is the difference between t_mod and the vanilla x264? I noticed there are at least some new AQ modes, what do they improve upon and what kind of content are they for?

[jpsdr]

I don't know what vanilla has, you'll have to compare the patch applied.
About the new AQ, i think you refers to the TriAQ patch, wich add aq2 and aq3 mode. The original author of this patch made it most for anime purpose. Even if nothing prevent you to use them on something else than anime, for the few i've understood from aq3 mode, its purpose is mostly for anime "kind" video.
After, aq2 mode may be a more generic use.
Unfortunately, there was almost no information on this patch... :(
But my real advise would be to try.

[benwaggoner]

I don't know what vanilla has, you'll have to compare the patch applied.
About the new AQ, i think you refers to the TriAQ patch, wich add aq2 and aq3 mode. The original author of this patch made it most for anime purpose. Even if nothing prevent you to use them on something else than anime, for the few i've understood from aq3 mode, its purpose is mostly for anime "kind" video.
After, aq2 mode may be a more generic use.
Unfortunately, there was almost no information on this patch... :(
But my real advise would be to try.
aq-mode 3 is the same as aq-mode 2 but with a bias to lower QPs in the low luma range. If anything, it's most useful for film sources where quantization or banding in grain cause issues in shadow detail.

[jpsdr]

Don't mix aq-mode (2 or 3) with aq2-mode or aq3-mode ! They are absolutely not the same thing.
aq2-mode and aq3-mode are others aq modes added by the TriAQ patch, as i've said.

[benwaggoner]

Don't mix aq-mode (2 or 3) with aq2-mode or aq3-mode ! They are absolutely not the same thing.
aq2-mode and aq3-mode are others aq modes added by the TriAQ patch, as i've said.
Oh, right, thanks.

I think some renaming is in order!

[StvG]

Some info (https://forum.doom9.org/showthread.php?p=1172141#post1172141). MixAQ = aq2, OreAQ = aq3. After that MixAQ+OreAQ=TriAQ(+ some additional updates).

[sneaker_ger]

FWIW:
https://artifacts.videolan.org/x264/

Hi, all.

Here is URL for new x264 binaries: https://artifacts.videolan.org/x264/
Binaries of old x264 versions still can be downloaded from: http://download.videolan.org/pub/x264/binaries/
https://mailman.videolan.org/pipermail/x264-devel/2019-July/012705.html

[tormento]

I build with a pretty generic MSYS2 / MinGWAnd my H is capital.
Would you please tell me the differences between your builds and the "official" ones?

Would it be possible to have some ICL ones to test too?

[LigH]

I can't compare with the "official" builds, as I don't know how the "official" builds were created. I guess they don't contain lavf and ffms which MABS does include. And MABS uses MSYS2 / MinGW with GNU C/C++ in a current stable release (v10.1 at the moment). My latest build is linked and documented here (https://forum.doom9.org/showthread.php?p=1916663#post1916663).

I can't use ICL, I don't have any experience with it.

[LoRd_MuldeR]

I can't compare with the "official" builds, as I don't know how the "official" builds were created.

It looks like they are using GitLab CI/CD (https://docs.gitlab.com/ee/ci/yaml/README.html) runners to create the "official" builds, and you can see their configuration file here:
https://code.videolan.org/videolan/x264/-/blob/master/.gitlab-ci.yml

Anyway, the "official" builds have libavcodec/libavformat support enabled, but not FFMS. Also, they use GCC 8.2.

[tormento]

I can't use ICL, I don't have any experience with it.
Thanks.

You can download ICL with free subscription too, if interested.

[nakTT]

FWIW:
https://artifacts.videolan.org/x264/


https://mailman.videolan.org/pipermail/x264-devel/2019-July/012705.html
Thanks for the sharing.

[FranceBB]

Can someone with the rights on the x264 GitLab merge this pull request?

https://code.videolan.org/videolan/x264/-/merge_requests/6

[jpsdr]

Prayer answered it seems...
https://code.videolan.org/videolan/x264/-/commit/ae03d92b52bb7581df2e75d571989cb1ecd19cbd

[FranceBB]

Yep, I've got the email the other day: it has been merged. :D
Time to celebrate, then. ;)

annuntio vobis gaudium magnum: habemus Intra Class 300-480 xD

[jpsdr]

New version build.

[chompy]

New version build.

@jpsdr: Will you continue updating your x264 t_mod versions? Thanks!

[jpsdr]

I will when there will be interesting/worthwile commits (bug fixes or encode improvement), as it take a lot of time for me to make the build. Didn't check if there was commits the last 3 weeks, but until there, the commits were not worth spending time.

[chompy]

I will when there will be interesting/worthwile commits (bug fixes or encode improvement), as it take a lot of time for me to make the build. Didn't check if there was commits the last 3 weeks, but until there, the commits were not worth spending time.

Great, lots of thanks for your great work!!

[jpsdr]

New t_mod version for those who are still interested.

[mastrboy]

New t_mod version for those who are still interested.

Thank you.

[kebulek]

Thanks! :)

[FranceBB]

Nice, thank you, Jean Philippe! :D

[chompy]

New t_mod version for those who are still interested.

Lots of thanks!!

[FranceBB]

Hi there guys, I've just noticed that if I use --asm=avx512 with x264 8bit, it works, however if I use it while encoding with a 10bit profile, it doesn't, it only goes up to AVX2.
Is this expected? Is this because no one wrote AVX512 intrinsics for 10bit?

[LoRd_MuldeR]

Hi there guys, I've just noticed that if I use --asm=avx512 with x264 8bit, it works, however if I use it while encoding with a 10bit profile, it doesn't, it only goes up to AVX2.
Is this expected? Is this because no one wrote AVX512 intrinsics for 10bit?
You probably mean "assembly code" functions. An "intrinsic" is a function (well, not really a function, just something that can be called like a function) which is built directly into your compiler.

Anyways, as far as I can tell, the only places where the flag X264_CPU_AVX512 appears is in cpu.c and dct.c.

Obviously the code in cpu.c detects the CPU features. It's in dct.c where x264 actually uses the X264_CPU_AVX512 flags to enable (or not) certain function:
https://raw.githubusercontent.com/mirror/x264/0bb85e8bbc85244d5c8fd300033ca32539b541b7/common/dct.c

But, if I read the pre-processor directives in that file correctly, then the X264_CPU_AVX512 flag does not appear in the HIGH_BIT_DEPTH part at all; it only appears in the !HIGH_BIT_DEPTH part.

In other words, there is nothing in the "high bit-depth" code path that gets enabled/disabled depending on the availability of AVX-512 support.

Probably there simply are no "high bit-depth" functions that would benefit from AVX-512 instructions, or at least nobody nobody cared enough about AVX-512 to figure it out ;)

[FranceBB]

You probably mean "assembly code" functions.

Yep, sorry, I meant manually written assembly optimizations. :)




if I read the pre-processor directives in that file correctly, then the X264_CPU_AVX512 flag does not appear in the HIGH_BIT_DEPTH part at all; it only appears in the !HIGH_BIT_DEPTH part.


I see! So it's normal that I don't see it being enabled there as no one actually wrote anything for it in the high bit depth part, so it only works for 8bit. Gotcha. :)


In other words, there is nothing in the "high bit-depth" code path that gets enabled/disabled depending on the availability of AVX-512 support.


Gotcha, which is why I couldn't see it being enabled. Thanks for taking a look at it. :)


Probably there simply are no "high bit-depth" functions that would benefit from AVX-512 instructions


Nah, that's very unlikely, I just think no one wrote assemblies 'cause 10bit H.264 is much less used compared to the 8bit flavors (and indeed the only two groups of people who use it are those encoding in intra class to target broadcast hardware SDI playout ports in professional settings and those encoding anime, like fansubbers doing reverse upscale of BDs xD)



nobody cared enough about AVX-512 to figure it out ;)

Yeah, that's much more likely.
I wonder if Henrik Gramner will get back on this, given that he's the one behind the AVX-512 commits (among plenty of other things)...

[FranceBB]

Remember the whole discussion about OpenCL?
I actually tested again but this time on Amazon AWS machines.

m6i.4xlarge 16c/16th AVX-512 CPU Only
1h 24m

m6i.4xlarge 16c/16th AVX-512 CPU + OpenCL GPU
1h 03m


The content is 1h 32min 25seconds and 3 frames long.

The video is MPEG-2 50 Mbit/s FULL HD yv16 25i with PCM 24bit lossless 5.1 audio bobbed to 50p and with the chroma downscaled to yv12 in Avisynth.


x264.exe "Z:\AVS Script.avs" --preset medium --profile high --level 4.1 --ref 4 --deblock -1:-1 --crf 25 --keyint 50 --aud --overscan show --range tv --opencl --colormatrix bt709 --transfer bt709 --colorprim bt709 --videoformat component --nal-hrd vbr --vbv-maxrate 25000 --vbv-bufsize 25000 --output "I:\temp\raw_video.h264"

ffmpeg.exe -i "Z:\AVS Script.avs" -vn -sn -af loudnorm=I=-24:LRA=12:tp=-2 -c:a aac -b:a 550k -ar 48000 "I:\temp\audio.aac"

mp4box.exe -add "I:\temp\raw_video.h264" -add "I:\temp\audio.aac" "I:\temp\final_output.mp4"


adding --opencl saved around 20 min compared to not adding it.
So... yeah, it still makes sense to have it on.

[rwill]

m6i.4xlarge 16c/16th AVX-512 CPU + OpenCL GPU
1h 03m


Which GPU is available in an m6i.4xlarge instance ?

[FranceBB]

Which GPU is available in an m6i.4xlarge instance ?

Since everything you run through AWS is virtualized (unless you specifically require bare metal), it's hard to know, but I believe they're running an NVIDIA Tesla M6 8GB GDDR5.

[benwaggoner]

I actually tested again but this time on Amazon AWS machines.

m6i.4xlarge 16c/16th AVX-512 CPU Only
1h 24m

m6i.4xlarge 16c/16th AVX-512 CPU + OpenCL GPU
1h 03m
...
adding --opencl saved around 20 min compared to not adding it.
So... yeah, it still makes sense to have it on.
Yeah, that follows the "about a 20% speedup" rule of thumb.

That said, a c6a.4xlarge (AMD EPYC 7R13) may well offer the same performance software-only at a lower per-hour instance cost.

[DTL]

Probably there simply are no "high bit-depth" functions that would benefit from AVX-512 instructions, or at least nobody nobody cared enough about AVX-512 to figure it out ;)

As from old intel whitepaper from start of x265 at the start of 201x - https://www.intel.com/content/dam/develop/external/us/en/documents/mcw-intel-x265-avx512.pdf

The >8bit MPEGs more benefit from AVX512 because it uses 2x wider computing of source and result and immediate numbers (16bit for src and out and 32bit immediate) in compare with 8bit MPEGs (8bit src and out and 16bit immediate possible). Median performance boost from AVX512 over AVX2 is about 40% at 'processing kernels' of MPEG encoder.
https://i1.imageban.ru/out/2023/02/10/2617fe727c4ae8dcae5bac905fb3f07c.png

But 10bit x264 looks never was interested for major usage and no developers resources were for design either wider AVX512 computing for existed x264 architecture (SIMD 'workunit' size of 512 bytes max for AVX2 register file) or even much more complex design separate brunch of 4x enlarged 'workunit' size for 2048 bytes register file for AVX512 x64 environment. And that AVX512 brunch will only be executed faster on rare exist at endusers AVX512 environment in prevoius years. And no rich investor put some grant to support AVX512 redesign of x264 (to use in some possible commertials).

When some company start project from AVX512 hardware it can invest in pro programmers to design software solution for target platform and use all benefits of AVX512 environment. Splitting problem chunks to 'large workunit' size up to 2048 bytes with best processing performance at AVX512 platform. Also using alignment of workunits addressing to 64bytes cacheline size for fastest transfer to and from AVX512 register file and dispatch ports. And freeware opensource developers for multiplatform development typically making C-reference solutions to rely on compiler vectorization is possible and may limit 'workunit size' of algorithm to smaller wider used by endusers platforms because it works faster on small register file chips (less reloads from cache). So practically when opensource developers design and profile for best performance some computing algorithms at cheap old platforms with small sized register file (128 or 256 bytes for SSE(2) and AVX(2)) they actually optimize algorithm to run only at small register file sized platforms. And resources of high-cost in the past AVX512 platforms left underused. Full optimizing for AVX512 includes both usage of 2x wider execution ports (and some more faster instructions) and 2x sized datawords transfer and usage of 4x larger register file increasing processed 'workunit' size. And changing 'workunit' size may need the significant redesign of software (like processing 4 blocks in single pass instead of 1 block at AVX2 and so on).

AVX512 programs significantly more complex in design and debug. Without AVX512 chip it is possible to design via intel SDE software simulator but it can not provide correct profiling for performance results.
May be with progress of AI like ChatGPT or others we can see some progress in using of new compute platforms for solving old tasks like x264. Because it looks resources of opensource freeware programmers fast dying with ending of current civilization.


m6i.4xlarge 16c/16th AVX-512 CPU Only

x264.exe "Z:\AVS Script.avs" --preset medium --profile high --level 4.1 --ref 4 --deblock -1:-1 --crf 25 --keyint 50 --aud --overscan show --range tv --opencl --colormatrix bt709 --transfer bt709 --colorprim bt709 --videoformat component --nal-hrd vbr --vbv-maxrate 25000 --vbv-bufsize 25000 --output "I:\temp\raw_video.h264"


Do programmers of x264 builds in 2022..2023 already included AVX512 usage in auto-detection of execution platform capabilities ? Or user still need to force it with --asm avx512 (or may be --asm=avx512) command line option ?



I can't use ICL, I don't have any experience with it.

Intel C compiler can use multi-file interprocedural optimization (not everytime works and may need to fix sources). It may visibly helps to performance of complex program with many small processing functions (and many C source files). Though with increasing of complexity of program the probability of successful full program multi-file IPO decreases. But you still can try to enable it for separate projects of solution. Sometime you need to run several compiling runs and one of it finally ends with successful multi-file IPO.

Also it possibly best compiler to make AVX512-targeted builds (and intel chips builds with individual optimization to many intel chips families).

[FranceBB]

But 10bit x264 looks never was interested for major usage and no developers resources were for design either wider AVX512 computing for existed x264 architecture (SIMD 'workunit' size of 512 bytes max for AVX2 register file) or even much more complex design separate brunch of 4x enlarged 'workunit' size for 2048 bytes register file for AVX512 x64 environment.


Yeah, x264 is almost always used in the 8bit flavor for distribution, however professionally AVC Intra and XAVC Intra are two very common use cases for both FULL HD and UHD workflows (like Intra Class 300 and 480) and there AVX512 would definitely speed things up a lot. It's a shame that no one invested into it, though. :(


no rich investor put some grant to support AVX512 redesign of x264 (to use in some possible commercials).


We're already supporting Multicoreware for x265 (and the future x266) by being part of their partner program, but unfortunately they're not the ones behind x264... :(
I'm sure that there are other companies using x264 to encode either AVC Intra files or XAVC files using the Sony and Panasonic profiles for linear playout beside us, so if they could chip in and support the development, that would be greatly appreciated.



Do programmers of x264 builds in 2022..2023 already included AVX512 usage in auto-detection of execution platform capabilities ? Or user still need to force it with --asm avx512 (or may be --asm=avx512) command line option ?


Ironically, x264 works automatically with AVX-512 once it detects a compatible CPU to run, however x265 still needs --asm=avx512 to make use of them.
Why? Dunno.

[DTL]

"professionally AVC Intra and XAVC Intra are two very common use cases for both FULL HD and UHD workflows (like Intra Class 300 and 480) and there AVX512 would definitely speed things up a lot"

Intra may be already very simple and too fast - so the total workflow may be too few benefit if someone make intra more faster. Most slow things may happen at inter frame encoding where motion search required. Also as I see today 10bit x264 builds for AVC-Intra is almost impossible to found. May be it somewhere in special builds of ffmpeg.

8bit 'classic' x264 throws an error at YV12 avisynth input -

at -I 1 --avcintra-class=100
x264 [error]: 8-bit AVC-Intra is not widely compatible
x264 [error]: 10-bit x264 is required to encode AVC-Intra
x264 [error]: x264_encoder_open failed


With simple I-frames only simulation with -I 1 it runs at about 12 fps vs 3 fps for IPB encoding. About 4x faster for 'intra-only' encoding.

"I'm sure that there are other companies using x264 to encode either AVC Intra files or XAVC files using the Sony and Panasonic profiles for linear playout beside us, so if they could chip in and support the development, that would be greatly appreciated."

If some commertials uses freeware for production it may be too poor company to pay even for its existing poor workers. Not have any funds to pay to pro programmers to make opensource software better. If you have some funds you may try to open some offering contract at software developers jobs sites with exact task to pay for - like make x264 build run 2x faster at AVX512 defined chip with your required arguments and provided sample footage. May be such jobs exist and already solved but not offered opensource as a commit to standard project for free.

Also current business models are about making money for business owners and not make job amount of hired workers lower for the same payments. So if worker want to encode faster and spent less work time it is only task for worker to read intel docs for chip and make software run faster. The business owner will not pay for it.
Also as stated in typical jobs contracts: All enchancements made by worker for software are new funds of business owner. So it may be illegal for workers contracts to share any enchancements made to x264 at the payed time by business owner.

[FranceBB]

Also as I see today 10bit x264 builds for AVC-Intra is almost impossible to found.


Just use any of the JPSDR builds and you're good to go.


8bit 'classic' x264 throws an error at YV12 avisynth input -

at -I 1 --avcintra-class=100
x264 [error]: 8-bit AVC-Intra is not widely compatible
x264 [error]: 10-bit x264 is required to encode AVC-Intra
x264 [error]: x264_encoder_open failed



Yeah cause Panasonic and Sony specs are 10bits only, so the preset won't allow you, however you can do it manually if you really want to without using the preset.
Keep in mind that the command line switch is a bit like the Blu-ray switch: it will make life easier for you, but you can also use the options and do it manually. https://forum.doom9.org/showthread.php?t=182715


With simple I-frames only simulation with -I 1 it runs at about 12 fps vs 3 fps for IPB encoding. About 4x faster for 'intra-only' encoding.


Well there are also the "Long GOP" version of AVC as per Sony specifications and those use a closed specific GOP and definitely make use of P and B.

About the last point, it's not true, this forum is the demonstration as we have people contributing to open source projects from all over the world and working on several different companies. Our Ben here works at Amazon for instance and they contributed to x265 with the NEON assembly optimization for ARM among other things, for instance, Steinar works at NRK and contributed to the Sony and Panasonic flavours we talked about in x264, Kieran works at Open Broadcast System and made x262 etc (I could go on and on and on), so companies do contribute to open source encoders.

[DTL]

I'm sure that there are other companies using x264 to encode either AVC Intra files or XAVC files using the Sony and Panasonic profiles for linear playout beside us, so if they could chip in and support the development, that would be greatly appreciated.


For I-frames only encoding you may check this build - https://github.com/DTL2020/x264/releases/tag/Rel_130223 . It have (temporarily for performance check) disabled some _x9_8x8 and _x9_4x4 SAD/SATD compare in intra analysis. At old E7500 CPU it runs about 34% faster but produces about 10% more bitrate (may be with fixed bitrate AVC-Intra modes it will only degrades quality in some degree and depending on frame complexity).
Later I hope to put this function call to multi-block SIMD processing of AVX2/AVX512 to keep full quality.

Updated: fixed build to include processing of 4:2:2 and 10bit format required for AVX-Intra with skipped _x9 macroblocks compare. It looks this functions still not exist at all for single call _x9 processing and for > 4:2:0 and/or > 8bit processing always performed longer loop of checking each predictor separately.

At i5-11600 CPU this build with simulated AVX-Intra 100 for FullHD frame settings (from https://forum.doom9.org/showthread.php?p=1940382#post1940382 post) run at about 22.9 fps (jpsdr build 'winthreads' marked run at about 20 fps).

As more profiling shows for I-frames only high bitrates encoding with CAVLC only compression:
It looks x264 not any optimized for such production. The AVC-Intra over 50 class not allow CABAC (having some asm optimizations) and so x264 only can run with CAVLC compression. CAVLC have only C-implementation and almost no asm optimizations. And it is not about math computing but mostly shuffling small enough and random length byte streams. So SIMD units unlikely can help alot here. It mostly memory-bound task. At least at first look at CAVLC compressor.
Also it much more display x264 feature to have lower performance at the lower compression rate. If you remove hard fixed bitrate from AVC-Intra and allow x264 to run at crf-ratecontrol with VBR it run significantly faster. At IBP encodings it is also visible but much lower. So at I-frames only and high fixed bitrates performance looks like limited by rate control logic to keep required very high bitrate stable. If disable CBR and allow low crf - the analysis run several times faster (about 80 fps vs 20fps).
May be for professional usage you can found other intra-frame encoder MJPEG-like with much better implementation of fixed CBR output.

[blob2500]

Latest 'official' x64 build (r3179): 3MB only? :confused:

https://artifacts.videolan.org/x264/release-win64/

[LigH]

Most probably not containing all the encoders specialized in various internal resolutions (8+10 bit). Especially the higher resolutions require a lot more efforts and code to handle more than 1 byte per video component in Assembler.

New MABS compile: x264 0.164.3179 12426f5 (https://forum.doom9.org/showthread.php?p=1997983#post1997983)

[benwaggoner]

Any release notes?

[Barough]

Any release notes?

https://code.videolan.org/videolan/x264/-/commits/master

[blob2500]

I read now that there is no lavf support in win64 version. There is in win32 ver.

x264 core:164 r3179 12426f5
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 (no) or ffms support (no).

[LigH]

From which source? My MABS build (https://forum.doom9.org/showthread.php?p=1997983#post1997983) supports both LAVF and FFMS in both bitnesses, also L-SMASH MP4 output.

[blob2500]

I was still referring to the latest build 'official' version (r3179, 3MB). ;)

https://artifacts.videolan.org/x264/release-win64/

Up to r3173 (win64) there was support for lavf:

x264 core:164 r3173 4815cca
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).

--

Thanks for your builds with full lavf+ffms support. I've been using them for a long time.

[jpsdr]

You can also check my builds. I'm doing the builds for now, should be finished before WE.

[blob2500]

Thank you.
But do you know why there is no longer support for lavf in the latest version of Videolan's x264 (win64 build)? Is it an error?

[jpsdr]

No idea... :(

[LigH]

You would have to ask those people who are responsible for building these binaries. Not us, though...

[blob2500]

https://artifacts.videolan.org/x264/release-win32/

I'm not asking anything this time :) , but I'll point out that the new r3213 (win32) from Videolan has a similar issue to the Videolan's r3179(win64): only 4 MB, no lavf support.