x264 compilation

[hpn]

Thank you, Sharktooth.
-march=pentium2 is a really nice trick. I wasn't aware that it would be faster than without -march. I guess without -march GCC produces code for every conceivable x86 including those before the pentium2 era (down to i386?), that's why the code is slower. I also just bechmarked the -march=athlon-xp option for my CPU. Compared to the already faster -march-pentium2 build it's even faster (and not only marginally), so CPU specific builds make sense for those who want ultimate speed (maybe also -march-athlon64, -march-pentium4), although the Average Joe would never notice any difference.

-ffloat-store and -fsingle-precision-constant are available in GCC 3.X.X, so I did some tests and the conclusion is that they are (most likely) not faster, at least not measurable.

I use 3.4.6, so the other options that require GCC 4.X.X will have to wait
-floop-optimize2 (GCC 4.0.3+)
-funsafe-loop-optimizations (GCC 4.1.1+)
-freorder-blocks-and-partition (GCC 4.0.3+)

Some tests: 3 consecutive runs for each test (2 passes each) to eliminate the fluctuations
---------------------------------
my builds (patched (http://x264.net/x264_clock1-614.diff) to print the total time)
without -march:
pass1: encoded 1000 frames, 5.85 fps, 946.39 kb/s, total time: 0:02:51:011
pass2: encoded 1000 frames, 4.31 fps, 1001.65 kb/s, total time: 0:03:51:953

encoded 1000 frames, 5.86 fps, 946.39 kb/s, total time: 0:02:50:610
encoded 1000 frames, 4.31 fps, 1001.65 kb/s, total time: 0:03:51:813

encoded 1000 frames, 5.86 fps, 946.39 kb/s, total time: 0:02:50:547
encoded 1000 frames, 4.31 fps, 1001.65 kb/s, total time: 0:03:51:797
---------------------------------
-march=pentium2
encoded 1000 frames, 5.97 fps, 946.39 kb/s, total time: 0:02:47:453
encoded 1000 frames, 4.42 fps, 1001.65 kb/s, total time: 0:03:46:500

encoded 1000 frames, 5.98 fps, 946.39 kb/s, total time: 0:02:47:282
encoded 1000 frames, 4.42 fps, 1001.65 kb/s, total time: 0:03:46:438

encoded 1000 frames, 5.98 fps, 946.39 kb/s, total time: 0:02:47:312
encoded 1000 frames, 4.41 fps, 1001.65 kb/s, total time: 0:03:46:515
---------------------------------
-march=pentium2 -fsingle-precision-constant -ffloat-store
encoded 1000 frames, 5.93 fps, 946.39 kb/s, total time: 0:02:48:719
encoded 1000 frames, 4.39 fps, 1001.65 kb/s, total time: 0:03:47:734

encoded 1000 frames, 6.00 fps, 946.39 kb/s, total time: 0:02:46:578
encoded 1000 frames, 4.40 fps, 1001.65 kb/s, total time: 0:03:47:343

encoded 1000 frames, 5.94 fps, 946.39 kb/s, total time: 0:02:48:282
encoded 1000 frames, 4.40 fps, 1001.65 kb/s, total time: 0:03:47:125
fourth run
encoded 1000 frames, 5.95 fps, 946.39 kb/s, total time: 0:02:48:062
encoded 1000 frames, 4.40 fps, 1001.65 kb/s, total time: 0:03:47:125
---------------------------------
-march=athlon-xp
encoded 1000 frames, 6.11 fps, 946.39 kb/s, total time: 0:02:43:766
encoded 1000 frames, 4.49 fps, 1001.65 kb/s, total time: 0:03:42:500

encoded 1000 frames, 6.10 fps, 946.39 kb/s, total time: 0:02:43:828
encoded 1000 frames, 4.49 fps, 1001.65 kb/s, total time: 0:03:42:578

encoded 1000 frames, 6.11 fps, 946.39 kb/s, total time: 0:02:43:641
encoded 1000 frames, 4.49 fps, 1001.65 kb/s, total time: 0:03:42:500
---------------------------------

Sharktooth build (614)
-march=pentium2?
encoded 1000 frames, 5.99 fps, 946.40 kb/s
encoded 1000 frames, 4.42 fps, 1001.66 kb/s

encoded 1000 frames, 5.99 fps, 946.40 kb/s
encoded 1000 frames, 4.43 fps, 1001.66 kb/s

encoded 1000 frames, 5.99 fps, 946.40 kb/s
encoded 1000 frames, 4.42 fps, 1001.66 kb/s
---------------------------------

bob0r build (618) -march= unkown
encoded 1000 frames, 6.04 fps, 946.40 kb/s
encoded 1000 frames, 4.41 fps, 1001.66 kb/s

encoded 1000 frames, 6.04 fps, 946.40 kb/s
encoded 1000 frames, 4.42 fps, 1001.66 kb/s

encoded 1000 frames, 6.04 fps, 946.40 kb/s
encoded 1000 frames, 4.41 fps, 1001.66 kb/s
---------------------------------

CelticDruid build (614) -march= unkown
encoded 1000 frames, 5.92 fps, 946.40 kb/s
encoded 1000 frames, 4.36 fps, 1001.66 kb/s

encoded 1000 frames, 5.92 fps, 946.40 kb/s
encoded 1000 frames, 4.36 fps, 1001.66 kb/s

encoded 1000 frames, 5.92 fps, 946.40 kb/s
encoded 1000 frames, 4.35 fps, 1001.66 kb/s
---------------------------------

unknown ICL build (614)
encoded 1000 frames, 5.81 fps, 946.39 kb/s
encoded 1000 frames, 4.24 fps, 1001.65 kb/s

[akupenguin]

On a related note, you can use e.g. -march=pentium2 -mtune=athlon-xp to enable only the instructions valid on pentium2+ but schedule them using athlon's timings. And gcc 4.2 has -mtune=generic to compromise between several common cpus.

And my benchmark: -march=k8 improved speed by 0.7% on a k8 (and reduced speed by 0.3% on a core2). I haven't tested -march=core2 since it was only added in gcc 4.3

[hpn]

Thank you. Playing with GCC 4.2 is on my list. I had some issues with GCC 4+ a few months ago (another c project compiled with 4.X was crashing while the same code was working fine with 3.X), but hopefully 4.2 is more stable.

[Sharktooth]

oh... keep in mind my builds have the AQ patch that adds some (little) "complexity"...

[hpn]

Mine too. But as long as the encodes are made without the --aq options, the patched builds speed-wise should be identical to clean svn builds.

[lcx]

If isn't too much to ask can unistd.h be conditionally included
as

#ifdef HAVE_UNISTD_H
#include <unistd.h>
#endif


in x264\encoder\analyse.c & x264\common\frame.c

so that x264 can be compiled in Visual C++

-Thx

[OmerParacha]

1>g:\My Build\common/common.h(85) : warning C4005: 'UNUSED' : macro redefinition
1> C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\include\afx.h(378) : see previous definition of 'UNUSED'
1>g:\my build\common\bs.h(41) : error C2440: '=' : cannot convert from 'void *' to 'uint8_t *'
1> Conversion from 'void*' to pointer to non-'void' requires an explicit cast
1>g:\my build\common\bs.h(42) : error C2440: '=' : cannot convert from 'void *' to 'uint8_t *'
1> Conversion from 'void*' to pointer to non-'void' requires an explicit cast
1>g:\My Build\common/common.h(367) : error C2061: syntax error : identifier 'luma16x16_dc'
1>g:\My Build\common/common.h(367) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>g:\My Build\common/common.h(367) : warning C4183: 'DECLARE_ALIGNED': missing return type; assumed to be a member function returning 'int'
1>g:\My Build\common/common.h(368) : error C2061: syntax error : identifier 'chroma_dc'
1>g:\My Build\common/common.h(368) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>g:\My Build\common/common.h(368) : error C2535: 'int x264_t::<unnamed-tag>::DECLARE_ALIGNED(int)' : member function already defined or declared
1> g:\My Build\common/common.h(367) : see declaration of 'x264_t::DECLARE_ALIGNED'
1>g:\My Build\common/common.h(368) : warning C4183: 'DECLARE_ALIGNED': missing return type; assumed to be a member function returning 'int'
1>g:\My Build\common/common.h(370) : error C2061: syntax error : identifier 'luma8x8'
1>g:\My Build\common/common.h(370) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>g:\My Build\common/common.h(370) : error C2535: 'int x264_t::<unnamed-tag>::DECLARE_ALIGNED(int)' : member function already defined or declared
1> g:\My Build\common/common.h(367) : see declaration of 'x264_t::DECLARE_ALIGNED'
1>g:\My Build\common/common.h(370) : warning C4183: 'DECLARE_ALIGNED': missing return type; assumed to be a member function returning 'int'
1>g:\My Build\common/common.h(373) : error C2061: syntax error : identifier 'residual_ac'
1>g:\My Build\common/common.h(373) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>g:\My Build\common/common.h(373) : warning C4183: 'DECLARE_ALIGNED': missing return type; assumed to be a member function returning 'int'
1>g:\My Build\common/common.h(374) : error C2061: syntax error : identifier 'luma4x4'
1>g:\My Build\common/common.h(374) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>g:\My Build\common/common.h(374) : error C2535: 'int x264_t::<unnamed-tag>::<unnamed-tag>::DECLARE_ALIGNED(int)' : member function already defined or declared
1> g:\My Build\common/common.h(373) : see declaration of 'x264_t::<unnamed-tag>::DECLARE_ALIGNED'
1>g:\My Build\common/common.h(374) : warning C4183: 'DECLARE_ALIGNED': missing return type; assumed to be a member function returning 'int'
1>g:\My Build\common/common.h(460) : error C2061: syntax error : identifier 'fenc_buf'
1>g:\My Build\common/common.h(460) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>g:\My Build\common/common.h(460) : warning C4183: 'DECLARE_ALIGNED': missing return type; assumed to be a member function returning 'int'
1>g:\My Build\common/common.h(461) : error C2061: syntax error : identifier 'fdec_buf'
1>g:\My Build\common/common.h(461) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>g:\My Build\common/common.h(461) : error C2535: 'int x264_t::<unnamed-tag>::<unnamed-tag>::DECLARE_ALIGNED(uint8_t)' : member function already defined or declared
1> g:\My Build\common/common.h(460) : see declaration of 'x264_t::<unnamed-tag>::DECLARE_ALIGNED'
1>g:\My Build\common/common.h(461) : warning C4183: 'DECLARE_ALIGNED': missing return type; assumed to be a member function returning 'int'

CANT STOP GETTING THIS ERROR PLZ HELP!

[DarkZell666]

[evilmode=on]
As you can see, the codec is laughing at you :D
[evilmode off]

Sorry :o

[akupenguin]

g:\my build\common\bs.h(41) : error C2440: '=' : cannot convert from 'void *' to 'uint8_t *'
Conversion from 'void*' to pointer to non-'void' requires an explicit cast
That means Visual Studio somehow got the idea that x264 is a C++ program. It's not. Despite the similarities between the languages, they are not completely compatible, and C++ compilers can't generally compile C programs.
Now, you're on your own as to how to fix it, I'm just saying what's wrong.

[imcold]

[evilmode=on]
As you can see, the codec is laughing at you :D
[evilmode off]

Sorry :o

OT: that made me laugh so much xD

[Yong]

[evilmode=on]
As you can see, the codec is laughing at you :D
[evilmode off]

Sorry :o

lol:D
Yeah, i have tried compile x264 with msvc++ 2005 express too,
no errror, lot of warnings, and the x264.exe seems doesnt work:p
it complain "no output files" when i tried to encode a small video clip.
too lazy to investigate the problem
just stick with mingw/gcc :p

[sts]

I have been using x264 in msvc++ and it works fines...
I did have some errors with unistd.h but I commented it out and now the code works.

[Kurtnoise]

Sharktooth, could you remind me what kind of gcc flags you use to compile this encoder ?

10x

[Sharktooth]

Actually -O3 -march pentium2 -ffast-math -fomit-frame-pointer (some of the -f flags may be included in -O3 depending on the GCC version you're using). I also use make fprofiled...

[OmerParacha]

hmmm i think i got it workin by adding __X264__ to the preprocessor...i dont know if that comment was for me but hell yeah the compiler was laughin at me.
im a java programmer,VC++ is a whole other world right now. im learning...wish me luck!

[OmerParacha]

lol:D
Yeah, i have tried compile x264 with msvc++ 2005 express too,
no errror, lot of warnings, and the x264.exe seems doesnt work:p
it complain "no output files" when i tried to encode a small video clip.
too lazy to investigate the problem
just stick with mingw/gcc :p

yeah...thats coz it takes command-line parameters:) the simplest without any options is of the form:
>x264 -o outfile infile widthxheight
for example for a CIF file called infile.yuv to give a raw bitstream outfile.264:
> x264 -o outfile.264 infile.yuv 352x288

haha, i recommend the x264 -h options;)

[Ajaja2005]

MSVC++ 2005 vs r622:
Linking...
x264.obj : error LNK2001: unresolved external symbol _getopt_long
bin/x264.exe : fatal error LNK1120: 1 unresolved externals


:(
Where can I find getopt_long function for MSVC?

[Ajaja2005]

Seems, I find getopt_long in glibc:
int
getopt_long (int argc, char *const *argv, const char *options,
const struct option *long_options, int *opt_index)
{
return _getopt_internal (argc, argv, options, long_options, opt_index, 0);
}

:)

[akupenguin]

see x264/extras/getopt.c (which, yes, was pasted from glibc)

[Ajaja2005]

see x264/extras/getopt.c (which, yes, was pasted from glibc)

x264/extras/getopt.h:
extern int getopt_long (int __argc, char *const *__argv, const char *__shortopts,
const struct option *__longopts, int *__longind);
That all. Where do you find implementation of getopt_long in getopt.c after r622 | pengvado | 2007-01-29 15:42:42 +0100 (Mon, 29 Jan 2007) | 2 lines

extras/getopt.c was BSD licensed. replace with a LGPL version (from glibc).
?

[akupenguin]

extras/getopt.c line 368

[Ajaja2005]

extras/getopt.c line 368

367: /* Exclude the moved top segment from further swapping. */
368: bottom += len;
369: }

Do you talk about 622 revision (getopt.c size 30155)? Seems like you talk about r621 (getopt.c 12909).

[akupenguin]

oops, no I hadn't svn up'ed that copy.
maybe I screwed up r622; I don't have a computer without getopt in its libc, so I guess I wouldn't notice if it was using that version instead of extras/ even if I force it to compile extras/

[rlandle]

To all MSVC builders...
In addition to all the changes to the source code and solution file documented in this thread I would like to add another change.

In order for me to compile the latest svn source snaphot (x264-snapshot-20070419-2245) on MSVC .NET 2003 SP1.

I had to add getopt1.c to the extras directory and add this to the compile. I was getting the linker error discussed in the posts above, so I found source code which defines getopt_long().

getopt1.c was taken from the glibcw32 source code found at
http://gnuwin32.sourceforge.net/packages/libgw32c.htm

Hope this helps.
Bobby

[lcx]

To all MSVC builders...
getopt1.c was taken from the glibcw32 source code found at
http://gnuwin32.sourceforge.net/packages/libgw32c.htm

Hope this helps.
Bobby

Or you can just use the older version of getopt.c

[lcx]

BTW, Just got the latest version.
Found that latest cabac.c doesn't compile in MSVC.

If you have the same problem:
Change
static inline void x264_cabac_putbyte( x264_cabac_t *cb )
{
...
int carry = out & 0x100;
...

to

static inline void x264_cabac_putbyte( x264_cabac_t *cb )
{
int carry;
...
carry = out & 0x100;
...

MSVC seems to be stricter about C versus C++ syntax.

[foxyshadis]

That's just because MSVC is under the impression that C99 was never ratified, so it gets to pick and choose its extensions to the language at random.

[rlandle]

X264 with SSE3?

I'm using source snap shot "x264-snapshot-20070424-2245"
I want to use SSE3.
I tried forcing the #define SSE3 and got some compile errors.

One says "unresolved external symbol _x264_quant_8x8_ssse3 referenced in function _x264_quant_init"

When I looked for this function it is not defined anywhere in the released source.

I did see x264_quant_8x8_sse2 in quant-a.asm, but no reference to ssse3.

Is SSE3 not ready for prime time yet?

Bobby

[akupenguin]

If configure doesn't set HAVE_SSE3, that's because your assembler doesn't support it. get yasm 0.6.0. Unless the function that detects sse3 support is broken, overriding configure's decision can't help.
x264_quant_8x8_ssse3 is defined at common/i386/quant-a.asm line 174.

[rlandle]

Aren't SSSE3 and SSE3 2 different things?
I think SSSE3 is the latest and greatest, i.e. SSSE3 = SSE4.

So what version is currently supported as far as Streming SIMD Extensions?

[akupenguin]

SSE3, SSSE3, and SSE4 are 3 different things. x264 supports up though SSSE3, because SSE4 cpus (Penryn) are not sold yet.

I have tried to be precise about the distinction in x264: Function names contain the highest level of instruction set used in that function. #defines group together whatever coarseness of conditional compilation I want. (HAVE_MMX contains MMX, MMX2, SSE, SSE2. HAVE_SSE3 contains SSE3, SSSE3.)

[rlandle]

OK I'm using nasm 0.98.39.
I'll upgrade to yasm.
Thanks for the info.

[rlandle]

So I updated my assembler to yasm 0.6.0 and ran configure.
My config.mak file now shows -DHAVE_SSE3 in the CFLAGS.

When I compile and run, the param->cpu variable is = 0XF.
If I have SSSE3 shouldn't it be 0X18F?

It seems likes its ignoring the #ifdef HAVE_SSE3 in x264_cpu_detect.c and not setting the cpu variable correctly.

Am I doing something else wrong?

Thanks,
Bobby

[_xxl]

http://en.wikipedia.org/wiki/SSE3
http://en.wikipedia.org/wiki/SSSE3
http://en.wikipedia.org/wiki/SSE4
Interesting:
MPSADBW - Compute eight offset sums of absolute differences (i.e. |x0-y0|+|x1-y1|+|x2-y2|+|x3-y3|, |x0-y1|+|x1-y2|+|x2-y3|+|x3-y4|, ...); this operation is extremely important for modern HDTV codecs, and (see [3]) allows an 8x8 block difference to be computed in less than seven cycles. One bit of a three-bit immediate operand indicates whether y0 .. y11 or y4 .. y15 should be used from the destination operand, the other two whether x0..x3, x4..x7, x8..x11 or x12..x15 should be used from the source.

[akupenguin]

@rlandle
No need to go poking into variables. The first thing x264 prints when you encode something is
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 SSSE3 (SSE3 omitted because x264 currently doesn't have any functions that are SSE3 and not SSSE3)
What's your cpu?

@drevil_xxl
MPSADBW is designed for exhaustive search, not for diamond/hex. And even for exhaustive, I'm not sure it's any better than x264's successive elimination search, which is a higher level algorithm to losslessly eliminate most of the blocks before they even get to SAD.

[Manao]

It's interesting to note that this instruction mostly helps for integer pel exhaustive search. But for x264, with m6 / m7 and hex/umh, it wouldn't help that much.

Other instructions are more versatile - blendxx, pmovxxx, packusdw, pmulld, pmax/minxx - and imho more interesting. They'll certainly ease the writing of simd optimized functions, once SSE4 becomes mainstream.

[rlandle]

Akupenguin,

I am using an Intel Pentium D 950 @ 3.4GHz with 800 MHz FSB.

I am MMX,SSE2,SSE3 enabled, but not SSSE3.

Yeah I noticed later on in the code where the cpu capabilities are printed out. That's what got me confused, cause It only said SSE2, but I knew I was SSE3.

So what your saying is it doesn't matter if I'm SSE3 capable, to see any benefit I need to be SSSE3 capable.

Thanks

[foxyshadis]

One of the things I've been curious about for a while is whether the SSE3 instructions MONITOR and MWAIT could have any use within the pthreads library as lower-level synchronizors. But then again, they might only be useful in the kernel-level if pthreads is already as fast as possible and checking locks.

[akupenguin]

MONITOR and MWAIT are privileged. The kernel might use them, but there's nothing x264 can do about it.

[_xxl]

I can't compile pixel-a.asm and pixel-sse2.asm for x64 using yasm 0.6.0.
yasm -w -f win64 -DWIN64 -I$(InputDir) -o $(IntDir)\$(InputName).obj $(InputPath)
yasm assembling h:\beta\trunk\src\codecs\x264\common\amd64\pixel-a.asm
h:\beta\trunk\src\codecs\x264\common\amd64\pixel-a.asm:453: expected `]'
yasm assembling h:\beta\trunk\src\codecs\x264\common\amd64\pixel-sse2.asm
h:\beta\trunk\src\codecs\x264\common\amd64\pixel-sse2.asm:647: expected `]'

[skottish]

I can't compile pixel-a.asm and pixel-sse2.asm for x64 using yasm 0.6.0.
yasm -w -f win64 -DWIN64 -I$(InputDir) -o $(IntDir)\$(InputName).obj $(InputPath)
yasm assembling h:\beta\trunk\src\codecs\x264\common\amd64\pixel-a.asm
h:\beta\trunk\src\codecs\x264\common\amd64\pixel-a.asm:453: expected `]'
yasm assembling h:\beta\trunk\src\codecs\x264\common\amd64\pixel-sse2.asm
h:\beta\trunk\src\codecs\x264\common\amd64\pixel-sse2.asm:647: expected `]'

Maybe some of these will help for your 64 bit troubles:

http://berkano.net/svn/berkano-overlay/trunk/media-video/ffmpeg/files/

These are the patches used for Gentoo.

[akupenguin]

Gentoo patches can't possibly help. It compiles just fine on 64bit linux, only the windows version has problems. And those aren't even patches for x264, they're for ffmpeg.

[skottish]

Gentoo patches can't possibly help. It compiles just fine on 64bit linux, only the windows version has problems. And those aren't even patches for x264, they're for ffmpeg.

Sorry, it was stupid anyway. My head was in FFMPEG, not x264. I have no problems what-so-ever compiling x264 on 64 bit.

[DarkZell666]

Ehm, I tried compiling r655 with MSVC8 (VS 2005)+YASM, and I got this :


------ Rebuild All started: Project: libx264, Configuration: Debug Win32 ------
Deleting intermediate and output files for project 'libx264', configuration 'Debug|Win32'
Assembly d:\x264\common\i386\quant-a.asm
Assembly d:\x264\common\i386\predict-a.asm
Assembly d:\x264\common\i386\pixel-sse2.asm
Assembly d:\x264\common\i386\pixel-a.asm
Assembly d:\x264\common\i386\mc-a2.asm
Assembly d:\x264\common\i386\mc-a.asm
Assembly d:\x264\common\i386\deblock-a.asm
Assembly d:\x264\common\i386\dct-a.asm
Assembly d:\x264\common\i386\cpu-a.asm
Compiling...
getopt.c
..\..\extras\getopt.c : fatal error C1033: cannot open program database 'd:\x264\build\win32\bin\libx264d.pdb'
set.c
..\..\common\set.c : fatal error C1033: cannot open program database 'd:\x264\build\win32\bin\libx264d.pdb'
quant.c
..\..\common\quant.c : fatal error C1033: cannot open program database 'd:\x264\build\win32\bin\libx264d.pdb'
predict.c
..\..\common\predict.c : fatal error C1033: cannot open program database 'd:\x264\build\win32\bin\libx264d.pdb'
predict-c.c
..\..\common\i386\predict-c.c : fatal error C1033: cannot open program database 'd:\x264\build\win32\bin\libx264d.pdb'
pixel.c
..\..\common\pixel.c : fatal error C1033: cannot open program database 'd:\x264\build\win32\bin\libx264d.pdb'
mdate.c
..\..\common\mdate.c : fatal error C1033: cannot open program database 'd:\x264\build\win32\bin\libx264d.pdb'
mc.c
..\..\common\mc.c : fatal error C1033: cannot open program database 'd:\x264\build\win32\bin\libx264d.pdb'
mc-c.c
..\..\common\i386\mc-c.c : fatal error C1033: cannot open program database 'd:\x264\build\win32\bin\libx264d.pdb'
macroblock.c
..\..\common\macroblock.c : fatal error C1033: cannot open program database 'd:\x264\build\win32\bin\libx264d.pdb'
frame.c
..\..\common\frame.c : fatal error C1033: cannot open program database 'd:\x264\build\win32\bin\libx264d.pdb'
dct.c
..\..\common\dct.c : fatal error C1033: cannot open program database 'd:\x264\build\win32\bin\libx264d.pdb'
csp.c
..\..\common\csp.c : fatal error C1033: cannot open program database 'd:\x264\build\win32\bin\libx264d.pdb'
cpu.c
..\..\common\cpu.c : fatal error C1033: cannot open program database 'd:\x264\build\win32\bin\libx264d.pdb'
common.c
..\..\common\common.c : fatal error C1033: cannot open program database 'd:\x264\build\win32\bin\libx264d.pdb'
cabac.c
..\..\common\cabac.c : fatal error C1033: cannot open program database 'd:\x264\build\win32\bin\libx264d.pdb'
Generating Code...
Build log was saved at "file://d:\x264\build\win32\Debug\BuildLog.htm"
libx264 - 16 error(s), 0 warning(s)
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========


All I did was open the x264.sln from build/win32 directory, right-click on libx264 and "Rebuild". Was there anything else I should have done ? The search doesn't return any results for "C1033" (other than mine now :)), so it looks like a "new" problem ^^'

Edit: I found a .pdb file here : D:\x264r655\build\win32\Debug\vc80.pdb, dunno if it's wrongly named or just another one that has another purpose, but the build\win32\bin\libx264d.pdb file simply doesn't exist :/

[puter]

I love you guys, It's real

[TheRyuu]

How would I apply the two patches in sharktooth's builds in cygwin or mingw? (or is the source thats on the same page as the patched builds have the patches already in them?).

Thanks.

[Sharktooth]

with the "patch" command

[nfm]

@wizboy11
cd x264
patch -p0 < ../x264_aq.5-634.diff

[TheRyuu]

with the "patch" command

lol
Thanks, just wasn't sure what came after "patch". Got that working (but it seems they were already applied to the source I downloaded :p, according to cygwin).

Got a compiler error now:
http://img477.imageshack.us/img477/2116/x264makeerrorax1.jpg

I bet this has probably been asked before (think it might have something to do with pthreads?)

Sorry for the trouble.
Thanks. :thanks:

Edit:
Mingw spits out the same error.
Got glibc too (as suggested in other x264 development thread), still gives me the error.

[bob0r]

Anyone know how i can fix this:
gcc -o x264.exe x264.o matroska.o muxers.o libx264.a -lpthreadGC2 -lwsock32 -lvfw32 -s
libx264.a(ratecontrol.o):ratecontrol.c:(.text+0x2e48): undefined reference to `strtok_r'
libx264.a(ratecontrol.o):ratecontrol.c:(.text+0x2faa): undefined reference to `strtok_r'
make: *** [x264.exe] Error 1

Please let me know...