View Full Version : x264 compilation
Pages :
1
2
3
4
[
5]
6
7
8
9
10
11
bob0r
7th December 2005, 16:07
@el divx
gcc -Wall -I. -O4 -ffast-math -D__X264__ -DHAVE_MMXEXT -DHAVE_SSE2 -DARCH_X86 -DSYS_MINGW -DAVIS_INPUT -DMP4_OUTPUT -DHAVE_PTHREAD=1 -s -fomit-frame-pointer -fprofile-generate -DHAVE_GETOPT_LONG=1 -c -o encoder/set.o encoder/set.c
encoder/set.c: In function 'x264_sei_version_write':
encoder/set.c:464: error: 'X264_VERSION' undeclared (first use in this function)
encoder/set.c:464: error: (Each undeclared identifier is reported only once
encoder/set.c:464: error: for each function it appears in.)
make[1]: *** [encoder/set.o] Error 1
make[1]: Leaving directory `/home/user/x264'
make: *** [fprofiled] Error 2
I have the same problem, make fprofiled (assuming you use that also) deletes config.h which it seems it needs. (make only does not have this problem)
To fix this easy:
Edit x264/Makefile, and remove config.h from clean:
Change
clean:
rm -f $(OBJS) $(OBJASM) config.h *.a x264.o matroska.o x264 x264.exe .depend TAGS
to:
clean:
rm -f $(OBJS) $(OBJASM) *.a x264.o matroska.o x264 x264.exe .depend TAGS
and add config.h to: distclean: clean:
Change
distclean: clean
rm -f config.mak vfw/build/cygwin/config.mak x264.pc
to:
distclean: clean
rm -f config.h config.mak vfw/build/cygwin/config.mak x264.pc
bob0r
7th December 2005, 16:11
Another problem, while on it:
make fprofiled with gcc 4.0.2:
I get this error:
gcc -Wall -I. -O4 -ffast-math -D__X264__ -DHAVE_MMXEXT -DHAVE_SSE2 -DARCH_X86 -DSYS_MINGW -DAVIS_INPUT -DMP4_OUTPUT -DHAVE_PTHREAD=1 -s -fomit-frame-pointer -fprofile-use -DHAVE_GETOPT_LONG=1 -c -o common/pixel.o common/pixel.c
gcc -Wall -I. -O4 -ffast-math -D__X264__ -DHAVE_MMXEXT -DHAVE_SSE2 -DARCH_X86 -DSYS_MINGW -DAVIS_INPUT -DMP4_OUTPUT -DHAVE_PTHREAD=1 -s -fomit-frame-pointer -fprofile-use -DHAVE_GETOPT_LONG=1 -c -o common/macroblock.o common/macroblock.c
common/macroblock.c: In function 'x264_mb_predict_mv_ref16x16':
common/macroblock.c:504: internal compiler error: Arithmetic exception
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
make[1]: *** [common/macroblock.o] Error 1
make[1]: Leaving directory `/home/user/x264'
make: *** [fprofiled] Error 2
Any solution?
el divx
7th December 2005, 18:17
OK, I've had it. How do you compile gcc 4.0.2 under windows?
I have tried to do it on MinGW and it failed.
el divx
7th December 2005, 18:22
Another problem, while on it:
make fprofiled with gcc 4.0.2:
I get this error:
gcc -Wall -I. -O4 -ffast-math -D__X264__ -DHAVE_MMXEXT -DHAVE_SSE2 -DARCH_X86 -DSYS_MINGW -DAVIS_INPUT -DMP4_OUTPUT -DHAVE_PTHREAD=1 -s -fomit-frame-pointer -fprofile-use -DHAVE_GETOPT_LONG=1 -c -o common/pixel.o common/pixel.c
gcc -Wall -I. -O4 -ffast-math -D__X264__ -DHAVE_MMXEXT -DHAVE_SSE2 -DARCH_X86 -DSYS_MINGW -DAVIS_INPUT -DMP4_OUTPUT -DHAVE_PTHREAD=1 -s -fomit-frame-pointer -fprofile-use -DHAVE_GETOPT_LONG=1 -c -o common/macroblock.o common/macroblock.c
common/macroblock.c: In function 'x264_mb_predict_mv_ref16x16':
common/macroblock.c:504: internal compiler error: Arithmetic exception
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
make[1]: *** [common/macroblock.o] Error 1
make[1]: Leaving directory `/home/user/x264'
make: *** [fprofiled] Error 2
Any solution?
It seems GCC is the culprit.
You could:
a) File a bug report on gcc's bugzilla or whatever they're using to collect bugs
b) Wait for the naxt revision that may has it fixed
c) Use a cvs version of gcc and pray that it works
bob0r
7th December 2005, 19:09
OK, I've had it. How do you compile gcc 4.0.2 under windows?
I have tried to do it on MinGW and it failed.
Extract
ftp://ftp.nluug.nl/mirror/languages/gcc/releases/gcc-4.0.2/gcc-core-4.0.2.tar.gz
and
ftp://ftp.nluug.nl/mirror/languages/gcc/releases/gcc-4.0.2/gcc-g++-4.0.2.tar.gz
(both will be gcc-4.0.2/) then:
1. cd gcc-4.0.2/
2. mkdir obj
3: cd obj
4: ../configure --prefix=/usr/local
5: make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap
6: make install
I have done the same for gcc 3.4.4.
I keep both compiled versions on my hdd (takes about 1 hour to compile here)
So i can switch between gcc versions. gcc 4.1.x failed on me, some program missing, will look into that later.
Note:
G:\msys\1.0\home\user\gcc-3.4.4 321 MB (337,360,089 bytes)
G:\msys\1.0\home\user\gcc-4.0.2 447 MB (468,898,041 bytes)
el divx
8th December 2005, 13:21
sort -u > tmp-macro_list
/bin/sh ../../gcc/../move-if-change tmp-macro_list macro_list
macro_list is unchanged
echo timestamp > s-macro_list
The directory that should contain system headers does not exist:
/usr/include
make[1]: *** [stmp-fixinc] Error 1
make[1]: Leaving directory `/home/gcc/obj/gcc'
make: *** [all-gcc] Error 2
Any ideas?
Sirber
8th December 2005, 13:38
You killed your linux box? What's inside /usr/include?
bob0r
8th December 2005, 13:38
No clue, update mingw runtime and w32api ?
http://www.mingw.org/download.shtml
mingw-runtime-3.9.tar.gz
w32api-3.5.tar.gz
el divx
9th December 2005, 13:44
You killed your linux box? What's inside /usr/include?
Actually, it's MinGW.
bob0r
10th December 2005, 13:13
gpac = fucked
My old gpac dir:
cd gpac
cvs up
make clean
make lib &>output.txt
The result:
http://files.x264.nl/output.txt
libgpac.dll 2.23 MB (2,348,791 bytes)
libgpac_static.a 2.90 MB (3,049,872 bytes)
When i re-run configure:
cd gpac
cvs up
make clean
configure
make lib &>output_configure.txt
The result:
http://files.x264.nl/output_configure.txt
libgpac.dll 2.23 MB (2,348,791 bytes)
libgpac_static.a 2.90 MB (3,049,872 bytes)
When i do a fresh checkout:
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/gpac co -P gpac
cd gpac
make clean
configure
make lib &>output_clean.txt
The result:
http://files.x264.nl/output_clean.txt
libgpac.dll error, not compiled
libgpac_static.a 2.55 MB (2,675,434 bytes)
What does this mean? cvs up is not working, not updating gpac?
(so cvs up != fresh checkout)
Then... what version am i using for x264 rev 385? Is there a CVS command to show you what version or date you are using?
Help!
el divx
14th December 2005, 10:22
I don't know, maybe ask Sharktooth to provide working GPAC tarbals(that will work on MinGW)?
His builds of GPAC always seem to work even if everybody else's don't.
leowai
14th December 2005, 11:22
gpac = fucked
Same here. :confused:
When i do a fresh checkout:
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/gpac co -P gpac
cd gpac
make clean
configure
make lib &>output_clean.txt
The result:
http://files.x264.nl/output_clean.txt
libgpac.dll error, not compiled
libgpac_static.a 2.55 MB (2,675,434 bytes)
I got the same error.
What does this mean? cvs up is not working, not updating gpac?
(so cvs up != fresh checkout)
I've exactly the same problem before. Is this the CVS bug? Or that's the feature it has? It seems like the "CVS update" will update the files by merging the modification you made on those new files.
I manage to avoid this by having two copy of the gpac, named "src" and the "prog". "src" copy will have the clean distribution of the project while "prog" copy is for compilation. "CVS update" is only for the "src" copy only. A progrm is used to synchronize (as an exact mirror) from folder "src" to "prog".
A good one is Super Flexible File Synchronizer (www.superflexible.com, beware, it's a shareware!). Only new files or additional files will be added or deleted with exact mirror option turned on. Synchronization can be done within few seconds. Not all files/data will be written onto the hard disk, only the neccessary files will be updated. This save hard disk life too....
Then... what version am i using for x264 rev 385? Is there a CVS command to show you what version or date you are using?
Help!
Try to look for it from the file: "gpac\CVS\Tag", it shows "D2005.12.04.16.00.00" here. I suspect the last update is on 4th Dec 2005, 4pm?
gpac dated 2005.12.03 works for me. I use Tortoise CVS to retrieve the src of gpac on 3rd Dec 2005. (Right click the gpac root folder: CVS-> Update special, click "Get date/time" and select 3th Dec 2005).
Sharktooth
14th December 2005, 13:23
i wonder how JLF didnt notice gcc is not able to compile GPAC...
try adding --disable-svg in configure.
celtic_druid
14th December 2005, 15:04
Still works with gcc 3.x though right? Just not gcc 4.x.
leowai
14th December 2005, 16:12
Still works with gcc 3.x though right? Just not gcc 4.x.
It doesn't work for me for gcc 3.4.4 here. I think that's some gpac src error instead of gcc.
Sharktooth
14th December 2005, 16:13
it's b0rked for every gcc version i tried 3.x and 4.x.
there are multiple syntax errors and other errors i cant just remember.
celtic_druid
14th December 2005, 16:50
Are you talking about the whole thing or just libgpac? dll and lib both compile fine here with gcc 3.4.4, but not with 4.0.2 (lib only).
Sharktooth
14th December 2005, 16:55
dll doesnt compile here (and doesnt compile to others too).
do a fresh checkout and try again.
celtic_druid
14th December 2005, 17:11
I did a checkout afterwards. Nothing had changed. So basically the same thing.
Sharktooth
14th December 2005, 17:23
well.. bobor was not having any problems compiling gpac (but something was weird in the bins) until he did a checkout.
Since then he experienced the same problems as me and other ppl too.
So there MUST be something wrong with GPAC (syntax errors are an obvious cause).
commands.c:432: error: `SVGElement' undeclared (first use in this function)
commands.c:432: error: (Each undeclared identifier is reported only once
commands.c:432: error: for each function it appears in.)
commands.c:432: error: syntax error before ')' token
commands.c:438: error: syntax error before ')' token
commands.c:457: error: syntax error before ')' token
commands.c:465: error: syntax error before ')' token
that's with GCC 3.4...
celtic_druid
14th December 2005, 17:47
commands.c compiles fine here.
Do you guys have SPIDERMONKEY installed? If not then you wouldn't have -DGPAC_HAS_SPIDERMONKEY and that would I think cause your problem.
Manually including nodes_svg.h should also fix it.
leowai
15th December 2005, 05:36
commands.c compiles fine here.
Do you guys have SPIDERMONKEY installed? If not then you wouldn't have -DGPAC_HAS_SPIDERMONKEY and that would I think cause your problem.
Manually including nodes_svg.h should also fix it.
erm... Never told by the README in gpac that gpac requires SPIDERMONDKEY. The only one I know is gpac requires zlib.
Thanks for the tips, I'll try it now.
[Edit:]
It works. :D
"make apps" now compiled ok too...
Index: src/scenegraph/commands.c
===================================================================
RCS file: /cvsroot/gpac/gpac/src/scenegraph/commands.c,v
retrieving revision 1.7
diff -u -r1.7 commands.c
--- src/scenegraph/commands.c 2 Dec 2005 18:31:56 -0000 1.7
+++ src/scenegraph/commands.c 15 Dec 2005 04:48:23 -0000
@@ -26,7 +26,7 @@
#include <gpac/internal/scenegraph_dev.h>
/*MPEG4 tags (for internal nodes)*/
#include <gpac/nodes_mpeg4.h>
-
+#include <gpac/nodes_svg.h>
GF_Command *gf_sg_command_new(GF_SceneGraph *graph, u32 tag)
{
celtic_druid
15th December 2005, 05:58
In case you have some of these libs already installed on your system, the detailed list of dependencies is
* freetype2 from version 2.1.4 on.
* SpiderMonkey v1.5 RC 4 (libjs from mozilla - you will need gmake to compile this one). RC5 and RC6 can be used but need
changes in /include/gpac/setup.h or configure script
* libjpg version 6b
* Libpng version 1.2.5
* MAD version 0.15.1b (older versions should work)
* xvid version 1.0 (0.9.0 / .1 / .2 should also work)
* ffmpeg 25 June 2005 CVS version
* libogg 1.1, libvorbis 1.1 and libtheora 1.0 from Xiph.org
* faad2, version 2.0 or 2.1 (CVS from www.audiocoding.com)
From INSTALL
edit: working with gcc4 again. At least here.
leowai
22nd December 2005, 12:26
It seems GCC is the culprit.
I don't think so now. :sly:
See below.
make fprofiled with gcc 4.0.2:
I get this error:
gcc -Wall -I. -O4 -ffast-math -D__X264__ -DHAVE_MMXEXT -DHAVE_SSE2 -DARCH_X86 -DSYS_MINGW -DAVIS_INPUT -DMP4_OUTPUT -DHAVE_PTHREAD=1 -s -fomit-frame-pointer -fprofile-use -DHAVE_GETOPT_LONG=1 -c -o common/pixel.o common/pixel.c
gcc -Wall -I. -O4 -ffast-math -D__X264__ -DHAVE_MMXEXT -DHAVE_SSE2 -DARCH_X86 -DSYS_MINGW -DAVIS_INPUT -DMP4_OUTPUT -DHAVE_PTHREAD=1 -s -fomit-frame-pointer -fprofile-use -DHAVE_GETOPT_LONG=1 -c -o common/macroblock.o common/macroblock.c
common/macroblock.c: In function 'x264_mb_predict_mv_ref16x16':
common/macroblock.c:504: internal compiler error: Arithmetic exception
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
make[1]: *** [common/macroblock.o] Error 1
make[1]: Leaving directory `/home/user/x264'
make: *** [fprofiled] Error 2
OK. I get the same error for the first time. Definitely the information is still not clear enough if you try to compile using "make fprofiled", it only tells you
usage: make fprofiled VIDS="infile1 infile2 ..."
where infiles are anything that x264 understands,
i.e. YUV with resolution in the filename, or avisynth
This actually means you MUST input a file that x264.exe "understands". Again, it means the infiles will serve as input file to x264.exe for encoding in the compilation! I successfully built with the command "make fprofiled VIDS="Video.avs" where "Video.avs" is a avisynth script file that x264.exe "understand". :)
Results:
1. The size compiled with "make fprofiled" is large (~100-200KB).
2. I tested two "make fprofile" compilations using same video source but one with 300 frames and the other one has only 100 frames (trim in avs). The binaries produced are slightly different in size. It's about 1KB smaller in size from the compilation output with less frame.
Now I've a few questions:
1. What's the benefit of using "make fprofiled"?
2. I assume the answer in Q1 is for encoding speed, then will the binaries compiled with "make fprofiled" for Video_A.avs benefit other inputs (says Video_B.avs) in terms of encoding speed too?
Hope these info are useful. ;)
omion
27th December 2005, 01:33
I've been trying to build x264 for Windows XP x64, and it's not easy.
What I want:
* CLI
* AVS input
* Matroska output
* 64-bitness :p
I did the SVN thing and fired up "libx264.vcproj" in MSVS 2005.
I (finally) built libx264.lib after a bit of trouble (*) and turned to "x264.vcproj"
I tried to build x264.vcproj and got a whole bunch of linker errors:
libx264.lib(cpu-a.obj) : warning LNK4078: multiple '.xdata' sections found with different attributes (60000020)
libx264.lib(cpu-a.obj) : warning LNK4078: multiple '.pdata' sections found with different attributes (60000020)
libx264.lib(frame.obj) : error LNK2019: unresolved external symbol x264_deblock_v8_luma_mmxext referenced in function x264_deblock_v_luma_mmxext
libx264.lib(frame.obj) : error LNK2019: unresolved external symbol x264_deblock_h_luma_mmxext referenced in function x264_deblock_init
libx264.lib(frame.obj) : error LNK2019: unresolved external symbol x264_deblock_h_chroma_intra_mmxext referenced in function x264_deblock_init
libx264.lib(frame.obj) : error LNK2019: unresolved external symbol x264_deblock_v_chroma_intra_mmxext referenced in function x264_deblock_init
libx264.lib(frame.obj) : error LNK2019: unresolved external symbol x264_deblock_h_chroma_mmxext referenced in function x264_deblock_init
libx264.lib(frame.obj) : error LNK2019: unresolved external symbol x264_deblock_v_chroma_mmxext referenced in function x264_deblock_init
libx264.lib(quant.obj) : error LNK2019: unresolved external symbol x264_dequant_8x8_mmx referenced in function x264_quant_init
libx264.lib(quant.obj) : error LNK2019: unresolved external symbol x264_dequant_4x4_mmx referenced in function x264_quant_init
libx264.lib(dct-c.obj) : error LNK2019: unresolved external symbol x264_ydct8_mmx referenced in function x264_sub8x8_dct8_mmxext
libx264.lib(dct-c.obj) : error LNK2019: unresolved external symbol x264_xdct8_mmxext referenced in function x264_sub8x8_dct8_mmxext
libx264.lib(dct-c.obj) : error LNK2019: unresolved external symbol x264_pixel_sub_8x8_mmx referenced in function x264_sub8x8_dct8_mmxext
libx264.lib(dct-c.obj) : error LNK2019: unresolved external symbol x264_pixel_add_8x8_mmx referenced in function x264_add8x8_idct8_mmxext
libx264.lib(dct-c.obj) : error LNK2019: unresolved external symbol x264_yidct8_mmx referenced in function x264_add8x8_idct8_mmxext
libx264.lib(dct-c.obj) : error LNK2019: unresolved external symbol x264_xidct8_mmxext referenced in function x264_add8x8_idct8_mmxext
bin/x264.exe : fatal error LNK1120: 14 unresolved externals
x264 - 15 error(s), 52 warning(s)
The functions that it wants are all MMX ones, and are only defined in /common/i386/* , not /common/amd64/* .
What can I do from here? I'd really like to be able to build a 64-bit version of x264, but it's too hard to do on my own. Any assistance?
(*) There were actually two problems with building libx264:
The first was in encoder/cabac.c, on lines 197-203. Apparently MSVS doesn't like the arrays with nothing in them. So I stuck a "0" in each one, and that seemed to work. (No idea if that would break anything, though)
The other problem was at the end of common/amd64/quant-a.asm, lines 516 and 517. YASM didn't like them. It kept complaining about "label or instruction expected at start of line" and "redefinition of ...". So I commented out those last 2 lines and everyone was happy.
akupenguin
27th December 2005, 01:47
x264_deblock_v8_luma_mmxext
x264_deblock_h_luma_mmxext
x264_ydct8_mmx
x264_xdct8_mmxext
x264_pixel_sub_8x8_mmx
x264_pixel_add_8x8_mmx
x264_yidct8_mmx
x264_xidct8_mmxext
These functions do not exist in 64bit, we only have SSE2 versions. Does the project file not define ARCH_X86_64?
x264_deblock_h_chroma_intra_mmxext
x264_deblock_v_chroma_intra_mmxext
x264_deblock_h_chroma_mmxext
x264_deblock_v_chroma_mmxext
These do exist, and work on 64bit linux. Is the whole common/amd64/frame-a.asm not included?
x264_dequant_8x8_mmx
x264_dequant_4x4_mmx
You commented these out, so of course they're missing.
omion
27th December 2005, 04:03
These functions do not exist in 64bit, we only have SSE2 versions. Does the project file not define ARCH_X86_64?It looks like it didn't. I changed the ARCH_X86 to ARCH_X86_64. That solved that!
These do exist, and work on 64bit linux. Is the whole common/amd64/frame-a.asm not included?It looks like common/amd64/deblock-a.asm was not in the project file. I hacked it in and got rid of those errors.
You commented these out, so of course they're missing.Oh yeah :D Well, I removed the references to them (at the bottom of common/quant.c) now it's happy.
So it builds just fine now (0 errors, 2 warnings) and spits out x264.exe, but when I try to run it... nothing. No errors, it just exits. I (again) have no clue where to go from here.
Here's the .exe file, in case it's any help:
x264-broken.exe (http://omion.dyndns.org/other/x264-broken.exe)
(hosted from my home computer, so have patience)
squid_80
27th December 2005, 08:24
These functions do not exist in 64bit, we only have SSE2 versions. Does the project file not define ARCH_X86_64?Nope, because the windows x64 stuff was integrated into SVN before there were any dependencies on ARCH_X86_64 :)These do exist, and work on 64bit linux. Is the whole common/amd64/frame-a.asm not included?deblock-a.asm and frame.c (I think) came along after the windows x64 stuff was checked in. I made windows versions of those functions, they should be in the source archive on my ftp server.
*Note about the new functions in quant-a.asm: The way the functions were defined didn't fit well with the stupid pad macro (hence the redefinition errors), so I made a rather kludgy workaround. :)
Omion:
I'm guessing your build is crashing because it's trying to use the assembly deblocking functions, which are written for linux only. Take a look at ftp://squid80.no-ip.com and get the x264cli_x64src.zip file. If I've remembered to update it recently it should compile with Avisynth input and matroska output. You might need to remove MP4_OUTPUT from the preprocessor definitions and remove libgpac_static from the linker input, unless you want to tackle compiling gpac as well.
omion
27th December 2005, 22:15
Hmm. Still no good. It's still exiting right after it's run. Here's what I did:
* Dowloaded and extracted "x264cli_x64src.zip"
* Opened up libx264.vcproj, updated it to work with MSVS 2005.
* Changed the configuration to Release64.
* Added a new "x64" platform
* Tweaked the properties to not use MP4_OUTPUT and libgpac_static, as you said
* Hit "build solution"
It builds, but again I get an executable which exits as soon as I run it.
I know that my setup is working, as I built 64-bit Apache in a similar manner.
The whole directory, after my changes, is here: x264_build_x64_broken.rar (http://omion.dyndns.org/other/x264_build_x64_broken.rar)
BTW squid, I also downloaded x264cli_x64.zip from your site. It runs, but it won't open any of my .avs files. I get back the line "could not open input file '.\Script720.avs'" whenever I try to run it. It says it's compiled for AVS input though...
squid_80
27th December 2005, 22:25
Hmm. Still no good. It's still exiting right after it's run. Here's what I did:
* Dowloaded and extracted "x264cli_x64src.zip"
* Opened up libx264.vcproj, updated it to work with MSVS 2005.
* Changed the configuration to Release64.
* Added a new "x64" platform
* Tweaked the properties to not use MP4_OUTPUT and libgpac_static, as you said
* Hit "build solution"
It builds, but again I get an executable which exits as soon as I run it.
I know that my setup is working, as I built 64-bit Apache in a similar manner.
The whole directory, after my changes, is here: x264_build_x64_broken.rar (http://omion.dyndns.org/other/x264_build_x64_broken.rar)I'll have a look when I get home from work later. Could be a bug caused by vs2005, I've been using the last platform SDK.BTW squid, I also downloaded x264cli_x64.zip from your site. It runs, but it won't open any of my .avs files. I get back the line "could not open input file '.\Script720.avs'" whenever I try to run it. It says it's compiled for AVS input though...Did you download and install the 64-bit version of avisynth from my site as well?
celtic_druid
28th December 2005, 05:10
http://celticdruid.no-ip.com/test/x264_x64.7z
Compiled with VS2005 and works ok here. I might see if I can get mp4 output working later.
squid_80
28th December 2005, 08:06
It's not hard, I don't think any changes are required. There's just lots and lots of warnings.
omion
28th December 2005, 08:44
Did you download and install the 64-bit version of avisynth from my site as well?That was the problem. I got it, as well as the 64-bit version of DGDecode, and it works great now (well, celtic_druid's build does...)
It's not hard, I don't think any changes are required. There's just lots and lots of warnings.Well, I didn't change the code in any way. I really just added the x64 build platform (which MSVS 2005 needs) then hit "go".
@celtic_druid:
Do you think you could send me a .zip of the build directory after you successfully built it? I want to see whether the problem is in my computer or my brain.
celtic_druid
28th December 2005, 13:32
You tried playing back anything encoded with it? I just tried playing my test encode and got a mostly grey screen.
omion
28th December 2005, 19:57
That's even more weird. Your build plays back perfectly on my machine. Maybe some feature that you used wasn't translated right to 64-bit.
My (working) command lines:
--mixed-refs --pass 1 --crf 19 --stats ".\1080 1b x64.stats" --subme 5 --ref 8 --progress --me umh --merange 16 --bframes 1 --weightb --b-pyramid --analyse all
--mixed-refs --pass 3 --bitrate 14674 --stats ".\1080 1b x64.stats" --subme 6 --ref 12 --progress --me umh --merange 16 --bframes 1 --weightb --b-pyramid --analyse all --8x8dct
edit: By the way, what revision is your build based off of? I see it's core 42, so it'd have to be at least 384.
Kurtnoise
29th December 2005, 10:15
Hi,
@Sharktooth or someone else : could you post somewhere the last patches ? This link http://files.x264.nl/Sharktooth/?dir=./x264_patches doesn't work for me. Thanks...
Yong
29th December 2005, 10:48
Here is the link to download the x264 patches:
http://s33.yousendit.com/d.aspx?id=3V0M09H53Q2WM32EA9RJWPG62V
i not sure those patches i uploaded are asme as here http://files.x264.nl/Sharktooth/?dir=./x264_patches , and some patch is out-dated or might conflict , so becareful :p(u can revert back to original by using tortoiseSVN ;) )
squid_80
29th December 2005, 11:25
@Omion:
The whole directory, after my changes, is here: x264_build_x64_broken.rar (http://omion.dyndns.org/other/x264_build_x64_broken.rar)I downloaded and extracted, tried to run the existing x264.exe (that you'd already build) and it exited straight away. So I loaded the solution into vs2005, removed bufferoverflowu.lib from the linker input because it couldn't find it, compiled and it seems to work flawlessly. One thing that did spring to mind though were these warnings (which I didn't get when I compiled):
libx264.lib(cpu-a.obj) : warning LNK4078: multiple '.xdata' sections found with different attributes (60000020)
libx264.lib(cpu-a.obj) : warning LNK4078: multiple '.pdata' sections found with different attributes (60000020)Can you run yasm --version and check when your copy of yasm was compiled? This could indicate that it's too old and not handling the kludgy exception code properly.
@celtic_druid: No multithreading support? ;) Other than that your build works fine here too.
omion
29th December 2005, 21:12
One thing that did spring to mind though were these warnings (which I didn't get when I compiled):Can you run yasm --version and check when your copy of yasm was compiled? This could indicate that it's too old and not handling the kludgy exception code properly.
I have YASM 0.4.0, which the web page says is the latest version.
I removed bufferoverflowu.lib as you said, but still no luck. It must be something to do with those warnings. I get 2 when I build libx264:
pixel-sse2.obj : warning LNK4078: multiple '.xdata' sections found with different attributes (60000020)
pixel-sse2.obj : warning LNK4078: multiple '.pdata' sections found with different attributes (60000020)
And then these 2 when I build x264:
libx264.lib(cpu-a.obj) : warning LNK4078: multiple '.xdata' sections found with different attributes (60000020)
libx264.lib(cpu-a.obj) : warning LNK4078: multiple '.pdata' sections found with different attributes (60000020)
squid_80
29th December 2005, 22:14
Yasm 0.4.0 is the latest release, but it's over a year old and not good enough. Try getting the latest snapshot build. (http://www.tortall.net/projects/yasm/snapshots/) r1215 or greater is needed.
omion
30th December 2005, 05:14
Yasm 0.4.0 is the latest release, but it's over a year old and not good enough. Try getting the latest snapshot build. (http://www.tortall.net/projects/yasm/snapshots/) r1215 or greater is needed.
That did it! It builds great now!
I also checked out the latest SVN and hacked it to add your changes to it. After a bit of trouble, it builds as well!
Tested everything out, and it all works perfectly. Thanks, squid_80!
Sirber
30th December 2005, 16:16
c:\projets\x264\common/common.h(30) : fatal error C1083: Cannot open include file: 'inttypes.h': No such file or directoryStill compilation problem under VC++ 2005 :(
libx264 work #1, x264 fails
omion
30th December 2005, 20:36
Still compilation problem under VC++ 2005 :(
libx264 work #1, x264 fails
It looks like HAVE_STDINT_H isn't defined for you. If you do have stdint.h (should be in \extras), then define HAVE_STDINT_H in the project properties.
Where did you get the source? I didn't have that problem when I built it. Well, I did have the problem in common/frame.h, where I needed to change
#include <inttypes.h>
to
#ifdef HAVE_STDINT_H
#include <stdint.h>
#else
#include <inttypes.h>
#endif
Ajaja2005
1st January 2006, 16:33
removed
squid_80
21st January 2006, 10:08
Has anyone compiled lately using VS? The large file support patch doesn't work, I can get it to work with vs 2005 by defining off_t and using _fseeki64 and _ftelli64 but I don't know if there's similar functions in earlier editions of vc++. It would be possible to write my own....but I'm probably too lazy.
Ajaja2005
21st January 2006, 10:13
2squid_80
#include <sys/types.h>
squid_80
21st January 2006, 10:49
That doesn't really fix the problem, it just #defines off_t as a long. What if I really do want large file support?
[Denis]
23rd January 2006, 15:54
Ajaja2005
thanks, it's fix problem for me.
-----------------------------
спасибо опять помог мне
max-holz
5th February 2006, 21:22
Anyone could give a little help about how to compile x264 cli under Visual Studio 2003? What's required other than x264 source and in which way I must procede?
Ciao
Manao
5th February 2006, 21:26
Nasm, and some MSVC project management knowledge because iirc, the project doesn't build out of the box.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.