Text only | Text with Images

Avidemux Forum

Avidemux => Windows => Topic started by: LoRd_MuldeR on January 30, 2009, 12:39:23 AM

Title: libx264 GIT builds
Post by: LoRd_MuldeR on January 30, 2009, 12:39:23 AM
Important:

Please do NOT use this "sticky" thread for discussion. This thread is intended for posting new libx264 builds only!

For discussion (install instructions, usage instructions, technical questions, etc.) please use this thread:
http://www.avidemux.org/smf/index.php?topic=7767.0 (http://www.avidemux.org/smf/index.php?topic=7767.0)



If you just came here to download the x264 library, please navigate to the LATEST post, which can be found on the LAST page of the topic!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on January 30, 2009, 02:24:20 PM
libx264 SVN-r1096:
http://www.mediafire.com/file/z21yttztt2j/libx264-r1096-gcc432-fprofiled-patched.7z

Compiled with MinGW GCC 4.3.2-tdm-2, march=pentium2, fprofiled.
Patched back to core version 65 in order to make it work with Avidemux 2.4.3 r4532.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on February 03, 2009, 04:17:58 PM
libx264 SVN-r1099:
http://www.mediafire.com/file/1dr0fzgzqhw/libx264-r1099-gcc432-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-2, march=pentium2, fprofiled. Tested with Avidemux 2.4.3 r4559.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on February 05, 2009, 12:27:46 AM
libx264 SVN-r1101:
http://www.mediafire.com/file/zzmwjhqmwmm/libx264-r1101-gcc432-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-2, march=pentium2, fprofiled. Tested with Avidemux 2.4.3 r4559.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on February 09, 2009, 03:30:00 PM
libx264 SVN-r1106:
http://www.mediafire.com/file/txwmxbyegku/libx264-r1106-gcc432-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-2, march=pentium2, fprofiled. Tested with Avidemux 2.4.4 Final.

Be aware: This build may crash on 32-bit systems without SSE (e.g. Athlon XP) :O
Title: libx264 GIT builds
Post by: LoRd_MuldeR on February 09, 2009, 10:44:45 PM
libx264 SVN-r1109:
http://www.mediafire.com/file/2eydy4mgldy/libx264-r1109-gcc432-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-2, march=pentium2, fprofiled. Tested with Avidemux 2.4.4 Final.

Be aware: Previous build (r1106) may crash on 32-bit systems without SSE (e.g. Athlon XP) :O
Title: libx264 GIT builds
Post by: LoRd_MuldeR on February 12, 2009, 12:49:13 AM
libx264 SVN-r1112:
http://www.mediafire.com/file/4otmlmzmnmj/libx264-r1112-gcc432-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-2, march=pentium2, fprofiled. Tested with Avidemux 2.4.4 Final.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on February 16, 2009, 05:46:48 PM
libx264 SVN-r1114:
http://www.mediafire.com/file/mowdyn4tjq3/libx264-r1114-gcc432-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-2, march=pentium2, fprofiled. Tested with Avidemux 2.4.4 Final.

--------------------------------------------------

Debug build:
http://www.mediafire.com/file/ye3tltlwzyi/libx264-r1114-gcc432-debug.7z

Debug build with optimizations:
http://www.mediafire.com/file/3wonwzt3mwz/libx264-r1114-gcc432-debug-optimized.7z
Title: libx264 GIT builds
Post by: LoRd_MuldeR on February 16, 2009, 08:37:16 PM
libx264 SVN-r1114 fixed:
http://www.mediafire.com/file/m2nn3c2w2zl/libx264-r1114-gcc432-fprofiled-fixed.7z

Compiled with MinGW GCC 4.3.2-tdm-2, march=pentium2, fprofiled. Tested with Avidemux 2.4.4 Final.

This build contains an experimental fix for the EXCEPTION_INT_DIVIDE_BY_ZERO crash that people reported!

The patch that has been used can be found here:
x264_nodivzero.diff (http://www.mediafire.com/file/jjwgnzytzvn/x264_nodivzero.diff)
Title: libx264 GIT builds
Post by: apollo567 on February 22, 2009, 01:21:42 PM
looks like the links are brocken ?!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on February 22, 2009, 03:29:54 PM
Quote from: apollo567looks like the links are brocken ?!

Uhm, no!? Works for me ;)

Title: libx264 GIT builds
Post by: apollo567 on February 22, 2009, 03:59:38 PM
Strange, the link for me only worked with IE7 but not with firefox 3 (=> resulting in page not found)
Thx I got the file now
Title: libx264 GIT builds
Post by: LoRd_MuldeR on February 22, 2009, 04:02:15 PM
Quote from: apollo567Strange, the link for me only worked with IE7 but not with firefox 3 (=> resulting in page not found)
Thx I got the file now

Something must be borked with your Firefox installation, with your Firewall or with your internet connection!

The link works just fine for me in Firefox 3.2 as well as SeaMonkey 2.0.

Title: libx264 GIT builds
Post by: apollo567 on February 22, 2009, 04:24:23 PM
Will explore this, thx
Title: libx264 GIT builds
Post by: LoRd_MuldeR on February 27, 2009, 12:01:08 AM
libx264 SVN-r1115:

MinGW GCC 3.4.5-r3, vanilla:
http://www.mediafire.com/file/vy50i0ngmkw/libx264-r1115-gcc345-fprofiled.7z

MinGW GCC 4.3.3-tdm-1, patched:
http://www.mediafire.com/file/zvj2alwnoam/libx264-r1115-gcc433-fprofiled-patched.7z

MinGW GCC 4.3.3-tdm-1, vanilla:
http://www.mediafire.com/file/gznntzwrzd0/libx264-r1115-gcc433-fprofiled-vanilla.7z

All builds: march=pentium2, fprofiled. Tested with Avidemux 2.5 SVN-r4629.
Title: libx264 GIT builds
Post by: apollo567 on March 01, 2009, 07:25:38 AM
Good morning,
may I ask what are the differences between the 3 versions of  r1115 or where to find more about them ?
Regards
apollo
Title: libx264 GIT builds
Post by: LoRd_MuldeR on March 01, 2009, 02:43:23 PM
Quote from: apollo567Good morning,
may I ask what are the differences between the 3 versions of  r1115 or where to find more about them ?

Different compilers (that is: different versions of MinGW) were used to compile them.

In theory the resulting binaries should be identical, of course. However in reality they sometimes are not!

It was indicated that MinGW 4.x.x may miscompile x264, which may be the reason for x264 to crash.

Therefore I also made a MinGW 3.4.5 build this time, so people can check whether that one works any better.

Of the two MinGW 4.3.3 builds one is unpatched (\"vanilla\") and one is \"patched\" to workaround the possible crash.

Now I\'d like to now which builds work and which don\'t ...

More info here:
http://forum.doom9.org/showthread.php?t=145041
Title: libx264 GIT builds
Post by: LoRd_MuldeR on March 04, 2009, 02:06:01 AM
libx264 SVN-r1119:

MinGW GCC 4.3.3-tdm-1:
http://www.mediafire.com/file/ynfaxm2hjil/libx264-r1119-gcc433-fprofiled-core66.7z

MinGW GCC 3.4.5-r3:
http://www.mediafire.com/file/murxn2z4025/libx264-r1119-gcc345-fprofiled-core66.7z

Both builds: march=pentium2, fprofiled. Tested with Avidemux 2.5 SVN-r4648.
Title: libx264 GIT builds
Post by: apollo567 on March 07, 2009, 07:40:44 PM
May I ask, if these Versions also work with the official 2.44 Milestone ?
Where can I find to information about the Version changes please ?

Regards
apollo
Title: libx264 GIT builds
Post by: LoRd_MuldeR on March 08, 2009, 12:37:05 AM
Quote from: apollo567May I ask, if these Versions also work with the official 2.44 Milestone?

Up to r1116 x264 will work with Avidemux 2.4.4. Starting with r1117 it won\'t, as the API has changed in r1117.

I patched my x264 r1119 builds to make them work with current Avidemux 2.5, so they should work with Avidemux 2.4.4 too.

However once Avidemux 2.5 has been updated for the recent x264 API changes, I will no longer patch my builds.

Therefore upcoming x264 builds will no longer work with Avidemux 2.4.4 very soon !!!

Quote from: apollo567Where can I find to information about the Version changes please ?

x264 GIT repository:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=log
Title: libx264 GIT builds
Post by: LoRd_MuldeR on March 08, 2009, 01:14:02 AM
libx264 SVN-r1123:
http://www.mediafire.com/file/md2mocjjyum/libx264-r1123-gcc433-fprofiled-core66.7z

Compiled with MinGW GCC 4.3.3-tdm-1, march=pentium2, fprofiled. Tested with Avidemux 2.5 r4658.
Title: libx264 GIT builds
Post by: apollo567 on March 08, 2009, 07:45:41 AM
Good morning,

as R1116 seems to be the latest stable Version of the lib264 for the Milestone Release.
May I ask where to find this Version please ?

Regards
Achim
Title: libx264 GIT builds
Post by: LoRd_MuldeR on March 08, 2009, 01:41:14 PM
You can use the r1115 or r1123 build, which I posted in this thread ;)

Again I patched r1123 to work with API version 66, as Avidemux 2.5 has not been updated for API version 67 yet.
Therefore the r1123 build should work Avidemux 2.4.4 Final too.

As soon as Avidemux 2.5 is updated to x264 API version 67, I finally will not need to patch the builds any longer.
This will then break compatibility to Avidemux 2.4.4, which is stuck at API version 66 (as it won\'t be updated).
Title: libx264 GIT builds
Post by: LoRd_MuldeR on March 08, 2009, 02:25:59 PM
libx264 SVN-r1125:

MinGW GCC 4.3.3-tdm-1:
http://www.mediafire.com/file/y2i5nwiyyq4/libx264-r1125-gcc433-fprofiled-core66.7z

MinGW GCC 4.2.1-sjlj:
http://www.mediafire.com/file/2zm2zyhcjmc/libx264-r1125-gcc421-fprofiled-core66.7z

MinGW GCC 3.4.5-r3:
http://www.mediafire.com/file/jth0mymrmjh/libx264-r1125-gcc345-fprofiled-core66.7z

All builds: march=pentium2, fprofiled. Tested with Avidemux 2.5 SVN-r4658 -and- 2.4.4 Final.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on March 10, 2009, 01:24:09 PM
libx264 SVN-r1127:

MinGW GCC 4.3.3-tdm-1:
http://www.mediafire.com/file/wmdw3tzmzma/libx264-r1127-gcc433-fprofiled-core66.7z

MinGW GCC 4.2.1-sjlj:
http://www.mediafire.com/file/0jy5mtdmnec/libx264-r1127-gcc421-fprofiled-core66.7z

MinGW GCC 3.4.5-r3:
http://www.mediafire.com/file/yodvnmayxm2/libx264-r1127-gcc345-fprofiled-core66.7z

All builds: march=pentium2, fprofiled. Tested with Avidemux 2.5 SVN-r4658 -and- 2.4.4 Final.
Title: libx264 GIT builds
Post by: Don't Blink on March 13, 2009, 04:32:06 AM
Thank you  - from me and everyone else who is getting this error

AppName: avidemux2_qt4.exe    AppVer: 2.5.0.4658    ModName: libx264-66.dll
ModVer: 0.0.0.0    Offset: 0004effd
Title: libx264 GIT builds
Post by: DarkZell666 on March 13, 2009, 09:25:15 AM
With which revision and build of libx264 ? :rolleyes:

Did you try the GCC 3.4.5-r3 build ? It\'s supposed to be less prone to crashing than the GCC 4 builds IIRC.
Does the same build also crash in avidemux 2.4.4 ?
Title: libx264 GIT builds
Post by: LoRd_MuldeR on March 13, 2009, 01:54:08 PM
Quote from: DarkZell666With which revision and build of libx264 ? :rolleyes:

Did you try the GCC 3.4.5-r3 build ? It\'s supposed to be less prone to crashing than the GCC 4 builds IIRC.
Does the same build also crash in avidemux 2.4.4 ?

That, plus: When does it crash? And post your Avidemux log file please! ;)

BTW: This looks like it crashed the \"hard\" way. Usually Avidemux\' exception handler would catch the exception and make a back-trace. But that looks like Windows\' crash dialog popped up, which indicates a more serious problem...
Title: libx264 GIT builds
Post by: LoRd_MuldeR on March 15, 2009, 09:59:28 PM
Here\'s yet another attempt:

libx264 SVN-r1127, cross-compiled with GCC 4.2.1 from Ubuntu:
http://www.mediafire.com/file/mttndtun3qb/libx264-r1127-gcc421-cross-core66.7z

This build is not fprofiled for obvious reasons. Tested with Avidemux 2.5 SVN-r4685.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on March 18, 2009, 07:18:57 PM
libx264 SVN-r1128:

MinGW GCC 4.3.3-tdm-1:
http://www.mediafire.com/file/xi5dlk1lmwo/libx264-r1128-gcc433-fprofiled-core66.7z

MinGW GCC 4.2.1-sjlj:
http://www.mediafire.com/file/mmjmmctf5jz/libx264-r1128-gcc421-fprofiled-core66.7z

MinGW GCC 3.4.5-r3:
http://www.mediafire.com/file/yjjdzu5mmy5/libx264-r1128-gcc345-fprofiled-core66.7z

Cross-compiled from Ubuntu:
http://www.mediafire.com/file/zgzn1zh5gli/libx264-r1128-cross-gcc421-core66.7z

All builds: march=pentium2, fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on March 19, 2009, 11:19:01 PM
libx264 SVN-r1129:

MinGW GCC 4.3.3-tdm-1:
http://www.mediafire.com/file/dzjgomkt2jm/libx264-r1129-gcc433-fprofiled-core66.7z

MinGW GCC 4.2.1-sjlj:
http://www.mediafire.com/file/f1oqndjonvn/libx264-r1129-gcc421-fprofiled-core66.7z

MinGW GCC 3.4.5-r3:
http://www.mediafire.com/file/wzim0rgzwqw/libx264-r1129-gcc345-fprofiled-core66.7z

All builds: march=pentium2, fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on March 27, 2009, 11:47:39 AM
libx264 SVN-r1130:

MinGW GCC 4.3.3-tdm-1:
http://www.mediafire.com/file/jvl0hxdwzhv/libx264-r1130-gcc433-fprofiled-core66.7z

MinGW GCC 4.2.1-sjlj:
http://www.mediafire.com/file/tmdm5nwzumc/libx264-r1130-gcc421-fprofiled-core66.7z

MinGW GCC 3.4.5-r3:
http://www.mediafire.com/file/qynhyly2zjr/libx264-r1130-gcc345-fprofiled-core66.7z

All builds: march=pentium2, fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.
Updated pthreads library, latest changelog entry: 2009-mar-19.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on March 31, 2009, 01:50:40 PM
libx264 SVN-r1134:

MinGW GCC 4.3.3-tdm-1:
http://www.mediafire.com/file/tnof2oqnmzw/libx264-r1134-gcc433-fprofiled-core66.7z

MinGW GCC 4.2.1-sjlj:
http://www.mediafire.com/file/tm3mymhj0ey/libx264-r1134-gcc421-fprofiled-core66.7z

MinGW GCC 3.4.5-r3:
http://www.mediafire.com/file/4mmruttklnz/libx264-r1134-gcc345-fprofiled-core66.7z

All builds: march=pentium2, fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on April 04, 2009, 11:45:13 AM
libx264 SVN-r1136:

libx264-r1136, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1136M-gcc433-core2-fprofiled.7z)
libx264-r1136, MinGW GCC 4.3.3, optimized for K8 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1136M-gcc433-k8-fprofiled.7z)
libx264-r1136, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1136M-gcc433-pentium2-fprofiled.7z)
libx264-r1136, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1136M-gcc421-pentium2-fprofiled.7z)
libx264-r1136, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1136M-gcc345-pentium2-fprofiled.7z)

All builds are fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.
The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on April 07, 2009, 12:20:53 PM
libx264 SVN-r1137:

libx264-r1137, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1137M-gcc433-core2-fprofiled.7z)
libx264-r1137, MinGW GCC 4.3.3, optimized for K8 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1137M-gcc433-k8-fprofiled.7z)
libx264-r1137, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1137M-gcc433-pentium2-fprofiled.7z)
libx264-r1137, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1137M-gcc421-pentium2-fprofiled.7z)
libx264-r1137, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1137M-gcc345-pentium2-fprofiled.7z)

All builds are fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.
The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on April 09, 2009, 11:52:15 AM
libx264 SVN-r1139:

libx264-r1139, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1139M-gcc433-core2-fprofiled.7z)
libx264-r1139, MinGW GCC 4.3.3, optimized for K8 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1139M-gcc433-k8-fprofiled.7z)
libx264-r1139, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1139M-gcc433-pentium2-fprofiled.7z)
libx264-r1139, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1139M-gcc421-pentium2-fprofiled.7z)
libx264-r1139, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1139M-gcc345-pentium2-fprofiled.7z)

All builds are fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.
The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on April 15, 2009, 12:48:10 AM
libx264 SVN-r1140:

libx264-r1140, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1140M-gcc433-core2-fprofiled.7z)
libx264-r1140, MinGW GCC 4.3.3, optimized for K8 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1140M-gcc433-k8-fprofiled.7z)
libx264-r1140, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1140M-gcc433-pentium2-fprofiled.7z)
libx264-r1140, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1140M-gcc421-pentium2-fprofiled.7z)
libx264-r1140, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1140M-gcc345-pentium2-fprofiled.7z)

All builds are fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.
The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on April 19, 2009, 12:30:35 PM
libx264 SVN-r1143:

libx264-r1143, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1143M-gcc433-core2-fprofiled.7z)
libx264-r1143, MinGW GCC 4.3.3, optimized for K8 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1143M-gcc433-k8-fprofiled.7z)
libx264-r1143, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1143M-gcc433-pentium2-fprofiled.7z)
libx264-r1143, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1143M-gcc421-pentium2-fprofiled.7z)
libx264-r1143, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1143M-gcc345-pentium2-fprofiled.7z)

All builds are fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.
The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on April 22, 2009, 11:40:14 PM
libx264 SVN-r1145:

libx264-r1145, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-core2-fprofiled.7z)
libx264-r1145, MinGW GCC 4.3.3, optimized for K8 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-k8-fprofiled.7z)
libx264-r1145, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-pentium2-fprofiled.7z)
libx264-r1145, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc421-pentium2-fprofiled.7z)
libx264-r1145, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc345-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4 any longer. Please update to Avidemux 2.5 SVN-r4758 or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on May 01, 2009, 10:04:18 PM
libx264 SVN-r1145:

libx264-r1145, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc440-core2-fprofiled.7z)
libx264-r1145, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc440-amdfam10-fprofiled.7z)
libx264-r1145, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc440-pentium2-fprofiled.7z)
libx264-r1145, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-core2-fprofiled.7z)
libx264-r1145, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-amdfam10-fprofiled.7z)
libx264-r1145, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-pentium2-fprofiled.7z)
libx264-r1145, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc345-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4 any longer. Please update to Avidemux 2.5 SVN-r4758 or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on May 10, 2009, 12:33:29 PM
libx264 SVN-r1148:

libx264-r1148, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc440-core2-fprofiled.7z)
libx264-r1148, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc440-amdfam10-fprofiled.7z)
libx264-r1148, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc440-pentium2-fprofiled.7z)

libx264-r1148, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc433-core2-fprofiled.7z)
libx264-r1148, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc433-amdfam10-fprofiled.7z)
libx264-r1148, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc433-pentium2-fprofiled.7z)

libx264-r1148, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc421-pentium2-fprofiled.7z)
libx264-r1148, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc345-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4763 or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on May 13, 2009, 02:58:44 PM
libx264 SVN-r1148 using experimental AutoVAQ patch v0.2 by BugMaster:

libx264-r1148, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1148M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1148, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1148M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1148, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1148M-autovaq-gcc440-pentium2-fprofiled.7z)

libx264-r1148, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1148M-autovaq-gcc433-core2-fprofiled.7z)
libx264-r1148, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1148M-autovaq-gcc433-amdfam10-fprofiled.7z)
libx264-r1148, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1148M-autovaq-gcc433-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4763 or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster\'s patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Again using the \"force_align_arg_pointer\" attribute to avoid crash, so only GCC 4.x builds this time.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on May 19, 2009, 05:53:54 PM
libx264 SVN-r1153:

libx264-r1153, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc440-core2-fprofiled.7z)
libx264-r1153, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc440-amdfam10-fprofiled.7z)
libx264-r1153, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc440-pentium2-fprofiled.7z)

libx264-r1153, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc433-core2-fprofiled.7z)
libx264-r1153, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc433-amdfam10-fprofiled.7z)
libx264-r1153, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc433-pentium2-fprofiled.7z)

libx264-r1153, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc421-pentium2-fprofiled.7z)
libx264-r1153, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc345-pentium2-fprofiled.7z)

libx264 SVN-r1153 using experimental AutoVAQ patch v0.2 by BugMaster:

libx264-r1153, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1153M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1153, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1153M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1153, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1153M-autovaq-gcc440-pentium2-fprofiled.7z)

libx264-r1153, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1153M-autovaq-gcc433-core2-fprofiled.7z)
libx264-r1153, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1153M-autovaq-gcc433-amdfam10-fprofiled.7z)
libx264-r1153, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1153M-autovaq-gcc433-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4763 or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster\'s patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the \"force_align_arg_pointer\" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on May 24, 2009, 10:51:29 PM
libx264 SVN-r1158:

libx264-r1158, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1158M-gcc440-core2-fprofiled.7z)
libx264-r1158, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1158M-gcc440-amdfam10-fprofiled.7z)
libx264-r1158, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1158M-gcc440-pentium2-fprofiled.7z)

libx264-r1158, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1158M-gcc433-core2-fprofiled.7z)
libx264-r1158, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1158M-gcc433-amdfam10-fprofiled.7z)
libx264-r1158, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1158M-gcc433-pentium2-fprofiled.7z)

libx264-r1158, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1158M-gcc421-pentium2-fprofiled.7z)
libx264-r1158, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1158M-gcc345-pentium2-fprofiled.7z)

libx264 SVN-r1158 using experimental AutoVAQ patch v0.2 by BugMaster:

libx264-r1158, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1158M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1158, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1158M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1158, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1158M-autovaq-gcc440-pentium2-fprofiled.7z)

libx264-r1158, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1158M-autovaq-gcc433-core2-fprofiled.7z)
libx264-r1158, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1158M-autovaq-gcc433-amdfam10-fprofiled.7z)
libx264-r1158, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1158M-autovaq-gcc433-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4763 or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster\'s patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the \"force_align_arg_pointer\" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on May 27, 2009, 08:11:53 PM
libx264 SVN-r1162:

libx264-r1162, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1162M-gcc440-core2-fprofiled.7z)
libx264-r1162, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1162M-gcc440-amdfam10-fprofiled.7z)
libx264-r1162, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1162M-gcc440-pentium2-fprofiled.7z)

libx264-r1162, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1162M-gcc433-core2-fprofiled.7z)
libx264-r1162, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1162M-gcc433-amdfam10-fprofiled.7z)
libx264-r1162, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1162M-gcc433-pentium2-fprofiled.7z)

libx264-r1162, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1162M-gcc421-pentium2-fprofiled.7z)
libx264-r1162, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1162M-gcc345-pentium2-fprofiled.7z)

libx264 SVN-r1162 using experimental AutoVAQ patch v0.2 by BugMaster:

libx264-r1162, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1162M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1162, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1162M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1162, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1162M-autovaq-gcc440-pentium2-fprofiled.7z)

libx264-r1162, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1162M-autovaq-gcc433-core2-fprofiled.7z)
libx264-r1162, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1162M-autovaq-gcc433-amdfam10-fprofiled.7z)
libx264-r1162, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1162M-autovaq-gcc433-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4871 or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster\'s patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the \"force_align_arg_pointer\" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on June 11, 2009, 02:28:33 PM
libx264 SVN-r1165:

libx264-r1165, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1165M-gcc440-core2-fprofiled.7z)
libx264-r1165, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1165M-gcc440-amdfam10-fprofiled.7z)
libx264-r1165, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1165M-gcc440-pentium2-fprofiled.7z)

libx264-r1165, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1165M-gcc433-core2-fprofiled.7z)
libx264-r1165, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1165M-gcc433-amdfam10-fprofiled.7z)
libx264-r1165, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1165M-gcc433-pentium2-fprofiled.7z)

libx264-r1165, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1165M-gcc421-pentium2-fprofiled.7z)
libx264-r1165, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1165M-gcc345-pentium2-fprofiled.7z)

libx264 SVN-r1165 using experimental AutoVAQ patch v0.2 by BugMaster:

libx264-r1165, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1165M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1165, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1165M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1165, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1165M-autovaq-gcc440-pentium2-fprofiled.7z)

libx264-r1165, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1165M-autovaq-gcc433-core2-fprofiled.7z)
libx264-r1165, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1165M-autovaq-gcc433-amdfam10-fprofiled.7z)
libx264-r1165, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1165M-autovaq-gcc433-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4871 or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster\'s patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the \"force_align_arg_pointer\" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on June 20, 2009, 01:12:49 AM
libx264 SVN-r1169:

libx264-r1169, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1169M-gcc440-core2-fprofiled.7z)
libx264-r1169, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1169M-gcc440-amdfam10-fprofiled.7z)
libx264-r1169, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1169M-gcc440-pentium2-fprofiled.7z)

libx264-r1169, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1169M-gcc421-pentium2-fprofiled.7z)
libx264-r1169, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1169M-gcc345-pentium2-fprofiled.7z)

libx264 SVN-r1169 using experimental AutoVAQ patch v0.2 by BugMaster:

libx264-r1169, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1169M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1169, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1169M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1169, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1169M-autovaq-gcc440-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4871 or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster\'s patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the \"force_align_arg_pointer\" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on June 22, 2009, 10:43:45 PM
libx264 SVN-r1171:

libx264-r1171, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1171M-gcc440-core2-fprofiled.7z)
libx264-r1171, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1171M-gcc440-amdfam10-fprofiled.7z)
libx264-r1171, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1171M-gcc440-pentium2-fprofiled.7z)

libx264-r1171, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1171M-gcc421-pentium2-fprofiled.7z)
libx264-r1171, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1171M-gcc345-pentium2-fprofiled.7z)

libx264 SVN-r1171 using experimental AutoVAQ patch v0.2 by BugMaster:

libx264-r1171, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1171M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1171, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1171M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1171, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1171M-autovaq-gcc440-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4871 or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster\'s patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the \"force_align_arg_pointer\" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on June 23, 2009, 09:08:09 PM
libx264 SVN-r1171 using experimental AutoVAQ patch v0.3 by BugMaster:

libx264-r1171, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1171M-autovaq-gcc440-core2-fprofiled.new.7z)
libx264-r1171, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1171M-autovaq-gcc440-amdfam10-fprofiled.new.7z)
libx264-r1171, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1171M-autovaq-gcc440-pentium2-fprofiled.new.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4871 or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster\'s patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the \"force_align_arg_pointer\" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on June 26, 2009, 01:29:20 PM
libx264 SVN-r1173:

libx264-r1173, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1173M-gcc440-core2-fprofiled.7z)
libx264-r1173, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1173M-gcc440-amdfam10-fprofiled.7z)
libx264-r1173, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1173M-gcc440-pentium2-fprofiled.7z)

libx264-r1173, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1173M-gcc421-pentium2-fprofiled.7z)
libx264-r1173, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1173M-gcc345-pentium2-fprofiled.7z)

libx264 SVN-r1173 using experimental AutoVAQ patch v0.3 by BugMaster:

libx264-r1173, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1173M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1173, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1173M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1173, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1173M-autovaq-gcc440-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4871 or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster\'s patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the \"force_align_arg_pointer\" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on July 07, 2009, 11:10:19 PM
libx264 SVN-r1179:

libx264-r1179, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1179M-gcc440-core2-fprofiled.7z)
libx264-r1179, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1179M-gcc440-amdfam10-fprofiled.7z)
libx264-r1179, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1179M-gcc440-pentium2-fprofiled.7z)

libx264-r1179, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1179M-gcc421-pentium2-fprofiled.7z)
libx264-r1179, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1179M-gcc345-pentium2-fprofiled.7z)

libx264 SVN-r1179 using experimental AutoVAQ patch v0.3 by BugMaster:

libx264-r1179, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1179M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1179, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1179M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1179, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1179M-autovaq-gcc440-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4871 or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster\'s patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the \"force_align_arg_pointer\" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.

Note: Until Avidemux is updated to core-68, you will need to rename \"libx264-68.dll\" to \"libx264-67.dll\" as a workaround.
This single time renaming the DLL is allowed, because the ABI didn\'t change between core-67 and core-68.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on July 11, 2009, 12:40:45 PM
libx264 SVN-r1181:
[list=*]

libx264 SVN-r1181 using experimental AutoVAQ patch v0.3 by BugMaster:
[list=*]

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5031 (http://forum.doom9.org/showpost.php?p=1304262&postcount=1181) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster\'s patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the \"force_align_arg_pointer\" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on July 17, 2009, 12:58:38 PM
libx264 SVN-r1183:
[list=*]
libx264 SVN-r1183 using experimental AutoVAQ patch v0.3 by BugMaster:
[list=*]
These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5087 (http://forum.doom9.org/showpost.php?p=1305115&postcount=1184) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster\'s patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the \"force_align_arg_pointer\" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on July 20, 2009, 02:02:31 PM
libx264 SVN-r1184:
[list=*]
libx264 SVN-r1184 with AutoVAQ enabled:
[list=*]
These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5104 (http://forum.doom9.org/showpost.php?p=1306367&postcount=1188) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on July 26, 2009, 07:25:08 PM
libx264 SVN-r1189:
[list=*]
libx264 SVN-r1189 with AutoVAQ enabled:
[list=*]
These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5104 (http://forum.doom9.org/showpost.php?p=1306367&postcount=1188) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Now using a custom patch that will increase SubME by one in order to allow the new SubME=10 in Avidemux (until the GUI is updated). However be aware that SubME=10 requires Trellis=2, otherwise it will fall back to SubeMe=9.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on July 27, 2009, 01:10:41 PM
libx264 SVN-r1190:
[list=*]
libx264 SVN-r1190 with AutoVAQ enabled:
[list=*]
These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5104 (http://forum.doom9.org/showpost.php?p=1306367&postcount=1188) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Now using a less \"aggressive\" patch to enable SubMe=10 in Avidemux:
Only SubMe=9 will be increased to SubMe=10 and even that only if Trellis=2 is used. Other SubMe modes aren\'t effected.
This workaround will be used until the x264 GUI in Avidemux is updated with respect to the recent changes...
Title: libx264 GIT builds
Post by: LoRd_MuldeR on July 28, 2009, 12:50:33 PM
libx264 SVN-r1192:
[list=*]
libx264 SVN-r1192 with AutoVAQ enabled:
[list=*]
These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5104 (http://forum.doom9.org/showpost.php?p=1306367&postcount=1188) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Now using a less \"aggressive\" patch to enable SubMe=10 in Avidemux:
Only SubMe=9 will be increased to SubMe=10 and even that only if Trellis=2 is used. Other SubMe modes aren\'t effected.
This workaround will be used until the x264 GUI in Avidemux is updated with respect to the recent changes...
Title: libx264 GIT builds
Post by: LoRd_MuldeR on July 28, 2009, 04:21:39 PM
libx264 SVN-r1193:
[list=*]
libx264 SVN-r1193 with AutoVAQ enabled:
[list=*]
These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5104 (http://forum.doom9.org/showpost.php?p=1306367&postcount=1188) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Now using a less \"aggressive\" patch to enable SubMe=10 in Avidemux:
Only SubMe=9 will be increased to SubMe=10 and even that only if Trellis=2 is used. Other SubMe modes aren\'t effected.
This workaround will be used until the x264 GUI in Avidemux is updated with respect to the recent changes...
Title: libx264 GIT builds
Post by: LoRd_MuldeR on July 29, 2009, 02:16:00 PM
libx264 SVN-r1195:
[list=*]
libx264 SVN-r1195 with AutoVAQ enabled:
[list=*]
These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5104 (http://forum.doom9.org/showpost.php?p=1306367&postcount=1188) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Now using a less \"aggressive\" patch to enable SubMe=10 in Avidemux:
Only SubMe=9 will be increased to SubMe=10 and even that only if Trellis=2 is used. Other SubMe modes aren\'t effected.
This workaround will be used until the x264 GUI in Avidemux is updated with respect to the recent changes.
(SubME=10 was borked in previous revisions of x264, so I recommend updating now)
Title: libx264 GIT builds
Post by: LoRd_MuldeR on August 03, 2009, 08:23:36 PM
libx264 SVN-r1195:
[list=*]
libx264 SVN-r1195 with AutoVAQ enabled:
[list=*]
These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5181 (http://forum.doom9.org/showpost.php?p=1310205&postcount=1200) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Re-built using Komisar\'s GCC 4.4.1 with Graphite loop transform framework (Link (http://forum.doom9.org/showpost.php?p=1311229&postcount=2118)).
Title: libx264 GIT builds
Post by: LoRd_MuldeR on August 12, 2009, 08:41:48 PM
libx264 SVN-r1206 with MB-Tree Ratecontrol:
[list=*]
libx264 SVN-r1206 without MB-Tree Ratecontrol:
[list=*]
libx264 SVN-r1206 with AutoVAQ enabled:
[list=*]
libx264 SVN-r1206 legacy compiler builds:
[list=*]
These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5234 (http://forum.doom9.org/showpost.php?p=1314049&postcount=1210) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Re-built using Komisar\'s GCC 4.4.1 with Graphite loop transform framework (Link (http://forum.doom9.org/showpost.php?p=1311229&postcount=2118)).
Title: libx264 GIT builds
Post by: LoRd_MuldeR on August 13, 2009, 11:50:56 PM
libx264 SVN-r1210 with MB-Tree Ratecontrol:
[list=*]
libx264 SVN-r1210 without MB-Tree Ratecontrol:
[list=*]
libx264 SVN-r1210 with AutoVAQ enabled:
[list=*]
libx264 SVN-r1210 legacy compiler builds:
[list=*]
These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5234 (http://forum.doom9.org/showpost.php?p=1314049&postcount=1210) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Re-built using Komisar\'s GCC 4.4.1 with Graphite loop transform framework (Link (http://forum.doom9.org/showpost.php?p=1311229&postcount=2118)).
Title: libx264 GIT builds
Post by: LoRd_MuldeR on August 17, 2009, 09:35:08 PM
libx264 SVN-r1214 with MB-Tree Ratecontrol:
[list=*]
libx264 SVN-r1214 without MB-Tree Ratecontrol:
[list=*]
libx264 SVN-r1214 with AutoVAQ enabled:
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 (http://forum.doom9.org/showpost.php?p=1315631&postcount=1216) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

This build fixes a bug (http://forum.doom9.org/showthread.php?t=148956) in QPRD (SubME 10) and greatly improves (http://forum.doom9.org/showthread.php?t=148964) 1-Pass VBV.
Update to x264 r1214+ is highly recommended.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on August 19, 2009, 04:33:13 PM
libx264 SVN-r1217 with MB-Tree Ratecontrol:
[list=*]
libx264 SVN-r1217 without MB-Tree Ratecontrol:
[list=*]
libx264 SVN-r1217 with AutoVAQ enabled:
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 (http://forum.doom9.org/showpost.php?p=1315631&postcount=1216) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

This build was patched back to core-70 in order to make it work with Avidemux 2.5.1 release version.
Hope I didn\'t break it ^^
Title: libx264 GIT builds
Post by: LoRd_MuldeR on August 20, 2009, 09:30:50 PM
libx264 SVN-r1222 with MB-Tree Ratecontrol:
[list=*]
libx264 SVN-r1222 without MB-Tree Ratecontrol:
[list=*]
libx264 SVN-r1222 with AutoVAQ enabled:
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 (http://forum.doom9.org/showpost.php?p=1315631&postcount=1216) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

This build was patched back to core-70 in order to make it work with Avidemux 2.5.1 release version.
Hope I didn\'t break it ^^
Title: libx264 GIT builds
Post by: LoRd_MuldeR on August 23, 2009, 11:18:35 PM
libx264 SVN-r1222:
[list=*]
libx264 SVN-r1222 without MB-Tree Ratecontrol:
[list=*]
libx264 SVN-r1222 with AutoVAQ enabled:
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5268 (http://forum.doom9.org/showpost.php?p=1317796&postcount=1231) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Re-built r1222 with core-72, because Avidemux was updated now. So I don\'t need to patch x264 back to core-70 any longer. The less workarounds we need, the better ^^
Title: libx264 GIT builds
Post by: LoRd_MuldeR on August 25, 2009, 01:55:10 PM
libx264 SVN-r1232:
[list=*]
libx264 SVN-r1232 without MB-Tree Ratecontrol:
[list=*]
libx264 SVN-r1232 with AutoVAQ enabled:
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5268 (http://forum.doom9.org/showpost.php?p=1317796&postcount=1231) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Re-built x264 r1232 with TDM\'s MinGW/GCC 4.3.3, which hopefully fixes the problem discussed in this (http://forum.doom9.org/showthread.php?p=1318401#post1318401) thread.
Waiting for feedback...
Title: libx264 GIT builds
Post by: LoRd_MuldeR on August 27, 2009, 02:20:31 PM
libx264 SVN-r1235:
[list=*]
libx264 SVN-r1235 without MB-Tree Ratecontrol:
[list=*]
libx264 SVN-r1235 with AutoVAQ enabled:
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5273 (http://forum.doom9.org/showpost.php?p=1319348&postcount=1246) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

I added a build with no ASM, because it seems that x264 r1233+ won\'t run on Non-SSE CPU\'s.
Well, unless I completely disable ASM. But that build is sloooooow, of course...
Title: libx264 GIT builds
Post by: LoRd_MuldeR on August 29, 2009, 01:23:05 AM
libx264 SVN-r1239:
[list=*]
libx264 SVN-r1239 without MB-Tree Ratecontrol:
[list=*]
libx264 SVN-r1239 with AutoVAQ enabled:
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5273 (http://forum.doom9.org/showpost.php?p=1319348&postcount=1246) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

I added a build with no ASM, because it seems that x264 r1233+ won\'t run on Non-SSE CPU\'s.
Well, unless I completely disable ASM. But that build is sloooooow, of course...
Title: libx264 GIT builds
Post by: LoRd_MuldeR on September 01, 2009, 02:45:23 AM
libx264 SVN-r1243:
[list=*]
libx264 SVN-r1243 using four slices:
[list=*]
libx264 SVN-r1243 with AutoVAQ enabled:
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 5281 (http://forum.doom9.org/showpost.php?p=1319838&postcount=1262) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

This build was patched back to core 72 to make it work with current Avidemux (hopefully).
Now with support for slices (http://img525.imageshack.us/img525/3856/slices.jpg), for details have a look at this (http://forum.doom9.org/showthread.php?p=1320574#post1320574) thread!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on September 09, 2009, 10:48:00 PM
libx264 SVN-r1251:
[list=*]
libx264 SVN-r1251 using four slices:
[list=*]
libx264 SVN-r1251 with AutoVAQ enabled:
[list=*]
libx264 SVN-r1251 with MB-Tree disabled:
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 5327 (http://forum.doom9.org/showpost.php?p=1323744&postcount=1292) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Now with Threaded Lookahead (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=5b3c89c592e412fc02fd8001ee361ea50c249153) which greatly increases performance with lookahead-intensive settings.
This is enabled by default.
Title: libx264 GIT builds
Post by: Aigio on September 12, 2009, 04:12:29 PM
does this work on windows 7?
Title: libx264 GIT builds
Post by: LoRd_MuldeR on September 12, 2009, 04:16:05 PM
Quote from: Aigiodoes this work on windows 7?

Sure. In fact my libx264 builds are compiled and tested on a Win7 machine now ;)
Title: libx264 GIT builds
Post by: outlaw on September 12, 2009, 06:32:10 PM
I own a phenom 9950, and i checked performance for both core2 and k10 versions,
and they seem to be exactly the same as far as transcode times...

k10 optimization come from the compiler ?
Title: libx264 GIT builds
Post by: LoRd_MuldeR on September 12, 2009, 06:54:47 PM
Quote from: outlawI own a phenom 9950, and i checked performance for both core2 and k10 versions,
and they seem to be exactly the same as far as transcode times...

k10 optimization come from the compiler ?

Yes. And those compiler-optimizations only apply to the plain C code in x264. But all the performance-critical functions in x264 are written as hand-optimized assembler code anyway. x264\'s assembler optimizations are selected at runtime depending on your CPU\'s capabilities. So the additional speed-up that can be achieved with compiler-optimizations isn\'t that great. Therefore you shouldn\'t expect too much! However even the slightest speed-up should be welcome. Last but not least people claim that the ICL produces slightly faster x264 binaries, compared to the GCC. My builds are GCC only...
Title: libx264 GIT builds
Post by: LoRd_MuldeR on September 15, 2009, 12:56:16 AM
libx264 SVN-r1259:
[list=*]
libx264 SVN-r1259 using four slices:
[list=*]
libx264 SVN-r1259 with AutoVAQ enabled:
[list=*]
libx264 SVN-r1259 with MB-Tree disabled:
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5327 (http://forum.doom9.org/showpost.php?p=1323744&postcount=1292) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

This build fixes the crash that occured when the encode was aborted prematurely.
It turns out that was a bug in x264 itself. Fixed in r1253.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on September 24, 2009, 11:33:52 AM
libx264 SVN-r1259:
[list=*]
libx264 SVN-r1259 using four slices:
[list=*]
libx264 SVN-r1259 with AutoVAQ enabled:
[list=*]
libx264 SVN-r1259 with MB-Tree disabled:
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5327 (http://forum.doom9.org/showpost.php?p=1323744&postcount=1292) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

I re-compiled r1259, this time with the \"real\" fix for the encoder_close crash.
Cannot provide builds of r1260 or later for Avidemux yet, because the x264 API was changed.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on October 05, 2009, 02:18:54 PM
libx264 SVN-r1271:
[list=*]
libx264 SVN-r1271 using four slices:
[list=*]
libx264 SVN-r1271 with AutoVAQ enabled:
[list=*]
libx264 SVN-r1271 with MB-Tree disabled:
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5369 (http://forum.doom9.org/showpost.php?p=1331731&postcount=1323) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Avidemux has been updated for the new x264 API (http://forum.doom9.org/showthread.php?t=149593), finally. So we can use up-to-date x264 again :)
Please update Avidemux before installing the core-76 builds of libx264!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on October 07, 2009, 02:12:26 PM
libx264 SVN-r1278:
[list=*]
libx264 SVN-r1278 using four slices:
[list=*]
libx264 SVN-r1278 with AutoVAQ enabled:
[list=*]
libx264 SVN-r1278 with MB-Tree disabled:
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5369 (http://forum.doom9.org/showpost.php?p=1331731&postcount=1323) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on October 09, 2009, 06:07:12 PM
libx264 SVN-r1278:
[list=*]
libx264 SVN-r1278 using four slices:
[list=*]
libx264 SVN-r1278 with AutoVAQ enabled:
[list=*]
libx264 SVN-r1278 with MB-Tree disabled:
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5369 (http://forum.doom9.org/showpost.php?p=1331731&postcount=1323) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Re-compiled r1278 with GCC 4.4.1 TDM-2, which should fix the bug in TDM\'s previous GCC 4.4.1 release.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on October 11, 2009, 03:39:14 PM
libx264 SVN-r1278:
[list=*]
libx264 SVN-r1278 using four slices:
[list=*]
libx264 SVN-r1278 with AutoVAQ enabled:
[list=*]
libx264 SVN-r1278 with MB-Tree disabled:
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5369 (http://forum.doom9.org/showpost.php?p=1331731&postcount=1323) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Re-compiled r1278 with GCC 4.4.1, again. This time I included a patch (http://pastebin.ca/1612400) to avoid miscompilation with GCC 4.4.x, as suggested here (http://forum.doom9.org/showthread.php?p=1333035#post1333035). So if you used one of the previous GCC 4.4.1 builds, then you are urged to update now!

I\'m not sure if the GCC 4.3.4/4.3.3 builds were broken too, as the visual difference is generally unnoticeable...
Title: libx264 GIT builds
Post by: LoRd_MuldeR on October 13, 2009, 12:25:59 PM
libx264 SVN-r1292:
[list=*]
libx264 SVN-r1292 using four slices:
[list=*]
libx264 SVN-r1292 with AutoVAQ enabled:
[list=*]
libx264 SVN-r1292 with MB-Tree disabled:
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5369 (http://forum.doom9.org/showpost.php?p=1331731&postcount=1323) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Miscompilation with GCC 4.4.x should be fixed (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=287641a7c54d525e0eb74925431541ffb5f9471d) now, finally.
So if you used one of the previous builds, you are urged to update now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on October 19, 2009, 10:27:15 PM
libx264 SVN-r1301:
[list=*]
libx264 SVN-r1301 using four slices:
[list=*]
libx264 SVN-r1301 with AutoVAQ enabled:
[list=*]
libx264 SVN-r1301 with MB-Tree disabled:
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5369 (http://forum.doom9.org/showpost.php?p=1331731&postcount=1323) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.


These builds were patched from core-78 to core-76 in order to make them work with the latest Avidemux build!
Hope I didn\'t break it too bad ^^
Title: libx264 GIT builds
Post by: LoRd_MuldeR on October 25, 2009, 09:29:12 PM
libx264 SVN-r1309:
libx264 SVN-r1309 using four slices:
libx264 SVN-r1309 with AutoVAQ enabled:
libx264 SVN-r1309 with MB-Tree disabled:
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5369 (http://forum.doom9.org/showpost.php?p=1331731&postcount=1323) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on October 30, 2009, 04:55:20 PM
libx264 SVN-r1318:
[list=*]
______________________________________________________


libx264 SVN-r1318 using four slices:
[list=*]
libx264 SVN-r1318 with AutoVAQ enabled:
[list=*]
libx264 SVN-r1318 with MB-Tree disabled:
[list=*]
______________________________________________________


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5422 (http://forum.doom9.org/showpost.php?p=1338882&postcount=1354) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on November 08, 2009, 12:30:00 PM
libx264 SVN-r1318+291 with Weighted P-Frame Prediction:
[list=*]
For information about Weighted P-Frame Prediction have a look here:
[list=*]
______________________________________________________


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5422 (http://forum.doom9.org/showpost.php?p=1338882&postcount=1354) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Please take care: These builds are highly experimental, use them for testing only!
Furthermore these builds won\'t work with \"interlaced\" mode.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on November 09, 2009, 08:30:16 PM
libx264 SVN-r1331 with Weighted P-Frame Prediction:
[list=*]
______________________________________________________


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5422 (http://forum.doom9.org/showpost.php?p=1338882&postcount=1354) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Weighted P-Frame Prediction is now officially committed. For details please read the official commit message at this (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=87de2346225721e8ca68a1b59bc87133fc598a42) location. I used a custom patch to make these builds work with current Avidemux (r5422).
Unfortunately interlaced encoding won\'t work yet! Also note that CoreAVC 1.x is known to be broken with the \"smart\" weight-p mode, but libavcodec (MPlayer, ffdshow, etc) works fine.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on November 10, 2009, 06:02:26 PM
libx264 SVN-r1332 with Weighted P-Frame Prediction:
[list=*]
______________________________________________________


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5422 (http://forum.doom9.org/showpost.php?p=1338882&postcount=1354) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

This revision fixes one (of possibly many) miscompilations in weightp. The issue occurred with some GCC versions if threads > 1 and the phase of the moon was right. Therefore people are highly encouraged to update!
Title: libx264 GIT builds
Post by: lych on November 11, 2009, 06:18:28 AM
Quote from: LoRd_MuldeR...the phase of the moon was right....
:lol:
Title: libx264 GIT builds
Post by: LoRd_MuldeR on November 13, 2009, 12:12:45 AM
libx264 SVN-r1336 with Weighted P-Frame Prediction:
[list=*]
______________________________________________________


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5422 (http://forum.doom9.org/showpost.php?p=1338882&postcount=1354) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

This revision contains various Weight-P fixes. Makes results match in threaded vs. non-threaded mode.
Therefore people are highly encouraged to update asap!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on November 15, 2009, 02:13:34 PM
libx264 SVN-r1339 with Weighted P-Frame Prediction:
[list=*]
______________________________________________________


libx264 SVN-r1339 without Weighted P-Frame Prediction and MB-Tree:
[list=*]
______________________________________________________


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5422 (http://forum.doom9.org/showpost.php?p=1338882&postcount=1354) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

This revision fixes at least two possible Deadlocks in Weighted P-Frame Prediction.
Therefore people are highly encouraged to update asap!
Title: libx264 GIT builds
Post by: Brazil on November 15, 2009, 05:26:07 PM
Quote from: LoRd_MuldeRlibx264 SVN-r1339 with Weighted P-Frame Prediction:
Which weightp parameter is your build using ? 1 or 2 ?


Quote from: LoRd_MuldeRlibx264 SVN-r1339 without Weighted P-Frame Prediction and MB-Tree:
I\'m not sure to understand it properly: does this mean this build has no weightp AND no mbtree or is it no weightp WITH mbtree on ?
Title: libx264 GIT builds
Post by: LoRd_MuldeR on November 15, 2009, 09:48:59 PM
Quote from: Brazil
Quote from: LoRd_MuldeRlibx264 SVN-r1339 with Weighted P-Frame Prediction:
Which weightp parameter is your build using ? 1 or 2 ?

It\'s hardcoded to mode 2 (aka \"Smart\") in my builds, as Avidemux doesn\'t support the \"weighted_pred\" parameter yet.

BTW: You know that Avidemux creates a log file and x264 prints its complete parameter set to that log?


Quote from: Brazil
Quote from: LoRd_MuldeRlibx264 SVN-r1339 without Weighted P-Frame Prediction and MB-Tree:
I\'m not sure to understand it properly: does this mean this build has no weightp AND no mbtree or is it no weightp WITH mbtree on ?

MB-Tree is always on, unless stated otherwise. That\'s because MB-Tree is x264\'s default and it does a great job.

However in that specific build both, MB-Tree and Weighted P-Frames, are disabled :o

That was a necessary workaround: I currently must disable MB-Tree when I hardcode weighted_pred to mode 0.

In original x264 weighted_pred = 0 would be overwritten to -1 (\"Fake\" mode), if MB-Tree is enabled ;)

Again a look at the log file could have answered your question faster. Also all patches are included in the 7z file.
Title: libx264 GIT builds
Post by: Brazil on November 16, 2009, 05:10:56 PM
Quote from: LoRd_MuldeRIt\'s hardcoded to mode 2 (aka \"Smart\") in my builds, as Avidemux doesn\'t support the \"weighted_pred\" parameter yet.
OK, thanks for the info. It has to be used with care then since there are some decoders and hardware having problems with this mode AFAIK.

Quote from: LoRd_MuldeRBTW: You know that Avidemux creates a log file and x264 prints its complete parameter set to that log?
No I didn\'t know that x264 parameters were in the log.
And you know what ? I never read the log when everything is working as expected :P
I read it only in case of a crash or any other error. But thanks for the tip, it\'ll be usefull.

Quote from: LoRd_MuldeRThat\'s because MB-Tree is x264\'s default and it does a great job.
Not always. It highly depends on the source that\'s why I\'m also using your non-mbtree build sometimes.

Quote from: LoRd_MuldeRHowever in that specific build both, MB-Tree and Weighted P-Frames, are disabled :o
OK thanks. So we can consider this build as an equivalent to r1318 without mbtree then ?
Title: libx264 GIT builds
Post by: LoRd_MuldeR on November 16, 2009, 08:09:14 PM
libx264 SVN-r1342 with Weighted P-Frame Prediction:
[list=*]
______________________________________________________


libx264 SVN-r1342 without Weighted P-Frame Prediction and MB-Tree:
[list=*]
______________________________________________________


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5422 (http://forum.doom9.org/showpost.php?p=1338882&postcount=1354) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.
More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

This revision contains yet another bugfix for Weighted P-Frame Prediction. Previous revisions could produce out-of-specs H.264 streams. Therefore people are highly encouraged to update asap!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on November 16, 2009, 08:21:46 PM
Quote from: Brazil
Quote from: LoRd_MuldeRIt\'s hardcoded to mode 2 (aka \"Smart\") in my builds, as Avidemux doesn\'t support the \"weighted_pred\" parameter yet.
OK, thanks for the info. It has to be used with care then since there are some decoders and hardware having problems with this mode AFAIK.

Weighted P-Frames are 100% spec compliant. H.264 decoders that fail are broken! However there are only two known decoders that are broken with respect to Weighted-P Frames: CoreVAC 1.9.x (in software mode) and the Apple TV.

Also note that bugs in weightp which could produce out-of-specs streams has just been fixed in r1342 ;)

Quote from: Brazil
Quote from: LoRd_MuldeRHowever in that specific build both, MB-Tree and Weighted P-Frames, are disabled :o
OK thanks. So we can consider this build as an equivalent to r1318 without mbtree then ?

More or less. But other things have been changed/fixed in the meantime. So output won\'t be bit-identical, I guess...
Title: libx264 GIT builds
Post by: lych on November 17, 2009, 06:24:12 AM
Quote from: LoRd_MuldeRWeighted P-Frames are 100% spec compliant. H.264 decoders that fail are broken! However there are only two known decoders that are broken with respect to Weighted-P Frames: CoreVAC 1.9.x (in software mode) and the Apple TV.
Is CoreAVC 1.9.x broken when using CUDA as well or is it just in software mode?
Title: libx264 GIT builds
Post by: LoRd_MuldeR on November 17, 2009, 01:34:26 PM
Quote from: lych
Quote from: LoRd_MuldeRWeighted P-Frames are 100% spec compliant. H.264 decoders that fail are broken! However there are only two known decoders that are broken with respect to Weighted-P Frames: CoreVAC 1.9.x (in software mode) and the Apple TV.
Is CoreAVC 1.9.x broken when using CUDA as well or is it just in software mode?

As I said, only \"software\" mode is effected. And it will be fixed in CoreAVC 2.0, to be released this week.

In \"CUDA mode\" CoreAVC doesn\'t decode the video itself. It simply lets the \"PureVideo HD\" decoder do the all the work ;)

Actually CoreAVC doesn\'t use CUDA. It only uses the CUDA Video API to access NVIDIA\'s built-in hardware video decoder unit.

But CoreAVC does NOT implement their own H.264 decoder as CUDA Kernels to run on the GPU.

So if NVIDIA\'s hardware video decoder does handle Weightp properly (and it does), then CoreAVC in \"CUDA mode\" will too.

Hardware decoders are tested more thoroughly against the specs, because they can\'t fix bugs after fabrication :p

[EDIT]

Note that Flash Player, which had some (rare) problems too, has just been fixed. The fix is will be in Flash Player 10.1 ;)
Title: libx264 GIT builds
Post by: lych on November 18, 2009, 06:21:12 AM
Quote from: LoRd_MuldeRAs I said, only \"software\" mode is effected. And it will be fixed in CoreAVC 2.0, to be released this week.

In \"CUDA mode\" CoreAVC doesn\'t decode the video itself. It simply lets the \"PureVideo HD\" decoder do the all the work ;)

Actually CoreAVC doesn\'t use CUDA. It only uses the CUDA Video API to access NVIDIA\'s built-in hardware video decoder unit.

But CoreAVC does NOT implement their own H.264 decoder as CUDA Kernels to run on the GPU.

So if NVIDIA\'s hardware video decoder does handle Weightp properly (and it does), then CoreAVC in \"CUDA mode\" will too.

Hardware decoders are tested more thoroughly against the specs, because they can\'t fix bugs after fabrication :p

[EDIT]

Note that Flash Player, which had some (rare) problems too, has just been fixed. The fix is will be in Flash Player 10.1 ;)
AH!!!  That makes perfect sense.  I was wondering what everyone was talking about in regards to CoreAVC being broken.  I have been using coreavc in cuda mode ever since it was supported and I have never noticed any problem with my encodes.  Thanks Mulder!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on November 20, 2009, 01:40:09 AM
libx264 SVN-r1342 with Weighted P-Frame Prediction:
[list=*]
______________________________________________________


libx264 SVN-r1342 without Weighted P-Frame Prediction:
[list=*]
______________________________________________________


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5530 (http://forum.doom9.org/showpost.php?p=1345642&postcount=1379) or later now!

Recompiled x264 r1342 for the latest Avidemux build, which finally supports x264 core-79.
Interlaced encoding should work again.
Title: libx264 GIT builds
Post by: Brazil on November 20, 2009, 12:07:50 PM
Quote from: LoRd_MuldeRlibx264 SVN-r1342 with Weighted P-Frame Prediction:
libx264 SVN-r1342 without Weighted P-Frame Prediction:
Thanks for your builds :)

Any chance for a no mbtree build though ? I find in some cases the result is visually better without mbtree.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on November 20, 2009, 03:03:11 PM
I could make one, when I return back home. But that\'s not before tomorrow.

The better way of course would be an updated x264 dialog in Avidemux, which adds the missing x264 options.

So users could configure MB Tree and weightp at Runtrime, instead of having to use \"special\" builds  ;)
Title: libx264 GIT builds
Post by: Brazil on November 20, 2009, 03:37:30 PM
Quote from: LoRd_MuldeRThe better way of course would be an updated x264 dialog in Avidemux, which adds the missing x264 options.
That would be nice indeed ;)
Title: libx264 GIT builds
Post by: LoRd_MuldeR on November 21, 2009, 06:26:06 PM
libx264 SVN-r1342 with Weighted P-Frame Prediction:
[list=*]
______________________________________________________


libx264 SVN-r1342 without Weighted P-Frame Prediction:
[list=*]

libx264 SVN-r1342 without MB-Tree RC:
[list=*]
______________________________________________________


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5530 (http://forum.doom9.org/showpost.php?p=1345642&postcount=1379) or later now!

Recompiled x264 r1342 for the latest Avidemux build, which finally supports x264 core-79.
Interlaced encoding should work again. Added  builds with MB-Tree RC disabled.
Title: libx264 GIT builds
Post by: Brazil on November 22, 2009, 02:35:02 PM
Quote from: LoRd_MuldeRlibx264 SVN-r1342 without MB-Tree RC:
Nice, thanks a lot :)
Title: libx264 GIT builds
Post by: Nik on November 27, 2009, 01:33:22 PM
stupid question:
there now are options to enable/disable weighted p-frame det. and MB tree in Avidemux if I get it right
what advantages are there using the files above?
I think with core i7 I don\'t need any of them and just use the files that come avidemux?
Title: libx264 GIT builds
Post by: DarkZell666 on November 27, 2009, 01:49:56 PM
Avidemux isn\'t re-released each time there\'s a x264 update (same goes for all libraries used), so you\'ll still use the builds provided here to keep libx264 up-to-date.

Actually, there\'s still QPRD (subme=10), as well as psy-trellis missing. IIRC MuldeR sets psy-trellis to 0.15 instead of 0.0 in his builds as well :)
Title: libx264 GIT builds
Post by: LoRd_MuldeR on November 27, 2009, 04:13:15 PM
Quote from: Nikstupid question:
there now are options to enable/disable weighted p-frame det. and MB tree in Avidemux if I get it right
what advantages are there using the files above?

Those builds are fprofiled, I don\'t think Gruntster\'s builds are. And I enabled CPU-specific optimizations!

Also I use some unofficial patches. Yes, now MB-Tree and RC Lookahead can be configured from within Avidemux.

But I use more custom patches, such as my \"print_params\" and \"fast_firstpass\" patch :)

Last but not least, as stated by DarkZell666, x264 is updated frequently and I try to keep my builds up to date.

BTW: Weighted P-Prediction can NOT be configured in Avidemux yet. Or did I miss that ???

Quote from: NikI think with core i7 I don\'t need any of them and just use the files that come avidemux?

AFAIK there are no CPU-specific optimizations for Nehalem (Core i7/i5) in GCC yet.

So from what we have available at the moment, the Core2 optimized builds should work best on the Core i7/i5.

At least they should perform better than the \"generic\" builds ;)

That said, the influence of compiler optimizations is relatively small, as most important code is ASM anyway.

But any small speed-up we can get \"for free\" does matter, right?
Title: libx264 GIT builds
Post by: LoRd_MuldeR on November 27, 2009, 05:27:14 PM
libx264 SVN-r1352 with Weighted P-Frame Prediction:
[list=*]
______________________________________________________


libx264 SVN-r1352 without Weighted P-Frame Prediction:
[list=*]
______________________________________________________


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5567 or later now!

This revision contains even more bugfixes and massive speed-up for Weighted-P Prediction.
Note that Avidemux now offers options for MB-Tree RC, Psy RDO and RC Lookahead.
Title: libx264 GIT builds
Post by: Brazil on November 27, 2009, 06:48:20 PM
Quote from: DarkZell666Actually, there\'s still QPRD (subme=10), as well as psy-trellis missing.
And AQ mode too ;)
Title: libx264 GIT builds
Post by: Nik on November 28, 2009, 02:43:50 PM
@Lord_Mulder: \"BTW: Weighted P-Prediction can NOT be configured in Avidemux yet. Or did I miss that ???\"

I mixed it up with the \"weighted prediction for p-frames\" checkbox ^^;

alright, then I keep using the core2 file :)
in a different thread I asked about the performance on core i7, since there\'s little to no gain from multithreading.
Does this result from the missing CPU-specific optimizations in GCC you mentioned?

thanks ^^
Title: libx264 GIT builds
Post by: LoRd_MuldeR on November 28, 2009, 04:29:14 PM
Quote from: Nikin a different thread I asked about the performance on core i7, since there\'s little to no gain from multithreading.


What??? x264 is scales extremely well on multiple cores!

Therefore any additional core (even those \"logical\" cores introduces through Hyperthreading) will boost the x264 speed.

Also the changes in the Nehalem architecture (Core i7/i5) are extremely beneficial for x264 as well ;)

\"Overall, the changes in Nehalem are extremely beneficial to x264 and have led to an enormous overall performance increase. Furthermore, since the primary speed increase is in SIMD, the more assembly code we write, the more of a boost Nehalem gets over previous processors.\" - http://x264dev.multimedia.cx/?p=51

Quote from: NikDoes this result from the missing CPU-specific optimizations in GCC you mentioned?

As said before, the compiler optimizations only have a relatively small influence on the overall performance, as (1) compiler optimizations only affect the plain C code in x264 and (2) compiler optimizations still aren\'t anywhere near the performance of a good hand-optimized Assembler code. Most (all?) performance-critical code in x264 already is hand-optimized Assembler code. Also the x264 developers have optimized x264 especially for the Nehalem architecture, even before you could buy a Core i7 in the stores. However CPU-specific compiler optimizations for Core i7 are available in Intel\'s C compiler. ICL provides some speed up for x264 compared to GCC, but it\'s NOT that dramatic! Compiler optimizations simply can\'t do magic...
Title: libx264 GIT builds
Post by: Nik on November 28, 2009, 05:12:52 PM
ah hmm, odd
no idea if this here is the place to talk about, but:

I see only 50% used of every core (since HT lists twice the cores in taskman).
I was told that there seems to be no gain from HT.
But running different programs to utilize the CPU I see up to 99% usage.
encoding with x264 50% (very seldom more than 50%)
encoding with xvid around 30% cpu usage.
the thread about it is somewhere in the dev-2.5-branch, no idea who told me that atm
Title: libx264 GIT builds
Post by: LoRd_MuldeR on November 28, 2009, 05:26:33 PM
Quote from: NikI see only 50% used of every core (since HT lists twice the cores in taskman).
I was told that there seems to be no gain from HT.

50% CPU usage on a CPU with Hyperthreading equals 100% CPU usage on a Non-Hyperthreading CPU.

So even if you see \"only\" 50% CPU usage on your Core i7, the encoding speed will still be much faster than on a Core2 at 100% CPU usage (with the same number of physical cores), because x264 runs generally faster on Core i7.

Furthermore, if the CPU usage doesn\'t exceed 50%, there obviously is some bottleneck, probably in the decoder and/or the filters you use. x264 cannot encode faster than input data is passed to it! It\'s also possible that the single-threaded part in x264 becomes the bottleneck, if you use \"fast\" encoder settings. This won\'t happen with \"slow\" settings. Note that with my builds the first pass of a 2-Pass encode will use \"turbo\" (very fast) settings, so it\'s likely to see low CPU usage in the first pass. Just wait for the second pass. Or, if you use CRF, use slower settings...

Quote from: Nikencoding with xvid around 30% cpu usage.

Xvid\'s multi-threading implementation is crappy. And development of Xvid is pretty much dead...
Title: libx264 GIT builds
Post by: LoRd_MuldeR on December 05, 2009, 12:23:05 PM
libx264 SVN-r1360:
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5602 (http://forum.doom9.org/showpost.php?p=1348253&postcount=1395) or later now!
Title: libx264 GIT builds
Post by: cbike on December 08, 2009, 04:03:05 PM
libx264 SVN-r1360:

Oops! (404)
We can\'t find the page you\'re looking for. Check out our FAQ or forums for help. Or maybe you should try heading home.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on December 08, 2009, 04:44:00 PM
Quote from: cbikelibx264 SVN-r1360:

Oops! (404)
We can\'t find the page you\'re looking for. Check out our FAQ or forums for help. Or maybe you should try heading home.

Yes, DropBox has disabled public download for my account. They say: Too much traffic :rolleyes:

Well, I know it\'s a free service and I can\'t complain. But if they say \"no limit on traffic\", I\'d expect they keep their promise.

I will re-upload the files somewhere else, as soon as I get back home...
Title: libx264 GIT builds
Post by: LoRd_MuldeR on December 08, 2009, 06:03:20 PM
libx264 SVN-r1360:
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5602 (http://forum.doom9.org/showpost.php?p=1348253&postcount=1395) or later now!

Re-uploaded, as the previous mirror, DropBox, is not available anymore. They disabled my account.
Reason: Too much traffic.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on December 09, 2009, 07:43:24 PM
libx264 SVN-r1369:
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5602 (http://forum.doom9.org/showpost.php?p=1348253&postcount=1395) or later now!

MB-Tree + B-Pyramid works now! Also slice-based threading is back (optionally), but cannot be used with Avidemux yet - that\'s not a big loss, as it\'s less efficient than the \"normal\" frame-based threading anyway.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on December 11, 2009, 10:36:35 AM
libx264 SVN-r1373:
[list=*]
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5602 (http://forum.doom9.org/showpost.php?p=1348253&postcount=1395) or later now!

This build fixes a crash (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=65b3d0fd9f8167a6d0772a29e8fcf1a66ee7f8af) introduced in the previous build. People are highly encouraged to update asap!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on December 16, 2009, 12:16:54 AM
libx264 SVN-r1376:
[list=*]
These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5602 (http://forum.doom9.org/showpost.php?p=1348253&postcount=1395) or later now!

This build fixes two bugs in 2-pass ratecontrol. Should significantly increase quality with many threads in 2-pass mode, especially in cases with extremely large I-frames, such as anime.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on December 21, 2009, 12:03:56 AM
libx264 SVN-r1376:
[list=*]
These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r5676 (http://forum.doom9.org/showpost.php?p=1355245&postcount=1422) or later now!

Re-compiled r1376 with x264 core-80. This will make it work with the latest Avidemux 2.5.2 SVN build, but not with the 2.5.2 Final release. For the Final release stick with the core-79 builds from above!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on January 17, 2010, 05:44:16 PM
libx264 SVN-r1378:
[list=*]
These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r5830 (http://forum.doom9.org/showpost.php?p=1361233&postcount=1428) or later now!

The libx264 DLL is now compiled with static pthreads library. So far this seems to work fine for me...
Title: libx264 GIT builds
Post by: Faiakes on January 23, 2010, 11:09:13 AM
Quote from: LoRd_MuldeRlibx264 SVN-r1378:
[list=*]
These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r5830 or later now!

The libx264 DLL is now compiled with static pthreads library. So far this seems to work fine for me...
All links dead...
Title: libx264 GIT builds
Post by: LoRd_MuldeR on January 23, 2010, 11:23:49 AM
Dropbox has (temporarily) disabled public downloads for my account. Too much traffic they say...
Title: libx264 GIT builds
Post by: Faiakes on January 23, 2010, 11:31:01 AM
Hi LoRd_MuldeR

Thanks for the quick reply.
Is there a mirror?
Title: libx264 GIT builds
Post by: LoRd_MuldeR on January 23, 2010, 02:09:43 PM
Quote from: FaiakesHi LoRd_MuldeR

Thanks for the quick reply.
Is there a mirror?

Will re-upload to another mirror, later this day. Currently my connecion is busy pushing out another release...
Title: libx264 GIT builds
Post by: LoRd_MuldeR on January 23, 2010, 04:27:04 PM
libx264 SVN-r1378:
[list=*]
These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r5830 (http://forum.doom9.org/showpost.php?p=1361233&postcount=1428) or later now!

Re-uploaded the r1378 builds to a new mirror, as the Dropbox links are currently disabled...
Title: libx264 GIT builds
Post by: Faiakes on January 23, 2010, 04:29:27 PM
Thanks
Title: libx264 GIT builds
Post by: LoRd_MuldeR on January 23, 2010, 08:58:52 PM
libx264 SVN-r1400:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1400 with Periodic Intra Refresh:
[list=*]
These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r5869 (http://forum.doom9.org/showpost.php?p=1367103&postcount=1445) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on January 30, 2010, 12:13:09 AM
I have re-compiled the GCC 4.5 builds of libx264 r1400 (http://avidemux.org/admForum/viewtopic.php?pid=41527#p41527) with GCC/MinGW 4.5.0 2010-01-29. Before was 2010-01-16.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on January 30, 2010, 10:05:13 PM
libx264 SVN-r1414:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1414 with Periodic Intra Refresh:
[list=*]
[list=*]

These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r5869 (http://forum.doom9.org/showpost.php?p=1367103&postcount=1445) or later now!
Title: libx264 GIT builds
Post by: Faiakes on January 31, 2010, 10:17:03 AM
What\'s the difference? Why not only provide the libx264 SVN-r1414 with Periodic Intra Refresh?
Title: libx264 GIT builds
Post by: LoRd_MuldeR on January 31, 2010, 01:39:54 PM
Quote from: FaiakesWhat\'s the difference?

The difference, as the name implies, is Periodic Intra Refresh ;)

Quote from: FaiakesWhy not only provide the libx264 SVN-r1414 with Periodic Intra Refresh?

Because not everybody wants to use Periodic Intra Refresh ???

Of course it would be desirable to have PIR as a runtime option, but currently Avidemux doesn\'t expose that option...
Title: libx264 GIT builds
Post by: Faiakes on January 31, 2010, 02:09:34 PM
Something is wrong with the 1414 mediafire links.

Is it jut me?
Title: libx264 GIT builds
Post by: LoRd_MuldeR on January 31, 2010, 05:49:51 PM
Quote from: FaiakesSomething is wrong with the 1414 mediafire links.

What is \"wrong\" with those links? Download seems to work for me...
Title: libx264 GIT builds
Post by: Faiakes on January 31, 2010, 05:58:47 PM
It takes forever to load and in the end it the download doesn\'t actually start.

Is this only happening to me?
Title: libx264 GIT builds
Post by: LoRd_MuldeR on January 31, 2010, 06:00:39 PM
Quote from: FaiakesIt takes forever to load and in the end it the download doesn\'t actually start.

Is this only happening to me?

Maybe the MediaFire sever is under heavy load at the moment.

However I successfully downloaded the file from MediaFire only 3 minutes ago. Please try again...
Title: libx264 GIT builds
Post by: popper on January 31, 2010, 08:09:48 PM
Quote from: LoRd_MuldeR
Quote from: FaiakesWhat\'s the difference?

The difference, as the name implies, is Periodic Intra Refresh ;)

Quote from: FaiakesWhy not only provide the libx264 SVN-r1414 with Periodic Intra Refresh?

Because not everybody wants to use Periodic Intra Refresh ???

Of course it would be desirable to have PIR as a runtime option, but currently Avidemux doesn\'t expose that option...

\"Because not everybody wants to use Periodic Intra Refresh ???\"
ohh but who couldnt WANT PIR its so sweet and even the 360 likes to play it.... :)

â€"intra-refresh â€"fps 25 â€"vbv-maxrate 5000 â€"vbv-bufsize 200 â€"slice-max-size 1500 -o whatever.mp4

now the only question is how to get a good default setting included inside avidemux for processing and producing generic 720P at 512kbit/s suitable for the average users upload ISP rate using the above options.

 and also how can avidemux take advantage of interactive x264 videos/720p50_mobcal_ter.y4m â€"preset veryfast â€"tune zerolatency realtime feedback for on the fly variable output in the future?

to make avidemux take 2 OR More input AVC files as future round robin interleaved input switching perhaps ?, then processed, and stuffed inside a Transport stream output, or whatever other things you might like to add later! for example, easy and simple scaled PIP (Picture In Picture) production TS perhaps.!
Title: libx264 GIT builds
Post by: Faiakes on January 31, 2010, 08:13:26 PM
Mediafire links working now.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on January 31, 2010, 08:33:57 PM
Quote from: popper
Quote from: LoRd_MuldeR
Quote from: FaiakesWhat\'s the difference?

The difference, as the name implies, is Periodic Intra Refresh ;)

Quote from: FaiakesWhy not only provide the libx264 SVN-r1414 with Periodic Intra Refresh?

Because not everybody wants to use Periodic Intra Refresh ???

Of course it would be desirable to have PIR as a runtime option, but currently Avidemux doesn\'t expose that option...

\"Because not everybody wants to use Periodic Intra Refresh ???\"
ohh but who couldnt WANT PIR its so sweet and even the 360 likes to play it.... :)

I usually don\'t want PIR, because compression is LESS efficient with PIR enabled :o

The loss in efficiency that PIR causes isn\'t that large, when compared to a \"short\" I-Frame interval (like 35). But compared to a \"normal\" I-Frame interval (like 250+) there certainly is a much bigger loss in efficiency!

Furthermore not every player seeks properly in a stream that doesn\'t contain any I-Frames ;)
Title: libx264 GIT builds
Post by: Faiakes on January 31, 2010, 08:41:07 PM
Quote from: LoRd_MuldeRFurthermore not every player seeks properly in a stream that doesn\'t contain any I-Frames ;)
Would the latest MPC-HC be able to seek properly such files?
Title: libx264 GIT builds
Post by: LoRd_MuldeR on January 31, 2010, 09:03:29 PM
Quote from: Faiakes
Quote from: LoRd_MuldeRFurthermore not every player seeks properly in a stream that doesn\'t contain any I-Frames ;)
Would the latest MPC-HC be able to seek properly such files?

As MPC-HC is a DirectShow-based player, it totally depends on the DirectShow filters (splitter & decoder) that you use ;)
Title: libx264 GIT builds
Post by: popper on January 31, 2010, 09:08:52 PM
yeah. MPC-HC ,VLC,internal xbox360,PS3 and many others work fine with it, you can offset any compression being LESS efficient for a given content OC by upping your CRF to the next higher digit OC if compression filesize is more important than the quality of the final output to you and your viewers OC, but thats not really a concern for generic streaming of your content on things like http://www.veetle.com/frameworked/index.php/listing/index/10/popular/grid/0 or your LAN for instance...

and OC everyone knows the \"not every player\" is sh$t :) and you should be using a better one.

what, you dont use veetle etc to run your â€"intra-refresh â€"fps 25 â€"vbv-maxrate 1000 â€"vbv-bufsize 200 â€"slice-max-size 1500 -o whatever.mp4 encoding tests samples for others to link to on the fly, thats crazy ;)
Title: libx264 GIT builds
Post by: LoRd_MuldeR on January 31, 2010, 09:32:47 PM
Sure, we can compensate for less efficient compression by using a higher bitrate. But that\'s not the Point. The point is: Why should I spend a higher bitrate for PIR? The only benefits that PIR delivers are: You can start decoding at any random position, the stream is more robust against packet loss (up to 25% loss) and all frames have roughly the same size (as there are no \"big\" I-Frames\" anymore). That is great for low-latency streaming, such as VoIP applications -- the kind of applications PIR was developed for. But it\'s pretty much useless for encoding content for local playback! So again: If PIR has zero benefit for local playback but requires a higher bitrate for the same quality, why should I use it ???

Yes, there is no reason to use PIR for encoding content that is intended for local playback. Except for testing ;)
Title: libx264 GIT builds
Post by: popper on January 31, 2010, 10:04:51 PM
why use PIR, you said it yourself \"benefits that PIR delivers are: You can seek to any random position, the stream is more robust against packet loss (up to 25% loss) and all frames have roughly the same size (as there are no \"big\" I-Frames\" anymore....)\"

you simply tune your â€"vbv-maxrate 1000 â€"vbv-bufsize 200 â€"slice-max-size 1500 options to fit your local/remote LAN settings, just one of the biggest benefits... all those people using 11g and lower grade 11N wireless connections to interconnect their LAN kit for one, get a Direct Long Term benefit from the up to 25% loss protection for virtually No effort.

and OC theres other new inter-related x264 options coming down the line soon that also benefit low-latency and yet will/may increase compression and quality for many generic situations in the right combinations even more, but im just an old optimist hopeing OSS people start creating and using their ISP uploads to create new interesting apps for remote stacking,Encoding,viewing, and interacting with their personal content anywere, be it local LAN, WAN,or ISP upload bitrate etc...

Fair Enough, you learn and make your choices and do as you will,
http://x264dev.multimedia.cx/?p=249
if you care about low-latency LAN streaming etc then PIR is a good tool to have in your toolbox, a good workman learns to use the tools available to them to best effect, a bad workman....now back to regular updates and make a new thread if you care too!, and point the reader there, and Thanks again for the update incase that wasnt clear...
Title: libx264 GIT builds
Post by: LoRd_MuldeR on January 31, 2010, 10:20:54 PM
I\'m not going to continue this pointless discussion. Especially since this is the \"sticky\" thread that should be used for posting builds and for nothing else. So I just want to summarize a few facts: PIR does not give any benefits that are relevant for local playback. The only benefits are for low-latency video streaming! At the same time PIR has a major drawback: It hurts compression efficiency. So with PIR you will need a bigger file for the same quality. Therefore I wouldn\'t recommend to use PIR, unless you want to experiment with it or you are running a video streaming server (which doesn\'t apply to Avidemux).
Title: libx264 GIT builds
Post by: lych on February 01, 2010, 06:13:44 AM
One more thing about PIR... You should use slices with it to achieve the most benefit.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on February 01, 2010, 08:24:17 PM
libx264 SVN-r1416:
[list=*]
[list=*]
[list=*]

These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r5869 (http://forum.doom9.org/showpost.php?p=1367103&postcount=1445) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on February 07, 2010, 08:16:38 PM
The GCC 4.5.0 builds of libx264 r1416 have been re-compiled with GCC 4.5.0 2010-02-06:
http://avidemux.org/admForum/viewtopic.php?pid=41780#p41780
Title: libx264 GIT builds
Post by: LoRd_MuldeR on February 11, 2010, 07:42:13 PM
The GCC 4.5.0 builds of libx264 r1416 have been re-compiled with GCC 4.5.0 2010-02-11:
http://avidemux.org/admForum/viewtopic.php?pid=41780#p41780
Title: libx264 GIT builds
Post by: LoRd_MuldeR on February 15, 2010, 05:27:35 PM
libx264 SVN-r1442:
[list=*]
[list=*]
[list=*]

These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r5869 (http://forum.doom9.org/showpost.php?p=1367103&postcount=1445) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on March 01, 2010, 10:04:35 PM
libx264 SVN-r1471:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1471 with AutoVAQ (formerly known as \"AQ method 4\") enabled:
[list=*]

libx264 SVN-r1471 with Periodic Intra Refresh (No I-Frames!) enabled:
[list=*]

These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r5955 (http://forum.doom9.org/showpost.php?p=1378821&postcount=1457) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on March 21, 2010, 12:48:30 AM
Here\'s a new set of libx264 r1471 builds, re-compiled with GCC 4.5.0 2010-03-20:


libx264 SVN-r1471:
[list=*]

libx264 SVN-r1471 with AutoVAQ (formerly known as \"AQ method 4\") enabled:
[list=*]

These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r5955 (http://forum.doom9.org/showpost.php?p=1378821&postcount=1457) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on March 28, 2010, 04:54:18 PM
libx264 SVN-r1478:
[list=*]

libx264 SVN-r1478 with AutoVAQ enabled:
[list=*]

These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6028 (http://forum.doom9.org/showpost.php?p=1386813&postcount=1477) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on April 06, 2010, 01:16:37 AM
libx264 SVN-r1510:
[list=*]

These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6064 (http://forum.doom9.org/showpost.php?p=1389207&postcount=1480) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on April 06, 2010, 06:40:44 PM
libx264 SVN-r1510:
[list=*]

libx264 SVN-r1510 with AutoVAQ enabled:
[list=*]

These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6064 (http://forum.doom9.org/showpost.php?p=1389207&postcount=1480) or later now!

x264 didn\'t compile with latest GCC 4.5.0 (2010-04-01), so I stick with the 2010-03-27 release.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on April 07, 2010, 12:36:24 AM
libx264 SVN-r1523:
[list=*]

libx264 SVN-r1523 with AutoVAQ enabled:
[list=*]

libx264 SVN-r1523 with NAL-HRD enabled:
[list=*]

These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6083 (http://forum.doom9.org/showpost.php?p=1389424&postcount=1483) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on April 09, 2010, 10:01:53 PM
The AMD K10 (amdfam10) optimized builds of libx264 r1523 have been updated.

These builds will now throw an error when executed on unsupported CPU\'s instead of producing broken output:
Code Select
x264 [error]: CLZ test failed: x264 has been miscompiled!
x264 [error]: Are you attempting to run an SSE4a-enabled build on a CPU that
x264 [error]: doesn\'t support it?
Even if older \"AMD K10\" builds appeared to work on Non-SSE4a CPU\'s, they potentially produced bad output! :o
Title: libx264 GIT builds
Post by: LoRd_MuldeR on April 11, 2010, 06:08:55 PM
libx264 SVN-r1538:
[list=*]

libx264 SVN-r1538 with AutoVAQ enabled:
[list=*]

libx264 SVN-r1538 with NAL-HRD enabled:
[list=*]

These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6121 (http://forum.doom9.org/showpost.php?p=1390665&postcount=1486) or later now!

All clear: With this release onwards, using the AMD K10 (amdfam10) builds should be safe again.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on April 15, 2010, 07:24:30 PM
libx264 SVN-r1542:
[list=*]

libx264 SVN-r1542 with AutoVAQ enabled:
[list=*]

libx264 SVN-r1542 with NAL-HRD enabled:
[list=*]

These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6121 (http://forum.doom9.org/showpost.php?p=1390665&postcount=1486) or later now!

GCC 4.5.x has been updated to GCC 4.5.0 (Stable)
Title: libx264 GIT builds
Post by: LoRd_MuldeR on April 16, 2010, 12:05:26 AM
libx264 SVN-r1542:
[list=*]

libx264 SVN-r1542 with AutoVAQ enabled:
[list=*]

libx264 SVN-r1542 with NAL-HRD enabled:
[list=*]

These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6129 (http://forum.doom9.org/showpost.php?p=1392061&postcount=1489) or later now!

Re-compiled libx264 r1542 as core-93, so these builds will work with Avidemux r6129 now.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on April 25, 2010, 12:41:24 PM
libx264 SVN-r1564:
[list=*]

libx264 SVN-r1564 with AutoVAQ enabled:
[list=*]

These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6129 (http://forum.doom9.org/showpost.php?p=1392061&postcount=1489) or later now!
Title: libx264 GIT builds
Post by: outlaw on April 28, 2010, 10:10:08 AM
hi,

2 questions :

1) where did you get gcc 4.6.0 ?
2) what exactly are the patches you use in these builds ?

Thanks
Title: libx264 GIT builds
Post by: LoRd_MuldeR on April 28, 2010, 10:18:24 AM
Quote from: outlaw1) where did you get gcc 4.6.0 ?

src: http://gcc.gnu.org/svn/gcc/trunk/gcc/ (The \"trunk\" is 4.6.x now, see \"BASE-VER\" for an exact version number)
bin: http://www.equation.com/servlet/equation.cmd?fa=fortran (for exmaple, there may be other pre-compiled binaries)

Quote from: outlaw2) what exactly are the patches you use in these builds ?

All source modifications are included in the 7z files (patches.tar), so see yourself ;)

(Note: It may appear that the patch is pretty big this time, but most lines are simply the reverse of r1549)
Title: libx264 GIT builds
Post by: LoRd_MuldeR on May 01, 2010, 02:30:24 AM
libx264 SVN-r1570:
[list=*]
[list=*]

libx264 SVN-r1570 with AutoVAQ enabled:
[list=*]

These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6129 (http://forum.doom9.org/showpost.php?p=1392061&postcount=1489) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on May 01, 2010, 08:13:32 PM
libx264 SVN-r1570:
[list=*]
[list=*]
[list=*]
[list=*]

libx264 SVN-r1570 with AutoVAQ enabled:
[list=*]
[list=*]
[list=*]

These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6129 (http://forum.doom9.org/showpost.php?p=1392061&postcount=1489) or later now!

EDIT: Proper GCC 4.6.0 builds of libx264 r1570 uploaded now. I made a stupid mistake before :/
Title: libx264 GIT builds
Post by: nerdpunk on May 02, 2010, 08:10:08 AM
Quote from: LoRd_MuldeRGCC 4.5.1 ... GCC 4.6.0

wow. you got compilers from the future... can i borrow your time machine for a while? ;)
Title: libx264 GIT builds
Post by: LoRd_MuldeR on May 02, 2010, 10:02:03 AM
Quote from: nerdpunk
Quote from: LoRd_MuldeRGCC 4.5.1 ... GCC 4.6.0

wow. you got compilers from the future... can i borrow your time machine for a while? ;)

Nope. The aforementioned compilers are not from the future at all :P

GCC 4.6.x is the \"active development\" series (see trunk), GCC 4.5.x is the \"current release\" series (see 4.5 branch).

See the file \"BASE-VER\" file for an exact version number, i.e. \"4.6.0\" and \"4.5.1\" at the moment.

And of course I have tested the \"pre-release\" compilers for regressions regarding x264. The results look fine now!
Title: libx264 GIT builds
Post by: Setsunaaa on May 09, 2010, 05:15:09 PM
Question: You you allow a bigger --merange ? Like up to 256? Or up to 500 since 511.5 is the maximum allowed motion vector...
Currently it is limited to 64, but I am using 128 on a few occasions when doing full HD encodings. It actually reduces the filesize about 5%, _very_ much source video dependent of course.

IF I edit the .js file and set 128 there, will it be accepted by avidemux? It looks like it resets to 16.

Why is --subme 10 missing? I don\'t use it, I only use --subme 9 since I see no difference, so this is just my curiosity....
Title: libx264 GIT builds
Post by: LoRd_MuldeR on May 09, 2010, 05:31:39 PM
@all:
Can we please keep discussion out of the sticky ???


Quote from: SetsunaaaQuestion: You you allow a bigger --merange ? Like up to 256? Or up to 500 since 511.5 is the maximum allowed motion vector...
Currently it is limited to 64, but I am using 128 on a few occasions when doing full HD encodings. It actually reduces the filesize about 5%, _very_ much source video dependent of course.

IF I edit the .js file and set 128 there, will it be accepted by avidemux? It looks like it resets to 16.

Increasing the motion search range over the default value of 16 is NOT recommended :o

Doing so will significantly slow down the encoding process for a very minor improvement or no improvement at all.

Furthermore 256 or even higher is totally insane. Even x264\'s built-in \"placebo\" and \"veryslow\" presets use a value of only 24.

Everything below \"veryslow\" (i.e. \"slower\" and all the faster presets) sticks with the default value of 16. So should you!


BTW: ME-Range does not specify the maximum MV length, but limits the range that x264 will search to find the best MV.

There also is a separate MV-Range setting in x264 that does limit the maximum MV length.


Quote from: SetsunaaaWhy is --subme 10 missing? I don\'t use it, I only use --subme 9 since I see no difference, so this is just my curiosity....

SubME=10 is not exposed in Avidemux. That\'s simply because nobody has bothered implementing it yet.

My custom builds have it enabled though: Use SubME=9 + ME=UMH/ESA/TESA + Trellis=2 to trigger SubME=10 ;)
Title: libx264 GIT builds
Post by: Setsunaaa on May 09, 2010, 05:51:36 PM
Serious slowdown of merange 128: yes. From 4 fps down to 0.7 fps : ). It is my \"Encoding time does not matter\" setting.

--preset veryslow sets merange to 24 (according to x264 --fullhelp).

I just want to be free to choose, when I see in the source video a lot of motion which goes a bit over 100 pixels per frame it works very well. Like I said: I only use it on SOME HD sources, such motion vector search ranges don\'t make much sense on DVD or lower resolutions.

Such motion vectors are used anyway, according to \"Dark Shakiri\", he says:
Also, \"merange\" is not the range of the maximum motion distance that the motion estimation will catch: it\'s only the distance that it will search beyond the best predictor.


He corrected me on a few other details in that thread (my nick there is Jou):

http://doom10.org/index.php?topic=141.msg1087#msg1087

I won\'t die if you don\'t implement, I can always go back to commandline x264-x64.exe : ). But Avidemux is much more convenient to use compared to my other methods.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on May 09, 2010, 06:40:41 PM
Quote from: SetsunaaaSerious slowdown of merange 128: yes. From 4 fps down to 0.7 fps : ). It is my \"Encoding time does not matter\" setting.

--preset veryslow sets merange to 24 (according to x264 --fullhelp).

That\'s exactly what I said. And the \"veryslow\" preset should give you a good indication of the slowest settings you should ever use. Anything that\'s beyond \"veryslow\" preset (and especially everything that is included or beyond \"placebo\") should NEVER be used for any real encoding task. The \"placebo\" presets only exists to show people what NOT to use.

Conclusion: If encoding time isn\'t important, use ME-Range 24. Otherwise use ME-Range 16.


Quote from: SetsunaaaI just want to be free to choose, when I see in the source video a lot of motion which goes a bit over 100 pixels per frame it works very well. Like I said: I only use it on SOME HD sources, such motion vector search ranges don\'t make much sense on DVD or lower resolutions.

Sure, you are free to choose. But if ME-Range 24 only gives a very minor improvement over the default ME-Range 16 (if at all) and further anything above ME-Range 24 doesn\'t give any benefit it all (except in homeopathic cases), it simply makes NO sense to use a totally overkill value, such as ME-Range 512. Of course if you insist on using insane settings, then I can\'t prevent you from shooting yourself into the foot. But you have been warned ^^


Quote from: SetsunaaaSuch motion vectors are used anyway, according to \"Dark Shakiri\", he says:
Also, \"merange\" is not the range of the maximum motion distance that the motion estimation will catch: it\'s only the distance that it will search beyond the best predictor.

He corrected me on a few other details in that thread (my nick there is Jou):

http://doom10.org/index.php?topic=141.msg1087#msg1087

That\'s what I said above ;)

ME-Range is the range x264 will search to find the best MV, starting at the best predictor. You know, H.264 doesn\'t store the MV, but only the delta (offset) between the predicted MV and the \"optimal\" MV chosen by the encoder. So the actual length of the resulting MV can be much bigger than the ME-Range. If the predicted MV has a length of 256 for example and the ME search-range is set to 16, then we can get MV\'s with a length of 256±16 (i.e. up to 272). The total MV length can be limited using the MV-Range setting, but of course this may hurt quality! So you should allow the maximum MV length allowed in the H.264 specs (which is the x264 default behavior), because any proper decoder will handle it just fine.

Also: Allowing a bigger ME-Range potentially allows x264 to find \"optimal\" MV\'s it wouldn\'t have found otherwise. BUT: There is no guarantee that a bigger ME-Range will actually result in a \"better\" MV. The predicted MV is pretty good already, so x264 only searches the area around the predicted MV - it does the \"fine adjustment\". The chance that a \"better\" MV is outside the search range of 24 is near zero (i.e. negligible). The chance to find one outside of 16 is very small already...
Title: libx264 GIT builds
Post by: Setsunaaa on May 09, 2010, 07:10:03 PM
But then why allowing up to 64 anyway? Why not remove the option?
But we are getting in the \"we have different opinions\" range : ), should be a different thread (if worth a thread anyway).
So it won\'t be implemented and I\'ll be using cmdline for such cases.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on May 09, 2010, 07:18:19 PM
Quote from: SetsunaaaBut then why allowing up to 64 anyway? Why not remove the option?

Because neither x264 nor Avidemux prevents the user from doing stupid things.

And choosing between 16 (default) and 24 (slower, slightly better) still makes sense, so removing the option is a no-go!

Furthermore sometimes people want to lower ME-Range below 16 to improve encoding speed.

Last not least, somebody may want to run test encodes with ME-Range 64 to see that it really isn\'t better than 24 ;)


This shows how important the rule of thumb is:
If you don\'t know what a specific setting does or if you don\'t have a good reason to adjusted it, then don\'t touch it.

And if you are uncertain, look at the built-in presets. Is your setting identical to \"placebo\" (or even higher), go correct it!

Blindly crippling your encoding speed by using insane/overkill settings doesn\'t necessarily improve quality...
Title: libx264 GIT builds
Post by: LoRd_MuldeR on May 09, 2010, 07:56:32 PM
libx264 SVN-r1583:
[list=*]
[list=*]
[list=*]
[list=*]

libx264 SVN-r1583 with AutoVAQ enabled:
[list=*]
[list=*]
[list=*]

These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6129 (http://forum.doom9.org/showpost.php?p=1392061&postcount=1489) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on May 17, 2010, 12:04:02 AM
libx264 SVN-r1583:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1583 with AutoVAQ enabled:
[list=*]
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6195 (http://forum.doom9.org/showpost.php?p=1400390&postcount=1508) or later now!

Re-compiled libx264 r1583 as core-94, because Avidemux 2.5.3 now supports core-94.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on May 17, 2010, 10:24:46 PM
libx264 SVN-r1592:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1592 with AutoVAQ enabled:
[list=*]
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6195 (http://forum.doom9.org/showpost.php?p=1400390&postcount=1508) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on May 21, 2010, 10:06:51 PM
libx264 SVN-r1602:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1602 with AutoVAQ enabled:
[list=*]
[list=*]

libx264 SVN-r1602 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6195 (http://forum.doom9.org/showpost.php?p=1400390&postcount=1508) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on May 26, 2010, 11:55:46 PM
libx264 SVN-r1613:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1613 with AutoVAQ enabled:
[list=*]
[list=*]

libx264 SVN-r1613 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6195 (http://forum.doom9.org/showpost.php?p=1400390&postcount=1508) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on May 27, 2010, 11:42:19 PM
libx264 SVN-r1613:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1613 with AutoVAQ enabled:
[list=*]
[list=*]

libx264 SVN-r1613 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6261 (http://forum.doom9.org/showpost.php?p=1403273&postcount=1516) or later now!

Re-compiled libx264 r1613 as core-96, because Avidemux r6261 now supports core-96.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on June 02, 2010, 11:23:23 PM
libx264 SVN-r1627:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1627 with AutoVAQ enabled:
[list=*]
[list=*]

libx264 SVN-r1627 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6288 (http://forum.doom9.org/showpost.php?p=1404580&postcount=1529) or later now!

Note: No more \"fast first-pass\" patch needed, because Avidemux exposes this an option now.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on June 04, 2010, 10:50:52 AM
libx264 SVN-r1629:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1629 with AutoVAQ enabled:
[list=*]
[list=*]

libx264 SVN-r1629 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6288 (http://forum.doom9.org/showpost.php?p=1404580&postcount=1529) or later now!

Note: libx264 r1629 fixes a regression introduced in r1627. Update is highly recommended!
Title: libx264 GIT builds
Post by: Brazil on June 07, 2010, 08:05:53 AM
Quote from: LoRd_MuldeR[list=*]
A great idea this all in one pack, better, easier, faster than all individual downloads, thanks for that :)
Title: libx264 GIT builds
Post by: xseoer on June 08, 2010, 07:51:28 AM
Quote from: apollo567looks like the links are brocken ?!
Yes , i can not visit it , :(
Title: libx264 GIT builds
Post by: LoRd_MuldeR on June 08, 2010, 11:20:03 AM
Quote from: xseoer
Quote from: apollo567looks like the links are brocken ?!
Yes , i can not visit it , :(

Works for me! Both, the MediaFire and the GoogleCode links. ;)

And can we keep discussion out of the sticky, please?

Use x264 discussion thread (configuration, etc.) for discussion...
Title: libx264 GIT builds
Post by: LoRd_MuldeR on June 09, 2010, 11:19:55 PM
libx264 SVN-r1643:
[list=*]
[list=*]

libx264 SVN-r1643 with AutoVAQ enabled:
[list=*]

libx264 SVN-r1643 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6340 (http://forum.doom9.org/showpost.php?p=1406704&postcount=1533) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on June 14, 2010, 07:04:02 PM
libx264 SVN-r1643:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1643 with AutoVAQ enabled:
[list=*]
[list=*]

libx264 SVN-r1643 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6370 (http://forum.doom9.org/showpost.php?p=1408254&postcount=1535) or later now!

Re-compiled libx264 as core-97 for compatibility with Avidemux r6370 and later.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on June 15, 2010, 10:33:29 PM
libx264 SVN-r1649:
[list=*]
[list=*]

libx264 SVN-r1649 with AutoVAQ enabled:
[list=*]

libx264 SVN-r1649 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6370 (http://forum.doom9.org/showpost.php?p=1408254&postcount=1535) or later now!

Note: libx264 r1649 fixes regressions introduced in r1501 and r1535. Update is highly recommended!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on June 26, 2010, 10:39:03 PM
libx264 SVN-r1659:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1659 with AutoVAQ enabled:
[list=*]

libx264 SVN-r1659 with OpenGOP enabled:
[list=*]

libx264 SVN-r1659 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6370 (http://forum.doom9.org/showpost.php?p=1408254&postcount=1535) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on July 08, 2010, 10:10:01 PM
libx264 SVN-r1666:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1666 with AutoVAQ enabled:
[list=*]

libx264 SVN-r1666 with OpenGOP enabled:
[list=*]

libx264 SVN-r1666 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6422 (http://forum.doom9.org/showpost.php?p=1415485&postcount=1545) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on July 15, 2010, 11:49:56 PM
libx264 SVN-r1671:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1671 with AutoVAQ enabled:
[list=*]

libx264 SVN-r1671 with OpenGOP enabled:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6422 (http://forum.doom9.org/showpost.php?p=1415485&postcount=1545) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on July 18, 2010, 02:59:38 PM
libx264 SVN-r1671:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1671 with AutoVAQ enabled:
[list=*]

libx264 SVN-r1671 with OpenGOP enabled:
[list=*]

libx264 SVN-r1671 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6422 (http://forum.doom9.org/showpost.php?p=1415485&postcount=1545) or later now!

Re-compiled r1671 with regression fixes backported from r1675/r1676. Update recommended!
(Note: Currently I cannot provide any r1677 builds for Avidemux 2.5.3 r6422)
Title: libx264 GIT builds
Post by: LoRd_MuldeR on July 21, 2010, 04:56:02 PM
libx264 SVN-r1680:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1680 with AutoVAQ enabled:
[list=*]

libx264 SVN-r1680 with OpenGOP enabled:
[list=*]

libx264 SVN-r1680 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6422 (http://forum.doom9.org/showpost.php?p=1415485&postcount=1545) or later now!

Be aware: This revision has a bug that will cause a crash in 2-Pass encoding!
That was fixed in the latest version, please see below...
Title: libx264 GIT builds
Post by: LoRd_MuldeR on July 21, 2010, 11:11:24 PM
libx264 SVN-r1681:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1681 with AutoVAQ enabled:
[list=*]

libx264 SVN-r1681 with OpenGOP enabled:
[list=*]

libx264 SVN-r1681 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6422 (http://forum.doom9.org/showpost.php?p=1415485&postcount=1545) or later now!

This revision fixes a bug that caused a crash in 2-Pass encoding (at the beginning of second pass).
Update is highly recommended!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on July 31, 2010, 06:42:56 PM
libx264 SVN-r1688:
[list=*]
[list=*]

libx264 SVN-r1688 with AutoVAQ enabled:
[list=*]

libx264 SVN-r1688 with OpenGOP enabled:
[list=*]

libx264 SVN-r1688 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6422 (http://forum.doom9.org/showpost.php?p=1415485&postcount=1545) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on August 04, 2010, 06:01:01 PM
libx264 SVN-r1688:
[list=*]
[list=*]

libx264 SVN-r1688 with AutoVAQ enabled:
[list=*]

libx264 SVN-r1688 with OpenGOP enabled:
[list=*]

libx264 SVN-r1688 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6502 (http://forum.doom9.org/showpost.php?p=1423078&postcount=1556) or later now!

Re-compiled libx264-r1688 as core-104, because Avidemux r6502 supports x264 core-104 now.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on August 16, 2010, 03:40:50 PM
libx264 SVN-r1698:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1698 with AutoVAQ enabled:
[list=*]

libx264 SVN-r1698 with OpenGOP enabled:
[list=*]

libx264 SVN-r1698 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6502 (http://forum.doom9.org/showpost.php?p=1423078&postcount=1556) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on August 24, 2010, 10:44:52 PM
libx264 SVN-r1703:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1703 with AutoVAQ enabled:
[list=*]

libx264 SVN-r1703 with OpenGOP enabled:
[list=*]

libx264 SVN-r1703 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6502 (http://forum.doom9.org/showpost.php?p=1423078&postcount=1556) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on September 06, 2010, 12:17:51 AM
libx264 SVN-r1713:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1713 with AutoVAQ enabled:
[list=*]

libx264 SVN-r1713 with OpenGOP enabled:
[list=*]

libx264 SVN-r1713 with NAL-HRD (VBR mode) enabled:
[list=*]

libx264 SVN-r1713 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6587 (http://forum.doom9.org/showpost.php?p=1432083&postcount=1582) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on September 20, 2010, 09:23:05 PM
libx264 SVN-r1724:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1724 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6587 (http://forum.doom9.org/showpost.php?p=1432083&postcount=1582) or later now!

Extra builds with AutoVAQ, OpenGOP and NAL-HRD enabled are included in the \"all-in-one\" library pack.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on September 21, 2010, 07:45:23 PM
libx264 SVN-r1724:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1724 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6636 (http://forum.doom9.org/showpost.php?p=1445010&postcount=1586) or later now!

Re-compiled x264 r1724 as core 105 for compatibility with Avidemux r6636. Update is recommended!

Extra builds with AutoVAQ, OpenGOP and NAL-HRD enabled are included in the \"all-in-one\" library pack.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on September 28, 2010, 11:02:47 PM
libx264 SVN-r1732:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1732 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6636 (http://forum.doom9.org/showpost.php?p=1445010&postcount=1586) or later now!

Extra builds with AutoVAQ, OpenGOP and NAL-HRD enabled are included in the \"all-in-one\" library pack.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on September 30, 2010, 09:09:32 PM
libx264 SVN-r1732:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1732 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6689 (http://forum.doom9.org/showpost.php?p=1447526&postcount=1592) or later now!

Re-compiled x264 r1732 as core 106 for compatibility with Avidemux r6689. Update is recommended.

As Avidemux fully supports OpenGOP as well as NAL-HRD now, special \"patched\" builds are NOT needed for those anymore. However AutoVAQ-enabled builds are still provided in the \"all-in-one\" library pack.
Title: libx264 GIT builds
Post by: LoRd_MuldeR on October 11, 2010, 03:45:09 PM
libx264 SVN-r1745:
[list=*]
[list=*]
[list=*]
[list=*]

libx264 SVN-r1745 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6689 (http://forum.doom9.org/showpost.php?p=1447526&postcount=1592) or later now!

As Avidemux fully supports OpenGOP as well as NAL-HRD now, special \"patched\" builds are NOT needed for those anymore. However AutoVAQ-enabled builds are still provided in the \"all-in-one\" library pack.
Title: libx264 GIT builds
Post by: dirk362 on October 17, 2010, 12:17:28 PM
I\'m very thankful that these interim x264 releases are made available.

Without wishing to sound ungrateful, is there any hope of producing a version that doesn\'t alter parameters (specifically so that it matches the main releases of AviDemux so things like subme isn\'t set to 10 but takes into account what I\'ve set).

I had a look through the various versions, and all had adjusted values via the patches.tar file in each directory (well for 451 anyway as that is all I checked against).

If this was in say the Generic build then those wishing to just newer x264 (for fixes etc) without adjusting their values could, whereas those wishing to use the adjusted values could still via the other builds optimised for their processor.

Just a thought...
Title: libx264 GIT builds
Post by: LoRd_MuldeR on October 17, 2010, 12:33:42 PM
Quote from: dirk362I\'m very thankful that these interim x264 releases are made available.

Without wishing to sound ungrateful, is there any hope of producing a version that doesn\'t alter parameters (specifically so that it matches the main releases of AviDemux so things like subme isn\'t set to 10 but takes into account what I\'ve set).

With my patched builds \"Sub-ME=10\" is only triggered when using \"ME=UMH + Sube-ME=9 + Trellis=2\". That\'s because when using such slow settings anyway, then using \"Sub-ME=10\" makes a lot of sense.

Anyway, I have made a patch to add Sub-ME 10 to Avidemux\' x264 config window, but it has not been approved yet...


Quote from: dirk362I had a look through the various versions, and all had adjusted values via the patches.tar file in each directory (well for 451 anyway as that is all I checked against).

My patches also enables Psy-Trellis at a strength of 0.15, which is x264\' default for encoding \"Film\" material. Moreover there are special builds with \"Auto VAQ\" (aka \"AQ mode 2\") enabled. Both, Psy-Trellis and AQ mode, are not exposed in Avidemux yet, but my proposed Avidemux patch adds those options to the GUI as well. Not sure if it can get committed before 2.5.4 release.

(Next time don\'t use the sticky thread for discussion please!)
Title: libx264 GIT builds
Post by: LoRd_MuldeR on December 26, 2010, 10:32:39 PM
libx264 SVN-r1834:
[list=*]
[list=*]
[list=*]
[list=*]

libx264 SVN-r1834 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r6854 (http://forum.doom9.org/showpost.php?p=1466619&postcount=1602) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on January 11, 2011, 09:09:46 PM
libx264 SVN-r1867:
[list=*]
[list=*]
[list=*]
[list=*]

libx264 SVN-r1867 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r6854 (http://forum.doom9.org/showpost.php?p=1466619&postcount=1602) or later now!

Please note the recent changes caused by the introduction of framerate-aware ratecontrol:
QuoteWARNING: This change redefines x264\'s internal quality measurement. x264 will now scale its quality based on the framerate of the video due to the aforementioned frame duration logic. That is, --crf X will give lower quality per frame for a 60fps video than for a 30fps one. This will make --crf closer to constant perceptual quality than previously. The \"center\" for this change is 25fps: that is, videos lower than 25fps will go up in quality at the same CRF and videos above will go down. This choice is completely arbitrary. (see the full commit message (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=22bfd310abced4df0b11c9620b152e5cfe746d43) for details)
Title: libx264 GIT builds
Post by: LoRd_MuldeR on January 27, 2011, 10:40:31 PM
libx264 SVN-r1881:
[list=*]
[list=*]
[list=*]

libx264 SVN-r1881 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r6854 (http://forum.doom9.org/showpost.php?p=1466619&postcount=1602) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on January 29, 2011, 07:43:53 PM
libx264 SVN-r1882:
[list=*]
[list=*]
[list=*]
[list=*]

libx264 SVN-r1882 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r6854 (http://forum.doom9.org/showpost.php?p=1466619&postcount=1602) or later now!

r1882 should fix a potential crash on AVX-enabled CPU\'s when running on Windows versions prior to Windows 7 Service-Pack 1, which was introduced in r1881 build (older Windows doesn\'t support AVX).
Title: libx264 GIT builds
Post by: LoRd_MuldeR on January 31, 2011, 06:36:23 PM
libx264 SVN-r1884:
[list=*]
[list=*]
[list=*]
[list=*]

libx264 SVN-r1884 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r6854 (http://forum.doom9.org/showpost.php?p=1466619&postcount=1602) or later now!

r1884 includes a hot-fix for a regression introduced with r1881. Update is highly recommended!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on February 20, 2011, 08:47:04 PM
libx264 SVN-r1913:
[list=*]
[list=*]
[list=*]
[list=*]

libx264 SVN-r1913 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r6854 (http://forum.doom9.org/showpost.php?p=1466619&postcount=1602) or later now!
Title: libx264 GIT builds
Post by: LoRd_MuldeR on March 25, 2011, 11:31:26 PM
libx264 SVN-r1924:
[list=*]
[list=*]
[list=*]
[list=*]

libx264 SVN-r1924 library pack:
[list=*]

These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r6854 (http://forum.doom9.org/showpost.php?p=1466619&postcount=1602) or later now!
Title: Re: libx264 GIT builds
Post by: LoRd_MuldeR on May 27, 2011, 04:34:24 PM
libx264 SVN-r1995:


libx264 SVN-r1995 library pack:


These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r7194 (http://forum.doom9.org/showpost.php?p=1499718&postcount=1631) or later now!
Title: Re: libx264 GIT builds
Post by: LoRd_MuldeR on June 24, 2011, 02:12:07 PM
libx264 SVN-r2008:


libx264 SVN-r2008 library pack:


These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r7296 (http://forum.doom9.org/showpost.php?p=1509665&postcount=1639) or later now!

Title: Re: libx264 GIT builds
Post by: LoRd_MuldeR on July 11, 2011, 03:27:40 PM
libx264 SVN-r2019:


libx264 SVN-r2019 library pack:


These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r7317 (http://forum.doom9.org/showpost.php?p=1512732&postcount=1650) or later now!
Title: Re: libx264 GIT builds
Post by: LoRd_MuldeR on August 11, 2011, 09:08:56 AM
libx264 SVN-r2057:
libx264 SVN-r2057 library pack:

These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r7389 (http://forum.doom9.org/showthread.php?p=1518791#post1518791) or later now!
Title: Re: libx264 GIT builds
Post by: LoRd_MuldeR on September 05, 2011, 03:05:20 PM
libx264 SVN-r2074:


libx264 SVN-r2074 library pack:

These builds will NOT work with Avidemux 2.5.4 or older. Please update to Avidemux 2.5.5 r7428 (http://code.google.com/p/mulder/downloads/list?can=2&q=Avidemux&sort=-uploaded&colspec=Filename%20Summary%20Type%20Uploaded%20Size%20DownloadCount) or later now!
Title: Re: libx264 GIT builds
Post by: LoRd_MuldeR on September 25, 2011, 09:03:38 PM
libx264 SVN-r2085:


libx264 SVN-r2085 library pack:


These builds will NOT work with Avidemux 2.5.4 or older. Please update to Avidemux 2.5.5 r7573 (http://code.google.com/p/mulder/downloads/detail?name=Avidemux.2011-09-22.Win32.exe&can=2&q=) or later now!
Title: Re: libx264 GIT builds
Post by: dado023 on October 27, 2011, 04:31:35 PM
new revision is out :)
Waiting patiently  :o

EDIT:
Got it from here:
http://code.google.com/p/mulder/downloads/detail?name=libx264-118-r2106M-win32.7z&can=2&q=&sort=-uploaded

thank you in the name of all avidemux junkies

PS: what is the minimum avidemux version to use it?
Title: Re: libx264 GIT builds
Post by: LoRd_MuldeR on December 07, 2011, 11:30:12 PM
libx264 SVN-r2120 library pack:

Changelog:
Code Select
commit 0c7dab9c2a106ce3ee5d6ad7282afb49e1cc3954 [revision 2120]
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Tue Dec 6 14:39:21 2011 -0800

    Fix regression in r2118
    Broke trellis with i16x16 macroblocks.

commit 0637cd67cb245fce5ba190fa4b9c341319ea2b37 [revision 2119]
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Wed Nov 30 13:02:12 2011 -0800

    Modify MBAFF chroma deblock functions to handle U/V at the same time
    Allows for more convenient asm implementations.

commit 67f1fdc4d9c030568eac8cf9ab9d0bb249f520db [revision 2118]
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Thu Nov 10 16:16:13 2011 -0800

    CABAC trellis optimizations: use SIMD quant
    Significant speed increase, minor change in output due to rounding.

commit e047b3c475cd42b6647397a244e239ebfca53bf6 [revision 2117]
Author: Steven Walters <kemuri9@gmail.com>
Date:   Sun Nov 6 09:48:30 2011 -0800

    YUV range detection and support for x264CLI
    Two new options: --input-range and --range.
    --input-range forces the range of the input in case of misdetection; auto by default.
    -- range sets the range of the output; x264cli will convert if necessary, TV by default.
    --fullrange is now removed as a CLI option (but the libx264 API is unchanged).

commit 00df989cc06208050230756525633438d76b5a6a [revision 2116]
Author: Kieran Kunhya <kieran@kunhya.com>
Date:   Fri Nov 4 20:09:13 2011 +0000

    Pass through user data

commit 04a0aeefd2f5b152c5dbca4a1c6569bd27c9f721 [revision 2115]
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Thu Oct 27 14:05:56 2011 -0700

    Remove unpredictable branch in CABAC dqp

commit 4185ee883b04d9cee57a64fdebd153830b7b27ba [revision 2114]
Author: Loren Merritt <pengvado@akuvian.org>
Date:   Sun Oct 23 23:15:11 2011 +0000

    x86inc: AVX symmetry optimization
    3-arg AVX ops with a memory arg can only have it in src2,
    whereas SSE emulation of 3-arg prefers to have it in src1 (i.e. the move).
    So, if the op is symmetric and the wrong one is memory, swap them.
    Eliminates redundant moves in some cases when using 3-operand without AVX with memory arguments.
    Also fix movss and movsd in some cases, and flag shufps correctly as float.

commit cc129adcaaf5604f3d4fea9ebcb289403192a741 [revision 2113]
Author: Anton Mitrofanov <Bugmaster@narod.ru>
Date:   Tue Nov 29 13:45:13 2011 -0800

    checkasm: shut up gcc warnings, fix some naming of functions in results

commit f0ccc98bb747b8ee0fe9329f4205cf382788bb89 [revision 2112]
Author: Mans Rullgard <mans@mansr.com>
Date:   Mon Nov 28 16:29:12 2011 -0800

    checkasm: fix build on ARM
    Because of how ALIGNED_ARRAY_16 is defined on ARM, array initialisers cannot be used here.  Use memset() instead.

commit d8d8e756b1fee72b4771761d6aa4cfb31edc0b67 [revision 2111]
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Sat Nov 12 01:31:49 2011 +0400

    Improve makefile rules
    Remove the need for "make clean" after most reconfigures.

commit e6d33a931c08918e78dcae97e4d80d0c3411bf2c [revision 2110]
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Sat Nov 12 00:47:48 2011 +0400

    Mark some local functions as static, cosmetics

commit e0c11dc6e283569606aaa97767401c6a13c2529d [revision 2109]
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Fri Nov 11 23:19:02 2011 +0400

    Fix crash if timecode file opening fails

commit a14db080c3fdba4cadc38152a292bb1fa216d50e [revision 2108]
Author: Fabian Greffrath <fabian+debian@greffrath.com>
Date:   Fri Nov 11 13:25:43 2011 -0800

    Configure: force PIC for shared build on PARISC and MIPS

commit 6a0bd421bf5fd006012ddcd1be2072a8736b2d27 [revision 2107]
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Sat Oct 22 19:41:07 2011 +0400

    Improve yasm version check
    Previous check allowed certain earlier versions that weren't fully compatible.

commit 07efeb45db224b7757880d4d63bb549fb454f6db [revision 2106]
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Tue Oct 18 14:30:26 2011 -0700

    Add fenc prefetching to adaptive quant
    Many fewer cache misses, faster adaptive quant.

These builds will NOT work with Avidemux 2.5.4 or older. Please update to Avidemux 2.5.5 r7694 (http://forum.doom9.org/showpost.php?p=1543434&postcount=1695) or later now!
Title: Re: libx264 GIT builds
Post by: LoRd_MuldeR on January 01, 2012, 09:58:19 PM
libx264 SVN-r2120 library pack (updated for the Avimdeux 2.5.6 release):
Changelog:
Code Select
commit 0c7dab9c2a106ce3ee5d6ad7282afb49e1cc3954 r2120
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Tue Dec 6 14:39:21 2011 -0800

    Fix regression in r2118
    Broke trellis with i16x16 macroblocks.

commit 0637cd67cb245fce5ba190fa4b9c341319ea2b37 r2119
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Wed Nov 30 13:02:12 2011 -0800

    Modify MBAFF chroma deblock functions to handle U/V at the same time
    Allows for more convenient asm implementations.

commit 67f1fdc4d9c030568eac8cf9ab9d0bb249f520db r2118
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Thu Nov 10 16:16:13 2011 -0800

    CABAC trellis optimizations: use SIMD quant
    Significant speed increase, minor change in output due to rounding.

commit e047b3c475cd42b6647397a244e239ebfca53bf6 r2117
Author: Steven Walters <kemuri9@gmail.com>
Date:   Sun Nov 6 09:48:30 2011 -0800

    YUV range detection and support for x264CLI
    Two new options: --input-range and --range.
    --input-range forces the range of the input in case of misdetection; auto by default.
    -- range sets the range of the output; x264cli will convert if necessary, TV by default.
    --fullrange is now removed as a CLI option (but the libx264 API is unchanged).

commit 00df989cc06208050230756525633438d76b5a6a r2116
Author: Kieran Kunhya <kieran@kunhya.com>
Date:   Fri Nov 4 20:09:13 2011 +0000

    Pass through user data

commit 04a0aeefd2f5b152c5dbca4a1c6569bd27c9f721 r2115
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Thu Oct 27 14:05:56 2011 -0700

    Remove unpredictable branch in CABAC dqp

commit 4185ee883b04d9cee57a64fdebd153830b7b27ba r2114
Author: Loren Merritt <pengvado@akuvian.org>
Date:   Sun Oct 23 23:15:11 2011 +0000

    x86inc: AVX symmetry optimization
    3-arg AVX ops with a memory arg can only have it in src2,
    whereas SSE emulation of 3-arg prefers to have it in src1 (i.e. the move).
    So, if the op is symmetric and the wrong one is memory, swap them.
    Eliminates redundant moves in some cases when using 3-operand without AVX with memory arguments.
    Also fix movss and movsd in some cases, and flag shufps correctly as float.

commit cc129adcaaf5604f3d4fea9ebcb289403192a741 r2113
Author: Anton Mitrofanov <Bugmaster@narod.ru>
Date:   Tue Nov 29 13:45:13 2011 -0800

    checkasm: shut up gcc warnings, fix some naming of functions in results

commit f0ccc98bb747b8ee0fe9329f4205cf382788bb89 r2112
Author: Mans Rullgard <mans@mansr.com>
Date:   Mon Nov 28 16:29:12 2011 -0800

    checkasm: fix build on ARM
    Because of how ALIGNED_ARRAY_16 is defined on ARM, array initialisers cannot be used here.  Use memset() instead.

commit d8d8e756b1fee72b4771761d6aa4cfb31edc0b67 r2111
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Sat Nov 12 01:31:49 2011 +0400

    Improve makefile rules
    Remove the need for "make clean" after most reconfigures.

commit e6d33a931c08918e78dcae97e4d80d0c3411bf2c r2110
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Sat Nov 12 00:47:48 2011 +0400

    Mark some local functions as static, cosmetics

commit e0c11dc6e283569606aaa97767401c6a13c2529d r2109
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Fri Nov 11 23:19:02 2011 +0400

    Fix crash if timecode file opening fails

commit a14db080c3fdba4cadc38152a292bb1fa216d50e r2108
Author: Fabian Greffrath <fabian+debian@greffrath.com>
Date:   Fri Nov 11 13:25:43 2011 -0800

    Configure: force PIC for shared build on PARISC and MIPS

commit 6a0bd421bf5fd006012ddcd1be2072a8736b2d27 r2107
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Sat Oct 22 19:41:07 2011 +0400

    Improve yasm version check
    Previous check allowed certain earlier versions that weren't fully compatible.

commit 07efeb45db224b7757880d4d63bb549fb454f6db r2106
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Tue Oct 18 14:30:26 2011 -0700

    Add fenc prefetching to adaptive quant
    Many fewer cache misses, faster adaptive quant.

These builds will NOT work with Avidemux 2.5.4 or older. Please update to Avidemux 2.5.6 r7716 (http://forum.doom9.org/showpost.php?p=1548105&postcount=1701) or later now!
Title: Re: libx264 GIT builds
Post by: LoRd_MuldeR on January 21, 2012, 02:24:10 PM
libx264 SVN-r2146 library pack:
Changelog:
Code Select
commit bcd41dbcaa4430b2118d9f6828c2b9635cf9d58d r2146
Author: Loren Merritt <pengvado@akuvian.org>
Date:   Wed Jan 18 15:47:07 2012 -0800

    Fix trellis 2 + subme >= 8
    Trellis didn't return a boolean value as it was supposed to.
    Regression in r2143-5.

commit 748fe16c1303b89d2a1d0378addd83fb4198f51a r2145
Author: Loren Merritt <pengvado@akuvian.org>
Date:   Fri Jan 6 15:53:29 2012 +0000

    CABAC trellis opts part 4: x86_64 asm
    Another 20% faster.
    18k->12k codesize.
   
    This patch series may have a large impact on encoding speed.
    For example, 24% faster at --preset slower --crf 23 with 720p parkjoy.
    Overall speed increase is proportional to the cost of trellis (which is proportional to bitrate, and much more with --trellis 2).

commit cfdb36ece729209631f7213506685ae733d7f5d4 r2144
Author: Loren Merritt <pengvado@akuvian.org>
Date:   Fri Jan 6 15:53:04 2012 +0000

    CABAC trellis opts part 3: make some arrays non-static

commit 65bd12ae875a768a06b67ec6297dec18323e0768 r2143
Author: Loren Merritt <pengvado@akuvian.org>
Date:   Thu Dec 22 17:56:06 2011 +0000

    CABAC trellis opts part 2: C optimizations
   
    Hoist the branch on coef value out of the loop over node contexts.
    Special cases for each possible coef value (0,1,n).
    Special case for dc-only blocks.
    Template the main loop for two common subsets of nodes, to avoid a bunch of branches about which nodes are live.
    Use the nonupdating version of cabac_size_decision in more cases, and omit those bins from the node struct.
    CABAC offsets are now compile-time constants.
    Change TRELLIS_SCORE_MAX from a specific constant to anything negative, which is cheaper to test.
    Remove dct_weight2_zigzag[], since trellis has to lookup zigzag[] anyway.
   
    60% faster on x86_64.
    25k->18k codesize.

commit e176619d010fc32c970c7ab7a769bbfbe2665f61 r2142
Author: Loren Merritt <pengvado@akuvian.org>
Date:   Thu Dec 22 17:55:06 2011 +0000

    CABAC trellis opts part 1: minor change in output
    Due to different tie-break order.

commit 4e87f36a0e1a78242f04db611e06f80b6b38d900 r2141
Author: Henrik Gramner <hengar-6@student.ltu.se>
Date:   Sun Jan 8 04:14:10 2012 +0100

    x86inc improvements for 64-bit
   
    Add support for all x86-64 registers
    Prefer caller-saved register over callee-saved on WIN64
    Support up to 15 function arguments

commit 84a06e611aff1267a720bf9552b3bcf263bd83b5 r2140
Author: Ilia Valiakhmetov <zakne0ne@gmail.com>
Date:   Sun Jan 15 04:47:58 2012 -0600

    High bit depth SSE2/AVX add8x8_idct8 and add16x16_idct8
    From Google Code-In.

commit c605e3174410ba5c7d1d0a777082e2397734d637 r2139
Author: Edward Wang <edward.c.wang@compdigitec.com>
Date:   Wed Jan 4 15:35:54 2012 -0800

    MMX/SSE2/AVX predict_8x16_p, high bit depth fdct8
    From Google Code-In.

commit 6b06f6d3f7f800dca1a4ea154f54427d5b3cea2b r2138
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Thu Dec 22 14:03:15 2011 -0800

    XOP 8-bit fDCT
    Use integer MAC for one of the SUMSUB passes.  About a dozen cycles faster for 16x16.

commit c4b54c83629bb92af6c4836a8859e9432dc7333a r2137
Author: Cristian Militaru <cristipiticul@yahoo.com>
Date:   Wed Jan 4 12:38:08 2012 -0800

    High bit depth intra_sad_x3_4x4
    From Google Code-In.

commit c032fbaa3801fb4cf8dd1dd95a6479ca5bd262e2 r2136
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Thu Dec 8 13:45:41 2011 -0800

    Use a large LUT for CAVLC zero-run bit codes
    Helps the most with trellis and RD, but also helps with bitstream writing.
    Seems at worst neutral even in the extreme case of a CPU with small L2 cache (e.g. ARM Cortex A8).

commit ebb1429e2d24f57aa4ea75284386a15f2eab553e r2135
Author: Matt Habel <habelinc@gmail.com>
Date:   Fri Dec 16 23:16:09 2011 -0800

    High bit depth intra_sad_x3_8x8, intra_satd_x3_4x4/8x8c/16x16
    Also add an ACCUM macro to handle accumulator-induced add-or-swap more concisely.

commit 6d921c5bdefae1a733a3a4c29d88ea15fcece76e r2134
Author: Shitiz Garg <mail@dragooon.net>
Date:   Sat Dec 3 15:34:57 2011 -0800

    MMX 10-bit predict_8x8c_h and predict_8x16c_h
    From Google Code-In.

commit 47cdaa9c3d8197d4deb711d9bcc4af869ef8a426 r2133
Author: Aaron Schmitz <me@aaronschmitz.com>
Date:   Wed Nov 30 00:15:45 2011 -0600

    Some MBAFF x86 assembly functions.
    deblock_chroma_420_mbaff, plus 422/422_intra_mbaff implemented using existing functions.
    From Google Code-In.

commit 027b05e0a22421e477847506a205a49b151ae5bf r2132
Author: George Stephanos <gaf.stephanos@gmail.com>
Date:   Thu Dec 1 16:53:45 2011 -0800

    More ARM NEON assembly functions
    predict_8x8_v, predict_4x4_dc_top, predict_8x8_ddl, predict_8x8_ddr, predict_8x8_vl, predict_8x8_vr, predict_8x8_hd, predict_8x8_hu.
    From Google Code-In.

commit 658a3585b74f77fd8f78588f3f39e0abefb104c4 r2131
Author: Ilia <zakne0ne@gmail.com>
Date:   Mon Nov 28 05:20:09 2011 -0800

    More 4:2:2 asm functions
    High bit depth version of deblock_h_chroma_422.
    Regular and high bit depth versions of deblock_h_chroma_intra_422.
    High bit depth pixel_vsad.
    SSE2 high bit depth and MMX 8-bit predict_8x8_vl.
    Our first GCI patch this year!

commit 978abe065737089913feccffece483bc69a9e5b0 r2130
Author: Henrik Gramner <hengar-6@student.ltu.se>
Date:   Thu Dec 8 16:14:35 2011 +0100

    SSE2 and SSSE3 versions of sub8x16_dct_dc
    Also slightly faster sub8x8_dct_dc

commit 61a78a1b417595c4b5d7ef6831692904a243a9fc r2129
Author: Steven Walters <kemuri9@gmail.com>
Date:   Mon Dec 5 08:46:34 2011 -0500

    Resize filter updates
    Use AVPixFmtDescriptors to pick the most compatible x264 csp for any pixel format.
    Fix deprecated use of av_set_int.
    Now requires libavutil >= 51.19.0

commit bc6c98cf4f76c779c8c07f43aa97ac29b1150bc0 r2128
Author: Oka Motofumi <chikuzen.mo@gmail.com>
Date:   Thu Jan 5 14:23:50 2012 -0800

    Add out-of-tree build support

commit f33c8cb0f8fff7a83100b3e9d15baba53c6f6a35 r2127
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Fri Dec 16 18:17:00 2011 +0400

    Limit SSIM to 100db
    Avoids floating point error for infinite SSIM (lossless).

commit c0d698859c36be611d465f968762f042853be817 r2126
Author: Reynaldo H. Verdejo Pinochet <reynaldo@collabora.com>
Date:   Wed Jan 4 13:16:12 2012 -0300

    Fix wrong conditional inclusion of inttypes.h
    inttypes.h is required by encoder/ratecontrol.c for SCNxxx macros, and HAVE_STDINT_H does not imply having inttypes.h.
    stdint.h is a subset of inttypes.h, but this isn't enough for x264.
    This change fixes building x264 with Android's toolchain.

commit b081d179e741ceffee2217f6fda06779693dce56 r2125
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Wed Dec 21 11:08:56 2011 +0400

    Fix crash with sliced threads and input height <= 112

commit 64da5f9df46ac33a5a6b56ca1510d2082e6fbb62 r2124
Author: Phillip Blucas <pblucas@gmail.com>
Date:   Mon Dec 19 17:43:41 2011 -0600

    Fix loading custom 8x8 chroma quant matrices in 4:4:4

commit 4c08e42504af81cdbe5789a309e868ca8eda2c1f r2123
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Fri Dec 16 01:48:07 2011 +0400

    Fix PCM cost overflow

commit 489a9b2d04c4828877930d2a9104ce93dde8cb85 r2122
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Fri Dec 9 01:54:22 2011 +0400

    Fix overflow in 8-bit x86 vsad asm function

commit c291a9d09263708e9d9f02e28f8442fdbe46bb06 r2121
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Wed Dec 7 19:14:52 2011 +0400

    Fix crash in --fullhelp when compiled against recent ffmpeg
    Don't assume all pixel formats have a description.

These builds will NOT work with Avidemux 2.5.5 or older. Please update to Avidemux 2.5.6 r7716 (http://forum.doom9.org/showpost.php?p=1548105&postcount=1701) or later now!
Title: Re: libx264 GIT builds
Post by: dado023 on March 16, 2012, 04:51:20 PM
hi mulder,

can we expect new build any time soon  :-\
Title: Re: libx264 GIT builds
Post by: LoRd_MuldeR on July 14, 2012, 03:38:15 PM
libx264 SVN-r2200 library pack:
Changelog:
Code Select
commit 999b753ff0f4dc872077f4fa90d465e948cbe656 r2200
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Tue May 8 15:42:56 2012 -0700

    Threaded lookahead
   
    Split each lookahead frame analysis call into multiple threads.  Has a small
    impact on quality, but does not seem to be consistently any worse.
   
    This helps alleviate bottlenecks with many cores and frame threads. In many
    case, this massively increases performance on many-core systems.  For example,
    over 100% faster 1080p encoding with --preset veryfast on a 12-core i7 system.
    Realtime 1080p30 at --preset slow should now be feasible on real systems.
   
    For sliced-threads, this patch should be faster regardless of settings (~10%).
   
    By default, lookahead threads are 1/6 of regular threads.  This isn't exacting,
    but it seems to work well for all presets on real systems.  With sliced-threads,
    it's the same as the number of encoding threads.

commit ecfbf9d8025e39783bc4262dc1972ca742d8a993 r2199
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Fri May 4 17:18:12 2012 +0400

    Add support for RGB formats in bit-depth conversion filter

commit 1c97f3570fba02f768fbf649b9f7d48beb720048 r2198
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Sat May 12 13:57:49 2012 +0400

    Fix some bugs in mb_info code

commit 69a0443e7d8ab032a7f3c3468a42177d5e64daa2 r2197
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Thu Mar 29 14:14:07 2012 -0700

    Add mb_info API for signalling constant macroblocks
    Some use-cases of x264 involve encoding video with large constant areas of the frame.
    Sometimes, the caller knows which areas these are, and can tell x264.
    This API lets the caller do this and adds internal tracking of modifications to macroblocks to avoid problems.
    This is really only suitable without B-frames.
    An example use-case would be using x264 for VNC.

commit df6252cfed7c23fbe883456f4e0607a7f8e91ad8 r2196
Author: Henrik Gramner <hengar-6@student.ltu.se>
Date:   Sat Apr 7 00:40:09 2012 +0200

    Faster chroma weight cost calculation
   
    New assembly function with SSE2, SSSE3 and XOP implementations for calculating absolute sum of differences.

commit cce88ebc9e517b0fa8735b81ac30b4e6a79c8154 r2195
Author: Lucien <astrataro@gmail.com>
Date:   Sat Mar 31 13:42:49 2012 +0100

    Add Level 5.2 support

commit ee30c84e38b30896ffa6ddc417f3b4c281a86d1a r2194
Author: Henrik Gramner <hengar-6@student.ltu.se>
Date:   Thu Apr 12 19:14:43 2012 +0200

    Eradicate all mention of Extended Profile
    x264 never supported it and never will because nobody uses it.

commit 8ca49cc5c40813d8b98544989eb684e167b06aa0 r2193
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Tue Apr 3 21:46:52 2012 +0400

    Fix disabling of mbtree when using 2pass encoding and zones

commit 3691332c0b33a68f9d6f519edaa2b848ed34a38c r2192
Author: Alexander Prikhodko <komisar666@gmail.com>
Date:   Sat Mar 31 12:06:21 2012 +0300

    configure: force select -mXX gcc option for i386/x86-64
    Makes multilib compilation more convenient.

commit e1ccbf9bb3abdd25d3f0c76682926ec49f3f8001 r2191
Author: Rafaël Carré <funman@videolan.org>
Date:   Sun Apr 15 21:20:14 2012 -0400

    Update config.guess and config.sub
    Adds support for a bunch of targets, including:
    aarch64 (armv8)
    arm-linux-androideabi

commit f87619768dba73c1effbcfb08875d096575e079e r2190
Author: Alexander Prikhodko <komisar666@gmail.com>
Date:   Sat Mar 31 11:33:41 2012 +0300

    configure: correct use of RC variable and add --extra-rcflags

commit 35cf912671fddcb3e701bf667a75f77dd8b28264 r2189
Author: Steven Walters <kemuri9@gmail.com>
Date:   Wed Mar 28 21:15:04 2012 -0400

    ICL/MSVS: Fix shared library generation and usage
    MSVS requires exported variables to be declared with the DATA keyword, and requires that imported variables be declared with dllimport.
    This does not fix x264 cli being unable to use a shared library built by ICL however.

commit 259a6e57ae25c71acc1669e0aefde7ffe7e235ec r2188
Author: Kieran Kunhya <kierank@ob-encoder.com>
Date:   Tue Mar 27 17:38:56 2012 +0100

    Fix intra-refresh + hrd

commit e0351cdfeb45bf7f891eeb1dc475292154bb9d82 r2187
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Sun Mar 25 17:34:24 2012 +0400

    Fix frame input colorspace check

commit 7392c8c31f791e9b4c10e4959f8715c8a8233d25 r2186
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Thu Mar 22 13:56:50 2012 -0700

    Fix comment in deblock.c
    The code does, in fact, handle CAVLC+8x8dct correctly already.

commit 6979713216d792e44e3cbaeeba74b455e0a07c62 r2185
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Tue Mar 13 14:37:26 2012 -0700

    Fix sliced-threads ratecontrol bug
    Was using qp instead of qscale; could cause NANs (not to mention less accurate results).

commit 5c85e0a2b7992fcaab09418e3fcefc613cffc743 r2184
Author: Anton Mitrofanov <Bugmaster@narod.ru>
Date:   Sun Mar 11 23:08:18 2012 -0700

    Fix clobbering of mutex/cvs
    Regression in r2183.
    Bizarrely seemed to work on many platforms, but crashed on win64 and may have been slower.
    Only affected sliced threads during encoding, but could cause crashes on x264 encoder close even without sliced threads.

commit c522ad1fed167d0e985e4f9dcdee042473cf74db r2183
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Fri Feb 24 13:34:39 2012 -0800

    Sliced-threads: do hpel and deblock after returning
    Lowers encoding latency around 14% in sliced threads mode with preset superfast.
    Additionally, even if there is no waiting time between frames, this improves parallelism, because hpel+deblock are done during
    the (singlethreaded) lookahead.
    For ease of debugging, dump-yuv forces all of the threads to wait and finish instead of setting b_full_recon.

commit 6a27a481d4c3508ce778a61a139a4734bb8126f7 r2182
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Fri Feb 24 13:16:52 2012 -0800

    Add full-recon API option
    Fully reconstruct frames even without dump-yuv.

commit e856755d2a67f45249c24cb51aa38fc4fa192321 r2181
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Wed Feb 22 13:33:36 2012 -0800

    x86inc: switch to amdnops
    Recent AMD CPUs' instruction decoders choke horribly on extremely long nops (i.e. with 4 prefixes).
    Won't affect much, since we don't use ALIGN much.

commit 5a242c5862baaa4bd5829bd1b43dc11cf5c86344 r2180
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Tue Feb 14 16:54:03 2012 -0800

    BMI1 decimate functions
    Intel was nice enough to make tzcnt equal to "rep bsf", which is backwards-compatible.
    This means we don't actually have to add new functions to make it work.

commit ac31c59a98c6c690894670b9c9af2612f799d85b r2179
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Tue Feb 14 15:07:10 2012 -0800

    Minor asm changes

commit 83561e55dde06f3247aa9b99fa62ead38d7a406e r2178
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Thu Feb 9 14:23:52 2012 -0800

    Add row-reencoding support to VBV for improved accuracy
    Extremely accurate, possibly 100% so (I can't get it to fail even with difficult VBVs).
    Does not yet support rows split on slice boundaries (occurs often with slice-max-size/mbs).
    Still inaccurate with sliced threads, but better than before.

commit 5a69f8e105663497794d4bb4e58cf7baa5cd29cb r2177
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Thu Feb 9 12:38:44 2012 -0800

    Abstract bitstream backup/restore functions
    Required for row re-encoding.

commit 037d123cf62c4af2dc13742b8606882b6d0d3d9e r2176
Author: Anton Mitrofanov <Bugmaster@narod.ru>
Date:   Thu Feb 9 15:27:53 2012 -0800

    Add an small per-MB cost penalty for lowres
    Helps avoid VBV predictors going nuts with very low-cost MBs.
    One particular case this fixes is zero-cost MBs: adaptive quantization decreases the QP a lot, but (before this patch),
    no cost penalty gets factored in for this, because anything times zero is zero.

commit de5a0adca1a7d08b1233b317ec092dbf19263d2f r2175
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Mon Feb 13 18:31:51 2012 -0800

    Remove explicit run calculation from coeff_level_run
    Not necessary with the CAVLC lookup table for zero run codes.

commit 9f1ac3b36eb2666e9d2ec4b859f3b63f60827bf0 r2174
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Mon Feb 13 13:20:06 2012 -0800

    Export PSNR/SSIM in x264 API

commit 7e85ec036df4290697239f5dc9f4a793313ceebc r2173
Author: Ronald S. Bultje <rsbultje@gmail.com>
Date:   Wed Feb 8 13:10:31 2012 -0800

    x86inc: support yasm -f win64
    Not necessary for x264, as -m amd64 already does the right thing, but used by external users of x86inc.

commit 02c3d5ec58d6bcbc5e22715ae80d53d8556f3c8f r2172
Author: Henrik Gramner <hengar-6@student.ltu.se>
Date:   Wed Feb 1 23:52:48 2012 +0100

    Fix incorrect zero-extension assumptions in x86_64 asm
    Some x264 asm assumed that the high 32 bits of registers containing "int" values would be zero.
    This is almost always the case, and it seems to work with gcc, but it is *not* guaranteed by the ABI.
    As a result, it breaks with some other compilers, like Clang, that take advantage of this in optimizations.
    Accordingly, fix all x86 code by using intptr_t instead of int or using movsxd where neccessary.
    Also add checkasm hack to detect when assembly functions incorrectly assumes that 32-bit integers are
    zero-extended to 64-bit.

commit 01f7a333e6c6a6d91a7fe977b491a448ddf4c117 r2171
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Thu Feb 23 09:11:23 2012 -0800

    Fix possible alignment crash when linking from MSVC
    x264_cavlc_init needs to be stack-aligned now.

commit b17c247178a24c218843639c3f46bcfde0edab0a r2170
Author: Anton Mitrofanov <Bugmaster@narod.ru>
Date:   Tue Feb 21 12:58:22 2012 -0800

    Fix rare overflow in 10-bit intra_satd_x3_16x16 asm

commit 1446fe7c47cf660d764b4cbf53694bc3df9b04de r2169
Author: Steven Walters <kemuri9@gmail.com>
Date:   Sat Feb 11 22:56:43 2012 -0500

    ICL: fix out of tree building and resource file usage on Windows

commit d3efb00abbedd2bbb70156bd989beefe06468116 r2168
Author: Oka Motofumi <chikuzen.mo@gmail.com>
Date:   Mon Feb 6 06:07:34 2012 +0900

    Add error handling for out-of-tree build

commit ec41b19edc67ee4eca09c0e3b37e6290844c5e1f r2167
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Tue Mar 6 17:34:02 2012 +0400

    Fix RGB colorspace input
    BGR/BGRA input was correct.

commit 39a4c6fecaaa0d6cde8d89d31ef6cd1d25ab802b r2166
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Mon Feb 13 16:40:32 2012 -0800

    Fix interlaced + extremal slice-max-size
    Broke if the first macroblock in the slice exceeded the set slice-max-size.

commit 3f72c99a15a07511b758d9e94217223480865124 r2165
Author: Henrik Gramner <hengar-6@student.ltu.se>
Date:   Sun Feb 5 20:43:09 2012 +0100

    Fix regression in r2141
    Broke register preservation in x264_cpu_cpuid and x264_cpu_xgetbv.
    Did not cause any problems.

commit da19765d723b06a1fa189478e9da61a1c18490f8 r2164
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Thu Jan 19 14:56:54 2012 -0800

    TBM, AVX2, FMA3, BMI1, and BMI2 CPU detection support
    TBM and BMI1 are supported by Trinity/Piledriver.
    The others (and BMI1) will probably appear in Intel's upcoming Haswell.
    Also update x86inc with AVX2 stuff.

commit efef20090a06a38f9d95755588d7830fb92a2a02 r2163
Author: Loren Merritt <pengvado@akuvian.org>
Date:   Fri Feb 3 06:27:18 2012 +0000

    x86inc: add TAIL_CALL macro to abstract a common asm idiom

commit a7e6e1793b4d2b49c9449d767320c71daa855cb6 r2162
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Wed Jan 25 16:44:38 2012 -0800

    Minor asm optimizations/cleanup

commit 56ba096141d16ffcbabd805e2d27014f62f0d722 r2161
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Tue Jan 24 19:03:58 2012 -0800

    Clean up and optimize weightp, plus enable SSSE3 weight on SB/BDZ
    Also remove unused AVX cruft.

commit 961a278e0123eb662b46a6f136a48a43f6a2d427 r2160
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Mon Jan 23 18:57:58 2012 -0800

    XOP frame_init_lowres
    Covers both 8-bit and 16-bit, ~5-10% faster on Bulldozer.

commit c5809994990df6c63b4250546844dc77181fee0f r2159
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Tue Jan 17 15:25:10 2012 -0800

    XOP 8x8 zigzags
    Field: 35(mmx) ->16(xop) cycles
    Frame: 32(ssse3)->20(xop) cycles

commit 14dc11f7c52fa29576e0003c8c16857a78bf5fbf r2158
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Mon Jan 23 15:09:38 2012 -0800

    AVX 32-bit hpel_filter_h
    Faster on Sandy Bridge.
    Also add details on unsuccessful optimizations in these functions.

commit 2fcd0446b5d91ae52e143682c30000a49441e4a1 r2157
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Fri Jan 27 16:29:30 2012 -0800

    x86inc: add high halfword register support
    Might be useful in a few cases.

commit 5c4b8484ea9aaabfb70523ba1f9c4d8343ad3221 r2156
Author: Ronald S. Bultje <rsbultje@gmail.com>
Date:   Wed Jan 25 13:53:59 2012 +0800

    Change %ifdef directives to %if directives in *.asm files
    This allows combining multiple conditionals in a single statement.

commit 1b558de42dc08a303c2faf79fc9999b48a876370 r2155
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Sun Jan 22 22:13:52 2012 +0400

    Use TV range algorithm for bit-depth conversions
    Such sources are more common, so better to be correct for the common case.
    This also produces less error for the case of full range than the previous algorithm produced for the case of TV range.

commit 83c371deba853a4ebb28739e868df86b3153fb3e r2154
Author: Hii <hiiragikei@gmail.com>
Date:   Wed Jan 25 16:29:22 2012 +0800

    Bump dates to 2012

commit a2925c5a707e833c34fa0a64d497c02e6dcfe6e6 r2153
Author: Henrik Gramner <hengar-6@student.ltu.se>
Date:   Sat Jan 28 21:38:27 2012 +0100

    Add Windows resource file
    Displays version info in Windows Explorer.

commit 98ade832d053f6bfca4d0dd2ab0cd1c88531721d r2152
Author: Sergey Radionov <RSATom@gmail.com>
Date:   Mon Jan 16 13:22:44 2012 -0800

    Fix win32 pthread_cond_signal
    Isn't used by x264 currently, so didn't cause a problem.
    Fix backported from libav.

commit a3f44077dc238dea92c0894d352b5a8723b9201b r2151
Author: Mans Rullgard <mans@mansr.com>
Date:   Wed Feb 1 15:55:25 2012 -0800

    ARM: align asm functions to 4 bytes.
    Some linkers apparently fail to correctly align ARM functions when mixing with Thumb code.

commit d3a39c92f5c130cad6d45e9daffa5a2beb145ebb r2150
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Sun Jan 22 13:00:23 2012 +0400

    Fix normalization of colorspace when input is packed YUV 4:2:2


These builds will NOT work with Avidemux 2.5.6 or older. Please update to Avidemux 2.6 r8054 (http://avidemux.razorbyte.com.au/#betaBuilds) or later now!
Text only | Text with Images