Current Patches, Where to get them, How they affect speed/output

[Atak_Snajpera]

I always use ffshow.

[Blue_MiSfit]

@Roozhou:

Suppose you had a very high quality ~10-20mbps 480p H.264 file (or a whole giant lot of them, in my case), and you wanted to transcode them to various CBR bitrates as quickly as possible without totally looking like crap. A good way to do this is via 1 pass CBR encodes with --preset veryfast, or thereabouts. It works very well for my purposes anyway, and you can get insanely high transcoding speeds this way.

While it's true that my testing has only been via FFMS2 in AviSynth, my script is usually otherwise empty. Therefore, I would expect similar performance when using x264 directly on the sources, via its internal FFMS2 when built with ffmpeg-mt.

~MiSfit

[roozhou]

While it's true that my testing has only been via FFMS2 in AviSynth, my script is usually otherwise empty. Therefore, I would expect similar performance when using x264 directly on the sources, via its internal FFMS2 when built with ffmpeg-mt.
~MiSfit
FFMS2 needs extra indexing so it is not suitable for high-speed transcoding.

And if you have a lot of videos, spawning multiple encodings gives faster speed and better quality because you don't have to use multi-threaded encoding.

[Blue_MiSfit]

Maybe true, but indexing the source can sometimes be worth the additional time.

Regarding the whole "spawn multiple encodes vs use more threads" debate, I dunno... I've always been more comfortable with the idea of being able to rush through a single file if I needed to, versus always running a bunch of single or lightly threaded encodes.

I do totally agree that in theory it should be faster / better quality to do the latter, but I would bet the differences would be minor, especially since on a large scale, you would cause a lot more random I/O activity. But, I'm getting off-topic.

Regardless, I think ffmpeg-mt is very nice to have in x264 when I simply want to take an existing H.264 file and transcode to a lower bitrate as quickly as possible. I actually use this same method to transcode content from unrestricted / High@4.1 down to a lower level for device compatibility (iPhone etc). I do this alllll the time when I'm in a hurry, and headed to the gym, laudromat, or airport in need of new media to consume. :)

~MiSfit

[rack04]

Toolchain:
gcc 4.4.3
gpac 0.4.6-dev revison 5
pthreads 2.9.0.0 gc-static
yasm 1.0.0
x264_x86_r1542M_Generic (http://www.multiupload.com/TUI1S1IW3D)

Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

Patches:
x264.open-gop.19_r1542 (http://pastebin.com/MbKdh684) <Trahald>
ffmpeg_static_pthreads_r22912 (http://pastebin.com/xyQiwPYD) <angustia>
ffms2_threads_fix_r309 (http://pastebin.com/FppV5KE6) <komisar>
x264_x86_r1542M_Generic (http://www.multiupload.com/OOBVLDAYLL)

Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
filters: resize select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no

Patches:
x264.open-gop.19_r1542 (http://pastebin.com/MbKdh684) <Trahald>
x264_filtering_r1542 (http://pastebin.com/Xqv2G1bS) <kemuri-_9>
ffmpeg_static_pthreads_r22912 (http://pastebin.com/xyQiwPYD) <angustia>
ffms2_threads_fix_r309 (http://pastebin.com/FppV5KE6) <komisar>

[outlaw.78]

x264 0.93.1542 x64 & x86 (http://www.mediafire.com/?m5rghmbjxyz)

gcc 4.5.0
ffmpeg svn 22926
swscale svn 31053
ffms2 svn 309
pthreads 2.9.0.0 static
x264 0.93.1542 x86,x64,amdfam10,fprofiled

[bob0r]

pthreads 2.9.0.0 static
Where does this made up version come from?

[kemuri-_9]

Where does this made up version come from?

pthread.h:

/*
* See the README file for an explanation of the pthreads-win32 version
* numbering scheme and how the DLL is named etc.
*/
#define PTW32_VERSION 2,9,0,0
#define PTW32_VERSION_STRING "2, 9, 0, 0\0"

[roozhou]

pthread.h:

/*
* See the README file for an explanation of the pthreads-win32 version
* numbering scheme and how the DLL is named etc.
*/
#define PTW32_VERSION 2,9,0,0
#define PTW32_VERSION_STRING "2, 9, 0, 0\0"


Where can i get the source code of pthreads-win32 2.9.0.0?

[Audionut]

x264_x86_r1542M_Generic

Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
filters: resize select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no

Patches:
x264.open-gop.19_r1542 (http://pastebin.com/MbKdh684) <Trahald>
x264_filtering_r1542 (http://pastebin.com/Xqv2G1bS) <kemuri-_9>
ffmpeg_static_pthreads_r22912 (http://pastebin.com/xyQiwPYD) <angustia>
ffms2_threads_fix_r309 (http://pastebin.com/FppV5KE6) <komisar>

Hi rack04, any chance of a 64bit build with these patches?

[LoRd_MuldeR]

Where can i get the source code of pthreads-win32 2.9.0.0?

http://sourceware.org/cgi-bin/cvsweb.cgi/pthreads/?cvsroot=pthreads-win32

[alexins]

Where can i get the source code of pthreads-win32 2.9.0.0?

http://sources.redhat.com/pthreads-win32/
cvs -d :pserver:anoncvs@sourceware.org:/cvs/pthreads-win32 login
{enter ``anoncvs'' for the password}
cvs -d :pserver:anoncvs@sourceware.org:/cvs/pthreads-win32 checkout pthreads

[rack04]

Toolchain:
gcc 4.4.3
gpac 0.4.6-dev revison 5
pthreads 2.9.0.0 gc-static
yasm 1.0.0
LAVF/FFMS Builds:
ffmpeg svn22939 and libswscale svn31054 (http://www.multiupload.com/8MEH109002)
ffms2 svn310 (http://www.multiupload.com/M7ITP46POL)
x264 Builds:
x264_x86_r1542M (http://www.multiupload.com/VNMD003PNB)

Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
filters: resize select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x64_r1542M (http://www.multiupload.com/IEIPFI7PMR)

Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
filters: resize select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no
Patches:
x264.open-gop.19_r1542 (http://pastebin.com/MbKdh684) <Trahald>
x264_filtering_r1542 (http://pastebin.com/Xqv2G1bS) <kemuri-_9>
ffmpeg_static_pthreads_r22912 (http://pastebin.com/xyQiwPYD) <angustia>
ffms2_threads_fix_r309 (http://pastebin.com/FppV5KE6) <komisar>

[outlaw.78]

x264 0.94.1564 x64 & x86 (http://www.mediafire.com/?nqjdmmm2ilm)

gcc 4.5.0
ffmpeg svn 22960
swscale svn 31067
ffms2 svn 310
pthreads 2.9.0.0 static
x264 0.94.1564 x86,x64,amdfam10,fprofiled

[alwa]

Hello,
i've tried today to compile x264 with the new 2.7 release of the GCC frontend for llvm. (http://llvm.org/releases/download.html#2.7)
It produces a smaller executable than GCC, that sadly crashes immediately (standard configuration no ffmpeg stuff). But if asm is disabled the executable works (at least with the default x264 stettings so far).
The the first speed impressions are disillusioning.
With the x264 default settings on SOCCER_704x576_30fps.yuv with a Q9550:
~13fps gcc executable
~9fps llvm executable
(i'know no stdev and stuff, but llvm builds still seem to be clearly slower)

Maybe some x264 dev can take a look on compiles with llvm (if not already done) and diagnose the asm problem and figure out if there would be any benefit in supporting llvm.

I'm aware that the compiler is not that important for the speed of x264, i just wanted to put some thoughts out there.

[rack04]

Toolchain:
GCC 4.4.3
GPAC 0.4.6-DEV Revison 5
Pthreads 2.9.0.0 GC-static
Yasm 1.0.0
LAVF/FFMS Builds:

ffmpeg SVN-r23012M and libswscale SVN-r31128M (http://www.multiupload.com/YWJ7FHCXS5)
ffms2 SVN-r311M (http://www.multiupload.com/6OJPV3X6LU)
LAVF/FFMS Patches:
ffmpeg_static_pthreads_r23011 (http://pastebin.com/0LMeaBqt) <angustia>
libswscale_x64_fix_r31032 (http://pastebin.com/0yAGkLXC) <BugMaster>
ffms2_threads_fix_r309 (http://pastebin.com/i0M5EuHs) <komisar>
x264 Builds:

x264_x64_r1570M_Generic (http://www.multiupload.com/PBQK3WN7OC)
Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x86_r1570M_Generic (http://www.multiupload.com/3KHHTA89IC)
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264 Patches:
x264_sws_typecast_r1570 (http://pastebin.com/78yXue1H) <komisar>
x264_demuxer_threads_r1570 (http://pastebin.com/rQpuTTAY) <komisar>
x264.open-gop.20_r1570 (http://pastebin.com/LiDUepz8) <Trahald>

[kemuri-_9]

gcc 4.4.4 and gcc 4.5.0 are out, builders still using 4.4.3 should update to one of them.

[Audionut]

rack04, could you include this patch, http://x264.fushizen.eu/patches/x264_fade_compensation-1542.diff
in your next build please.

[rack04]

Toolchain:
GCC 4.4.3
GPAC 0.4.6-DEV Revison 5
Pthreads 2.9.0.0 GC-static
Yasm 1.0.0
LAVF/FFMS Builds:

ffmpeg SVN-r23022M and libswscale SVN-r31137M (http://www.multiupload.com/7NABARIGI0)
ffms2 SVN-r311M (http://www.multiupload.com/APHVP0EDF9)
LAVF/FFMS Patches:
ffmpeg_static_pthreads_r23016 (http://pastebin.com/f8NWT5j5) <angustia>
libswscale_x64_fix_r31032 (http://pastebin.com/0yAGkLXC) <BugMaster>
ffms2_threads_fix_r309 (http://pastebin.com/i0M5EuHs) <komisar>
x264 Builds:

x264_x64_r1570M (http://www.multiupload.com/IZX18M32JD)
Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x86_r1570M (http://www.multiupload.com/2P68UNJPX7)
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264 Patches:
x264_sws_typecast_r1570 (http://pastebin.com/78yXue1H) <komisar>
x264_demuxer_threads_r1570 (http://pastebin.com/rQpuTTAY) <komisar>
x264.open-gop.20_r1570 (http://pastebin.com/LiDUepz8) <Trahald>
x264_fade_compensation_r1570_v2 (http://pastebin.com/dhCNv6bx) <Dark Shikari>

[julius666]

rack04, could you include this patch, http://x264.fushizen.eu/patches/x264_fade_compensation-1542.diff
in your next build please.

What changes do this patch make?

[JEEB]

Basically makes use of x264's internal fade-finding mechanism and assigns more bits to those places that are "marked" as fades. Works when mbtree is on with weightp 0 and 2 IIRC.

Adds a setting that controls the strength of this feature (how strong the effect is).

--fade-compensate <float> Allocate more bits to fades [0.0]
Approximate sane range: 0.0 - 1.0

Edit: A small fix pointed out by VFR Maniac. Line 19 on the pastebin'd 1570 patch, change %2.f to %.2f

[outlaw.78]

x264 0.94.1570 x64 & x86 (http://www.mediafire.com/?wbddnmnwh2a) AMD

gcc 4.5.1 20100429 pre-release
ffmpeg svn 23017
swscale svn 31136
ffms2 svn 311
pthreads 2.9.0.0 static
x264 0.94.1570 x86,x64,amdfam10,fprofiled

[Audionut]

Thanks rack04. Were you aware of the fix before you made your build?

[rack04]

Thanks rack04. Were you aware of the fix before you made your build?

No. I will post updated builds soon.

[jpsdr]

Not too soon maybe, open-gop have seems to have a high probability to update to 21 soon...
BTW, thanks for your builds.

[rack04]

Not too soon maybe, open-gop have seems to have a high probability to update to 21 soon...
BTW, thanks for your builds.

I edited my previous post with a new x264 build patched with x264_fade_compensation_r1570_v2 (http://pastebin.com/dhCNv6bx)

[rack04]

Toolchain:
GCC 4.4.3
GPAC 0.4.6-DEV Revison 5
Pthreads 2.9.0.0 GC-static
Yasm 1.0.0
LAVF/FFMS Builds:

ffmpeg SVN-r23034M and libswscale SVN-r31139M (http://www.multiupload.com/ZBG0S2KPMR)
ffms2 SVN-r311M (http://www.multiupload.com/2ANQARVAO1)
LAVF/FFMS Patches:
ffmpeg_static_pthreads_r23016 (http://pastebin.com/f8NWT5j5) <angustia>
libswscale_x64_fix_r31032 (http://pastebin.com/0yAGkLXC) <BugMaster>
ffms2_threads_fix_r309 (http://pastebin.com/i0M5EuHs) <komisar>
x264 Builds:

x264_x64_r1583M (http://www.multiupload.com/QZ3ED30O1S)
Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x86_r1583M (http://www.multiupload.com/UJX3V6BZPV)
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264 Patches:
x264_sws_typecast_r1570 (http://pastebin.com/78yXue1H) <komisar>
x264_demuxer_threads_r1570 (http://pastebin.com/rQpuTTAY) <komisar>
x264.open-gop.20_r1583 (http://pastebin.com/uEsyh9Xf) <Trahald>
x264_fade_compensation_r1583 (http://pastebin.com/bfL8MNgR) <Dark Shikari>

I will post some GCC 4.4.4 builds later to compare to GCC 4.4.3.

EDIT: I get a segmentation fault when trying to build ffmpeg using GCC 4.4.4.

[alexins]

EDIT: I get a segmentation fault when trying to build ffmpeg using GCC 4.4.4.

I did build x 264, using GCC 4.4.4 (Stable) (http://www.xvidvideo.ru/2009-10-22-10-49-14/doc_details/3567-cross-mingw-x86x64-201004292200-with-gcc-444-stable-pthreads-290-static.html). No error, here's a detailed logs build ffmpeg, ffms2, gpac, x 264 (http://www.mediafire.com/?riz2czdfdnm).

[rack04]

I did build x 264, using GCC 4.4.4 (Stable) (http://www.xvidvideo.ru/2009-10-22-10-49-14/doc_details/3567-cross-mingw-x86x64-201004292200-with-gcc-444-stable-pthreads-290-static.html). No error, here's a detailed logs build ffmpeg, ffms2, gpac, x 264 (http://www.mediafire.com/?riz2czdfdnm).

This is what I get when i cross compile x64 ffmpeg using GCC 4.4.4.

http://i11.photobucket.com/albums/a199/rack04/untitled.jpg

[kemuri-_9]

it works fine here with komisar's gcc 4.4.4 binutil set, so try that instead i guess.

[roozhou]

This is what I get when i cross compile x64 ffmpeg using GCC 4.4.4.

http://i11.photobucket.com/albums/a199/rack04/untitled.jpg
Try "make" instead of "make -j2/-j4".

[burfadel]

Just curious, is it known how useful all the new instructions coming out at the end of the year and next year will be, on processors that support them? Like AvX, CVT16 etc?

[bob0r]

Also a ffmpeg error here on gcc 4.4.4:


CC libavcodec/dsputil.o
libavcodec/dsputil.c: In function 'put_h264_qpel2_mc10_c':
libavcodec/dsputil.c:2586: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [libavcodec/dsputil.o] Error 1


Latest working ffmpeg git revision: 22940

Side note: the same file, dsputil.c segmentation faulted before, then on gcc 4.4.3.
It was fixed 1 days after pasting it in #ffmpeg, but that was a coincidence i guess.
(i have how ever pasted it again :p)

[rack04]

Try "make" instead of "make -j2/-j4".

I used "make". BTW, I have no problem cross compiling x64 ffmpeg using GCC 4.4.4 in x64 Win7 but I get the error above in x32 WinXP.

[roozhou]

I used "make". BTW, I have no problem cross compiling x64 ffmpeg using GCC 4.4.4 in x64 Win7 but I get the error above in x32 WinXP.
I got the same error with TDM's GCC 4.4.1 long ago. You can also try qp gcc builds (http://code.google.com/p/qp-gcc/downloads/list).

[juGGaKNot]

Need a generic gcc 4.4.4 32bit build with fade compensation guys.

anyone ?

[[ReX]]

Need a generic gcc 4.4.4 32bit build with fade compensation guys.

anyone ?

ffmpeg/ffms2 is a little old, but not too much (not even a month old if I remember).

Only patch used: x264_fade_compensation_r1583
GCC 4.4.4 x86
make fprofiled
http://www.mediafire.com/?zyzymyvyzmn

[rack04]

I got the same error with TDM's GCC 4.4.1 long ago. You can also try qp gcc builds (http://code.google.com/p/qp-gcc/downloads/list).

Turns out it is a bug in ffmpeg. It has been reproduced and reported by angustia. Evidently it will work if you don't disable filters.

[juGGaKNot]

;1398603']ffmpeg/ffms2 is a little old, but not too much (not even a month old if I remember).

Only patch used: x264_fade_compensation_r1583
GCC 4.4.4 x86
make fprofiled
http://www.mediafire.com/?zyzymyvyzmn

thnx.

[jsday187]

Is there a possiblilty of getting an up to date DLL of ffms2 with thread fix patch separate from these builds?

[burfadel]

You mean an avisynth ffms2 filter so you can us ffvideosource? I second the request with an automated thankyou!

[[ReX]]

I think it was fixed, so there's no need for patch.
http://code.google.com/p/ffmpegsource/source/detail?r=312

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6-DEV
Pthreads 2.9.0.0
YASM 1.0.0
x264 Builds:
x264_x86_r1583M (http://www.multiupload.com/BHUIZOAYGH)

Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x64_r1583M (http://www.multiupload.com/4LBMK9508B)

Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
Patches:
x264_sws_typecast_r1570 (http://pastebin.com/2D94ZEm7) <komisar>
x264_demuxer_threads_r1570 (http://pastebin.com/X8uQdiE9) <komisar>
x264.open-gop.22 (http://pastebin.com/363tDMnb) <Trahald>
x264_fade_compensation_r1583 (http://pastebin.com/yfwNyqxG) <Dark Shikari>

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6-DEV Rev 5
Pthreads 2.9.0.0
Yasm 1.0.0
LAVF/FFMS Builds:

ffmpeg SVN-r23156M and libswscale SVN-r31179M (http://www.multiupload.com/60DNAC7CSR)
ffms2 SVN-r312 (http://www.multiupload.com/43NOZEOH35)
LAVF/FFMS Patches:
ffmpeg_static_pthreads_r23179 (http://codetidy.com/42) <angustia>
libswscale_x64_fix_r31032 (http://codetidy.com/44) <BugMaster>
x264 Builds:

x264_x64_r1592M (http://www.multiupload.com/VL5W219EDI)
Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x86_r1592M (http://www.multiupload.com/W2U7A8DF7I)
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264 Patches:
x264_sws_typecast_r1570 (http://codetidy.com/45) <komisar>
x264_demuxer_threads_r1570 (http://codetidy.com/46) <komisar>
x264.open-gop.22_r1592 (http://codetidy.com/47) <Trahald>
x264_fade_compensation_r1583 (http://codetidy.com/48) <Dark Shikari>

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6-DEV Rev 5
Pthreads 2.9.0.0
Yasm 1.0.0
LAVF/FFMS Builds:

ffmpeg SVN-r23201M and libswscale SVN-r31186M (http://www.multiupload.com/QSJ47SDG8N)
ffms2 SVN-r312 (http://www.multiupload.com/I9MTBQD10P)
LAVF/FFMS Patches:
ffmpeg_static_pthreads_r23179 (http://pastebin.com/Phx49DGt) <angustia>
llibswscale_x64_fix_r31032 (http://pastebin.com/hNQGLpYm) <BugMaster>
x264 Builds:

x264_x64_r1592M (http://www.multiupload.com/7NR8FBZQLP)
Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
avi output: yes
pthread: yes
filters: resize select_every crop hqdn3d
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x86_r1592M (http://www.multiupload.com/56NLFZ4CUQ)
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
avi output: yes
pthread: yes
filters: resize select_every crop hqdn3d
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264 Patches:
x264_sws_typecast_r1570 (http://pastebin.com/qcNYfXWZ) <komisar>
x264_demuxer_threads_r1570 (http://pastebin.com/G7zjaChB) <komisar>
x264.open-gop.22_r1592 (http://pastebin.com/at39YNXN) <Trahald>
x264_fade_compensation_r1583 (http://pastebin.com/rf9EZfN2) <Dark Shikari>
x264_avi_output.v4_r1592 (http://pastebin.com/xyNNAqy6) <MasterNobody>
x264_filtering_r1592 (http://pastebin.com/98VLM5Pg) <kemuri-_9>
x264_filtering_changes_r1592 (http://pastebin.com/1eiDAmiv) <J_Darnley>

[Audionut]

Thanks rack04

[jpsdr]

I don't know where to put it, just to notify, in the help, the default mode for nal-hrd is not specified.

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.0
LAVF/FFMS Builds:

ffmpeg SVN-r23285M and libswscale SVN-r31206M (http://www.multiupload.com/2TYCAHXMLK)
ffms2 SVN-r312 (http://www.multiupload.com/N69SBIXUFP)
Patches:
ffmpeg_static_pthreads_r23179 (http://pastebin.com/LMuCc9hd) <angustia>
libswscale_x64_fix_r31032 (http://pastebin.com/GiDV9aVf) <BugMaster>
x264 Builds:

x264_x64_r1602 (http://www.multiupload.com/ANLADULZG0)
Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x86_r1602 (http://www.multiupload.com/ZIJOZK6PVP)
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x64_r1602M (http://www.multiupload.com/PSN6VJ76VS)
Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
avi output: yes
pthread: yes
filters: resize select_every crop hqdn3d
debug: no
gprof: no
PIC: no
shared: no
visualize: no
Patches:
x264_sws_typecast_r1570 (http://pastebin.com/Gj3vR7re) <komisar>
x264_demuxer_threads_r1602 (http://pastebin.com/12ECMUPX) <komisar>
x264_open-gop.22_r1602 (http://pastebin.com/enPSBBGK) <Trahald>
x264_fade_compensation_r1602 (http://pastebin.com/qw8WCBJf) <Dark Shikari>
x264_avi_output.v4_r1602 (http://pastebin.com/4sew624g) <MasterNobody>
x264_filtering_r1602 (http://pastebin.com/KEEGHzBB) <kemuri-_9>
x264_filtering_changes_r1602 (http://pastebin.com/QU9Xwxy6) <J_Darnley>
x264_x86_r1602M (http://www.multiupload.com/NTX2YJVK19)
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
avi output: yes
pthread: yes
filters: resize select_every crop hqdn3d
debug: no
gprof: no
PIC: no
shared: no
visualize: no
Patches:
x264_sws_typecast_r1570 (http://pastebin.com/Gj3vR7re) <komisar>
x264_demuxer_threads_r1602 (http://pastebin.com/12ECMUPX) <komisar>
x264_open-gop.22_r1602 (http://pastebin.com/enPSBBGK) <Trahald>
x264_fade_compensation_r1602 (http://pastebin.com/qw8WCBJf) <Dark Shikari>
x264_avi_output.v4_r1602 (http://pastebin.com/4sew624g) <MasterNobody>
x264_filtering_r1602 (http://pastebin.com/KEEGHzBB) <kemuri-_9>
x264_filtering_changes_r1602 (http://pastebin.com/QU9Xwxy6) <J_Darnley>

[tormento]

@ rack04

Using x264_x64_r1602M I get the error

raw [error]: raw input requires a resolution

[rack04]

@ rack04

Using x264_x64_r1602M I get the error

raw [error]: raw input requires a resolution

http://doom10.org/index.php?topic=177.msg2130#msg2130