How to compile x264

[jamespand]

Hi Friends,

I am new to video codecs.
I am using x264 msvc-2005 build.
My task is encode x264 to .mp4 , for that i downloaded gpac (gpac-0.4.5.rar) from sourceforge.
and downloaded zlib125-dll.zip for dependency of mp4Box.
Now i am getting error below...

Error 2 fatal error LNK1104: cannot open file 'js32.lib'
--------
can someone help me to fix it. Or advice me some code to plug in to x264 encoder. Please help me ASAP.


Thanks,
James

[LoRd_MuldeR]

So do you mean you have a pre-compiled "msvc-2005" binray of x264 or do you want to compile x264 yourself using MSVC ???

Anyway, x264 doesn't officially support MSVC as a compiler. It used to do so long ago, but support for MSVC was dropped in favor of MinGW/GCC.

If you wan to compile x264 yourself, why not use MinGW? And if you use pre-compiled x264, where did you get it?

[LoRd_MuldeR]

About link-time optimization

(1) Do I understand correctly that "-flto" must be passed to both, the compiler and the linker?

(2) Do I understand correctly that with LTO enabled, the optimization flags must be passed to the linker, as all the code generation now happens in the linker phase?

(3) If the above assumptions are correct, does this patch (http://pastie.org/private/rknrf1azgjueuoarsbmllg) make sense ???


Documentation:
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto-821

[komisar]

(1) yes.
(2) no. only if you need to change this flags in link-time.
(3) if you need -- pass extra flags in "--extra-cflags/--extra-ldflags"

for you attention:If object files containing GIMPLE bytecode are stored in a library archive, say libfoo.a, it is possible to extract and use them in an LTO link if you are using gold as the linker (which, in turn requires GCC to be configured with --enable-gold). To enable this feature, use the flag -fuse-linker-plugin at link-time:

gcc -o myprog -O2 -flto -fuse-linker-plugin a.o b.o -lfoo

With the linker plugin enabled, gold will extract the needed GIMPLE files from libfoo.a and pass them on to the running GCC to make them part of the aggregated GIMPLE image to be optimized.

If you are not using gold and/or do not specify -fuse-linker-plugin then the objects inside libfoo.a will be extracted and linked as usual, but they will not participate in the LTO optimization process.gold not available for mingw... the use of LTO is justified only for projects such as mp4box in gpac... but not for libgpac.a

p.s. gcc 4.5.x produce slower binary than gcc 4.4.x

[LoRd_MuldeR]

(2) no. only if you need to change this flags in link-time.

Are you 100% sure ???

As far as I understand, when compiled with LTO, then the object files will contain both, GIMPLE byetcode and the usual "final" code. The optimization flags passed at compile-time only apply to the "final" code generated at compile-time, but not to the GIMPLE bytecode. Also the docs say clearly that the flags passed at compile-time are not remembered in the GIMPLE code (with the only exception of "-fPIC", "-fcommon" and "-m"). Last but not least, when the object files are linked together with LTO enabled, then the linker will use the GIMPLE byetcode stored in the object files, if available. As the "final" code is then generated at link-time, the optimized flags that were passed at compile-time don't have any effect! Therefore I believe we must pass the optimization flags again at link-time when using LTO.

In my test with LTO enabled I noticed that when I used "-march" only at compile-time, but not at link-time, then all the binaries (i686, core2, amdfam10, pentium3) cam out at the identical byte-size. That made me suspicious! And another strange effect: The 'amdfam10' optimized build did not abort with "CLZ test failed: x264 has been miscompiled!" error on my Core2, which it usually (and for good reason) does! Then I re-read the GCC docs about LTO and I decided to pass the optimization flags (actually all the CFLAGS) also at link-time. And voilà! I got binaries of different size and the 'amdfam10' build errored out again.

So can you confirm this? Or what do I miss? :confused:


(3) if you need -- pass extra flags in "--extra-cflags/--extra-ldflags"

I'm aware of that method. But this way I had to "hard" pass all the optimization flags I'd like to have for the linker.

With the patch above, I can simply re-use that flags that the x264 ./configure added to the CFLAGS variable automatically, which I'd prefer.

[komisar]

can I put it wrong, but I mean something like `CF="-march=amdfam10 -O2"; configure --extra-cflags=$CF --extra-ldflags="-s $CF"`

[LoRd_MuldeR]

can I put it wrong, but I mean something like `CF="-march=amdfam10 -O2"; configure --extra-cflags=$CF --extra-ldflags="-s $CF"`

I think I got your point on this.

But this way I still would have to add all the optimization flags explicitly to the "--extra-ldflags" (or "CF", respectively), including those that x264 ./configure would normally add to CLFAGS automatically.

Any comments about the other issue?

[jamespand]

So do you mean you have a pre-compiled "msvc-2005" binray of x264 or do you want to compile x264 yourself using MSVC ???

Anyway, x264 doesn't officially support MSVC as a compiler. It used to do so long ago, but support for MSVC was dropped in favor of MinGW/GCC.

If you wan to compile x264 yourself, why not use MinGW? And if you use pre-compiled x264, where did you get it?


Hi,

i am able to compile in msvc 2005 and working fine. but now i want to make mp4 writer also.

[LoRd_MuldeR]

@jamespand:
I moved you posts to the "Development" forum, as I think compilation issues better fit here.

You still didn't answer my previous questions: Why do you compile x264 in MSVC (not in MinGW/GCC) and what version of x264 are you using?

Up-to-date x264 doesn't ship with MSVC project files. Also the x264 code needs to be modified in order to satisfy MSVC. So did you pick an old version of x264, did you make the MSVC project files and the required code modifications yourself or are you using 'unofficial' project files and patches provided by someone else?

Adding MP4 support would be much easier with MinGW/MSYS, simply by using x264's "./configure" script. It will find and compile-in GPAC (MP4 output) automatically, if available.

[jamespand]

@jamespand:
I moved you posts to the "Development" forum, as I think compilation issues better fit here.

You still didn't answer my previous questions: Why do you compile x264 in MSVC (not in MinGW/GCC) and what version of x264 are you using?

Up-to-date x264 doesn't ship with MSVC project files. Also the x264 code needs to be modified in order to satisfy MSVC. So did you pick an old version of x264, did you make the MSVC project files and the required code modifications yourself or are you using 'unofficial' project files and patches provided by someone else?

Adding MP4 support would be much easier with MinGW/MSYS, simply by using x264's "./configure" script. It will find and compile-in GPAC (MP4 output) automatically, if available.

Hi,

I am using x264-snapshot-20090216-2245 and working fine as of now with msvc. now i want to made mp4 writer.

Thanks,
Pandu

[J_Darnley]

Install gpac or apply the l-smash patch

[LoRd_MuldeR]

Hi,

I am using x264-snapshot-20090216-2245 and working fine as of now with msvc. now i want to made mp4 writer.

Thanks,
Pandu

Now that is a very old version! It works with MSVC because the support for MSVC was officially dropped around September 2009 ;)

I highly recommend to use an up-to-date x264 version, instead of such an old snapshot.

If one really needs to compile the latest x264 with MSVC, this is possible. It needs a few 'unofficial' code modifications and project files, but it works.

Anyway, you still haven't answered why you are insisting on MSVC, while the obvious way to compile x264 would be using MinGW/MSYS.

(And yes, it is possible to use a MinGW-compiled x264 DLL from a MSVC-compiled application - if that is your concern)

[jamespand]

Now that is a very old version! It works with MSVC because the support for MSVC was officially dropped around September 2009 ;)

I highly recommend to use an up-to-date x264 version, instead of such an old snapshot.

If one really needs to compile the latest x264 with MSVC, this is possible. It needs a few 'unofficial' code modifications and project files, but it works.

Anyway, you still haven't answered why you are insisting on MSVC, while the obvious way to compile x264 would be using MinGW/MSYS.

(And yes, it is possible to use a MinGW-compiled x264 DLL from a MSVC-compiled application - if that is your concern)

Thank you for reply, but my project is msvc based.
So i need to use msvc.

[LoRd_MuldeR]

Thank you for reply, but my project is msvc based.
So i need to use msvc.

No, as I already told you, you don't need to. You can built the libx264 DLL with MinGW/MSYS and still use it from an MSVC application.

Anyway, if your "project" uses x264 a library, then MP4 output cannot be "enabled" anyway, as the output modules (MKV, FLV, MP4, etc) are part of the x264 CLI encoder, and NOT part of the x264 library (libx264) itself. So if you want to use the output modules, you'd built the x264 CLI encoder as a "stand alone" application. And in that case there is even more reason to build it via MinGW/MSYS.

[jamespand]

No, as I already told you, you don't need to. You can built the libx264 DLL with MinGW/MSYS and still use it from an MSVC application.

Anyway, if your "project" uses x264 a library, then MP4 output cannot be "enabled" anyway, as the output modules (MKV, FLV, MP4, etc) are part of the x264 CLI encoder, and NOT part of the x264 library (libx264) itself. So if you want to use the output modules, you'd built the x264 CLI encoder as a "stand alone" application. And in that case there is even more reason to build it via MinGW/MSYS.

Ok,

Can you help me to install MinGW in windows7 PC.

[LoRd_MuldeR]

Can you help me to install MinGW in windows7 PC.

http://tinyurl.com/2epm45p

[jamespand]

No, as I already told you, you don't need to. You can built the libx264 DLL with MinGW/MSYS and still use it from an MSVC application.

Anyway, if your "project" uses x264 a library, then MP4 output cannot be "enabled" anyway, as the output modules (MKV, FLV, MP4, etc) are part of the x264 CLI encoder, and NOT part of the x264 library (libx264) itself. So if you want to use the output modules, you'd built the x264 CLI encoder as a "stand alone" application. And in that case there is even more reason to build it via MinGW/MSYS.

Hi,

any update on gpac compilation with msvc, because its giving zlib error.

[LoRd_MuldeR]

It's still unclear what you are doing. Did you move on to compiled x264 under MinGW/MSYS? If so, why are you still trying to compile GPAC under MSVC?

Under MinGW/MSYS you can simply grab Komisar's "Library pack for build x264", put the GPAC libs as well as the header files into their appropriate directories and run "./configure" form the x264 source directory.
http://komisar.gin.by/mingw/index.html

Anyway, if you need to compile GPAC yourself under MSVC for whatever reason and it complains about missing 'zlib', you'll need to compile the 'zlib' library first, I guess ;)

[RBO]

LoRd_MuldeR is right: GPAC needs zlib to compile ;)

GPAC also has troubles compiling with MinGW since I began working on 64 bits support. Because MinGW uses the runtime from VC6 (from 1998...).
Please use mingw64 for both 32 and 64 bits builds. I tried using more recent VC runtimes with MinGW as suggested on some forums, but the support seems unfortunately broken...

If you want to help or have tremendous problems compiling GPAC, please PM me or go to the GPAC forums. Thanks!

Romain

[XhmikosR]

@RBO:
http://xhmikosr.1f0.de/patches/gpac/gpac_mingw.patch
http://xhmikosr.1f0.de/patches/gpac/gpac_x64_mingw.patch

Both patches made by golgol7777. With the above patches I can successfully build the latest gpac svn with this (http://xhmikosr.1f0.de/tools/MSYS_MinGW_GCC_451_x86-x64_components.txt) toolchain.

[RBO]

Thank you :)

We officially don't support 64 bits platforms, but I take care of these patches until we finally make it (end of 2010 if ok ;) )