Compile x264 on win 32

[sirt]

Hello,

As I am a perfect noob at compiling x264 for win32, I come with some questions to understand much more what I am doing. First of all, I get the source from there :

http://www.videolan.org/developers/x264.html

Then I save the x264 folder to C:\

I decided to follow that tutorial right there :

http://mediaretriever.blogspot.fr/2011/05/compile-x264-on-windows.html

I followed it step by step and I ended with the "x264.exe" on my top x264 folder demuxed before to C:\ ; but something is unclear to me : the exe created is only 1.50 MB ! Is that normal ? I would have expected it to be 9.8 Mb like the latest one you can download from www.x264.nl ; then, what am I doing wrong ? I guess I should add some diff patches somewhere but I ignore how and from where to get them (excepted Komisar page)

[LoRd_MuldeR]

x264 can be built-with optional libraries, such as libavcodec/libavformat and ffms2. You probably have built your binary without these, which explains why it's much smaller.

As long as you don't need the built-in libav/ffms2 support, that should be no problem at all. Otherwise you'll have to put the missing libraries in place and re-built x264. The configure script will find and enable them automatically.

BTW: If you don't want to compile those libraries yourself, Komisar (http://komisar.gin.by/mingw/index.html) provides a quite useful "libpack" for building x264 :)

[sirt]

Thanks Lord, and sorry for having posted this in the wrong place.

But how would you "put the missing libraries in place and re-built x264" ? Should I download some patch (diff files ?) and create a sub folder called "patch" on my top x264 source folder for example ? I am surely dumb but I have no idea what these diff refer to and how to compile x264 with the method described below.

Are you referring to the "x264 libpack" section on Komisar page ? Let's say I get that : http://komisar.gin.by/mingw/libpack-gcc44x-20120119.7z ; I have any idea what to do with that (again, where to incoparate those folders in order to compile everything with the method below)

Moreover, I don't understand either what are the "precompiled toolchains" either, how to choose one and how to use/compile them.

[LoRd_MuldeR]

You don't need any patch to add the missing libraries. The official x264 supports these out-of-the-box.

As said before, the optional libraries will be detected and enabled by the ./configure script, if they are available. Just put the .lib files into your "lib" directory and put the corresponding header files into your "include" directory.

Alternatively you may add --extra-cflags="-I<path_to_additional_header_files> -L<path_to_additional_lib_files>" to your call of the ./configure script - if you don't want to add the files to your global "lib" / "include" folder.

BTW: You can always check the output of ./configure to see which libraries have been found/enabled.

[sirt]

Well I've copied both "lib" and "include" foloders to the top x264 folders downloaded from videolansource, then I followed the tutorial ; everyhting
worked well, excepted that the fact the lib and include folders seem not to have been taken in account !

In MINGW32 I tried something like : make --extra-cflags="-I<"c:\x264\include"> -L<"c:\x264\lib">" but it doesnt seem to work either (I still get the 1.50 mb file) ; it says something is ignored. Well, as you try to explain to me, it is certainly simple but I keep on doing something wrong.

[LoRd_MuldeR]

Try the following:
./configure --extra-cflags="-I/c/x264/include -L/c/x264/lib"

Given you have put the suitable .lib files into "c:\x264\lib" and the corresponding header files into "c:\x264\include".

If ./configure still won't find the desired libraries, check your config.log ;)

[sirt]

It seems what you told me to do works but I still end with a 1.50 MB file ! Let me explain you what I exactly do :

1) I have gotten git and I open "Git Batch" where I type :

git clone git://git.videolan.org/x264.git "C:/x264"

All the source code is then copied to C:\x264

2) I have no idea what I should choose there http://komisar.gin.by/mingw/index.html ; then I decided to get that http://komisar.gin.by/mingw/libpack-gcc47x-20120620.7z (x264 libpack GCC 4.7.x)

I create an empty "lib" and "include" folder under "x264"

3) Behind that libpack there too folders "i686-w64-mingw32" and "x86_64-w64-mingw32" ; I choose the second one ; there are two sub folders : "include" that contains one billion .h files and "lib" which gathers only .a files. I copied both folders to my x264 top folder then used :

./configure --extra-cflags="-I/c/x264/include -L/c/x264/lib"

(On MinGW Shell)

Then : make

It works but I still end with the 1.50 MB file ! It is probably not surprising as much as I don't have any .lib files anywhere. Am I maybe wrong at downloading those libpacks ? Should I download a "precompiled chains" ?

It looks like I would not understand whatever you can tell me, so an example would be welcomed if you are enough courageous to !

Let's say you start with "c:\x264" , how would you proceed then step by step to compile x264 with some libraies like I intend to (trough MinGW Shell) ?

[LoRd_MuldeR]

If you are building a 32-Bit binary (using the 32-Bit MinGW/GCC compiler), which you probably are, then you need the 32-Bit libraries, from the "i686-w64-mingw32" folder of the libpack. The "x86_64-w64-mingw32" folder is for 64-Bit.

There is no need to create the "lib" and "include" folders inside the x264 source folder. It's kind of unusual, but nevertheless should work - as long as you specify the paths properly.

Let's assume you have put the library (.a) files into "C:\libpack\lib" and the corresponding header (.h) files into "C:\libpack\include", then the proper command would be: ./configure --extra-cflags="-I/c/libpack/include -L/c/libpack/lib"

Also note that if the libpack has some header (.h) files inside "...\include\some_subfolder" they need to go into "C:\libpack\include\some_subfolder" on your HDD too. The original directory structure within "include" must be retained.

Last but not least: Next time look at your config.log after you ran ./configure in order to find out what exactly went wrong! This will be much easier than having us guess what went wrong :rolleyes:

[sirt]

Thanks Lord.

I did what you asked for :

I keep the x264 source on "c:\x264"

I've got "libpack-gcc47x-20120620" and copied "include" and "lib" to the created folder "c:\libpack"

Then this is what I've typed on MinGW Shell :

http://i1240.photobucket.com/albums/gg481/abel413/compile1.jpg

I don't know if the message dealing with "gpac too old" can provoke errors or not and I have no idea what that gpac is either.

Then I type "make" and the compiling process begins and I end again with my 1.5 MB file !!

Here are screenshot of the process that I guess is incorrect :

http://i1240.photobucket.com/albums/gg481/abel413/compile2.jpg
http://i1240.photobucket.com/albums/gg481/abel413/compile3.jpg

[LoRd_MuldeR]

It seems that x264's configure script has detected an outdated revision of the GPAC library.

Komisar's libpack should contain a suitable version. So are you 100% sure there isn't another (older) version floating around on your system somewhere?

The "lib" and "include" folders inside your MinGW installation folder would be the primary places to check...

(As for lavf and ffms2: They have not been detected. I already told you where you can find more information on what exactly went wrong)

[LoRd_MuldeR]

Sorry, after thinking about it a bit more, I think we need:

./configure --extra-cflags="-I/c/libpack/include" --extra-ldflags="-L/c/libpack/lib"

BTW: You said you picked Komisar's libpack for GCC 4.7.x. What version of GCC are you using? Typing "gcc -v" will tell you.

[sirt]

Thanks for your help again.

Then how can I delete the current GPAC library and update it ?

I've tried gcc -v in minGW shell and it told me which GCC i should choose so I downloaded this :

http://komisar.gin.by/mingw/libpack-gcc46x-lto-20120620.7z

Then, again I got x264 source, place it under "c:\x264" and under "c:\libpack" I placed the "include" and "lib" folders from the previous download without changing anything

I opened minGW and type cd "c:\x264", then ./configure --extra-cflags="-I/c/libpack/include" --extra-ldflags="-L/c/libpack/lib"

And..I still get the 1.50 mb file. I PMed you my log because I don't really understand what happens even though it is clear some errors occur.

[sirt]

Then did you have a look at my log ?

[LoRd_MuldeR]

I was busy with "real life" stuff. But I just had a quick look at your log and it seems various symbols are missing!

As far as I can tell, these are functions that normally should be included in MinGW/GCC itself (e.g. "__mingw_vsscanf") , so I guess your MinGW/GCC somehow is broken or "incompatible" with Komisar's lib pack.

I'd suggest to download "GCC 4.7.x" or whatever version your prefer directly from Komisar's site (http://komisar.gin.by/mingw/index.html).

Then extract it into "C:\MinGW.komisar", so that "C:\MinGW.komisar\bin\gcc.exe" exists. After that, open your MSYS (MinGW) shell (console) and type the following commands:

umount /mingw
mount c:/MinGW.komisar /mingw

If you then type only "mount" without a parameter, you should now see something like that:

C:\Users\YourName\AppData\Local\Temp on /tmp type user (binmode,noumount)
c:\MSYS\msys\1.0 on /usr type user (binmode,noumount)
c:\MSYS\msys\1.0 on / type user (binmode,noumount)
c:\MinGW.komisar on /mingw type user (binmode)
c: on /c type user (binmode,noumount)
d: on /d type user (binmode,noumount)
e: on /e type user (binmode,noumount)
f: on /f type user (binmode,noumount)
g: on /g type user (binmode,noumount)
h: on /h type user (binmode,noumount)
i: on /i type user (binmode,noumount)
j: on /j type user (binmode,noumount)
k: on /k type user (binmode,noumount)

Also try to type "gcc -v" to make sure that the new MinGW/GCC really is working as expected. It should say:

gcc version 4.7.1 (multilib.generic.Komisar) (GCC)

Finally try again with this command from x264 source directory:

./configure --extra-cflags="-I/c/libpack/include" --extra-ldflags="-L/c/libpack/lib"
make -B

Still assuming the libpack is at "C:\libpack" and matches your new MinGW/GCC version...

[sirt]

Thank you for this detailed help.

I followed exactly what you asked and it is better because...I end with a 1.61 MB file ! I guess there are still errors so I uploaded the log and PMed it to you again.

I don't understand the problem because let's sum up what I did :

1) I got last x264 source code via git Bash and place it to "c:\x264"

2) I opened MinGW shell, typed gcc -v and it says gcc 4.6.2. So I went to komisar and downloaded the corresponding "procompiled chain" and "x264 libpack" (both GCC 4.6.x)

3) I extracted the "precompiled chain" to "c:\MinGW.komisar" and it contains "bin" (including the gcc.exe), doc, i686-w64-mingw32 (a sub filder that also contains bin, include, lil, lib64) , lib and libexec ; I added "yasm.exe" to "c:\MinGW.komisar\bin"

4) I extracted to "c:\libpack" both include and lib with all the three .tag files from the "x264 libpack" downloaded at step 2.

5) I finally followed the steps from your last post.

As I obtain a 1.61 MB, it looks like, at least, something has been added during the compilation.

EDIT : I did exactly the same thing with gcc 4.7 and came up with a 1.71 mb file this time lol...I pmed you the log again. I precise I installed and download that version of MinGW : http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/mingw-get-inst-20110316/mingw-get-inst-20110316.exe/download

[LoRd_MuldeR]

You really should start reading the log ;)

Failed commandline was:
--------------------------------------------------
gcc conftest.c -m32 -Wall -I. -I$(SRCPATH) -march=i686 -mfpmath=sse -msse -std=gnu99 -lswscale -lavutil -m32 -Wl,--large-address-aware -lpthread -o conftest
conftest.c:1:32: fatal error: libswscale/swscale.h: No such file or directory
compilation terminated.

Obviously this time the header file(s) could not be found :eek:

Make sure that "C:\libpack\include\libswscale\swscale.h" (and all the others) do exist and that you are adding the proper --extra-cflags="-I/c/libpack/include" to your ./configure call.

BTW: It is not surprising that the size of the binary differs slightly between different GCC versions. This alone doesn't tell anything about which libraries have been included (or not).

The output of ./configure does:

platform: X86
system: WINDOWS
cli: yes
libx264: internal
shared: no
static: no
asm: yes
interlaced: yes
avs: yes
lavf: no
ffms: no
gpac: no

[sirt]

Thanks again for your answer. I kept on trying more and more and I finally ended with a 13 MB file and this happened when "include" and "lib" are the same on "c:\MinGW.komisar" and "c:\libpack" but unfortunately the log still seem to contain errors. Then I've uploaded the given x264.exe + log but I have no idea if you can know from this if it is almost correct (I mean : can you know from the exe if I've really added the libraries ?)

http://www.sendspace.com/file/xsa0a8

Well, as I see from the log such and such files are sitll not found even though I have them, I guess I will have to try until it is perfect.

Despite everything, there is still something obscur to me : let's say I encode a video with the 1.5 MB file compiled without any libraries and this last 13 MB file. What will be obviously different ? More precisely, I have no idea what such and such libraries added will change and in what way compiling them will be usefull or improve anything.

Finally how could I compile a patch like that one http://komisar.gin.by/old/2200/p/x264_fadecomp.1936.diff or any given patch ? You said something like it would be easier to work with precompiled chains and not diff but I don't understand why.

[LoRd_MuldeR]

Well, the "configure" script tries out various things in order to figure out what does work in your current build environment and what does not.

Not every single test needs to run through cleanly. If something fails, this will only tell the configure script that this "feature" cannot be used in your build environment.

As long as the final result is "okay" (i.e. all libraries you want to have included have been found/enabled), you don't need to bother ;)

And your result looks good now:
platform: X86
system: WINDOWS
cli: yes
libx264: internal
shared: no
static: no
asm: yes <- we have YASM, i.e. x264 won't run in "super slow" mode
interlaced: yes
avs: yes
lavf: yes <- we have built-in LAVF input
ffms: yes <- we have built-in FFMS2 input
gpac: yes <- we have built-in MP4 output
gpl: yes
thread: posix <- we have pthreads, i.e. multi-threading will be enabled

BTW #1: You may want to add --enable-strip in order to strip (http://en.wikipedia.org/wiki/Strip_%28Unix%29) the debug symbols, which reduces the size of the binary.

BTW #2: You may want to include -march=core2 (or whatever your CPU is) into the --extra-cflags="..." to get a (potentially) slightly faster binary.

BTW #3: If you don't already do that, you may want to run "make fprofiled VIDS=sample.avs" instead of only "make", which again might result in a slightly faster binary.

(Note that "sample.avs" needs to exist in the current folder and should output a short video sequence. I'd use foreman (http://media.xiph.org/video/derf/y4m/foreman_cif.y4m) or something like that)

[LoRd_MuldeR]

Finally how could I compile a patch like that one http://komisar.gin.by/old/2200/p/x264_fadecomp.1936.diff or any given patch ? You said something like it would be easier to work with precompiled chains and not diff but I don't understand why.

Patches modify the source code and maybe also the make/configure files.

Thus you have to apply the patch before you do anything else. Usually a "patch -p1 < something.diff" should do the job.

But be aware: Patches are usually made for a specific revision of x264. Whether they work with other revisions is not guaranteed at all!

Even if the "patch" command runs through cleanly, the patch may not work as expected when applied on a "wrong" revision.


BTW: The term "build chain" refers to all the tools that are involved in building a program. This includes the compiler, the linker, the Make program and so on.

If you download a MinGW/GCC package that works "out of the box" (like the one provided by Komisar), then it's pre-compiled - as you did not compile MinGW/GCC from the sources yourself.

After all you will always have to use a pre-compiled MinGW/GCC at some point, even if you want to compile MinGW/GCC yourself ("chicken or egg" paradoxon (http://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29#The_chicken_and_egg_problem)).

[sirt]

Okay, thanks for the time spent to help me with that stuff. I will keep on experimenting by myself.

According to you what is the point of compiling x264 yourself ? I know one's version will differ from someone else version by the different patches applied but I think some patches are somehow interesting : like that one for example http://komisar.gin.by/old/2200/p/x264_aq3.diff which in my opinion is some kind of modified aq-mode, included on x264 TMod. In fact, it looks like official x264 features concocted with x264 kMod or x264 Tmod are pretty enough, aren't they ? As much as my gait is purely experimental, I don't understand in which way compiling yourself x264 will be "better" than downloading one of those compiled version listed before. Withal, do you think some people simply create patches by themselves and compile them afterwards ? Otherwise, I think it is enough to stick with official or Mod versions in so far as the used patches are avaible to everyone.

[LoRd_MuldeR]

According to you what is the point of compiling x264 yourself ?

If you just want to use x264 and don't need any "exotic" patches, there is no point to compile it yourself.

Also by using one of the "popular" builds, like the ones provided on http://x264.nl, you can greatly reduce the chance of using a broken/miscompiled build without noticing ;)

The reasoning is that if something was "wrong" with the latest x264.nl builds, then one of the many users would probably have noticed and complained...

(At the same time your own build is pretty much "untested")

I know one's version will differ from someone else version by the different patches applied but I think some patches are somehow interesting : like that one for example http://komisar.gin.by/old/2200/p/x264_aq3.diff which in my opinion is some kind of modified aq-mode, included on x264 TMod. In fact, it looks like official x264 features concocted with x264 kMod or x264 Tmod are pretty enough, aren't they ?

"AQ mode 3" is yet another variant of x264's Auto-AQ algorithm.

The patch is already included in Komisar's "kMod" builds, so you won't have to build x264 yourself in order to experiment with AQ mode 3.

AFAIK, Komisar was experimenting a lot with different AQ variants and "mode 2" (aka Auto-VAQ) was finally adopted into "official" x264.

As much as my gait is purely experimental, I don't understand in which way compiling yourself x264 will be "better" than downloading one of those compiled version listed before.

It's not "better" per se. Making your own builds even comes at the danger of screwing up something and ending up with a broken/miscompiled build.

In 99.9% of all cases you will be fine downloading a pre-compiled build. But on the other hand, if nobody would be making (and sharing!) x264 builds, then we couldn't download any pre-compiled builds ;)

And, of course, if you want to figure out how to build x264 just for your own education, then that's of course a good reason.

Withal, do you think some people simply create patches by themselves and compile them afterwards ?

That's what people normally do with patches - apply and compile :p

[sirt]

Well, I didn't express myself clearly : I was meaning : do you think some people create patches for themselves and don't share them in public ? In my opinion, it would be one of the headmistress reason to compile x264 on your own. Alternatively, I don't see the point of this excepted education goal (like myself).

Howhever, in the hypothesis some gurus create their own patches and compile them, I can gamble they necessarily have a deep understanding of the x264 source code (or h264 norm) which leads me to think they are working on x264 or related to. I don't think somebody can decide to create a patch from day to day. For example, I know you are a software developper as much as I tested a large amount of your programs (in particular AVIdemux & Simple x264 Launcher) but would you be able to create your own patch (assuming that you are not a x264 developper of course) ? As you may bet, I would like to understand how those things work. Being able to see the content of any .c, .h, .asm via Notepad++ won't help me much if I'm unable to understand what occurs (even though I can understand the programming language itself). So I wonder if someone could explain me the source code or if there is a tutorial for this.

Furthermore, I have still no idea in what way LAVF or FFMS2 support for example will change something. I compiled the x264 source without any libraries some days ago, encoded some movie and I didn't have any trouble watching it on my blu ray player or via VLC, MPC.

[LoRd_MuldeR]

Well, I didn't express myself clearly : I was meaning : do you think some people create patches for themselves and don't share them in public ? In my opinion, it would be one of the headmistress reason to compile x264 on your own. Alternatively, I don't see the point of this excepted education goal (like myself).

x264 is OpenSource software, released under the GPL.

If somebody modifies the source code in any way, he MUST share the modified code (e.g. in the form of a patch) - as soon as he shares a binary.

AFAIK, it would be allowed to keep your modifications "private", if (and only if) you never give your binary to someone else...

Howhever, in the hypothesis some gurus create their own patches and compile them, I can gamble they necessarily have a deep understanding of the x264 source code (or h264 norm) which leads me to think they are working on x264 or related to. I don't think somebody can decide to create a patch from day to day. For example, I know you are a software developper as much as I tested a large amount of your programs (in particular AVIdemux & Simple x264 Launcher) but would you be able to create your own patch (assuming that you are not a x264 developper of course) ?

Sure, everybody can create a patch. The act of creating a patch is trivial: Modify an arbitrary line of code, save the file and type "git diff > my_patch.diff" ;)

The real question here is: Would I be able to come up with a new idea that actually improves something in x264, implement that idea in code and finally make a patch of it?

I think the answer is yes - given enough time, support (by the "core" developers) and motivation :p

Also remember that x264 has participated in GSoC (Google Summer of Code) (http://code.google.com/soc/) multiple times. So student developers are capable of contributing something to x264 :)


BTW: I think the idea of a "code guru" who has created the "ultimate" x264 patch, but keeps it in secret for himself, is kind of absurd.

The people actively working on improving x264 are the "official" x264 developers and maybe the companies they collaborate with. And these people generously share their code.

If somebody else implemented a "big" improvement in x264, this guy would probably be a scientist (e.g. student or doctoral candidate), interested in publishing his results...

As you may bet, I would like to understand how those things work. Being able to see the content of any .c, .h, .asm via Notepad++ won't help me much if I'm unable to understand what occurs (even though I can understand the programming language itself). So I wonder if someone could explain me the source code or if there is a tutorial for this.

This isn't explained in a few minutes. x264 is a pretty complex and highly optimized software.

Unless you are a software developer or a student of computer science or at least a "hobby" programmer/enthusiast, you won't be able to get anywhere.

If you really want to dig into x264's code, I suggest you start by reading a good book about C programming and one about x86 assembler.

Then you may go on by learning the fundamentals of video compression. And of course, studying the MPEG-4 AVC (H.264) specifications will be necessary as well.

Furthermore, I have still no idea in what way LAVF or FFMS2 support for example will change something.

Without LAVF/FFMS2, x264 won't be able to "read" any source files, except for Avisynth scripts and "raw" (uncompressed) video.

Once LAVF/FFMS2 support is enabled, you can throw pretty much everything onto x264 and it will be able to decode and process it - as long as libavcodec/libavformat can deal with it.

The actual "encoder" is not effect by LAVF/FFMS2 at all. That is: If you don't need x264's built-in decoders, e.g. because you use Avisynth anyway, LAVF/FFMS2 is irrelevant for you.

[sirt]

I see, in fact I wasted my time compiling those libraries :helpful: in so far as I use avisynth scripts or raw (at my work) as input !

Then, let's say I want to add some patches, will the process be the same ? I mean :

1) Throw last x264 source from git
2) Open MinGW Shell, then cd "c:\x264"
3) patch -p1 < something.diff
4) Everything done since your helpful post dealing with MinGW.komisar ect

[LoRd_MuldeR]

Probably yes.

Given that "something.diff" is located in the x264 source directory and is intended to be applied to the x264 revision you have checked out from the GIT repository.

Note that most patches need the -p1 option to "fix" the paths. Though that's not always the case...

[sirt]

Ok I've tried to proceed like discussed below (step 1 to 4) and I've added aq3 and fade_compensate patches and it seems to work because I've tried an encode setting --aq-mode 3 --fade-compensate 1 and I didn't get any error.

[sirt]

Hi,

Well I come back to this topic because I have a very annoying problem right now. For an unknown reason, and from a day to another I can't compile x264 anymore...I've gotten the latest version via git (git clone, via Git Bash) then I opened MinGW Shell and used cd to access the corresponding x264 folder ; finally I want to use ./configure and...it says : No Working C Compiler Found :

checking whether windres works... no
Failed commandline was:
--------------------------------------------------
windres --target=pe-i386 -o conftest.o conftest.rc
./configure: line 212: windres: command not found
--------------------------------------------------
Failed program was:
--------------------------------------------------
0 RCDATA {0}
--------------------------------------------------
x264 configure script

checking whether gcc works... no
Failed commandline was:
--------------------------------------------------
gcc conftest.c -m32 -Wall -I. -I$(SRCPATH) -march=i686 -mfpmath=sse -msse -m32 -Wl,--large-address-aware -o conftest
./configure: line 140: gcc: command not found
--------------------------------------------------
Failed program was:
--------------------------------------------------
int main () { return 0; }
--------------------------------------------------
DIED: No working C compiler found.

Then I guess gcc is not found anymore and I can't understand why because it worked perfectly yesterday. If I type mount, I get this :

C:\Users\YourName\AppData\Local\Temp on /tmp type user (binmode,noumount)
c:\MSYS\msys\1.0 on /usr type user (binmode,noumount)
c:\MSYS\msys\1.0 on / type user (binmode,noumount)
c: on /c type user (binmode,noumount)
d: on /d type user (binmode,noumount)
e: on /e type user (binmode,noumount)
f: on /f type user (binmode,noumount)
g: on /g type user (binmode,noumount)
h: on /h type user (binmode,noumount)
i: on /i type user (binmode,noumount)
j: on /j type user (binmode,noumount)
k: on /k type user (binmode,noumount)

I know a line is missing but I can't get it work ; everyhting needed (yasm.exe, gcc.exe) is on c:/MinGW/bin

[LoRd_MuldeR]

Before you run "./configure", you should try "gcc -v". If the latter already doesn't work, then compiling x264 cannot work, obviously.

You say you have installed MinGW in "c:\MinGW\bin", but I cannot see it mounted anywhere!

Consequently you may need something like "mount c:/mingw /mingw". Also type "export" to check whether "/mingw/bin" is in the PATH.

[sirt]

Thanks Lord_Mulder...Well I may be stupid because It works now and I'm pretty sure I've tried to set mount like you suggested. :confused:

Anyway, sorry for this waste.

[sirt]

Sorry for opening back this thread. Long time I haven't focused on this kind of stuff but I suddendly decided to go there : http://www.videolan.org/developers/x264.html, get the source (or use git if you prefer) then I opened MinGW, put ./configure and finally make.

But, no .exe is generated. I get an error saying some .o files are missing in common/x86 such as quant_a.o, predict_a.o and so on. Indeed none already exists in the folder, so do you know what's the problem ?

[LoRd_MuldeR]

Sounds like the ASM files in "common/x86" have not been compiled, but it still tries to link the resulting object files - which are not there.

This is kind of strange, because before Make goes on to the linker stage, it will try to produce (compile) all required object files. And if any required objects files fail to compile, it would stop with error there rather than going on :confused:

Also, if you were missing the assembler (YAMS), then "./configure" would already fail, unless "--disable-asm" had been specified explicitly.

First of all, you should try a "make clean" followed by a "make" in order to do a clean rebuild. If that doesn't help, try deleting your x264 source directory, get a fresh copy of the x264 sources and re-run "./configure" plus "make".

If that still doesn't resolve the issue, it would indicate something with your build environment is seriously screwed up...

[sirt]

Well thank you Lord. Unfortunately, I deleted everything and I don't have anything anymore (Mingw, yasm...). Moreover, I don't remember how to proceed to instal everything useful to compile that x264. It seems MinGW has been updated and it doesn't work like one year ago. What should I instal exactly and in which order ?

Otherwise, isn't there anything less complicated to compile that x264 on win 32 without using MinGW ?

EDIT : I tried to reinstal MinGW ect and when I type ./configure it says "No working C compiler found"..so I guess the later is missing but I installed all from there http://sourceforge.net/projects/mingw/files/ (I got the mingw-get-setup.exe (86.5 kB and ticked and installed everything from the basic installation)

[LoRd_MuldeR]

Otherwise, isn't there anything less complicated to compile that x264 on win 32 without using MinGW ?

No, there isn't. And it's already quite straight forward!

Since your build environment seems to be messed up, I recommend you re-install your build environment from the scratch. First of all, get the latest MSYS (including Git, etc.) from here (http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/msys%2B7za%2Bwget%2Bsvn%2Bgit%2Bmercurial%2Bcvs-rev13.7z/download) plus the latest MinGW from here (http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.1/32-bit/threads-posix/dwarf/x32-4.8.1-release-posix-dwarf-rev5.7z/download).

Then unzip both packages completely to an empty directory, e.g. "c:\sandbox", each in its own sub-directory. So that you have, e.g., "c:\sandbox\msys\bin\msys-1.0.dll" (and friends) plus "C:\sandbox\mingw\bin\gcc.exe" (and friends).

Now just start "msys.bat" from the MSYS directory, which will give you a bash. Then make sure that the MinGW path (e.g. "c:\sandbox\mingw") is mounted correctly to "/mingw", by typing mount, which should give something like:
mount
C:\Users\John_Doe\AppData\Local\Temp on /tmp type user (binmode,noumount)
C:\Sandbox\MinGW on /mingw type user (binmode)
C:\Sandbox\msys on /usr type user (binmode,noumount)
C:\Sandbox\msys on / type user (binmode,noumount)
c: on /c type user (binmode,noumount)
d: on /d type user (binmode,noumount)
e: on /e type user (binmode,noumount)

In case it's not mounted correctly yet, you simply do the following (assuming MinGW was extracted to "c:\sandbox\mingw"):
umount /mingw
mount c:/sandbox/mingw /mingw

Once MinGW is mounted properly, type "gcc -v", which should give you something like:
gcc -v
Using built-in specs.
COLLECT_GCC=c:\Sandbox\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/sandbox/mingw/bin/../libexec/gcc/i686-w64-mingw32/4.8.1/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: [...]
Thread model: posix
gcc version 4.8.1 (rev5, Built by MinGW-W64 project)

And now you are set up! But remember to put yasm.exe (http://www.tortall.net/projects/yasm/releases/yasm-1.2.0-win32.exe) (with exactly that name!) into your "msys\bin" directory, if you wish to build x264 with ASM enabled. And you want ASM to be enabled ;)

Finally you can build x264 from the sources, again from the MSYS bash:
git clone git://git.videolan.org/x264.git x264
cd x264
./configure --enable-win32thread
make

[sirt]

Well thank you for those explanations Lord. Unfortunately, I'm stuck at the beginning : "Now just start "msys.bat" from the MSYS directory.." : this bat is not launched because I get a message claiming /bin/sh.exe is not a valid win 32 application. Il also tried another random link from http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/ with no luck : each time msys.bat can't be started. Of course, I haven't "installed" anything : I simply unzip both mingw and msys as you explained earlier.

For some unknown reason, while extracting msys, I get some warning message like "Unknown method in msysbin\7zae" and there are thousands like that. Nevertheless, the folder seems to be extracted though (msys-1.0.dll is on /bin for example). Well it seems this msys version is not a valid 32 application.

[LoRd_MuldeR]

For some unknown reason, while extracting msys, I get some warning message like "Unknown method in msysbin\7zae" and there are thousands like that. Nevertheless, the folder seems to be extracted though (msys-1.0.dll is on /bin for example). Well it seems this msys version is not a valid 32 application.

Seriously, is it so hard to unzip a 7z archive with 7-Zip (http://www.7-zip.org/) or WinRAR (http://www.rarlab.com/download.htm)? :rolleyes:

If it still fails to extract with one of those, the archive probably is corrupted, so re-download! And if it still says "sh.exe is not a valid win 32 application" after successfull extraction, get a non-broken computer before trying to build x264 ;)

[sirt]

Okay, fortunately it worked. The problem was winrar didn't unzip correctly msys for some reason to the contrary of 7zip.

[sirt]

Hi, it's me again.

This time I'm using Ubuntu and try to compile x264. I installed yasm and moved the obtained executable to x264 folder. Then, using the terminal, I simply typed ./configure (being on x264 folder) then make all and I ended with an executable file. But, it doesn't seem to work on win32 : it doesn't have the ".exe" extension and renaming it to x264.exe doesn't work either.

After some research, I found this (http://alex.jurkiewi.cz/blog/2010/cross-compiling-x264-for-win32-on-ubuntu-linux) which seems to be long and complex. Am I forced to follow such a tutorial so as to get an x264.exe usable on win32 ?

[LoRd_MuldeR]

Hi, it's me again.

This time I'm using Ubuntu and try to compile x264. I installed yasm and moved the obtained executable to x264 folder. Then, using the terminal, I simply typed ./configure (being on x264 folder) then make all and I ended with an executable file. But, it doesn't seem to work on win32 : it doesn't have the ".exe" extension and renaming it to x264.exe doesn't work either.

On Linux you generally don't download pre-compiled binaries, because there are a zillion of different operating systems (distributions) that all are based on the Linux kernel, but still are not 100% binary compatible. Fortunately, most of the time, you can simply install the desired software directly from the "official" repository of your distribution, by using the packet manager (e.g. "apt-get"). Otherwise, you'll have to compile it yourself, from the source.

Furthermore, Linux (actually everything but Windows) doesn't use file extensions. And of course Windows "EXE" files cannot run under Linux, except by using something like Wine. Just like Linux binaries cannot run under Windows ;)


So I suggest you try something like this:
sudo apt-get install build-essential

sudo apt-get install yasm

sudo apt-get install git

git clone git://git.videolan.org/x264.git

cd x264

./configure

make


The first three lines should install the essential build tools (gcc, g++, make, etc), yasm and git. If everything completes successfully, you should end up with a file "x264" in the x264 directory, which you can start by typing "./x264".

PS, while cross-compiling Windows binaries from a Linux system is possible, in theory, that is not trivial. Most of the time, using MinGW+MSYS on a "native" Windows will be the preferred way to get a Windows binary!

[sirt]

Well thank tou for those detailled explanations. I don't really know Linux so that's why I would have wanted to use it on windows ! Of course I could do as we discussed before. But imagine I would like to use avisynth and .bat files to encode on Linux, is that possible ?

In fact, you told me to use x264 as ./x264 so I guess I have to set it like I used to do on Windwos via .bat files (command lines);

[LoRd_MuldeR]

Nope, neither does Linux support Windows binaries ("EXE files") nor does it support Batch scripts ("BAT files"). Just Like Windows cannot run Linux binaries, or Mac OS binaries or <you name it> ;)

On Linux you can run Linux binaries (ELF format), i.e. programs that have been compiled for Linux. And scripting can be done, for example, using Shell Script, Perl, Python etc.

As for Avisynth: Avisynth is a Windows-only application, which you cannot run on Linux. But there has been a project, called AvxSynth, which was (or still is) working on porting Avisynth to the Linux platform.

BTW: As mentioned before, there is Wine, which does allow running (some) Windows applications under Linux. But if you primarily use Windows programs, Linux+Wine probably is the worst solution.

[sirt]

Well my purpose would have been to compile x264 on linux and use it on windows 32 afterwards. It is indeed quite easy - at least for me - to compile it on there albeit mingw reproduces basically the same thing. I guess I might follow the guide aforedmentioned (check my link) but it is similar to the MinGW method we discussed. So I think I can stick to Windows.

[LoRd_MuldeR]

As explained before, compiling x264 on a Linux system in the "standard" way will give you a Linux binary of x264 - which will not work under Windows!

Yes, it is possible to cross-compile a Windows binary under Linux. But this will generally be much more complex than just compiling a "native" Windows binary under Windows with MSYS/MinGW - given you normally use Windows.

For the Linux enthusiast, who just needs to compile a Windows binary now and then, cross-compiling might be a reasonable option though ;)

[sirt]

Yes, that is why I don't plan to follow the tutorial aforedmentionned (for linux). The fact is that it is easier to edit/implement codes via linux tools rather than in Windows and also to compile afterwards. At least, I think many developpers prefer using Linux than Windows to implement softwares (maybe yourself). But, as we discuss, cross-compiling is not trivial and from what I've read around, it is almost similar to what I've done on Windows to compile x264. Consequently, I'm suprised by the fact Linux offers very intuitive tools to program but doesn't generate .exe so easely. Also, original avisynth and some filters I need are not directly available.

I tell you that because I was planning to work on Linux which is not possible (I need avisynth filters, also some editing programs to edit streams like DGindex, lossless codecs ect that don't seem to be available). It would have been easier it all that stuff was available like in Windows !

[LoRd_MuldeR]

The fact is that it is easier to edit/implement codes via linux tools rather than in Windows and also to compile afterwards. At least, I think many developpers prefer using Linux than Windows to implement softwares (maybe yourself).

That's more a question of personal preferences. And it depends greatly on what kind of software you are dealing with! Personally, I think Visual Studio is very a good IDE. Also, compiling a software from an existing Visual Studio solution couldn't be easier. Of course, compiling a software that originates from the "Unix world" is usually more straight forward under Linux - simply because the required development tools (gcc, make, etc) will already be pre-installed on your Linux distro (or at least can be installed easily via package manager). On Windows you'll need to download and install MinGW+MSYS manually to compile such software, which is a bit more work - but still not rocket science ;)

But, as we discuss, cross-compiling is not trivial and from what I've read around, it is almost similar to what I've done on Windows to compile x264. Consequently, I'm suprised by the fact Linux offers very intuitive tools to program but doesn't generate .exe so easely.

Why should Linux development tools generate binaries in the PE (Portable Executable) file format - the file format used by Windows executable? The binary format used on Linux is ELF, so that is what Linux development tools generate by default. Furthermore, it is no surprise that cross-compiling Windows binaries from Linux, clearly being a non-standard case, requires some extra effort.

And even if both, Windows and Linux, were using the PE format, you still couldn't run "native" Linux binaries on Windows! The same way you still couldn't run "native" Windows binaries on Linux. That's because Linux and Windows use very different (incompatible) programming interfaces. Windows programs build on top of the Win32 API, which isn't available under Linux. And Linux programs build on top of the POSIX API, which isn't available under Windows.

I tell you that because I was planning to work on Linux which is not possible (I need avisynth filters, also some editing programs to edit streams like DGindex, lossless codecs ect that don't seem to be available). It would have been easier it all that stuff was available like in Windows !

Well, you can't blame Linux that some software isn't available for Linux, because the developer of that software decided to make it Windows only (or just didn't bother to port his software to Linux). The same way you can't blame Windows that some software isn't available for Windows, because the developer of that software decided to make it Linux only (or just didn't bother to port his software to Windows). As a matter of fact, developing a cross-platfrom software is much more work than concentrating on a single "ecosystem". Surely, cross-platform frameworks like Qt make this task much easier, but there still are things that require platform-specific code. Also the test effort multiplies which each platform you want to support :eek:

Having said that, for most tools that you are used to from the "Windows world" you will probably find a Linux equivalent or a cross-platfrom solution. For example, try AvxSynth or VapourSynth instead of Avisynth!

(And with "ffmpeg" or "avconv" you will be able to encode or decode pretty much any audio/video format in existence on pretty much any platfrom)