x264 compilation

[bob0r]

I have put all revisions online.
I have setup a script to check, compile and mirror the latest version.
The script will check for a new revision every hour.
Generic version of x264vfw.dll is compiled, default compile settings from x264.
A full changelog can be found in changelog.txt :eek:
Read the readme.txt for info about the builds and more info.

url: http://x264.nl

[Sharktooth]

I added some cflags that should give some speed in general:
Added -O3 in vfw
Added -march=pentium3 -mmmx -msse -mfpmath=sse
Removed -ffast-math due to crashes with sse.

The (in)famous compiler bug was generated by -fomit-frame-pointer (that was removed as well).

[LigH]

Only P3 (, P4?) and AXP builds would kick me out of business: I only have a Duron 800, which supports only MMX and ISSE. So please: Do not turn down vanilla builds, if possible.

[Sharktooth]

Vanilla builds can be downloaded at the celtic druid site or bob0r site.

[bob0r]

Originally posted by LigH
Only P3 (, P4?) and AXP builds would kick me out of business: I only have a Duron 800, which supports only MMX and ISSE. So please: Do not turn down vanilla builds, if possible.

My builds are for any 386 or higher CPU.
The default Makefile doesn't force any cpu-specific optimizations, and gcc defaults to 386-compatible.
My compiled versions ( http://x264.nl/x264/readme.txt ) only adds no debug, so it should work just fine for you.
I just did a test on a Intel Pentium II, 334MHz, 512KB and it works fine.

I think adding cpu optimalisations and not offering the default version is not very smart, as indeed some people want to test and don't have the luxury of a great new CPU, or other reasons!
As x264 is still in early development (although progress is great),
Puting more specific cpu versions online also limits the feedback from users, which at this stage seems always welcome!


@Sharktooth
Yup edit is our friend :D
Agreed!


Grab my version from:
||
\/

[Sharktooth]

Ppl who doesnt own a P3 class CPU can always download your builds or celtic druid ones. That's the reason i added the links to my original post. It's quite useless to have 3 persons doing the same things, don't you think?

[LigH]

"I love you all!" :D

[LigH]

Stooopid question: An entry like "10L" in the changelog makes me wonder if the fixed bug was too embarassing to mention...

[el divx]

Has anyone noticed that the mirror is down? Tried to download the Athlon XP build a couple of minutes ago and nothing.

[Sirber]

WFM :o

[Sharktooth]

The mirror is overloaded. Just try again later.

[buzzqw]

rundll32.exe x264vfw.dll, Configure

isn't fuction or at last in 158 for p4 and p3

BHH

[Sharktooth]

It's no longer patched.
I restarted to compile from CVS again coz b-frame pyramid and weighted prediction was added to the vfw GUI.
Maybe i can re-enable the configure option for future builds.

[LigH]

Was it necessary or useful to remove the deblocking "Threshold" slider, and leave only the "Strength"?

[Sharktooth]

The vfw gui needs a heavy restyling coz there is no space for new options.
So if someone offers to make an "akupenguin proof" redesigning of the vfw GUI, it's more than welcome since there are already some options that are left out.
Btw, i'm designing my own...

[LigH]

Indeed - inside MeGUI, there are a hell of special advanced features revealed, which have not yet be seen in x264vfw.

[WelloBanir]

Concerning the ahlon-xp- build, I guess (MMX+SSE+3DNOW required) means

CFLAGS="... -m3dnow -msse -mmmx"

or is it

CFLAGS="... -march=athlon-xp"

or is it (for nasm)

DHAVE_SSE DHAVE_MMX DHAVE_3DNOW

(as in the x264-Makefile, sorry, don't have one here now).

Maybe it is a bit of everything.
Most of these flags do not seem to make that much of a difference yet, the framerates seem to be not much higher or lower (on Linux again only).

I am just asking, because i want to build it on Linux, and therefor i am searching for Flags (C, nasm) where i can get optimal performance.

Maybe i test gcc-4.0-beta with x264.

[planet1]

Hey Sharktooth, you can also add some AMD Durons to your build list.

The Durons 0.9-1.3 GHz (Morgan Core) & 1.4-1.8 Ghz (Applebred Core) should work with all AthlonXP "accelerations", as they support MMX, SSE & 3DNow!.

The old Durons < 950 MHz (Spitfire Core) can only cope with MMX & 3DNow!.


http://www6.tomshardware.com/cpu/20040601/images/cpu_history_big.gif


Last but not least, does GCC / MinGW make any use of the MMX+ or 3DNow!+ "Extended" instructions ?

[LigH]

My Duron works well with the Tbird builds of Mplayer/Mencoder. I guess they don't use too many 3Dnow!-Ext opcodes...

[akupenguin]

There are two ways to support all these cpu extensions:
There's the hand-optimized dsp functions (e.g. motion compensation, DCT) that come in several versions. Usually all versions are included in the executable, and it decides at runtime which to use. These will never cause compatibility problems. Currently there are no SSE or 3DNOW functions used in x264 (they're just known by the cpu recognition code), only MMX and Altivec.
Then there's compiler flags, which tell gcc that it can use the extra opcodes for the C part of the program. This is where cpu-specific builds come in. Since most of the parallelizable computations are in said dsp functions, cpu extensions don't make so much difference here.

[Sharktooth]

Originally posted by WelloBanir
Concerning the ahlon-xp- build, I guess (MMX+SSE+3DNOW required) means

CFLAGS="... -m3dnow -msse -mmmx"

or is it

CFLAGS="... -march=athlon-xp"

or is it (for nasm)

DHAVE_SSE DHAVE_MMX DHAVE_3DNOW

(as in the x264-Makefile, sorry, don't have one here now).

Maybe it is a bit of everything.
Most of these flags do not seem to make that much of a difference yet, the framerates seem to be not much higher or lower (on Linux again only).

I am just asking, because i want to build it on Linux, and therefor i am searching for Flags (C, nasm) where i can get optimal performance.

Maybe i test gcc-4.0-beta with x264.
i added -march=athlon-xp -mmmx -msse -m3dnow to the athlonxp compile. asm flags are unchanged.

[Sharktooth]

Originally posted by planet1
Hey Sharktooth, you can also add some AMD Durons to your build list.

The Durons 0.9-1.3 GHz (Morgan Core) & 1.4-1.8 Ghz (Applebred Core) should work with all AthlonXP "accelerations", as they support MMX, SSE & 3DNow!.

The old Durons < 950 MHz (Spitfire Core) can only cope with MMX & 3DNow!.


http://www6.tomshardware.com/cpu/20040601/images/cpu_history_big.gif


Last but not least, does GCC / MinGW make any use of the MMX+ or 3DNow!+ "Extended" instructions ?
You can use the athlon-xp optimized version for the morgan core durons, i also added an athlon tbird and a P2 build.
CPU optimized builds may be discontinued since there's no real big speedup (optimizations are only for the C code, not the asm), only few %.

EDIT: Updated with the new builds.

[Sharktooth]

P4 prescott build with SSE3 available.
Those new builds (p2, athlon tbird, prescott) have been patched to enable the "Configure" again (rundll32.exe x264vfw.dll,Configure).

[WelloBanir]

@Sharktooth: Thanks for the information. BTW. I have a duron, 1400 MHZ, "mobilized" (mobile), with 3dnow, mmx, sse, 3dnowext.

@akupenguin: Thanks for the information, too.

[Sirber]

duron don't have SSE IIRC

[Sharktooth]

Morgan core Durons have SSE coz they're derived from the Palomino core.
If you google for "duron morgan" you will find some info and specs :)

[LigH]

I'll check what my "Spitfire" can do, one moment...
__

The TBird compile seems to work well.
The P2 build, too (as expected).
Even the Athlon XP build works... well, so it probably isn't too optimized, yet.

[Sharktooth]

Spitfire is the first duron core version. So it supports MMX+3DNOW(+), so the tbird compile should work well.
The AXP build shouldnt work coz SSE is used... weird.

[planet1]

Originally posted by Sharktooth
You can use the athlon-xp optimized version for the morgan core durons, i also added an athlon tbird and a P2 build.


I knew that, by "adding the Durons to you build list" - i meant that you could mention that the AthlonXP build was for Durons as well :p .

e.g. AMD Build {MMX,SSE,3DNow!} -> (all AthlonXPs, Duron (Morgan,Applebred), other mobile or multiprocessor CPUs)

@ Sirber

The last two core revisions of the Duron (Morgan and Applebred) have SSE functionality - only the first Duron (Spitfire core) lacks this feature.
Btw the Applebred is actually an Athlon clone but yet labeled Duron.

@LigH

in order to find all your CPUs featuresets (your Spitfire might as well support MMX+) I recommend using WCPUID:

http://www.h-oda.com

;)

[Sharktooth]

GCC does not have explicit options for MMX+/iSSE/3DNOW+ etc.
but i found that 3dnow cpus supports SSE addressing that's why maybe the SSE builds seem to work or maybe GCC didnt use SSE at all on athlon-xp builds but preferred 3dnow.

[LigH]

I know what a Duron Spitfire (800 MHz, Family 6, Stepping 1) can do: http://www.sandpile.org/80x86

Mencoder reports it verbosely, too: http://forum.doom9.org/showthread.php?s=&threadid=87567&perpage=20&pagenumber=16

[Sharktooth]

Then there are 2 possibilities as i said in my previous post.

[LigH]

Indeed, I don't care too much why it surprisingly works. Probably the compiler didn't need to use SSE instructions anywhere.

If the source authors once may decide to use highly CPU specific assembler optimized parts for optimum speed-ups, and don't rely on C compiler optimizations anymore, this may indeed change then, and Athlon XP builds won't run on my Duron anymore. But I will be prepared then.

[TripleA]

First, the disclaimer:

It's been quite a while since I used this particular bit of info or anything related to it, so it is very likely it's not accurate. Indeed, it is more likely to be inaccurate than accurate. But perhaps someone can check if it's accurate, if it's important enough to them, for whatever reason.

Now, I believe the Spitfire had a partial SSE implementation. Termed iSSE or some such, I believe. "Integer SSE", perhaps. I believe there must be posts on the forum here dealing with this from back then.

Please don't base anything substantial on this piece of info without first verifying it since it would be likely to collapse, K?

BTW, there existed 1GHz and maybe even 1.1GHz Spitfires. So the clockspeed alone is not enough to decide which is which. Use CPU-Z or something.

Also BTW, I found the reference to an x264 CODEC that would run on 386 quite funny. What unit would you measure the encoding speed on that archaic piece of silicon? FPD? :)

[LigH]

Well, e.g. "hdot264" is that slow. Nevertheless, such implementations work at all. ;)

[dragongodz]

Now, I believe the Spitfire had a partial SSE implementation. Termed iSSE or some such, I believe. "Integer SSE", perhaps
correct, just as the thunderbird Athlons also had ISSE. a little info on ISSE here
http://www.avisynth.org/IntegerSSE

BTW, there existed 1GHz and maybe even 1.1GHz Spitfires.
sorry but no there didnt. 1GHZ is when AMD decided to switch to the Morgan core for Durons. actually from what i understand there was a small amount of 950mhz Morgan core cpus made aswell but they were abandoned quickly in favour of the 1ghz chip.

[Sharktooth]

Rev 167 is coming soon.
I'm "fighting" with yasm and asm code to make 64bit vfw compiles too :)

[MacAddict]

Is it possible to put the compile information the 'about' dialog box(ie. Athlon 64 build)? I've been trying a few of the optimized builds and then get confused as to which I have installed since only the core and date are shown:)

[Sharktooth]

I dont think i will compile CPU optimized build anymore since i had only few feedbacks about the compiles speed and the differences were not so big (only few % points).
I will keep a generic build (MMX only or SSE... i have to decide) and a 64 bit build.

[IgorC]

It´s very hard to do a few compilations for each new revision. But people appritiate that a lot for example as Xvid (P4 x64 etc) (not like commercial codecs VP7 Divx). Difference between compile p2 and p4 isn´t big but it is. Each minute is important. Don´t discriminate P4, athlonXP ;) since they are mainstream ;)

[TripleA]

Originally posted by dragongodz
sorry but no there didnt. 1GHZ is when AMD decided to switch to the Morgan core for Durons. actually from what i understand there was a small amount of 950mhz Morgan core cpus made aswell but they were abandoned quickly in favour of the 1ghz chip.

I took a look at the latest datasheets and they support what you are saying. But they haven't been updated since A.D. 2001, on the other hand.

And, I clearly remember that when my 700MHz Spitfire sputtered for the last time way back when Morgan was pretty new, I could only find 1GHz Spitfires in the local market and ended up getting a 1.1GHz Duron from the States to ensure it's a Morgan.

The local market parts *could* have been remarked. But if ever the difference between a Morgan and a Spitfire is significant, I would suggest not relying on clock speed to tell which is which.

[loni_blues]

Well, as I own an Athlon Thunderbird, I would love a generic build I could use. The last p2 generic build worked like charm.
Regards!

[Sirber]

Originally posted by Sharktooth
I will keep a generic build (MMX only or SSE... i have to decide) and a 64 bit build. I'd love to have the amd64 32bit builds. It works great! :D

[pest]

my athlon thunderbird cries for a generic mmx-compile :rolleyes:

[Sharktooth]

the P2 version IS a generic MMX compile...

[pest]

thanks very much sharktooth

regards

[DeathTheSheep]

Perhaps you should correct me if I'm wrong, but each "revision" is actually changing one small aspect of the encoder, right? So, essentially, if you don't much care for the improvement listed in the log, it would be OK to skip an upgrade, correct? Or do the incremental improvements often stretch beyond those recorded in the log?

Pardon me, but I'm asking this because x264 is being upgraded one HECK of a lot more frequently than I ever had mind to expect ( ;-) holy cow-- ppl must be towin' down on this baby!!! ), and this would help a lot. Thanks:)

[Sharktooth]

Every update reflects a committed change in the source.
The changes are reported in the log, so when build xxx is made it contains that change.
So if revision xxx has no significant improvement (for example, sometimes there are revisions that affect only the CLI encoder) you can skip it.

PS - Rev. 171 is coming... :)

[Sirber]

How about 178? ;)

[Sharktooth]

Done.
178 has only minor changes and doesnt change the codec efficiency.

[rushin_911]

@Sharktooth:

Could you please compile a P4 optimized build of revision 178 :), as it might be the last one for a long time?

[Sharktooth]

The P4 build is no faster than the standard SSE build and 178 wont be the last one.

[Sirber]

Originally posted by Sharktooth
178 wont be the last one. Good to hear :D Could you add to the sticky a small howto on how to compile it ourselve? I'm a noob in that field :(

[rushin_911]

Originally posted by Sharktooth
The P4 build is no faster than the standard SSE build and 178 wont be the last one.
oh ok well I'm glad to hear that :)

[Sharktooth]

Pretty easy sirber. No need to place it in the sticky.
Just grab mingw and all the stuff needed (msys, binutils, gcc ...).
Launch msys, move to the x264 dir then to build/cygwin/ and type "make NDEBUG=1".
From there move to ../../vfw/build/cygwin/ and do the same as above.
Move to bin and grab the dll.
That's compiled with default makefiles.

[Sirber]

Trying... got mingw, msys. Getting binutils and gcc. Do I put them in msys or mingw?

[Yong]

Originally posted by Sirber
Trying... got mingw, msys. Getting binutils and gcc. Do I put them in msys or mingw?
First, install Msys to directory "C:\Msys"(example),
then install mingw32 to "C:\Msys\Mingw32",
and you are done:)

[Sirber]

It says I need GCC :) binutils seems to be already included with mingw.

[edit]

sirber@DETRITUS-WS /x264/build/cygwin
$ make NDEBUG=1
C: common/mc.c
gcc.exe: no input files
make: *** [common/mc.obj] Error 1

sirber@DETRITUS-WS /x264/build/cygwin
$ gcc --help
gcc.exe: no input files

:confused:

[Yong]

Originally posted by Sirber
It says I need GCC :) binutils seems to be already included with mingw.

[edit]

sirber@DETRITUS-WS /x264/build/cygwin
$ make NDEBUG=1
C: common/mc.c
gcc.exe: no input files
make: *** [common/mc.obj] Error 1

sirber@DETRITUS-WS /x264/build/cygwin
$ gcc --help
gcc.exe: no input files

:confused:
Strange, compile x264 is pretty simple,
May be you can try to download the latest version binutil and put it into "C:\Msys\Mingw"....:)

[Sirber]

Latest binutils is older than mingw files :(

[Yong]

Originally posted by Sirber
Latest binutils is older than mingw files :(
binutils-2.15.94-20050118-1.tar.gz,
Are you sure?
What version of Mingw you use?
The "current" version i used seems create alot of problem,
may be the "Candidate" version is recommended:)

[Sirber]

MinGW-3.1.0-1.exe
MSYS-1.0.8.exe
binutils-2.13.90-20021006-2.tar.gz
gcc-3.2.3-20030504-1.tar.gz

I will try the "candidate".

[edit]

MSYS-1.0.8.exe
MinGW-3.2.0-rc-3.exe

Works! :D

[edit 2]

Now needing nasm :(

[dinolib2]

Just compiled latest sources with (in order of installation):

- MinGW-3.2.0-rc-3
- MSYS-1.0.10 (reply Y when ask to align with MinGW)
- nasm-0.98.39 (http://sourceforge.net/project/showfiles.php?group_id=6208&package_id=47034) (copy nasm.exe in /MinGW/bin)

That's all! :)

Look at x264.nl (http://mirror01.x264.nl/x264/readme.txt) for details

bye, Dino

edit: added link to nasm
edit2: msysDTK is not necessary (Sirber is right)

[Sirber]

I did not need msysDTK-1.0.1.

[Sirber]

I'd like to use: -O3 -march=athlon-xp -pipe -fomit-frame-pointer -mmmx -msse -m3dnow -mfpmath=sse -funroll-loops -msse2

but there are no ./configure and make don't like them. How? :(

[celtic_druid]

Edit the makefile adding -march=athlon-xp, etc.

[el divx]

Just tried to build it but when I go to "x264/build/cygwin", type "make" and then hit enter, it returns the following:

make: *** No rule to make target `common/mc.obj', needed by `libx264.a'. Stop.

Is it something related to the makefile?

[Magno]

May I ask why the decoder in x264 isn't working, even not compiling?

Just curiosity, because the coder has a built-in decoder to use the reconstructed samples as prediction to next decoded frames, so it only would be necessary to add code for CAVLC and CABAC decoding.

Anyone knows?

[LigH]

Not a complete answer, but a suspicion:

Due to the possible heavy use of (even rather wide, and multiple) forward and backward prediction, it is not easy to support VfW decoding of H.264 - just think of the "B-Frame lag" in XviD when using B-VOPs: Those AVIs either cannot be decoded sequentially, or have to be restructured (packed bitstreams).

So I guess: The AVI container appears to be one problem, and the VfW architecture another one.

DirectShow filters instead seem to be not bound to similar restrictions, they must have more "degrees of freedom" when decoding such heavily temporally depending material.

[Sirber]

Working! Added:ifdef AMD64
CFLAGS += -march=athlon-xp
CFLAGS += -mfpmath=sse
CFLAGS += -msse2
endif
make clean && make NDEBUG=1 AMD64=1

:D

[edit]

crashing! :D lol

ifdef AMD64
CFLAGS += -mmmx
CFLAGS += -msse
CFLAGS += -msse2
CFLAGS += -m3dnow
endif
Even this crash :confused: Standart build works though

[Sirber]

Remove:
CFLAGS += -ffast-mathAdd:
ifndef AMD64
CFLAGS += -ffast-math
endif
ifdef AMD64
CFLAGS += -march=athlon-xp
CFLAGS += -mfpmath=sse
CFLAGS += -mmmx
CFLAGS += -msse
CFLAGS += -msse2
CFLAGS += -m3dnow
endifmake NDEBUG=1 AMD64=1

[Sharktooth]

You can't use -ffast-math in conjuction with -mfpmath=sse or it will crash (gcc...).
Also don't try to add -fomit-frame-pointer or you will get screwed encodings.
Also use -march=athlon64.

[Sirber]

-march=athlon64

never saw that in GCC docs... gonna try :)

[Sharktooth]

Ensure you have gcc 3.4.x

[video]

Originally posted by Sirber
I'd like to use: -O3 -march=athlon-xp -pipe -fomit-frame-pointer -mmmx -msse -m3dnow -mfpmath=sse -funroll-loops -msse2

but there are no ./configure and make don't like them. How? :(

if you ar in a windows command enviroment, you may try this before configure:

set CFLAGS="-O3 -march=athlon-xp -pipe -fomit-frame-pointer -mmmx -msse -m3dnow -mfpmath=sse -funroll-loops -msse2"
set CXXFLAGS="-O3 -march=athlon-xp -pipe -fomit-frame-pointer -mmmx -msse -m3dnow -mfpmath=sse -funroll-loops -msse2"

[Sharktooth]

-fomit-frame-pointer = NO WAY.
Tried it and it produces artifacts.

-pipe = USELESS.
It's only for speed up the compiling process.

-msse2 = MAYBE but -march=athlon-xp? won't work on athlon xp CPUs...
I already built SSE2 binaries and even SSE3 but there was no significative speedup. The heavy parts are done in assembly so those flags wont make it faster...

[Sirber]

I didn't know there was a -march=athlon64, so I set athlon-xp. I'm doing this for fun and to learn, I don't aim public release.

[video]

Originally posted by Sharktooth
-fomit-frame-pointer = NO WAY.
Tried it and it produces artifacts.

-pipe = USELESS.
It's only for speed up the compiling process.

-msse2 = MAYBE but -march=athlon-xp? won't work on athlon xp CPUs...
I already built SSE2 binaries and even SSE3 but there was no significative speedup. The heavy parts are done in assembly so those flags wont make it faster...

Sharktooth You are right. I've just showed a trick how to tell configure to use specific compilation flags. I feel, anyway that using special flags don't help too much, 'coz critical parts already in asm. Remained c parts can be speed up, with a specific vectorizing compiler, I mean compiler what can do MIMD scheduling optimal for the processor's ROB - or alternatively rewrite some remained parts to asm or use BLAS.

Would like me to do a run on x264 with PathScale's EkoPath compiler? but EkoPath available only for linux.

[Sirber]

@video

Thanks for the hint, will be better than to mod the Makefile :D

[Sharktooth]

Originally posted by video
Sharktooth You are right. I've just showed a trick how to tell configure to use specific compilation flags. I feel, anyway that using special flags don't help too much, 'coz critical parts already in asm. Remained c parts can be speed up, with a specific vectorizing compiler, I mean compiler what can do MIMD scheduling optimal for the processor's ROB - or alternatively rewrite some remained parts to asm or use BLAS.

Would like me to do a run on x264 with PathScale's EkoPath compiler? but EkoPath available only for linux.
Well, i dont think it will be much faster. Btw, if you want to test it you're free to do it but usually x264 CLI is not of common use... mencoder is a much better solution.

[video]

Originally posted by Sharktooth
mencoder is a much better solution.
mencoder is reliant so much on a specific compiler and assembler. I feel it will be a pain in the ass to achieve compiling mplayer with ekopath, but i may try it :) However today x264's encoding quality is the major issue, not it's speed.

[Sharktooth]

It's incomplete... but it is the 2nd best AVC encoder after NeroDigital.

[video]

Originally posted by Sharktooth
It's incomplete... but it is the 2nd best AVC encoder after NeroDigital.

http://forum.hwsw.hu/html/emoticons/offtopic.gif I'm sorry, I didn't mean flaming on x264

[Sharktooth]

You didn't. I meant it's not the best encoder, but it has a relatively high quality even if it is incomplete.

[ChronoCross]

well I decided to compile the default version of the vfw. and the resulting dll was over 1000k when the same dll in the p3 version download of the mainpage is only about 450. what's up with that? I compiled it under cygwin using the makefile provided.

[dinolib2]

make NDEBUG=1
Compile x264 lib with this option

edit:completed answer

[Sharktooth]

The dll is now some kbytes smaller. It's barely 400kbytes (exactly 397kb for my SSE compile).

[Sirber]

Originally posted by Sharktooth
The dll is now some kbytes smaller. It's barely 400kbytes (exactly 397kb for my SSE compile). Optimization? :D UPX? :(

[Sharktooth]

UPX? no.
Maybe because some code has been rewritten.

[Sirber]

Mine is 1022KB :confused:
CFLAGS="-O3 -march=athlon64 -m32 -pipe -mfpmath=sse -funroll-loops"
CXXFLAGS="-O3 -march=athlon64 -m32 -pipe -mfpmath=sse -funroll-loops"
Same size whitout those flags

[dinolib2]

1200K is the size of the debug version...

I've already posted: try to compile with
make NDEBUG=1

does it solve your problem?

bye

[Sirber]

oh, forgot :D Thanks!

[Sharktooth]

I updated the install script to add the x.264 configuration link in the start menu.

[Sharktooth]

Installed commandline svn in my MSYS so my builds now show the svn version correctly (you can find it in the "about" box)

[Sharktooth]

Thanks! i was just going to ask to split the thread :D

EDIT: If you have any requests for my builds please post them here.

[bob0r]

I have used: ftp://sources.redhat.com/pub/pthreads-win32/pthreads-w32-2-6-0-release.exe

Did:
make clean GC-static

then:
copied libpthreadGC2.a > G:\MinGW\lib
copied pthread.h > G:\MinGW\include
copied sched.h > G:\MinGW\include

Now my make result is:

gcc -o x264.exe x264.o libx264.a -lvfw32 -lm4systems_static -lwinmm -lpthreadGC2 -s
libx264.a(encoder.o)(.text+0x394d):encoder.c: undefined reference to `_imp__pthread_create'
libx264.a(encoder.o)(.text+0x3982):encoder.c: undefined reference to `_imp__pthread_join'
collect2: ld returned 1 exit status
make: *** [x264.exe] Error 1

What have i done wrong?
Meaning, just explain me the full and correct way of handling this :(

[Sharktooth]

You have to place the pthreadGC2.dll in G:\MinGW\lib

EDIT: ehrr... not true. libpthreadGC2.a is enaugh.

[bob0r]

You have to place the pthreadGC2.dll in G:\MinGW\lib

Done that, still the same, i heard i have to "link it", how to?

[Sharktooth]

-L (uppercase) option

[bob0r]

-L (uppercase) option

Remember i have no idea what to do, you have to explain me what to do step by step

bob0r
:stupid:

All i know is:
cd x264
configure --enable-vfw --enable-avis-input --enable-mp4-output --enable-pthread
make clean
make

So i have no idea where and how to use -L

[Sharktooth]

remove --enable-vfw if you want multithreading
it should work

[bob0r]

remove --enable-vfw if you want multithreading
it should work

You aren't reading what i said/asked.... i have NO idea how or where to use "-L " Thus i am asking your help! I have NO idea what do to with -L and pthreadGC2.dll

[LigH]

Just a guess: Maybe "-L..." instead of "-l..." in

gcc -o x264.exe x264.o libx264.a -lvfw32 -lm4systems_static -lwinmm -lpthreadGC2 -s

[Sharktooth]

I didnt read bobor copied the files in mingw/libs and mingw/include. Sorry, -L is not necessary. However --enable-vfw must be removed to compile x264 CLI using --enable-pthread.
@bobor: just use the configure command line you posted above without --enable-vfw and adding --extra-ldflags=-lpthreadGC2 (this is for linking pthreads) and it will work.

[ak]

Just a guess: Maybe "-L..." instead of "-l..." in
Nope '-L' is for path, '-l' is for lib name, so if you link against '/some/path/libfoo.a', you either pass absolute name or add '-L/some/path -lfoo'

As temporary measure sth like this should do: http://4nykey.nm.ru/tmp/VFW_PTHR

'patch -p0 < VFW_PTHR' will apply it, 'patch -p0 -R < VFW_PTHR' will revert back

[Sharktooth]

Nope '-L' is for path, '-l' is for lib name, so if you link against '/some/path/libfoo.a', you either pass absolute name or add '-L/some/path -lfoo'

As temporary measure sth like this should do: http://4nykey.nm.ru/tmp/VFW_PTHR

'patch -p0 < VFW_PTHR' will apply it, 'patch -p0 -R < VFW_PTHR' will revert back
Sure, i suggested -L coz i didnt read he already copied the files in the correct dirs...
In that case he doesnt need -L.

[bob0r]

Ok Sharktooth explained it all to me now.

What i do is:
cvs -z3 -d:pserver:anoncvs@sources.redhat.com:/cvs/pthreads-win32 co -P pthreads
make clean GC
copied libpthreadGC2.a > G:\MinGW\lib
copied *.h > G:\MinGW\include
configure --enable-avis-input --enable-mp4-output --enable-pthread

(1) Note that make clean GC is NOT make clean GC-static, which gives us the following error:

gcc -o x264.exe x264.o libx264.a -lvfw32 -lm4systems_static -lwinmm -lpthreadGC2 -s
libx264.a(encoder.o)(.text+0x394d):encoder.c: undefined reference to `_imp__pthread_create'
libx264.a(encoder.o)(.text+0x3982):encoder.c: undefined reference to `_imp__pthread_join'
collect2: ld returned 1 exit status
make: *** [x264.exe] Error 1


(2) Also when you enable vfw with configure ( --enable-vfw ) x264vfw.dll will not compile, because it does not "allow" pthreads yet, which means you have to compile vfw and cli MT seperately.

The first problem seems to be a pthreads problem, the second problem is hopefully something pengvado(irc name) can fix quickly, so we can have all versions by just using:
configure --enable-vfw --enable-avis-input --enable-mp4-output --enable-pthread
make

Thanks all!
make clean

[celtic_druid]

Looks like x264 in ffdshow just got pthread support. Also looks there have been some updates in regards to gcc compiling.

[Ajaja2005]

I use MSVC .NET 2003 + nasm for compiling x264. In my tests msvc builds are faster than gcc (mingw) builds for my Athlon Barton. But I have one small problem. Is it possible to use GPAC library in this case for mp4 support?

[bob0r]

@celtic_druid & Sharktooth

I tried Sharktooth's VFW multithread build, the vfw patch indeed shows the option pthread, but vdub crashes the minute you change 1 to any higher value.

This is the exact same i had with my own compile.
You may have overlooked it, but you should get the same error as before:


Creating library file: x264vfw.dll.a
G:/msys/1.0/home/user/x264_pthread/vfw/build/cygwin/../../../libx264.a(encoder.o)(.text+0x394c):encoder.c: undefined reference to `pthread_create'
G:/msys/1.0/home/user/x264_pthread/vfw/build/cygwin/../../../libx264.a(encoder.o)(.text+0x3980):encoder.c: undefined reference to `pthread_join'
collect2: ld returned 1 exit status
make[1]: *** [x264vfw.dll] Error 1
make[1]: Leaving directory `/home/user/x264_pthread/vfw/build/cygwin'
make: *** [x264vfw.dll] Error 2

(ofcourse your paths are different)

If one of you guys truely managed to compile x264 cli AND vfw with pthreads
( configure --enable-vfw --enable-avis-input --enable-mp4-output --enable-pthread )
please tell us how, and x264 can be updated, if not, we have to wait patiently :)



Extra for general readers:
X264.exe (cli) does infact work, but only when pthread compiled as: make clean GC.
make clean GC-static also does compile, but x264.exe fails to work (probably pthread bug)

make clean GC does mean you require an extra .dll file (pthreadGC2.dll), Sharktooth includes this with his installer to your system32 directory.

[Sharktooth]

bobor, my builds (both CLI and VFW) work with threads > 1...
it crashes only with GC-static.
Ensure you have the correct pthread library builds in your paths.

[bob0r]

Great, it works indeed!
Good work, i hope so see it updated for x264 soon, :thanks:

For anyone who wants to try it: Just wait, because i still have no idea what sharktooth did exactly, and i think to be honest, nor did he, hehehe :D

[celtic_druid]

As said, with phtreads statically linked it crashes. Guess maybe the method I came up with for getting it to link statically is floored?. x264 in ffdshow works fine though as does x264 if you link dynamically.

If you get "undefined reference to `pthread_join'" then you are linking statically. The problem is VfW not linking to libpthread or linking in the wrong order.

[Sharktooth]

i managed to link vfw to pthreads and it's working. But as CD said, static links generate crashes. I think it's a problem with pthreads too.
Btw the problem lies in the configure script. It does not propagate --extra-xxflags to the vfw/build/cygwin/config.mak

[akupenguin]

Btw the problem lies in the configure script. It does not propagate --extra-xxflags to the vfw/build/cygwin/config.mak It does for me...

[Sharktooth]

My configure line looks like this: ./configure --enable-vfw --enable-avis-input --enable-mp4-output --enable-pthread --extra-cflags=-I../gpac/include --extra-ldflags=-L../gpac/bin/gcc --extra-cflags=-march=pentium2 --extra-cflags=-mmmx --extra-cflags=-O4 --extra-cflags=-finline-functions --extra-cflags=-funroll-loops --extra-cflags=-ffast-math --extra-cflags=-fomit-frame-pointer --extra-cflags=-I../pthread --extra-ldflags=-L../pthread

and the vfw/build/cygwin/config.mak after the configure looks like this:
CFLAGS=-I../pthread
LDFLAGS=-L../pthread -s

so something was not being propagated... only the last "--extra-xxflags=" value was written in the vfw/build/cygwin/config.mak ...

[celtic_druid]

Try:


./configure --enable-vfw --enable-avis-input --enable-mp4-output --enable-pthread --extra-cflags="-I../gpac/include -march=pentium2 -mmmx -O4 -finline-functions -funroll-loops -ffast-math -fomit-frame-pointer -I../pthread" --extra-ldflags="-L../pthread -L../gpac/bin/gcc"

[Sharktooth]

uhm... it works... the flags are propagated but it doesnt compile (the usual linking problem with pthreads).

actually with this patch it works (both static and dynamic libs - but static linking crashes at runtime):
--- vfw/build/cygwin/Makefile Thu Jun 2 11:49:32 2005
+++ M2 Thu Jun 2 11:51:57 2005
@@ -38,7 +38,7 @@

# Constants which should not be modified
# The `mingw-runtime` package is required when building with -mno-cygwin
-CFLAGS += -I$(DIR_SRC)/w32api -I$(DIR_INC)
+CFLAGS += -I$(DIR_SRC)/w32api -I$(DIR_INC) -DPTW32_BUILD -DHAVE_PTHREAD=1
CFLAGS += -D_WIN32_IE=0x0500
CFLAGS += -mno-cygwin

@@ -50,7 +50,7 @@
# Compiler flags for linking stage
##############################################################################

-LDFLAGS += -L$(DIR_LIB) -lx264
+LDFLAGS += -L$(DIR_LIB) -lx264 -lwinmm -lpthreadGC2 -lwsock32

##############################################################################
# Rules

[celtic_druid]

From recollection it works without -DPTW32_BUILD (static or otherwise). But yeah if you don't add the lib to the make file, then it doesn't compile. I guess it is because lpthread has to be linked in the right order.

Also you should only need -lwsock32 if you are using the static libpthread. Does this mean that you got it to work without crashing?

[Sharktooth]

no.. static linking pthreads make x264 crash at runtime with threads > 1.

[bob0r]

Ok, i updated pthread: cvs up
make clean GC

clean x264 248
added sharktooth patch: patch -p0 < VFWthreads.diff

Manual edit: x264_pthread\vfw\build\cygwin\config.mak:

CFLAGS += -DPTW32_BUILD -DHAVE_PTHREAD=1
LDFLAGS += -lwinmm -lpthreadGC2 -lwsock32 -s

And edit x264_pthread\vfw\build\cygwin\Makefile:
changed:
CFLAGS += -I$(DIR_SRC)/w32api -I$(DIR_INC)
to:
CFLAGS = -I$(DIR_SRC)/w32api -I$(DIR_INC)
I removed the + from +=

same for:
LDFLAGS += -L$(DIR_LIB) -lx264
to:
LDFLAGS = -L$(DIR_LIB) -lx264

x264vfw.dll does compile and seems to work.
Also when my config.mak looks like this:
LDFLAGS += -lpthreadGC2 -s

x264vfw.dll does compile and still seems to work. (yes i removed a lot of flags and CFLAGS)


.... When i try all of the above with: make clean GC-static, nothing compiles, so also with full config.mak:
CFLAGS += -DPTW32_BUILD -DHAVE_PTHREAD=1
LDFLAGS += -lwinmm -lpthreadGC2 -lwsock32 -s

i get:
Creating library file: x264vfw.dll.a
G:/msys/1.0/home/user/x264_pthread/vfw/build/cygwin/../../../libx264.a(encoder.o)(.text+0x38ea):encoder.c: undefined reference to `_imp__pthread_create'
G:/msys/1.0/home/user/x264_pthread/vfw/build/cygwin/../../../libx264.a(encoder.o)(.text+0x391f):encoder.c: undefined reference to `_imp__pthread_join'
collect2: ld returned 1 exit status
make[1]: *** [x264vfw.dll] Error 1
make[1]: Leaving directory `/home/user/x264_pthread/vfw/build/cygwin'
make: *** [x264vfw.dll] Error 2


I am by all means no expert, i am just trying some things, to learn and hopefully clear some things up.... What is the verdict?


Edit:
I have found out, that with make clean GC-static, the new updated pthread, also does no longer compiles with the test files (x264.7z) sharktooh send me, which means, pthread now "logically" does not compile x264 with pthread, by simple giving the same output again:

Creating library file: x264vfw.dll.a
G:/msys/1.0/home/user/x264/vfw/build/cygwin/../../../libx264.a(encoder.o)(.text+0x5f14):encoder.c: undefined reference to `_imp__pthread_create'
G:/msys/1.0/home/user/x264/vfw/build/cygwin/../../../libx264.a(encoder.o)(.text+0x5f49):encoder.c: undefined reference to `_imp__pthread_join'
collect2: ld returned 1 exit status
make[1]: *** [x264vfw.dll] Error 1
make[1]: Leaving directory `/home/user/x264/vfw/build/cygwin'
make: *** [x264vfw.dll] Error 2
cp: cannot stat `x264.exe': No such file or directory
cp: cannot stat `vfw/build/cygwin/bin/x264vfw.dll': No such file or directory


So x264 + pthread no longer will compile with GC-static, which did not work (crashed x264) anyway!

[bob0r]

Problem of pthread solved:
------------------------------------------------------------------------
r250 | titer | 2005-06-05 12:17:10 +0200 (Sun, 05 Jun 2005) | 3 lines

Use win32 native threads (you still have to --enable-pthread to use
them, though)

------------------------------------------------------------------------
pthread is no longer used! :devil:

I also heard win32 native threads can be enabled in x264 by default in the future, good news for Sharktooth's VFW-GUI :eek:

[leowai]

I'm wondering anyone of you experience problem with the compiled x264 vfw under MinGW32?

I did experience problem from the vfw where the "About" dialog can not be shown. This occurs in the OS (I tried in win2k, winxp) which uses "Chinese Simplified" as the default language for non-Unicode programs (this can be changed in the control panel -> Regional & Languages Settings -> "Language for non-Unicode programs"). There will no be a problem IF "English" is used for non-Unicode programs (You can try this out out. :)).

I use the Resource Hacker to check on the x264vfw.dll file, it shows as follow:
http://img236.echo.cx/img236/43/resourcebefore4rb.png (http://www.imageshack.us)

As you can see, the "Visit Homepage" button in resource (and the third line in the window) can't be read correctly and I found the cause is from the resource.rc in line 225. There are unicodes in the line!

CTEXT "Copyright 2005 Laurent Aimar, Justin Clay, Min Chen,\nEric Petit, M錸s Rullg錼d, Loren Merritt\n\nThis program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation",
IDC_STATIC,7,47,199,51

So I move the portion of the codes in resource.rc a few lines lower and just before the "END" at line 231 as follow:

LTEXT "x264 - H.264/MPEG-4 AVC codec",IDC_X264,53,8,145,8,
SS_CENTERIMAGE
CTEXT "Copyright 2005 Laurent Aimar, Justin Clay, Min Chen,\nEric Petit, M錸s Rullg錼d, Loren Merritt\n\nThis program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation",
IDC_STATIC,7,47,199,51
END

So the line with unicode chars is read after all others resources. This solves the problem of not showing "About" dialog box of vfw after changes above. The resource hacker shows the correct "About" dialog as:
http://img298.echo.cx/img298/3509/resourceafter5qw.png (http://www.imageshack.us)

As a result, I propose to make some changes to the resource.rc file so that it works under MinGW32 with non-English language used for non-Unicode programs.

Thanks.

regards,
leowai

[Sharktooth]

http://www.webalice.it/f.corriga/x264/x264vfw_unicode_fix.diff

submitted to akupenguin. just wait until he commits it...

[leowai]

@Sharktooth,

Thanks for your attention. :)

As an additional information, the bug only occurs in MinGW32 but not in cygwin in my OS using chinese language for non-unicode programs.

Just another minor problem in the vfw? The compiled vfw shows one of the author's name as "M?ns Rullg?rd" instead of "Måns Rullgård" (as shown in the author list from http://www.videolan.org/x264.html).

Have a quick search through about the windres function, it seems like reading unicode chars in *.rc is a known bug for windres. :(

regards,
LeoWai

[Sharktooth]

Nothing i can do then, sorry. but at least in my rev263A build the Visit Homepage button should work now.

[leowai]

@Sharktooth,
Nothing to say sorry. You've tried your best for this. :)

*Just for your information:*
I've found the cause where the char å (0xE5) not disappear correctly. It's because my OS is set to Chinese with non-unicode program (I think my OS will read any char as double byte if the char is greater ascii 128, which is 0x80).

See the reason? There is two å (0xE5) chars in the "resource.rc" file. As a result, when compiling with "windres", it reads char "ån" and char "år" as one char. This produced a "blank" char in vfw about dialog (see the picture I attached in previous thread).

So, I think it'll be better to use cygwin to compile the source if you're using non-English language for non-unicode program in your OS. MinGW32 probably will produce incorrect information of author's name in the "About" dialog box (even if there is no errors after the vfw patch :)). I believe this is because MinGW32 uses windows native reading method while cygwin uses unix based reading method.

So, you don't surprise if you see the author's name as "M?ns Rullg?rd" instead of "Måns Rullgård", in my case. :)

Cheers. :)

regards,
leowai


PS: Also note that, if you use VC++ to compile the source (not the case for cygwin and MingGW), the information in the "About" dialog will be truncated to a max of 256 chars. You will found your vfw with trancuated text at the end as "... Free Software Found??". For the users with VC++, you've to seperate the static text for Author and the terms and conditions to avoid this problem.

[el divx]

Anyone that can help with this:
make -C vfw/build/cygwin
make[1]: Entering directory `/home/God Of War/x264/vfw/build/cygwin'
make[1]: *** No rule to make target `codec.obj', needed by `x264vfw.dll'. Stop.

make[1]: Leaving directory `/home/God Of War/x264/vfw/build/cygwin'
make: *** [x264vfw.dll] Error 2

I get it every time I try to compile vfw. I've checked the makefile and it seems to include "codec.c".

[Sharktooth]

did you ./configure?
however:
./configure --enable-vfw
make

there are also other usefull options and features (for CLI) that can be set up/enabled: use ./configure --help. Also if you dont use the "standard" metod (posted above) remember you have to compile the CLI (core) before you can compile the vfw dll.

[el divx]

I did use ./configure --enable-vfw & make. Problem is that for a strange reason the linux lib compiles perfectly. Oh, and I'm using the latest version of cygwin if that is of any help.

Here's what the config.mak looks like:
prefix=/usr/local
eprefix=${prefix}
bindir=${eprefix}/bin
libdir=${eprefix}/lib
includedir=${prefix}/include
ARCH=X86
SYS=CYGWIN
CC=gcc
CFLAGS=-Wall -I. -O3 -ffast-math -D__X264__ -mno-cygwin -DHAVE_MMXEXT -DHAVE_SSE -DARCH_X86 -DSYS_CYGWIN -s -fomit-frame-pointer
LDFLAGS= -mno-cygwin -s
AS=nasm
ASFLAGS=-f win32 -DPREFIX
VFW=yes
EXE=.exe
VIS=no
default: x264vfw.dll


Lastly, OS is Win XP Pro SP2, CPU Athlon XP 2700+ Thoroughbred(I changed the multiplier and it now has become a 2800+), MEM 2x512MB Transcend.

[leowai]

el divx,
You can try MinGW (www.mingw.org). The compilation instructions is available from bob0r's website (http://mirror01.x264.nl/x264/readme.txt).

In short, you need following programs (without avs & mp4 support) to be installed:
1. MinGW-3.2.0-rc-3.exe
2. MSYS-1.0.10.exe
3. nasm-0.98.38-win32.zip (renamed nasm.exe to nasmw.exe into: C:\MinGW\bin)

[el divx]

This time I used MinGW and got, what a surprise, this:
ranlib libx264.a
make -C vfw/build/cygwin
make[1]: Entering directory `/home/God Of War/x264/vfw/build/cygwin'
make[1]: *** No rule to make target `codec.obj', needed by `x264vfw.dll'. Stop.
make[1]: Leaving directory `/home/God Of War/x264/vfw/build/cygwin'
make: *** [x264vfw.dll] Error 2Any help?

BTW, how do you cross-compile it on linux(I have SuSE Linux 9.3 Pro dual boot on my machine).

[leowai]

el divx,
Would you try a clean compilation by running following commands in MinGW in sequences?
>make distclean
>./configure --enable-vfw
>make

[el divx]

Tried now and same thing happened.

[leowai]

New (re-written) gpac is out.
http://forum.doom9.org/showthread.php?p=686757#post686757

Bad news is the new release consists different source structure and file names. Will the source of x264 be updated to get latest mp4 output format supported?

Since mp4 output works fine now, just want to know whether it will be updated or not (and I know it won't be so soon).

[leon_id]

Hi,

downloaded last sources from http://www.webalice.it/f.corriga/x264/X264_rev275_src.7z
encounter two small problems while trying to compile them

1) ./common/set.c doenst included in libx264.lib build under win32
2) ./vfw/codec.c, function compress_query() in comparision with fourcc uses inhdr->biCompression, i think outhdr must be used instead.

[TheUnforgiven]

i got mingw, msys and nasm.
nasm is in mingw bin folder
i did configure then make
the following error appears:

...
....
.....
nasm -f win32 -DPREFIX -o common/i386/dct-a.o common/i386/dct-a.asm
0 [main] make 3116 proc_subproc: Couldn't duplicate my handle<0x7E4> for pid 0, Win32 error 6
10602 [main] make 3116 proc_subproc: Couldn't duplicate my handle<0x7E4> for pid 0, Win32 error 6
make: nasm: Command not found
make: *** [common/i386/dct-a.o] Error 127

any help?

[Birdy1]

Did you rename nasmw.exe to nasm.exe?

[TheUnforgiven]

successfully compiled.
the problem was wrong version of nasm. i was using nasm for dos32. i thought this is windows :p didnt notice the win32 version.
thanx birdy for the response.

[ddnt]

For recent versions, including version 281, I can't get them compiled under cygwin and VC6 with default building configuration, while configure.sh can solve the problem.
I got messages like those:
libx264.lib(encoder.obj) : error LNK2001: unresolved external symbol _x264_cqm_parse_file
libx264.lib(encoder.obj) : error LNK2001: unresolved external symbol _x264_cqm_init

[Ajaja2005]

2ddnt
Add .\common\set.c and .\matroska.c to the project for MSVC compiling.

[Kopernikus]

I try to compile x264 with --enable-avis-input, the compilation is successful, but when I try to execute x264.exe something like "The procedure entry point wasnt found in msvfw32.dll AVIFileExit()"

If i compile without --enable-avis-input the error doesnt occur.

I`m using MinGW and MSys (don`t know which Version)

OS: Win XP Home SP1

The dll is in my path.

[TheUnforgiven]

is there a specific version of GPac i need to use?
I got the latest one but i am unable to compile with MP4 output.
where exactly should i put the gpac source?
should i compile it before compiling x264?
thank you

[celtic_druid]

You need a version prior to 0.4.0, one the produces libm4systems_static.a instead of libgpac_static.a that is untill x264 is updated to the new API.

You need to compile the GPAC's lib first. You also need the include files.

[TheUnforgiven]

compile done successfully.
:thanks:
I wonder if it is possible to compile x264 under intel compiler and wether it gives good speed gains?

[Sharktooth]

:search:

[LigH]

rel285 @ x264.nl ;)

[bob0r]

@sharktooth

My old gpac 0.3.x configure was:
configure --disable-jpeg --disable-xvid --disable-mad --disable-faad --disable-ffmpeg --disable-png

I kept doing cvs up, untill gpac became 0.4.x, i could still compile 0.4.x.
Now when i ran configure --disable-jpeg --disable-xvid --disable-mad --disable-faad --disable-ffmpeg --disable-png (or configure alone)
I cant compile on mingw/msys anymore.

Can you please advice me how to compile gpac 0.4.x?

[celtic_druid]

If it is just for x264 then just run ./configure && make lib.

[bob0r]

@celtic_druid

Thanks that worked!
(i used to run just make)

btw look at the New ffdshow build (?) thread please

You know we love you right? RIGHT?! ;)

[Sharktooth]

compiling gpac 0.4.x with gcc is still problematic. i gave up... i only make the lib.

[celtic_druid]

I was able to compile most of it last time I tried. Just a problem with a few plugins from recollection. I find it easier just to use MSVC though.

[leowai]

compiling gpac 0.4.x with gcc is still problematic. i gave up... i only make the lib.
gpac static Lib should be enough to do the job for x264 with mp4 output support.

However, l would like to share my way to compile gpac succesfully to Sharktooth or others fail to compile gpac project. There is NO guarantee of success but that's how it works on my platform and it should work on yours (I think)!. And I hope you guys don't mind it's slightly off topic here. :D

DirectX dx_hw.dll is used to be the last module I can't compile successfully (before gpac CVS 23rd Sep 2005, see end of the thread for latest gpac CVS). It seems like it can detect DirectX in my MinGW but can't find the DirectX libraries correctly when compiling the DirectX sources. Therefore, I make following patch to force predefined DirectX lib and include folder to be used for the compilation.

Index: configure
===================================================================
RCS file: /cvsroot/gpac/gpac/configure,v
retrieving revision 1.9
diff -u -r1.9 configure
--- configure 23 Sep 2005 12:23:43 -0000 1.9
+++ configure 26 Sep 2005 04:18:22 -0000
@@ -703,6 +703,8 @@

if $cc -o $TMPO $TMPC 2> /dev/null ; then
has_mingw_directx="yes"
+dx_include="$dxsdk_path/include"
+dx_lib="$dxsdk_path/lib"
else
dx_include="$dxsdk_path/include"
dx_lib="$dxsdk_path/lib"


Following configuration settings are used:

./configure --cc=gcc --dxsdk-path=c:/MinGW --disable-amr-nb-fixed --disable-amr-nb --disable-amr-wb --disable-amr --disable-debug --disable-oss-audio --disable-opengl --disable-ssl --use-js=no --use-ft=no --use-jpeg=no --use-png=no --use-faad=no --use-mad=no --use-xvid=no --use-ffmpeg=no


I just found some problem for me to compile latest gpac CVS (says 26th Sep 2005). I don't remember I installed any WXWIDGETS under MinGW but the configure script says it is detected! Anyone experience the same thing here? :confused: :confused: Compilation fails with no doubt. This is the additional patch I used to disable the compilation of "osmo4_wx" application.

Index: applications/Makefile
===================================================================
RCS file: /cvsroot/gpac/gpac/applications/Makefile,v
retrieving revision 1.3
diff -u -r1.3 Makefile
--- applications/Makefile 31 Aug 2005 16:19:45 -0000 1.3
+++ applications/Makefile 26 Sep 2005 05:06:18 -0000
@@ -10,11 +10,11 @@
V4STUDIODIR=
INSTDIRS=mp4client osmozilla

-ifeq ($(USE_WXWIDGETS), yes)
-APPDIRS+=osmo4_wx
-V4STUDIODIR=V4Studio
-INSTDIRS+=osmo4_wx
-endif
+#ifeq ($(USE_WXWIDGETS), yes)
+#APPDIRS+=osmo4_wx
+#V4STUDIODIR=V4Studio
+#INSTDIRS+=osmo4_wx
+#endif

ALLDIRS=$(APPDIRS)

Hope these information helps.

[celtic_druid]

Well without Osmo4 do you need any of the plugins? You could just run make apps or whatever it is.

[leowai]

Well without Osmo4 do you need any of the plugins? You could just run make apps or whatever it is.
True...
So for the settings above, I will only need compile certain part of gpac project rather than all (lib, apps & mods).

i.e.

./configure && make lib && make apps

* use "make apps" is to get "MP4Box.exe" compiled.

[Sharktooth]

thanks for the info but i think i'll stick to the lib compilation. if i need the other stuff i'll just fire up visual studio and build the rest...

[Kurtnoise]

I think there is a missing header file in the last x264 revision (afxres.h to build the vfw version), right ? I've got an error message when I made a compile with vfw enabling.

[celtic_druid]

http://forum.doom9.org/showthread.php?p=715033&highlight=afxres.h#post715033

[Kurtnoise]

mmh...I've the last minGW build and "make clean" doesn't resolve the problem for me. So, I replaced afxres.h by winres.h and it works fine now.

[bob0r]

http://www.mingw.org
http://www.mingw.org/download.shtml
w32api-3.3.tar.gz
http://prdownloads.sourceforge.net/mingw/w32api-3.3.tar.gz?download

Copy/overwrite lib and include dir to mingw/

I had the same problem (Thank Sharktooth ;) )

P.S. do a clean SVN checkout....

[hpn]

@celtic_druid, Sharktooth, bobOr and the others.

Probably no one will want to do this, but....if someone has 10 spare minutes could you please compile and post here a very detailed step by step guide for dummies (like me) on how to compile x264 under Windows XP (or at least fix and complete the example guide below). I don't need to understand how exactly it works, rather just blindly follow the steps. I've read the whole thread and made some compilation attempts, but a few things are still eluding me (the GPAC thing?). If more than one posts his version of such a guide, it would be even better. I can see x264vfw.dll and x264.exe always have different sizes, depending on who compiles them (St, bobOr or CD), so I guess different compilation procedures (parameters) are used.

A HUGE thanks in advance!


Example Guide:

Note: Most of this example guide is incorrect, including steps order, unnecessary steps, software versions, configure options etc. It's just an example of how to explain things to complete newbies (if you want the real thing check the final guide a few posts below).

step 1. Download and install TortoiseSVN from
http://prdownloads.sourceforge.net/tortoisesvn/TortoiseSVN-1.2.4.4479-svn-1.2.3.msi?download

step 2. To download the x264 source, create an empty folder on your hard drive like this c:\x264\ . Right-click on this folder and select "SVN checkout" from the menu. Then in the field named "URL of repository:" type "svn://svn.videolan.org/x264/trunk" (without the quotes) and click OK. Wait for a few seconds until downloading is finished. Now the latest x264 source code is in the folder.

(note: there are many ways to download the source. TortoiseSVN is just one of them)

step 3. Download "MinGW-2.0.0-3.exe" from
http://prdownloads.sourceforge.net/mingw/MinGW-3.2.0-rc-3.exe?download
Execute the file and install MinGW to folder "c:\MinGW\"

step 4. Download "nasm-0.98.38-win32.zip" from
http://prdownloads.sourceforge.net/nasm/nasm-0.98.39-win32.zip?download
Extract the zip file, rename "nasmw.exe" to "nasm.exe" and copy "nasm.exe" to: C:\MinGW\bin\)

step 5. Download "gcc-core-3.4.4-20050522-1.tar.gz" from
http://prdownloads.sourceforge.net/mingw/gcc-core-3.4.4-20050522-1.tar.gz?download
Extract the file, maintaining the directory structure, into your root directory for mingw "c:\MinGW", overwriting the old ones.

step 6.
Download "GPAC Framework 0.4.1 2005.10.08.exe" from
http://www.aziendeassociate.it/cd.asp?dir=/gpac/dev
Execute the file and install MinGW to folder "C:\GPAC\" (not c:\Program Files\GPAC\)

step 7. Download "binutils-2.16.91-20050827-1.tar.gz" from
http://prdownloads.sourceforge.net/mingw/binutils-2.16.91-20050827-1.tar.gz?download
Extract the file, maintaining the directory structure, into your root directory for mingw "c:\MinGW\", overwriting the old ones.

step 8. Download "w32api-3.3.tar.gz" from
http://prdownloads.sourceforge.net/mingw/w32api-3.3.tar.gz?download
Extract the file, overwriting lib and include folders into your root directory for mingw "c:\MinGW\"

step 9. Download "MSYS-1.0.10.exe" from
http://prdownloads.sourceforge.net/mingw/MSYS-1.0.10.exe?download
Execute the file and install to "C:\msys\1.0"

When asked "Do you want to continue with the post install? [yn]" type y to confirm and press "Enter"
When asked "Do you have MinGW installed? [yn]" type y and press "Enter"
When asked "Where is your MinGW installation?" type c:/MinGW and press "Enter". Make sure you type in the path of your MinGW directory using forward slashes (/), not like the Dos prompt style (c:\)
Press Ok to finish the MSYS installation.

step 10. Some other steps may need to be added here...

step 11. In Start Menu->Programs->MinGW->MSYS execute msys. This will open the MSYS window.

step 12. Type "cd /c/x264/" (without the quotes) and press "Enter". If you have downloaded the x264 source to a different folder you need to specify the correct path here.

step 13. Type "./configure --enable-vfw --enable-avis-input --enable-mp4-output" (without the quotes). Instead of typing it you could copy the string from this guide (Ctrl+C) and paste it into the MinGW window by hitting the middle mouse button (or the scroll ball) or Shift + Left-click if your mouse has only 2 buttons.

step 14. Type "cd /c/x264/build/cygwin/" . If you have downloaded the x264 source to a different folder you need to specify the correct path here.

step 15. Type "make NDEBUG=1" (without the quotes) and press "Enter".

step 16. Now go to "C:\x264\build\cygwin\bin\" and you'll find the x264.exe (note: I've never reached this point, always get "make: *** [x264.exe] Error 1" or something at the end)

step 17. When compiling a new version of x264, always type "make clean" first.

step 18. Some extra steps for compiling the x264vfw.dll

[Sharktooth]

make NDEBUG=1 is no longer necessary. just make.
step 14 and 18 are not necessary too.

[bob0r]

for --enable-mp4-output you need gpac.

cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/gpac login
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/gpac co -P gpac
configure
make clean
make lib

copy /gpac/include/gpac/ to c:/MinGW/include/
copy /gpac/bin/gcc/libgpac_static.a to c:/MinGW/lib/

[leowai]

right after step13, just issue a "make" command will compile and produce both "x264.exe" (in root directory) and "x264vfw.dll" (in root\vfw\build\cygwin\bin).

[hellfred]

I second Sharktooths suggestion to type make in x264 root directory (omitt step 14). The one in build/cygwin is most probably outdated
make
make install
Make install will copy x264.exe to /mingw/bin, the headers and libs to /mingw/include and /mingw/lib, allowing one to build mencoder with support of x264.
But on WinXP, with admin root, one can use the Makefile in vfw/build/cygwin to install the vfw dll:
cd vfw/build/cygwin/
make install

Hellfred

[hpn]

Thank you all for the tips, especially bob0r for the GPAC details!


Here is the final version:

---------------------------------------------------------------------------------------------------

Step by step x264 compilation guide for complete newbies:
Last updated: Oct. 21, 2006

Note: Tested under Windows XP with x264 revision 594. All tools used in this guide will be replaced by new versions in the future (and some links broken), so make sure you always use the most recent versions.


step 1. Download and install "TortoiseSVN-1.3.4.6692-svn-1.3.2.msi" from
http://prdownloads.sourceforge.net/tortoisesvn/TortoiseSVN-1.3.4.6692-svn-1.3.2.msi
(check for new version: link (http://prdownloads.sourceforge.net/tortoisesvn))

step 2. To download the x264 source, create an empty folder on your hard drive like this c:\x264\ . Right-click on this folder and select "SVN checkout" from the menu. Then in the field named "URL of repository:" type "svn://svn.videolan.org/x264/trunk" (without the quotes) and click OK. Wait a few seconds until downloading is finished. Now the latest x264 source code is in the folder.

(note: there are many ways to download the source. TortoiseSVN is just one of them)

step 3.
Download "MinGW-3.2.0-rc-3.exe" from
http://prdownloads.sourceforge.net/mingw/MinGW-3.2.0-rc-3.exe
Execute the file and install MinGW to folder "C:\MinGW\"
(check for new version: link (http://prdownloads.sourceforge.net/mingw/?sort_by=name))

step 4. Download "mingw-runtime-3.9.tar.gz" from
http://prdownloads.sourceforge.net/mingw/mingw-runtime-3.9.tar.gz
Extract the file, maintaining the directory structure to your root directory for mingw "C:\MinGW", overwriting the old files.
(check for new version: link (http://prdownloads.sourceforge.net/mingw/?sort_by=name))

step 5.
Download "w32api-3.7.tar.gz" from
http://prdownloads.sourceforge.net/mingw/w32api-3.7.tar.gz
Extract the file, overwriting "lib" and "include" folders into your root directory for mingw "C:\MinGW\"
(check for new version: link (http://prdownloads.sourceforge.net/mingw/?sort_by=name))

step 6.
Download "nasm-0.98.39-win32.zip" from
http://prdownloads.sourceforge.net/nasm/nasm-0.98.39-win32.zip
Extract the file, rename "nasmw.exe" to "nasm.exe" and copy "nasm.exe" to "C:\MinGW\bin\"
(check for new version: link (http://prdownloads.sourceforge.net/nasm/?sort_by=name))

step 7. Download "gcc-core-3.4.5-20060117-1.tar.gz" from
http://prdownloads.sourceforge.net/mingw/gcc-core-3.4.5-20060117-1.tar.gz
Extract the file, maintaining the directory structure to your root directory for mingw "C:\MinGW", overwriting the old files.
(check for new version: link (http://prdownloads.sourceforge.net/mingw/?sort_by=name))

step 8.
Download "binutils-2.16.91-20060119-1.tar.gz" from
http://prdownloads.sourceforge.net/mingw/binutils-2.16.91-20060119-1.tar.gz
Extract the file, maintaining the directory structure, into your root directory for mingw "C:\MinGW\", overwriting the old files.
(check for new version: link (http://prdownloads.sourceforge.net/mingw/?sort_by=name))

step 9. Download "zlib-1.2.3.exe" from
http://prdownloads.sourceforge.net/gnuwin32/zlib-1.2.3.exe
Execute the file and install it to "C:\zlib\" (select full installation) and copy the contents of "C:\zlib\" maintaining the directory structure into "C:\MinGW\"
(check for new version: link (http://prdownloads.sourceforge.net/gnuwin32/?sort_by=name))

step 10. Download "MSYS-1.0.11-2004.04.30-1.exe" from
http://prdownloads.sourceforge.net/mingw/MSYS-1.0.11-2004.04.30-1.exe
Execute the file and install in "C:\msys\1.0"
When asked "Do you want to continue with the post install? [yn]" type y to confirm and press "Enter"
When asked "Do you have MinGW installed? [yn]" type y and press "Enter"
When asked "Where is your MinGW installation?" type c:/MinGW and press "Enter". Make sure you type in the path of your MinGW directory using forward slashes (/), not backslashes (\) like the DOS prompt style (C:\)
Press Ok to finish the MSYS installation.
(check for new version: link (http://prdownloads.sourceforge.net/mingw/?sort_by=name))

step 11. Download "msysDTK-1.0.1.exe" from
http://prdownloads.sourceforge.net/mingw/msysDTK-1.0.1.exe
Execute the file and install in "C:\msys\1.0"
(msysDTK-1.0.1.exe installs cvs needed for the GPAC download below)

step 12. In Start Menu->Programs->MinGW->MSYS execute msys. This will open the MSYS window. If the font looks too small on your screen, just open the file "c:\msys\1.0\msys.bat" with notepad, search for "Courier-12" and change it to "Courier-14", then restart msys.

step 13 Type "cd /c" (without the quotes) and press "Enter".

step 14. Type "msys/1.0/bin/cvs -z3 -d:pserver:anonymous@gpac.cvs.sourceforge.net:/cvsroot/gpac co -P gpac" (without the quotes). This command will download the GPAC source code to C:\gpac\
(note: Instead of typing this long string you can copy it from this guide (Ctrl+C) and paste in the MinGW window by clicking the middle mouse button (or press the scroll ball) or Shift + Left-click if your mouse has only 2 buttons)

step 15. Reserved (currently not used, so just skip them)

step 16. Type "cd /c/gpac/" (without the quotes) and press "Enter".

step 17. Type "configure" (the only thing it does is to create config.mak in the C:\gpac folder)

step 18. Type "make lib" (a long process follows, so wait about a minute until it's complete)

step 19. Reserved (currently not used, so just skip it)

step 20. Type "cd /c/x264/" (without the quotes) and press "Enter". If you have downloaded the x264 source to a different folder you need to specify the correct path here.

step 21. (optional, go to step 22 if you don't want to patch the source) If you want to apply patch(es) to the x264 source code, just copy the diff file(s) to c:\x264\ folder, then type "patch < filename.diff -p0" replacing filename.diff with the real file name.

For example if you want to apply 2 patches:

x264_aq.5-576.diff
x264_tcplx_mask.00.diff

you just type:
patch < x264_aq.5-576.diff -p0
then
patch < x264_tcplx_mask.00.diff -p0

The latest diff files may be found at this (http://mirror05.x264.nl/Sharktooth/?dir=./x264/patches) page. If you get "failed hunks" errors while applying diff files, just read the quide about fixing conflicting diffs a few posts below.

step 22. Type configure --enable-avis-input --enable-mp4-output --extra-cflags="-Ic:/gpac/include" --extra-ldflags="-Lc:/gpac/bin/gcc" (here the closing character " is part of the configure string, so don't miss it). Instead of typing this long string you can copy it from this guide (Ctrl+C) and paste in the MinGW window by clicking the middle mouse button (or press the scroll ball) or Shift + Left-click if your mouse has only 2 buttons .

step 23. Type "make" (without the quotes) and press "Enter".

note: when compiling x264 again (step 23), always type "make clean" first.

step 24. Now you can locate the compiled file here:
C:\x264\x264.exe

Of course instead of compiling x264 yourself, it is always safer to download and install the latest x264 builds from bob0r (http://x264.nl) or celtic_druid (http://ffdshow.faireal.net/mirror/x264/)

[JimiK]

Instead of having to copy the libs in step 20 everytime, you could add:
--extra-cflags="-Ic:/gpac/include" --extra-ldflags="-Lc:/gpac/bin/gcc"
in step 22. This way your MinGW/lib folder stays clean and your latest gpac compile gets used without the copying.
Best regards,
JimiK

[Sharktooth]

alternative to step24:
for VFW there's also an installer folder located in wfv/installer.
to compile the installer script (x264-conf.nsi) you need to download and install NSIS version 2.xx from http://nsis.sourceforge.net/ .
Once you installed NSIS just righ-click the x264.conf.nsi script and select "Compile NSIS script".
Then, when finished, double click the .exe file and you get x264 VFW installed with start menu entries for configuration and uninstall.

[thetrueavatar]

Hi,
First a big thanks for this thread about x264 compilation.
I never tried to compile an open-source projet before and my first attempt was really painful. So once again thanks for all those informations.

However, I still have two problems even if I've followed all your instruction.

First, I can't compile vfw.
Here's my error

make -C vfw/build/cygwin
make[1]: Entering directory `/c/x264/trunk/vfw/build/cygwin'
C: ./config.c
C: ./driverproc.c
c:/x264/trunk/vfw/build/cygwin/../../x264vfw.h:133: warning: 'tabs_enable_items' declared `static' but never defined
c:/x264/trunk/vfw/build/cygwin/../../x264vfw.h:134: warning: 'tabs_update_items' declared `static' but never defined
W: ./resource.rc
L: x264vfw.dll
Creating library file: x264vfw.dll.a
c:/x264/trunk/vfw/build/cygwin/../../../libx264.a(common.o):common.c:(.text+0xd) : undefined reference to `mcount'
c:/x264/trunk/vfw/build/cygwin/../../../libx264.a(common.o):common.c:(.text+0x36 c): undefined reference to `mcount'
c:/x264/trunk/vfw/build/cygwin/../../../libx264.a(common.o):common.c:(.text+0x3b e): undefined reference to `mcount'
c:/x264/trunk/vfw/build/cygwin/../../../libx264.a(common.o):common.c:(.text+0x44 c): undefined reference to `mcount'
c:/x264/trunk/vfw/build/cygwin/../../../libx264.a(common.o):common.c:(.text+0x4e c): undefined reference to `mcount'
c:/x264/trunk/vfw/build/cygwin/../../../libx264.a(common.o):common.c:(.text+0x58 d): more undefined references to `mcount' follow
collect2: ld returned 1 exit status
make[1]: *** [x264vfw.dll] Error 1
make[1]: Leaving directory `/c/x264/trunk/vfw/build/cygwin'
make: *** [x264vfw.dll] Error 2

The compilation of the cli work well but when I try to use it I have this problem:

avis [error]: unsupported input format (DIB )


Any idea about the problem would be welcome.
I use the command line:
/configure --enable-avis-input --enable-mp4-output --extra-cflags="-Ic:/gpac/include" --extra-ldflags="-Lc:/gpac/bin/gcc"
thetrueavatar

[hpn]

I use the command line:
/configure --enable-avis-input --enable-mp4-output --extra-cflags="-Ic:/gpac/include" --extra-ldflags="-Lc:/gpac/bin/gcc"
thetrueavatar

I don't see "--enable-vfw" in your configure line, so try to add it like this:
configure --enable-vfw --enable-avis-input --enable-mp4-output --extra-cflags="-Ic:/gpac/include" --extra-ldflags="-Lc:/gpac/bin/gcc"

Also make sure you strictly follow all 24 steps I posted above and everything should compile fine.

[leowai]

@thetrueavatar,
For the client error, you need to install AVISynth (v2.5.5, v2.5.6 beta is not recommended). Read the help to use it.

Feed your video input to a avi script file (*.avs) and convert the colorspace to yv12 with following command in the script:

converttoyv12()

[Sharktooth]

the makefiles in the subfolder may be outdated.
use the makefile in the x264 root folder.

[thetrueavatar]

I have the right version of avisynth. Moreover I use all2x264 to encode and this one works fine with your build sharktooth but not with mine...
For the makefile, I use the one in the root but I don't know why for the vfw It use the cygwin makefile

[Sharktooth]

have you added --enable-vfw in the configure lina as suggested by hpn?

[thetrueavatar]

For the vfw now it's ok. I don't understand why that didn't work before but it's ok now.
However I still have my problem whith the cli. I had already install mingwin so I didn't follow all the step(only the last one.). I will try to follow step by step your guide and will reinstall everything

[Sharktooth]

The problem with the cli is most likely an unsupported colorspace and not a build problem.

[el divx]

the makefiles in the subfolder may be outdated.
use the makefile in the x264 root folder.

In the mailing list akupenguin wrote that the /x264/build/cygwin makefile was obsolete and that he would mark it for deletion.

[thetrueavatar]

I have tried to compile x264 on another computer(and I follow all the steps this time!)and now it seems to works. Just a last question: is it normal that my own build weigh only 713kb while sharktooth's build is 940kb???
I know that there are some patch applied to this build but I suppose that this is not the only reason for such a difference

[Sharktooth]

The reason is i added some optimizations to both GPAC and x264.

EDIT: And i also use gcc 4.0.2 which, when using optimizations, produces larger binaries. But maybe i will switch back to gcc 3.4.4.

[max-holz]

Ehm. I follow this step:

step 2. To download the x264 source, create an empty folder on your hard drive like this c:\x264\ . Right-click on this folder and select "SVN checkout" from the menu. Then in the field named "URL of repository:" type "svn://svn.videolan.org/x264/trunk" (without the quotes) and click OK. Wait a few second until downloading is finished. Now the latest x264 source code is in the folder.

but I always got the same message: the host is unreachable

[hpn]

I just tried and the server responds fine as usual. Make sure in your firewall program (if you're using any) you give TurtoiseSVN permission to access the Internet.

[max-holz]

I just tried and the server responds fine as usual. Make sure in your firewall program (if you're using any) you give TurtoiseSVN permission to access the Internet.

Yes the problem is my PeerGuardian.

[max-holz]

Thanks for the guide compilation works fine.
Now I have another question :) .
In which way I could set optimization for CPU and CPU's instruction?
es. P4, MMX, SSE2, SSE3

[Sharktooth]

search for the -march switch options in your gcc manual (or online manual)...

[Audionut]

edit: silly mistake.

[Sharktooth]

however the compiler optimizations wont give you a remarkable speed difference, since all the complex parts were already written in ASM.

[Yong]

Here's the error message i got when try to compile x264 with AQ patch... :(
$ make -s
./version.sh: svnversion: command not found
In file included from common/common.h:61,
from common/predict.c:35:
common/dct.h:82: error: redefinition of 'x264_dct8_weight_tab'
common/dct.h:34: error: previous definition of 'x264_dct8_weight_tab' was here
common/predict.c: In function `predict_4x4_vr':
common/predict.c:535: warning: unused variable `l3'
common/predict.c: In function `predict_4x4_hd':
common/predict.c:568: warning: unused variable `t3'
common/predict.c: In function `predict_4x4_vl':
common/predict.c:592: warning: unused variable `t7'
common/predict.c: In function `predict_8x8_vr':
common/predict.c:774: warning: unused variable `l7'
common/predict.c: In function `predict_8x8_hd':
common/predict.c:802: warning: unused variable `t7'
make: *** [common/predict.o] Error 1

EDIT: Just compiled with r360, same error message... :mad:
May be is my computer or gcc broken... :(
Has anyone hav this problem too?

Now failed to pacthing it with r362... :rolleyes:
(atleast the RD patch V3 is working ;) )

[Sharktooth]

download the updated AQ patch it works for rev360+.

[hpn]

Sharktooth (and the others), how do you apply both conflicting patches "x264_p8rd.5.diff" and "x264_brdo.3.diff" to revision 364?

I aplly:
patch < x264_p8rd.5.diff -p0
then
patch < x264_brdo.3.diff -p0

and I get 2 failed hunks:

patching file `x264.c'
Hunk #1 FAILED at 253.
Hunk #2 FAILED at 477.
Hunk #3 succeeded at 521 (offset 10 lines).
Hunk #4 succeeded at 735 (offset 2 lines).
2 out of 4 hunks FAILED -- saving rejects to x264.c.rej

Is there some tool or command to fix this (for example by changing the second diff so that it takes the changes made by the first diff into consideration) or I have to read the x264.c.rej and manually fix the source (which sounds like not a good idea)? I googled and found some info about a diff3 command (diff3 --help in the MinGW console), but have no idea if it can work in my case.

[Sharktooth]

http://forum.doom9.org/showthread.php?p=733273#post733273

[hpn]

I've already read that, but didn't like the "manual" part, that's why I'm asking hoping for a more elegant solution. Anyway, I'll do it manually. Thank you :)

[Sharktooth]

I can suggest a less elegant solution: merging the 2 patches (it still requires some "manual" work) and then applying the new patch to the sources.

[hpn]

After wasting some time today trying to figure out the best way to compile revision 364 with the current conflicting patches from the Sharktooth's page (http://forum.doom9.org/showthread.php?t=89979), I decided to post a short guide for total newbies like me about fixing conflicting diff files (feel free to correct me if you find errors). Such diff conflicts may occur when two or more developers make independent changes to a common original (Alex_W and pengvado in this particular case).

Example with revision 364 (the patches will change, but the same logic could be used for resolving similar diff conflicts in the future).

When applying the patches in the following order:
1. patch < x264_experimental_rd_pskip.0.diff -p0
2. patch < x264_aq.5.diff -p0
3. patch < x264_p8rd.6.diff -p0
4. patch < x264_brdo.3_fixed.diff -p0

You get 2 failed hunks:

patching file `x264.c'
Hunk #1 FAILED at 253.
Hunk #2 FAILED at 477.
Hunk #3 succeeded at 521 (offset 10 lines).
Hunk #4 succeeded at 735 (offset 2 lines).
2 out of 4 hunks FAILED -- saving rejects to x264.c.rej

"x264_aq.5.diff" is applying the following patch to "x264.c":

@@ -476,6 +484,8 @@
#define OPT_CHROMALOC 313
#define OPT_MIXED_REFS 314
#define OPT_CRF 315
+#define OPT_AQ_STRENGTH 316
+#define OPT_AQ_SENSITIVITY 317

static struct option long_options[] =
{
That's why "x264_brdo.3.diff" fails when trying to apply:

@@ -476,6 +477,7 @@
#define OPT_CHROMALOC 313
#define OPT_MIXED_REFS 314
#define OPT_CRF 315
+#define OPT_B_RDO 316

static struct option long_options[] =
{
So in "x264_brdo.3.diff" you have to manually replace the code above by:

@@ -476,6 +477,7 @@
#define OPT_CRF 315
#define OPT_AQ_STRENGTH 316
#define OPT_AQ_SENSITIVITY 317
+#define OPT_B_RDO 318

static struct option long_options[] =
{
As pointed out by Sharktooth in another thread 316 is already used by the AQ option (#define OPT_AQ_STRENGTH 316), so we must replace 316 by the first unused number - 318. (To edit the diff files don't use Notepad or WordPad, but some good code editor like this one (http://prdownloads.sourceforge.net/pnotepad/pn206.exe?download))

Plus:

x264_p8rd.6.diff is applying the following to "x264.c":

@@ -252,7 +252,7 @@
" - esa: exhaustive search (slow)\n"
" --merange <integer> Maximum motion vector search range [%d]\n"
" -m, --subme <integer> Subpixel motion estimation and partition\n"
- " decision quality: 1=fast, 6=best. [%d]\n"
+ " decision quality: 1=fast, 7=best. [%d]\n"
" --mixed-refs Decide references on a per partition basis\n"
" --no-chroma-me Ignore chroma in motion estimation\n"
" -8, --8x8dct Adaptive spatial transform size\n"
That's why "x264_brdo.3.diff" fails when trying to apply:

@@ -253,6 +253,7 @@
" --merange <integer> Maximum motion vector search range [%d]\n"
" -m, --subme <integer> Subpixel motion estimation and partition\n"
" decision quality: 1=fast, 6=best. [%d]\n"
+ " --b-rdo RD based mode decision for B-frames\n"
" --mixed-refs Decide references on a per partition basis\n"
" --no-chroma-me Ignore chroma in motion estimation\n"
" -8, --8x8dct Adaptive spatial transform size\n"
So to make the code in "x264_brdo.3.diff" works, just manually change "6=best" to "7=best" like this:

" --merange <integer> Maximum motion vector search range [%d]\n"
" -m, --subme <integer> Subpixel motion estimation and partition\n"
" decision quality: 1=fast, 7=best. [%d]\n"
+ " --b-rdo RD based mode decision for B-frames\n"
" --mixed-refs Decide references on a per partition basis\n"
" --no-chroma-me Ignore chroma in motion estimation\n"
" -8, --8x8dct Adaptive spatial transform size\n"
Now save the corrected "x264_brdo.3.diff" to something like "x264_brdo.3_fixed.diff" and apply it instead of the wrong one.

Instead of tweeking "x264_brdo.3.diff", an alternative way to fix the conflicts is first to apply all 4 patches (including the broken one) and after reading the MinGW console log about the failed hunks (Hunk #1 FAILED at 253 Hunk #2 FAILED at 477) and the rejects file (x264.c.rej) to manually add the failed hunks to the source, meaning adding 2 lines to the code directly to "x264.c" like this:

#define OPT_AQ_SENSITIVITY 317
+#define OPT_B_RDO 318

static struct option long_options[] =

.....
.....

" decision quality: 1=fast, 7=best. [%d]\n"
+ " --b-rdo RD based mode decision for B-frames\n"
" --mixed-refs Decide references on a per partition basis\n"
(Both lines are those with the leading +). This alternative way may seem easier, but IMHO is a worse solution, because instead of fixing the patch that causes the conflict you're trying to fix the SVN source ("x264.c" in this particular case) that has nothing to do with our problem, plus when building the next x264 revisions you'll have to fix the source again instead of just applying the already fixed "x264_brdo.3_fixed.diff" (if it's not already commited to the SVN).

And finally I want to repeat again that I'm a complete newbie (first time applying b0rked patches today) so the whole guide may be wrong (hopefully not :) )

[bob0r]

Small remark about gpac (needed for x264 .mp4 output)

Compiling fails after 2005-11-12 (x264 revision 367 was on that date and this worked)

The error:
gcc -O3 -fno-strict-aliasing -Wall -I/home/user/gpac/include -c -o encode_isom.o encode_isom.c
encode_isom.c:30:24: error: gpac/laser.h: No such file or directory
encode_isom.c: In function 'gf_sm_encode_scene':
encode_isom.c:381: error: 'GF_LASeRCodec' undeclared (first use in this function)
encode_isom.c:381: error: (Each undeclared identifier is reported only once
encode_isom.c:381: error: for each function it appears in.)
encode_isom.c:381: error: 'lsr_enc' undeclared (first use in this function)
encode_isom.c:579: warning: implicit declaration of function 'gf_odf_get_laser_config'
make[2]: *** [encode_isom.o] Error 1
make[2]: Leaving directory `/home/user/gpac/src/scene_manager'
make[1]: *** [libgpac.dll] Error 2
make[1]: Leaving directory `/home/user/gpac/src'
make: *** [lib] Error 2

Using gpac from 2005-11-12 does work.

Getting gpac from that date:
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/gpac co -D 2005-11-12 gpac

Will update thread when gpac works again (or if someone else notices, please do the same)

[el divx]

Pulled today a fresh copy of GPAC from cvs, followed your instructions and it compiled without problems(GPAC, offcourse).

[bob0r]

@el divx and all:

Yup it works again :)

[el divx]

gcc -o x264.exe x264.o matroska.o libx264.a -lwinmm -lgpac_static -Lc:/gpac/bin/gcc -lvfw32 -s
c:/gpac/bin/gcc/libgpac_static.a(os_divers.o):os_divers.c:(.text+0x535): undefined reference to `timeBeginPeriod@4'
c:/gpac/bin/gcc/libgpac_static.a(os_divers.o):os_divers.c:(.text+0x6ca): undefined reference to `timeEndPeriod@4'
c:/gpac/bin/gcc/libgpac_static.a(os_divers.o):os_divers.c:(.text+0x4e5): undefined reference to `timeGetTime@0'
collect2: ld returned 1 exit status
make: *** [x264.exe] Error 1

I get this though when trying to build x264 with MP4 support.

[el divx]

In file included from encoder/set.c:38:
c:/mingw/bin/../lib/gcc/mingw32/3.4.4/../../../../include/config.h:48:24: gpac/tools.h: No such file or directory
In file included from encoder/set.c:38:
c:/mingw/bin/../lib/gcc/mingw32/3.4.4/../../../../include/config.h:89: error: syntax error before "gf_cfg_set_key"
c:/mingw/bin/../lib/gcc/mingw32/3.4.4/../../../../include/config.h:97: error: syntax error before "gf_cfg_get_section_count"
c:/mingw/bin/../lib/gcc/mingw32/3.4.4/../../../../include/config.h:106: error: syntax error before "u32"
c:/mingw/bin/../lib/gcc/mingw32/3.4.4/../../../../include/config.h:115: error: syntax error before "gf_cfg_get_key_count"
c:/mingw/bin/../lib/gcc/mingw32/3.4.4/../../../../include/config.h:125: error: syntax error before "u32"
c:/mingw/bin/../lib/gcc/mingw32/3.4.4/../../../../include/config.h:138: error: syntax error before "gf_cfg_insert_key"
c:/mingw/bin/../lib/gcc/mingw32/3.4.4/../../../../include/config.h:138: error: syntax error before "u32"
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: *** [encoder/set.o] Error 1


Got this after compiling rev.384 with mingw.

[Sharktooth]

you didnt compile gpac correctly.

[unmei]

in the build change for sharktooth's 384G it reads
Enabled Profiling for CLI (should help encoding speed).
How is that to be understood?
At first i thought it might mean that you get profiler output on the CLI so one might base settings descions on that (or help the devs find anomalies or whatever). But obviously it does not.

So my only guess left is, that it means the exe is compiled with profiler support - but that is completly contra-intuitive - why would "extra bloat" help the encoding speed?

/me is confused

[bob0r]

@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]

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]

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]

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]

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]

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]

You killed your linux box? What's inside /usr/include?

[bob0r]

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]

You killed your linux box? What's inside /usr/include?
Actually, it's MinGW.

[bob0r]

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]

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]

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]

i wonder how JLF didnt notice gcc is not able to compile GPAC...
try adding --disable-svg in configure.

[celtic_druid]

Still works with gcc 3.x though right? Just not gcc 4.x.

[leowai]

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]

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]

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]

dll doesnt compile here (and doesnt compile to others too).
do a fresh checkout and try again.

[celtic_druid]

I did a checkout afterwards. Nothing had changed. So basically the same thing.

[Sharktooth]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

It's not hard, I don't think any changes are required. There's just lots and lots of warnings.

[omion]

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]

You tried playing back anything encoded with it? I just tried playing my test encode and got a mostly grey screen.

[omion]

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]

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]

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]

@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]

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]

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]

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]

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]

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]

removed

[squid_80]

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]

2squid_80
#include <sys/types.h>

[squid_80]

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]]

Ajaja2005
thanks, it's fix problem for me.
-----------------------------
спасибо опять помог мне

[max-holz]

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]

Nasm, and some MSVC project management knowledge because iirc, the project doesn't build out of the box.

[max-holz]

Nasm, and some MSVC project management knowledge because iirc, the project doesn't build out of the box.

I have some little MSVC project management.
What must I include in the project?

Nasm and Gpac

There is a good guide, but it's for MinGW.

[bill_baroud]

there is nothing to "include", but you've to correct some path (like nasm for asm files because the vc7 conversion is b0rked). I remember modifying a some headers because it wasn't correct, but nothing major. It was some times ago (hmmm 17/05/2005) though...

[max-holz]

there is nothing to "include", but you've to correct some path (like nasm for asm files because the vc7 conversion is b0rked). I remember modifying a some headers because it wasn't correct, but nothing major. It was some times ago (hmmm 17/05/2005) though...

So GPAC must be compiled separately?

[leowai]

I got problem compiling rev425 using mingw (under windows) configured with "--enable-pic".

Following errors return from nasm (v0.98.39)
C:\xxx\x264\trunk>nasm -f win32 -DPREFIX -D__PIC__ -Icommon/i386/ -o common
/i386/dct-a.o common/i386/dct-a.asm
common/i386/dct-a.asm:164: error: symbol `..gotpc' undefined
common/i386/dct-a.asm:176: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:288: error: symbol `..gotpc' undefined
common/i386/dct-a.asm:307: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:402: error: symbol `..gotpc' undefined
common/i386/dct-a.asm:404: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:405: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:406: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:407: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:461: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:461: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:461: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:461: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:461: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:461: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:461: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:461: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:559: error: symbol `..gotpc' undefined
common/i386/dct-a.asm:561: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:562: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:563: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:564: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:613: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:613: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:613: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:613: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:613: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:613: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:613: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:613: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:739: error: phase error detected at end of assembly.
Anyone experienced the same error?

BTW, how PIC works?

[celtic_druid]

Does PIC even work under windows? x264.exe uses a statically linked lib and x264vfw is a dll.

[leowai]

Does PIC even work under windows? x264.exe uses a statically linked lib and x264vfw is a dll.
Thanks. I see. My bad since PIC is not suppose to work under windows. :P

Compilation indeed works fine without PIC with MinGW.

Again. What's PIC that doesn't get supported under windows?

[foxyshadis]

PIC is how Apple and Unix do DLLs without fixups, basically. Their structure is much different from dlls and obviously windows can't use them.

[slavickas]

dunno myself for sure, but http://en.wikipedia.org/wiki/Position_independent_code sounds like it is

[leowai]

Thanks. I've better understanding of PIC now.

This shows why windows does not support PIC from the wikipedia:
-------------------------------------------------------------
Microsoft Windows DLLs are not shared libraries in the Unix sense and do not use position independent code. This means they cannot have their routines overridden by previously loaded DLLs and require small tricks for sharing selected global data. Code has to be relocated after it has been loaded from disk, making it potentially non-shareable between processes; sharing mostly occurs on disk.
-------------------------------------------------------------

[max-holz]

During compilation of gcc 4.0.2 I got this error

The directory that should contain system headers does not exist:
/usr/include
make[2]: *** [stmp-fixinc] Error 1
make[2]: Leaving directory `/c/gcc-4.0.2/obj/gcc'
make[1]: *** [stage1_build] Error 2
make[1]: Leaving directory `/c/gcc-4.0.2/obj/gcc'
make: *** [bootstrap] Error 2

I have unpacked source and created the dir C:\gcc-4.0.2 then I run this series of command under MinGW:

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

perhaps I should have ran ../configure --srcdir=../gcc-4.0.2 --prefix=/usr/local
Anyone can help me?

[bob0r]

http://forum.doom9.org/showthread.php?p=724582

[max-holz]

http://forum.doom9.org/showthread.php?p=724582

But I haven't C\msys\1.0\local\include dir :(

[bob0r]

You dont use mingw?

Else just copy the local/include to whatever your root is (cd /)
So you have cd /include

I have:
/include/unistd.h
/include/wx-2.6/
/include/wx-2.6/wx/
/include/wx-2.6/wx/<headers here>

[max-holz]

Are there any problems in using gcc-4.0.2? I notice that most people use 3.4.5

[bob0r]

Are there any problems in using gcc-4.0.2? I notice that most people use 3.4.5

ffdshow won't compile with gcc 3.4.5
x264 make fprofiled won't compile with gcc 4.0.2

Thats what i have both gcc version compiled ready on my hdd (only have to make install to switch)

So uhm guess you could say gcc has some "problems" :D

[max-holz]

ffdshow won't compile with gcc 3.4.5
x264 make fprofiled won't compile with gcc 4.0.2

Thats what i have both gcc version compiled ready on my hdd (only have to make install to switch)

So uhm guess you could say gcc has some "problems" :D

Strange, I have compiled x264 fprofiled with 4.0.2 yesterday, many warnings but not error. Tested today the .mkv output and seems normal. You speak about ffdshow and I have question: can I compile it using only gcc and if yes where can I find a starting guide to understand how do it?

[bob0r]

http://forum.doom9.org/showthread.php?p=727041#post727041

The above is how i do it, but this is the latest script i use:
http://files.x264.nl/ffdshow/ffdshow_gcc.sh

[Oline 61]

Most everything I need works fine in gcc 4.0.2. That really only consists of x264 and mplayer though.

[DarkZell666]

Tried to compile x264 using VS.NET 2003.

I had to modify frame.h and common.h because of this stdint.h and inttypes.h business to correct 2 errors (thx omion, I had the same problem as Sirber)

But I still have the following (translated from french, so it might not be accurate :p) :

libx264 error PRJ0019: A tool returned an error code from "Assembly d:\x264-snapshot-20060213-2245\common\i386\predict-a.asm"

I'm surprised that VS blocks on this file when there are many others in alphabetical order before it ... and why does VS even try to compile it ?

Should I be using NASM or can VS compile x86 ASM but fails for another reason ?

[foxyshadis]

It's most likely a masm issue. I think I had to use masm from vs6 for virtualdub and x264 because of some subtle incompatibilities in memory access syntax with 2005, may be similar for 2003. You can rename the original, or just replace it.

The svn project file is also missing one or two of the asm files, since it was last updated who knows when. Just add in all the asm files and the missing ones will show up. Those need to be given the same build instructions as the others. In fact, it might just be this, and not masm at all.

[DarkZell666]

Hmm even if there is files missing, predict-a.asm only includes i386inc.asm and this file is present in the directory ... btw I've looked in the corresponding .svn/text-base dir and all the files are there with the same sizes so ... (I didn't connect to the svn I just grabbed a daily snapshot of the source, was it a bad idea ? It was x264-snapshot-20060213-2245)

As for masm I've searched a bit everywhere (starting with the .NET directories and vsnet2003 dir) and haven't found anything looking like it :)

I found it using google though :p and just saw that it wasn't supported by M$ anymore but by another brave guy =) So if I've understood, VS uses masm to compile the asm files, and it's (or should be) bundled with it somewhere (place that I can't find for now). And the recent versions of masm won't compile the x264 asm files because of subtil syntax differences ?
I would then need an older version (e.g. the one from VS6 you mentioned), but since I can't even find my executable I can't replace it :( What's it called ?

I don't have a clue where to start, all this linking/compiling stuff is too complicated for me with my actual skills (I can compile a VB/C# projet ok, but I haven't had to deal with advanced C++ projects yet ;)), maybe I'll just stick to the instructions given to do it with mingw (saw those a bit earlier in the thread).

[foxyshadis]

Masm's in the vs6 sp5 processor pack. Extract but don't install it. Just copy masm.exe into the 2003 C++/bin folder.

All the versions of vs past 6 should come with a masm in the c++/bin folder, but I'm not familiar with the 2003 environment specifically. Once you get past the 'omfg this thing keeps failing' it's actually very simple, just have to make sure all the files are included or you'll get the hated symbol not found in linking.

[celtic_druid]

In the past I have successfully compiled 32bit with MSVC 2003 using nasm and 64bit using yasm/MSVC 2005. You shouldn't need masm unless things have really changed.

[foxyshadis]

sorry, I meant nasm. >_< I'm so sorry, I've been working on a project that uses masm and I keep confusing the two.

[DarkZell666]

lool ok no problem, it's the sort of thing that just happens u know =)
At least I've learnt something ^^

Haven't tried to recompile since the other day, but I've had a hard time finding the processor pack so I just let go of the idea =)

[gumimaci]

Hi

I tried to patch the latest x264 (Rev.445) with Sharktooth's patches from http://files.x264.nl/Sharktooth/?dir=./x264_patches and it can't be.
Are there any newer patches?

[ChronoCross]

Hi

I tried to patch the latest x264 (Rev.445) with Sharktooth's patches from http://files.x264.nl/Sharktooth/?dir=./x264_patches and it can't be.
Are there any newer patches?

the patches need to be updated manually. Additionally not only do the lines have to be updated but there are portions of the code that have been updated since then to provide even greater speed and quality since then.

I have a build up that has all the patches applied. The only one I'm weary about is --subme 7 which needs some testing.

http://www.chronocrossdev.com/apps/x264/

[gumimaci]

Thanks, but that is a compiled x264.
I need the patched source.
Would you put it to your webspace if it's possible.

Thanks.

[ChronoCross]

Thanks, but that is a compiled x264.
I need the patched source.
Would you put it to your webspace if it's possible.

Thanks.

I'll only put it up if I can confirm it works. hopefully sirber is trying it out, if you want to try it out on a small clip say 45 seconds and see if --subme 7 works that'd be great. Then I'll put up the patched source.

[Sharktooth]

sirber said it doesnt work.

[ChronoCross]

okay then. well I looked at the functions that I changed and it's wierd that it throws compiling errors complaining about the arguements. So I tried changing the number of arguements and making it conform to the others in it but now that I know that doesn't work I need to investigate further as to why it's throwing erros on things that aren't changed by the patch.

[omion]

A bit of a minor weirdness: compiling r445 on XP x64 fails on predict-a.asm. It says "undefined symbol `FDEC_STRIDE' (first use)" even though it's in amd64inc.asm. I got around it by changing the custom build step command line to include "-D FDEC_STRIDE=32" but I figure there's a better way.

BTW, anybody know how much the recent cache coherency stuff helps?

[ChronoCross]

pengvado said there should be a 3-5% speed increase.

[Chainmax]

Do bob0r's compiles have all of Sharktooth's patches?

[Sharktooth]

no...

[max-holz]

I see that gcc-4.1.0 final is out. Any tricks how to compile x264 with make fprofiled without error?

[Sharktooth]

no... 4.1 is buggy and the gprofile bug is in WAIT state.

[squid_80]

A bit of a minor weirdness: compiling r445 on XP x64 fails on predict-a.asm. It says "undefined symbol `FDEC_STRIDE' (first use)" even though it's in amd64inc.asm. I got around it by changing the custom build step command line to include "-D FDEC_STRIDE=32" but I figure there's a better way.
Didn't we have to make another copy of amd64inc.asm and put it somewhere else, because yasm doesn't like a long command line?

[omion]

Didn't we have to make another copy of amd64inc.asm and put it somewhere else, because yasm doesn't like a long command line?
Oh yeah... I completely forgot about that. :D
I had no clue why that line wasn't working when the rest of the file clearly was. Now it all makes sense. Thanks!

[Chainmax]

no...

Do any compile besides yours have them?

[ChronoCross]

Do any compile besides yours have them?

I put up a few that had every patch cept --subme 7.

it's incompatible with the latest svn.

[Kostarum Rex Persia]

Who was worked on development of --subme 7 patch? Perhaps he can update subme 7 for new builds.

[ChronoCross]

Who was worked on development of --subme 7 patch? Perhaps he can update subme 7 for new builds.

pengvado(the author) already said no. he'll work on it again when it's time for it to be worked on again.

[Sharktooth]

The author is Alex_W though.

[Kostarum Rex Persia]

Ok, thanks guys. BTW, where is Alex_W, he didn't post on this forum some time.

[Sharktooth]

KRP: dont bug the devs for that. They already said "NO".

[Sirber]

Well, I'll have to keep an odler build :(.

@RealAnime users

Beware! Upgrading to recent x264 and using "High" quality profile will result in death! ;)

[ChronoCross]

The author is Alex_W though.
I think pengvado had made some of the more recent changes to the patch. I could be wrong though.

[ChronoCross]

Ok, thanks guys. BTW, where is Alex_W, he didn't post on this forum some time.

stay away from the dev's KRP.

[celtic_druid]

Well yeah kosaleksandar's last message on the dev list didn't go down to well.

[Kostarum Rex Persia]

:D :confused: :D

[ChronoCross]

Well yeah kosaleksandar's last message on the dev list didn't go down to well.

True 3 or 4 of us yelled at him.

[Kostarum Rex Persia]

Ok, I didn't open new thread at mailing lists, because I didn't know the rules there. It's my fault.

[Chainmax]

Well, I'll have to keep an odler build :(.

Same here, still using Sharktooth's latest compile (r408).

[Sirber]

I'm on ChronoCross' rev 418 IIRC.

[ChronoCross]

438 build is my last build that has all of shaktooths patches. 445 is the most recent build with every patch except --subme 7.

[Sirber]

Maybe it's 438 then. It the build that was avalible before I ask you for a new one :)

[Chainmax]

438 build is my last build that has all of shaktooths patches.

Time to upgrade then :).

[max-holz]

With Rev. 460 I got these errors during compilation with fprofiled:


muxers.o:muxers.c:(.text+0x201b): undefined reference to `__gcov_init'
muxers.o:muxers.c:(.data+0x1e4): undefined reference to `__gcov_merge_add'
muxers.o:muxers.c:(.data+0x1f0): undefined reference to `__gcov_merge_single'


Someone could give some tricks to compile succesfully?

[ChronoCross]

With Rev. 460 I got these errors during compilation with fprofiled:


muxers.o:muxers.c:(.text+0x201b): undefined reference to `__gcov_init'
muxers.o:muxers.c:(.data+0x1e4): undefined reference to `__gcov_merge_add'
muxers.o:muxers.c:(.data+0x1f0): undefined reference to `__gcov_merge_single'


Someone could give some tricks to compile succesfully?

what's your gcc version? fprofiled doesn't work with 4.1. it only works with lower versions.

[max-holz]

what's your gcc version? fprofiled doesn't work with 4.1. it only works with lower versions.
gcc-3.4.5 :)
I used this command for configure: configure --enable-vfw --enable-avis-input --enable-mp4-output --extra-cflags="-Ic:/gpac/include" --extra-ldflags="-Lc:/gpac/bin/gcc"

Never had problems with previous rev.

[ChronoCross]

try the latest revision. just go tupdated again.

[lcx]

If anyone is able to compile for x64 Windows can you please share your *.vcproj

I just started compiling Win32 versions but have had no luck with Win x64 compilation.

[Kostarum Rex Persia]

Icx, look this, perhaps you will find something useful. http://forum.doom9.org/showthread.php?t=97531

[omion]

If anyone is able to compile for x64 Windows can you please share your *.vcproj

I just started compiling Win32 versions but have had no luck with Win x64 compilation.
My builds for Win x64 are here (http://omion.dyndns.org/x264x64/). The "-omion" ones are the pre-built binaries, the "-build" are a direct snapshot of the directory, including SVN data (you have TortoiseSVN, right? :D )

Only use the libx264.vcproj file. It will build both libx264 and x264.exe.

If you build your own, you might want to change line 178 of x264.c so that it doesn't say "built by Omion" ;)
Also if you update you have to manually update the version number at line 37 of common/common.h.

I don't have GPAC compiled in, so you can't output MP4. Instead, output raw or Matroska.

You also have to use a 64-bit version of avisynth, or pipe the input to x264 (akupenguin told me how to do it somewhere) Piping is much more practical if you have any kind of filters in the .avs file.

[lcx]

Awesome.
Thanks a bunch omion. :)

me off to try on my Win64 machine.

[IgorC]

Did anybody try Chronocross compilation of x264 r.463+AQ patch? It seems AQ doesn't do anything. MBs have constant quantizer.
x463.exe --pass 1 --bitrate 700 --stats ".stats" --ref 8 --mixed-refs --no-fast-pskip --bframes 3 --b-rdo --bime --weightb --filter -2,-2 --subme 6 --trellis 1 --analyse all --8x8dct --qcomp 0.75 --me hex --merange 16 --progress --b-pyramid --direct auto --aq-strength 0.2 --aq-sensitivity 15 --output 1x463_AQ_02_15.mp4 wall.avs

[Yong]

Just tested with different aq setting, all have same psnr :eek:

[ChronoCross]

The patch is working as far as I can tell. I manually added it by going through the patch and adding it to each file individually, and nothing in the patch or the code it effects changed. I need people to run more tests so I can see if it's broken. it shouldn't be and as far as I can tell most of the people still using it say it's working.

[IgorC]

But it doesn't work already for two people ( me and Young).
PSNR results are identical. Bit to bit comparing also says that two files ( with and without AQ) are indentical. All frame and MBs quantizer are identical. It is more than enough to say that AQ doesn't work.
I'm trying dif. values but the result is the same.


Can somebody check AQ in x264 r. 463? http://chronocrossdev.com/apps/x264/

[Yong]

this build works :
http://chronocrossdev.com/apps/x264/x264_438_cli.rar :rolleyes:

EDIT : 445, 458 doesnt work, i think no need to test the newer rev. :p

[foxyshadis]

It slows it down ~.5 fps, but does not appear to have any effect currently. Average quant is always an integer, size/psnr,etc are always identical. I will build my own and investigate this afternoon, once I reinstall VS2005; I'm sure it's just using a recently deprecated function call or similar.

Main test, with aq and bitrates tweaked around:

x264 --output test2.mp4 --bitrate 40 --subme 6 --threads 2 --bframes 3 --analyse all --me umh --aq-strength 1.1 --aq-sensitivity 15 --progress d:\video\work\Example.avs

No crf or 2pass tested yet.

[hpn]

But it doesn't work already for two people ( me and Young).
PSNR results are identical. Bit to bit comparing also says that two files ( with and without AQ) are identical. All frame and MBs quantizer are identical. It is more than enough to say that AQ doesn't work.
I'm trying dif. values but the result is the same.


Can somebody check AQ in x264 r. 463? http://chronocrossdev.com/apps/x264/

Yes, the results are identical with
--aq-strength 0.2 --aq-sensitivity 15

but I just tried different -aq options like
--aq-strength 0.5 --aq-sensitivity 5

and this time I got a different encode. Seems it depends on how much strength/sensitivity you apply. I have no idea why.
I also retested AQ with my own builds (http://mujweb.cz/www/x264/)to make sure everything is correct.

[ChronoCross]

I'll investigate it later today to see what I can find.

[ChronoCross]

okay guys. I just uploaded a new version. I went through by hand and checked everything it should be all good now. let me know please. thanks.

[Yong]

okay guys. I just uploaded a new version. I went through by hand and checked everything it should be all good now. let me know please. thanks.
--aq-strength 1.1 --aq-sensitivity 5 works... :p
but higher aq sensitivity(15, 22) still have same psnr.

[foxyshadis]

I'm still getting identical results with it. It must be that something recently modified whatever variables the "sensitivity" uses, so it needs to be rescaled.

[ChronoCross]

it's soo wierd. I can't find anything that would directly cause it. all the places where there is addition or changes in AQ code all look the same. that probably means that something else in a different file or method has changed so signifigantly that AQ no longer works. From the looks of it it seems that it broke at the same revision as --subme 7. so that definitely means that there was a major internal change.

[shon3i]

What is recommendation for AQ for DVD backups

[Yong]

I'm still getting identical results with it. It must be that something recently modified whatever variables the "sensitivity" uses, so it needs to be rescaled.
i tired the older build(r438) by ChronoCross with some weaker aq settings even like --aq-strength 0.1 --aq-sensitivity 22 and its work, unlike the newer revs.
may be the recent revs of x264 can produce optimal quality so the weaker aq settings doesnt work :D

[IgorC]

What is recommendation for AQ for DVD backups
It would be a hard task cause it depends on taste/psycovisual perception/preferements of each personally.
That's why I wanted to run some video with different aq setings.
Also it depends on other factors like source.

[ChronoCross]

Please test with as many values as you possibly can. please tell me about your different experiences. since some of you are saying certain values work an dothers don't.

Also don't just use psnr. Check the qp output manually and see if there are changes between the values (using ffdshow). Additionally do you notice any visual differences between the encoded clips.

[Yong]

a quick tested encode 320x240 @ 24fps mpeg1 video clip, with aq strength >=0.8 and aq sensitivity <=5 should work, at least for me, checked with ffdshow osd and psnr too.

EDIT: higher resolution might need stronger aq strength/sensitivity to get it work. ;)

[IgorC]

here is my result :
AQ of x438 works. How works is other question.

The results for AQ of x465.
Streght/sen-ty
0.1/5 - Doesn't work (no)
1.1/5 - yes (partial*)
0.1/22 - no
1.1/22 - no
0.5/15 - no.

* AQ 1.1/5 has very strange behavior. Only first (approx. 31-80) MBs have diferent quantiser. Others MBs just have the same quantiser while there's big contrast (darkness to light).
There were so many changes since then in code of x264 and maybe that's why AQ doesn't work anymore.

[foxyshadis]

Sensitivity is not an integer. If it is just a scaling issue, you should be able to specify something like 2.5 or 3.1 and get some results. 2.5 definitely gets results for me. I'm scanning the code (and trying to empirically match up how much it changes) to figure out how it changed.

[ChronoCross]

Sensitivity is not an integer. If it is just a scaling issue, you should be able to specify something like 2.5 or 3.1 and get some results. 2.5 definitely gets results for me. I'm scanning the code (and trying to empirically match up how much it changes) to figure out how it changed.

Haali and sharktooth have investigated and they aren't sure what's wrong either. I think they will be working on it some more when they have time but for now it's going to remain an unstable patch.

[Kostarum Rex Persia]

I must ask this: what is new decimation patch, compiled by Alex_W? What's purpose of this patch?

[Sharktooth]

speed up retaining as much quality as possible.

[foxyshadis]

So I got around to checking out AQ files in streameye and found something interesting: When you specify a threshold, like 2.0, the top of many frames is a high quant, and it suddenly ends at a lower quant some # of macroblocks in, and never changes after that. In older versions you'd see a somewhat random distribution of different quants around the frame, but this is just getting stuck in one low and one high quant. I spent a while wrestling with the code to find out why, but I'm not really familiar with x264's architecture at all; it looks like AQ is just going to have to be rewritten by someone familiar with the codebase.

[akupenguin]

http://students.washington.edu/lorenm/src/x264/x264_aq.5-466.diff

completely untested, I haven't even compiled it.

[ChronoCross]

v 466 on my site includes his patch. Everyone test please. Thanks.

[IgorC]

It works. Thank you, Chrono and Aku.
x264's AQ works diferently to Ateme's AQ. i.e. Ateme's AQ has higher quant on dark area where there aren't details and lower quant on walls (very high details). Imho very pleasent visual result.
x264's AQ seems to work totally vise versa.:confused: I'm going to look closer at it tommorow (dif. values, videos, setings.)

[foxyshadis]

No AQ: (http://foxyshadis.slightlydark.com/random/test0.mp4)
http://foxyshadis.slightlydark.com/random/test0.mp4_000144.png
AQ at .7/15: (http://foxyshadis.slightlydark.com/random/test-15.mp4)
http://foxyshadis.slightlydark.com/random/test-15.mp4_000144.png
Quant mask (dark=high/40, light=low/20)
http://foxyshadis.slightlydark.com/random/test-15.mp4_000144-quantmask.png

There's no obvious pattern to the oddly bright blocks, they show up mostly in low-quant portions of the frame though. Not every frame has them, either.

x264 --bitrate 500 --analyse all --me umh --pass 2 --stats .stats --bframes 3 --progress --no-fast-pskip --aq-strength .7 --aq-sensitivity 15 -o test-15.mp4 d:\video\work\test.avs

[IgorC]

--aq-strength .7 is too much . With 0.5 already all faces are washed. Something around 0.2 is more acceptable.
What happens if to low sen-ty to 20-22 with remaining strenght 0.7?

I think we are on offtopic here :rolleyes:. http://forum.doom9.org/showthread.php?t=105501&highlight=aq+adaptive

[akupenguin]

A guess about the oddly colored blocks: they might have been assigned high qp by the aq, and then decided to be Skip or at least no residual. But skips don't get a delta_qp (it doesn't matter what qp the mb used if it doesn't code any dct coefs), so the qp values you see on playback are not the values that were used to quantize those blocks.
Plus, imho 40/20 is way too much variation to have within one frame.

[foxyshadis]

Without no-fast-pskip they actually were assigned to pskip, though with it they were 16x16, so I guess you're right. I'll try again with much lower settings. At .3 and twenty the blocks are there but rare, like the old bluesky issue (maybe that's all this is?), at .1 there's not much difference to the original anyway; gradients are slightly smoother but sharp details are more lacking, even though the "main" quant is only one less. Oh well, I'll play around a bit more and see if I can find good settings.

[hpn]

rev. 474 introduced a new CLI option --thread-input (run Avisynth in its own thread), but that broke the current AQ patch "x264_aq.5-466.diff" posted on the akupenguin page, by adding
#define OPT_THREAD_INPUT 320 to x264.c. I fixed it manually by simply changing from

+#define OPT_AQ_STRENGTH 320
+#define OPT_AQ_SENSITIVITY 321

to

+#define OPT_AQ_STRENGTH 321
+#define OPT_AQ_SENSITIVITY 322

(plus fixing the offsets and stuff) like this
http://mujweb.cz/www/x264/x264_aq.5-474.zip

I guess this is the correct way to fix the patch, but if not please correct me, so I don't compile potentially broken builds.

[Sagittaire]

Why not to import mask from libavcodec:
Lumimask [0.00-1.00] : higher quant for luminess part
Darkmask [0.00-1.00] : higher quant for darkness part
Temporalmask [0.00-1.00] : higher quant for high motion part
Spatialmask [0.00-1.00] : higher quant for high texture part

and why not other mask for evaluation ... ???

and let x264's users to find the best possible setting

[ChronoCross]

rev. 474 introduced a new CLI option --thread-input (run Avisynth in its own thread), but that broke the current AQ patch "x264_aq.5-466.diff" posted on the akupenguin page, by adding
#define OPT_THREAD_INPUT 320 to x264.c. I fixed it manually by simply changing from

+#define OPT_AQ_STRENGTH 320
+#define OPT_AQ_SENSITIVITY 321

to

+#define OPT_AQ_STRENGTH 321
+#define OPT_AQ_SENSITIVITY 322

(plus fixing the offsets and stuff) like this
http://mujweb.cz/www/x264/x264_aq.5-474.zip

I guess this is the correct way to fix the patch, but if not please correct me, so I don't compile potentially broken builds.

that is correct. each one has to have it's own id. so the overlapping id thing is a simple fix.

[hpn]

:thanks:

[squid_80]

that is correct. each one has to have it's own id. so the overlapping id thing is a simple fix.
For the meantime why not give the experimental options high ids (e.g. 998, 999) so they don't need to be changed every time something new is added?

[akupenguin]

...and put them at the beginning of the list, so the patch's context doesn't break

[ChronoCross]

Sounds like a plan. I'll make a patch update for the next revision released.

[max-holz]

Today gpac's cvs update is borked? I have tried to compile with gcc-3.4.5 getting a couple of errors.


os_net.o:os_net.c:(.text+0x173): undefined reference to `getnameinfo'
os_net.o:os_net.c:(.text+0x49a): undefined reference to `getaddrinfo'
os_net.o:os_net.c:(.text+0x4d4): undefined reference to `freeaddrinfo'

[hpn]

rev.479 reduced the number of arguments to some function(s) used in x264_aq.5-xxx.diff, so the patch failed to compile. Hope akupenguin will post a fixed version of the patch when/if he finds time.

@max-holz
Nothing to worry about. Gpac's cvs is often broke, but usually gets fixed within a day or two. Just use some previous Gpac snapshot.

[ChronoCross]

rev.479 reduced the number of arguments to some function(s) used in x264_aq.5-xxx.diff, so the patch failed to compile. Hope akupenguin will post a fixed version of the patch when/if he finds time.

@max-holz
Nothing to worry about. Gpac's cvs is often broke, but usually gets fixed within a day or two. Just use some previous Gpac snapshot.

I need someone to test aq on this build. I think I understand what he changed. This is no way a perfect pathc but it MAY work.

WARNING: HIGHLY EXPERIMENTAL
http://chronocrossdev.com/apps/x264/479/x264.exe

I'll make another build once I know if this works....if it doesn't I'll release an official version without AQ.

[hpn]

@ChronoCross
rev.479 (vs. 478) only improves the encoding speed (plus 2k smaller .exe), so you could easily test if your new AQ patch is correct. Just make 2 AQ encodes with 478+old patch and 479+new patch and compare the encodes. It they are bit-identical your new AQ patch is (most likely) fine.

[ChronoCross]

unfortunately I don't have suitable test material available atm. which is why I asked lol

I updated the binary again, I screwed up the patch update. now it should be using the correct value.

[bob0r]

Gpac compiling is indeed broken:


ranlib ../bin/gcc/libgpac_static.a
gcc -shared -Wl,--warn-common -export-symbols libgpac.def -o ../bin/gcc/libgpac.dll *.o -lm -lws2_32 -lwinmm -lz
os_net.o(.text+0x173):os_net.c: undefined reference to `getnameinfo'
os_net.o(.text+0x49a):os_net.c: undefined reference to `getaddrinfo'
os_net.o(.text+0x4d4):os_net.c: undefined reference to `freeaddrinfo'
os_net.o(.text+0x1171):os_net.c: undefined reference to `getnameinfo'
os_net.o(.text+0x1205):os_net.c: undefined reference to `getaddrinfo'
os_net.o(.text+0x1221):os_net.c: undefined reference to `freeaddrinfo'
os_net.o(.text+0x1346):os_net.c: undefined reference to `getaddrinfo'
os_net.o(.text+0x1368):os_net.c: undefined reference to `freeaddrinfo'
make[1]: *** [libgpac.dll] Error 1
make[1]: Leaving directory `/home/user/gpac/src'
make: *** [lib] Error 2


But the required file for x264, libgpac_static.a, is working fine, so you can compile x264 just fine.
But indeed, gpac compiling and broken quite often, just report it and we can fall back on an older version, which is not needed now.
Thanks for the report!

[celtic_druid]

Problem is IPV6.

#ifdef IPV6_MULTICAST_IF
#pragma message("using WinSock IPV6")
#define GPAC_IPV6 1

Need to comment out
//#define GPAC_IPV6 1

Or I guess have the appropriate header files. Whatever they are. Either way IPV6 support is going to have zero effect on x264.

[max-holz]

Either way IPV6 support is going to have zero effect on x264.

Yes I saw, thanks celtic_druid

[emmel]

I already posted this in another thread, but its the header ws2tcpip.h of the newest mingw that seems to be broken:

#if (_WIN32_WINNT >= 0x0501)
void WSAAPI freeaddrinfo (struct addrinfo*);
blaablaa....
#else
/* FIXME: Need WS protocol-independent API helpers. */
#endif

[celtic_druid]

Really though if configure doesn't detect IPv6, then the code in question shouldn't be compiled.

[ChronoCross]

gpac update today fixes the problems from a few days ago. the libs compile fine now so update while you can.

[max-holz]

gpac update today fixes the problems from a few days ago. the libs compile fine now so update while you can.

I can't see any today's update in the cvs. Latest update for me is already borked. I have cancelled my gpac dir and done a cvs checkout. Then I recompile and the annoying problem with IPV6 is still there. ChronoCross are you drunk? :D


os_net.o(.text+0x173):os_net.c: undefined reference to `getnameinfo'
os_net.o(.text+0x49a):os_net.c: undefined reference to `getaddrinfo'
os_net.o(.text+0x4d4):os_net.c: undefined reference to `freeaddrinfo'
os_net.o(.text+0x1171):os_net.c: undefined reference to `getnameinfo'
os_net.o(.text+0x1205):os_net.c: undefined reference to `getaddrinfo'
os_net.o(.text+0x1221):os_net.c: undefined reference to `freeaddrinfo'
os_net.o(.text+0x1346):os_net.c: undefined reference to `getaddrinfo'
os_net.o(.text+0x1368):os_net.c: undefined reference to `freeaddrinfo'


P.S. If you aren't sure, browse the repository via HTTP and tell me which are the files updated.

[leowai]

Some here. Not new update check out so far since last nite.

Default cvs update setting will not give a clean update of gpac. Modified files will be merged in the in the cvs update process (default settings). ChronoCross did you have clean download of the gpac source?

[max-holz]

For Emmel

I have tried with a patched copy of ws2tcpip.h but still I get a couple of errors, I resaid that gpac is actually borked.

[ChronoCross]

it works fine for me in compilation of the lib files. they work fine with x264. i mean it throws alot of warnings but those should have no impact on the compilation. at least not for me anyway.

[lcx]

@max-holz

None of the functions in os_net.c are needed for x264.
You can just exclude it and any other files that use os_net from your build.

[max-holz]

@max-holz

None of the functions in os_net.c are needed for x264.
You can just exclude it and any other files that use os_net from your build.

Yes I know perfectly that I can patch os_net and I do it, but you can't exclude it from compilation even if IPV6 support is not detected from configure as celtic_druid said; this is another bug of the actually cvs. I could suppose that others include files not in the mingw package are needed.

[hellfred]

Hi there
I have checked gpac out today and build the libs and apps under debian linux (kanotix live dvd installed to hd). Just wanted to mention that after ./configure; make lib; make install-lib; make apps; make install
MP4Box did not find libgpac.so. The shared libary was compiled, but is not installed to /usr/local/lib. So I had to
install -m644 bin/gcc/libgpac.so /usr/local/lib/libgpac.so
chmod +x /usr/local/lib/libgpac.so
ldconfig
I am sure there are more elegant ways to get this done, but it worked out for me and might help others, too.

Hellfred

[max-holz]

Hi there
I have checked gpac out today and build the libs and apps under debian linux (kanotix live dvd installed to hd). Just wanted to mention that after ./configure; make lib; make install-lib; make apps; make install
MP4Box did not find libgpac.so. The shared libary was compiled, but is not installed to /usr/local/lib. So I had to
install -m644 bin/gcc/libgpac.so /usr/local/lib/libgpac.so
chmod +x /usr/local/lib/libgpac.so
ldconfig
I am sure there are more elegant ways to get this done, but it worked out for me and might help others, too.

Hellfred

Thanks hellfred, but the I'am speaking about it's probably a win32 compilation prob.

[hellfred]

Thanks hellfred, but the I'am speaking about it's probably a win32 compilation prob.You are right, this information will not help to workaround the bugs in the building process. But the topic of this thread in x264 compilation, gpac is needed for mp4 output and there is no restriction to win32. I just felt this piece of information might help another newbie to get the most out of his gpac compilation, that is mp4box for muxing the video stream from x264 together with some audio tracks. Just video and no sound is somewhat unsatifying :)

Hellfred

[lcx]

With command:
yasm -f win32 -DPREFIX -o dct-a.obj i386\dct-a.asm

I get the following errors:
dct-a.asm:272: label or instruction expected at start of line
dct-a.asm:272: label or instruction expected at start of line
dct-a.asm:280: label or instruction expected at start of line
dct-a.asm:280: label or instruction expected at start of line
dct-a.asm:287: label or instruction expected at start of line
dct-a.asm:288: label or instruction expected at start of line
dct-a.asm:289: label or instruction expected at start of line
dct-a.asm:290: label or instruction expected at start of line


Anyone know if I am doing something wrong or this is a bug in yasm?
I tried the latest yasm daily build with no luck.
Albeit, It does assemble in nasm.

[lcx]

Wow!
I reported the issue with yasm yesterday and this morning I wake up to find its fixed!
aku works extermely fast.

Thanks!

[lcx]

Changeset 504 libx264.dsp line 28

CPP=xicl6.exe


What compiler on windows is named xicl6 the default MSVC compiler is cl.exe ?

And whats up with the change to remove MP4 output from x264.vcproj?

[leowai]

And whats up with the change to remove MP4 output from x264.vcproj?
I think you need manually add in gpac library and some setup in order to get mp4 output supported. x264 project by it own do not support mp4 output.

[lcx]

OK I realize what is happening here.
The change must have come from omion.

He has a little weird way of compiling x264.
In addition, by default, gpac is somewhat broken on Win64 until you muck around with the gpac files -- so he must have removed gpac from the project.

[akupenguin]

The rationale given to me was:
gpac was assumed to be in "..\..\..\gpac\bin\w32_deb\libgpac_static.lib". This was a completely bogus path, and there was no good way to detect whether it exists, let alone search for gpac somewhere else.

Unless someone wants to write a .bat equivalent to the configure script, or however that's done...

[omion]

OK I realize what is happening here.
The change must have come from omion.

He has a little weird way of compiling x264.
In addition, by default, gpac is somewhat broken on Win64 until you muck around with the gpac files -- so he must have removed gpac from the project.
Wow, what a great theory! I don't compile my builds with GPAC, therefore I changed it so nobody else would either!

FYI, I had no say in the patch whatsoever. Nor does it look like somebody just took my version of the files and submitted them. I had nothing to do with this.

I don't know how you meant your post to be read, but it comes off very accusatory. Do you think you could have asked if I did it before you jump to your own conclusions? It's generally considered more civil than just blindly pointing fingers.

[squid_80]

I believe the include path for the gpac lib came from me, way back when the windows 64 stuff was imported. I keep x264 in l:\x264 and gpac in l:\gpac. I don't expect everyone to do the same, that's just how I had it set up and it ended up like that in x264's SVN. Now it's fixed.

There's nothing wrong with gpac on 64-bit either. At least, nothing more than the same problems it has on 32-bit.

[shin_san]

Hi all, I am a newbee and just need the x264 library to encode some parts of video in an existing vc++ project.

I use msvc 6 + sp6 + nasm + x264-snapshot-20060412-2245 and when I compile, I have 60 syntax errors with \encoder\rdo.c and some other with encoder\macroblock.c ... :(

May somebody help me?

[squid_80]

Maybe if you gave us a bit of a hint what the errors actually are.

[devaster]

by compiling in MSVS 2005 (latest platform,directx and windows media SDK) i get this error :
Error 1 error PRJ0019: A tool returned an error code from "Assembly ...\X264\trunk\common\i386\quant-a.asm"

what is this ??? :confused: :confused: :confused:

oh i forgot ... trying compile under XP x64 edition for debug x32 architecture ...

[lcx]

by compiling in MSVS 2005 (latest platform,directx and windows media SDK) i get this error :
Error 1 error PRJ0019: A tool returned an error code from "Assembly ...\X264\trunk\common\i386\quant-a.asm"

what is this ??? :confused: :confused: :confused:

oh i forgot ... trying compile under XP x64 edition for debug x32 architecture ...

Do you have yasm (or nasm) installed ?
If so, What error message does executing the following from the cmd-line return?

yasm32 -f win32 -DPREFIX -o quant-a.obj quant-a.asm

[shin_san]

Hi all, I am a newbee and just need the x264 library to encode some parts of video in an existing vc++ project.

I use msvc 6 + sp6 + nasm + x264-snapshot-20060412-2245 and when I compile, I have 60 syntax errors with \encoder\rdo.c and some other with encoder\macroblock.c ...

May somebody help me?

It s OK, I fixed the problem!!! :)

[bob0r]

would you mind sharing what the problem was?
Information is Power, and Power leads to:

topic- '#x264 - opensource MPEG-4 AVC / H.264 user dicussion - for development see #x264dev - http://videolan.org/x264.html - x264 wins Doom9 codec comparison - will take over the world next'
topic- set by pengvado (Tue 7th Mar 2006 02:38a)

[devaster]

I fixed it : I remove x64 WXP (for today a piece of sh*t ...) iam back on x32 ... but i must reinstall msvs2005 and after this i'll try it ... thanx for reply ...

[shin_san]

Sorry...
I had to replace
if (delta > 32767ll || delta < -32768ll)

by

if (delta > 32767I64 || delta < -32768I64)

in matroska.c

Now it compiles but if I want to #define AVIS_INPUT,
I included <windows.h> and <vfw.h> and liked vfw32.lib, but I have linking problems:

Linking...
x264.obj : error LNK2001: unresolved external symbol _close_file_avis
x264.obj : error LNK2001: unresolved external symbol _read_frame_avis
x264.obj : error LNK2001: unresolved external symbol _get_frame_total_avis
x264.obj : error LNK2001: unresolved external symbol _open_file_avis
bin/x264.exe : fatal error LNK1120: 4 unresolved externals
Error executing link.exe.

x264.exe - 5 error(s), 38 warning(s)

I haven t found any help on the x264-dev posts...

[squid_80]

Those functions are in muxers.c. Did you define #AVIS_INPUT for the whole project or just x264.c?

[shin_san]

only in 264.c ... :confused:

[squid_80]

So define #AVIS_INPUT for muxers.c as well...

[shin_san]

OK, I am a fool...
:stupid:
now it s working :) when I define if in the whole project. Thanks a lot.

[lcx]

In Visual C++ 2005 the following changes in macroblock.h of revision 520 does not compile
static const int x264_pred_i4x4_neighbors[13] =
{
[I_PRED_4x4_HU] = MB_LEFT,
[I_PRED_4x4_H] = MB_LEFT,
[I_PRED_4x4_HD] = MB_LEFT | MB_TOPLEFT | MB_TOP,
[I_PRED_4x4_DDR] = MB_LEFT | MB_TOPLEFT | MB_TOP,
[I_PRED_4x4_VR] = MB_LEFT | MB_TOPLEFT | MB_TOP,
[I_PRED_4x4_V] = MB_TOP,
[I_PRED_4x4_VL] = MB_TOP | MB_TOPRIGHT,
[I_PRED_4x4_DDL] = MB_TOP | MB_TOPRIGHT,
[I_PRED_4x4_DC] = MB_LEFT | MB_TOP,
[I_PRED_4x4_DC_LEFT] = MB_LEFT,
[I_PRED_4x4_DC_TOP] = MB_TOP,
[I_PRED_4x4_DC_128] = 0
};

So I changed it to
static const int x264_pred_i4x4_neighbors[13] =
{
MB_TOP, //I_PRED_4x4_V
MB_LEFT, //I_PRED_4x4_H
MB_LEFT | MB_TOP, //I_PRED_4x4_DC
MB_TOP | MB_TOPRIGHT, //I_PRED_4x4_DDL
MB_LEFT | MB_TOPLEFT | MB_TOP, //I_PRED_4x4_DDR
MB_LEFT | MB_TOPLEFT | MB_TOP, //I_PRED_4x4_VR
MB_LEFT | MB_TOPLEFT | MB_TOP, //I_PRED_4x4_HD
MB_TOP | MB_TOPRIGHT, //I_PRED_4x4_VL
MB_LEFT, //I_PRED_4x4_HU
MB_LEFT, //I_PRED_4x4_DC_LEFT
MB_TOP, //I_PRED_4x4_DC_TOP
0 //I_PRED_4x4_DC_128
};

Is this correct?

[ayanonline]

I have installed gpac-0.4.2-rc2 in my linux fedora core 5 system but when ever I am running MP4Box command it is givving the following error:
MP4Box: error while loading shared libraries: /usr/lib/libgpac.so: cannot restore segment prot after reloc: Permission denied

I have done even chmod 777 libgpac.so and tried to reinstall the total package for several times.

Plzzz suggest what to do.

Thanx in advance.

[bob0r]

In order to compile rev 574 i had to update strip.exe

My old mingw version (mingw that is up to date):
GNU strip 2.15.91 20040904

updated to:

GNU strip 2.16.91 20060119


I got it from someone in #x264, but i believe its in some mingw release candidate.

[hpn]

@Sharktooth, what are your current CFLAGS "custom" options that you build x264 with?
I'm struggling to find some extra stuff to add to the default CFLAGS in the configure (-O4 -ffast-math -fomit-frame-pointer), but seems -O4 implies every possible optimization, so nothing more can be added ( O4 == O3 ? ). Am I wrong?

(except for -march=athlon-xp that seems marginally faster on my CPU despite the asm code in x264, but of course this can't be used for generic builds)

[Sharktooth]

O4 doesnt exist... that means it's the same as O3.
when i have some time i will test:
-floop-optimize2
-funsafe-loop-optimizations
-freorder-blocks-and-partition
-ffloat-store
-funsafe-math-optimizations (edit: useless, already included in -ffast-math)
-fsingle-precision-constant

Pay particular attention to all the FP optimizations. x264 rate control doesnt require ultra precise FP operations, so those opts "should" not screw the results.
Also i do not include those options in my daily builds... they need testing (they may also need GCC 4.1.x, i didnt check if those work on earlier versions).
As for -march i use pentium2 as default

[akupenguin]

Pay particular attention to all the FP optimizations. x264 rate control doesnt require ultra precise FP operations, so those opts "should" not screw the results.
Yes, but by the same token x264 doesn't spend much time doing FP math, so optimizing it doesn't gain much speed. The total amount of time spent in ratecontrol is 0.02% without any FP-specific compile options. So what you really want is options to reduce the size of FP code, possibly at a cost to both precision and speed, because cache effects will make more difference than any direct optimization of FP code.

[Sharktooth]

that's why i want to try -ffloat-store and -fsingle-precision-constant...
those will help optimizing the registers usage (and -freorder-blocks-and-partition will help with paging and cache locality performance).

-ffloat-store
Do not store floating point variables in registers, and inhibit other options that might change whether a floating point value is taken from a register or memory.

This option prevents undesirable excess precision on machines such as the 68000 where the floating registers (of the 68881) keep more precision than a double is supposed to have. Similarly for the x86 architecture. For most programs, the excess precision does only good, but a few programs rely on the precise definition of IEEE floating point. Use -ffloat-store for such programs, after modifying them to store all pertinent intermediate computations into variables.

-fsingle-precision-constant
Treat floating point constant as single precision constant instead of implicitly converting it to double precision constant.
i cant think of anything better to do with CFLAGS. Any ideas are welcome...

[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...

[Cef]

In my builds, strtok_r is coming from pthread.h
#if !defined(__MINGW32__)
#define strtok_r( _s, _sep, _lasts ) \
( *(_lasts) = strtok( (_s), (_sep) ) )
#endif /* !__MINGW32__ */

[bob0r]

Yeah, same here, but i get that error anyway.
Hopefully pengvado returns soon and we can have this fixed.
I am sure he will know what to do.

[Cef]

Are you sure __MINGW32__ isn't defined ? You shouldn't get "undefined reference to `strtok_r'" since this define replaces strtok_r with a call to strtok.
I'm getting the same error when I try to compile without HAVE_PTHREAD

[bob0r]

Ok, a kind friend in #x264 told me temp solution for Mingw:

file: encoder/ratecontrol.c


#include <assert.h>

#include "common/common.h"


Change to, add:


#include <assert.h>

#if defined(__MINGW32__)
#define strtok_r( _s, _sep, _lasts ) \
( *(_lasts) = strtok( (_s), (_sep) ) )
#endif /* __MINGW32__ */

#include "common/common.h"


For Cygwin users:


#include <assert.h>

#if defined(SYS_CYGWIN)
#define strtok_r( _s, _sep, _lasts ) \
( *(_lasts) = strtok( (_s), (_sep) ) )
#endif /* SYS_CYGWIN*/

#include "common/common.h"

[TheRyuu]

Well, x264 seems to be completely random when it comes to compiling it.
The above does help.

I'm sure there's something I must be doing, but I'm just not sure what it is.

I keep getting this "invalid operands in non-64bit mode" or something like that. So annoying.

I managed to get it compiled a few times. Then it doesn't compile anymore when god knows what happened.

I also sometimes get this non-referenced error to some ssse3 files. No idea where they came from.

[TheRyuu]

I can successfully build x264. I can also now consistently build x264 :)

Problem is now my build is crashing.
Not only do I get these errors on the first pass, but the second pass doesn't even run.
http://img522.imageshack.us/img522/3927/x264builderrorcc4.jpg

I get the error with GCC 4.3.0 (experimental), GCC 4.2.0 (latest stable), and even the fall back stable GCC 3.4.4.
This is with our without custom flags.

I don't get what I'm doing wrong. Everything seems to build fine.

I'd love to know what I'm doing wrong.
Thanks. :thanks:

@Cef
What flags are you using to compile x264? (probably been asked before)
I'm not getting an exe near the size of the one you release in your builds. Does it have something to do with -march=i686 with -mtune=pentium3 (as an example, using both march and mtune?)

[squid_80]

Those errors are coming from your source (are you using ffmpegsource?) not x264.

[TheRyuu]

Those errors are coming from your source (are you using ffmpegsource?) not x264.

Well, I'm using the x264 SVN, and I've also tried the source from the page were Cef's builds are. Both give me that.

Oh, you mean the source of the file.
Well, I'm using directshowsource. Only the difference is Cef's builds don't give me that error. My builds do.

Why?

:thanks:

[squid_80]

Because the matroska @ errors and the libavcodec message aren't coming from x264 at all, they're being spit out by libavcodec which is probably being used by ffdshow, which is probably being used by directshowsource to decode the original video. It's not an x264 issue.

[TheRyuu]

Because the matroska @ errors and the libavcodec message aren't coming from x264 at all, they're being spit out by libavcodec which is probably being used by ffdshow, which is probably being used by directshowsource to decode the original video. It's not an x264 issue.

Yes, but why are Cef's build NOT giving me that error on the same file that my builds are?
Is there an option that may be set differently so that Cef's builds are still getting the error only I'm not seeing it? (like debug mode is enabled on mine?)

And yes, libavcodec is being used by ffdshow for the file.

But the fact that Cef's builds are working and mine aren't is what is bothering me. I'll try a d2v source next. See if I get any errors.

[TheRyuu]

Well, my builds just seem to be full of problems.
Now I can build it (consistently), and run it without the error (was the source, and it was using ffmpegsource, switched it to directshowsource())

Now, my second pass always crashes it.
Always something isn't it.

I'm real close to just giving up and using Cef's builds :)

:thanks:

[Sagittaire]

http://forum.doom9.org/showthread.php?p=723782#post723782

It's really good and simple faq ... :goodpost:

But how enable multithread ... ?


configure --enable-avis-input --enable-mp4-output --enable-pthread --extra-cflags="-Ic:/gpac/include" --extra-ldflags="-Lc:/gpac/bin/gcc"

Don't work for me ... ???

[Dark Shikari]

http://forum.doom9.org/showthread.php?p=723782#post723782

It's really good and simple faq ... :goodpost:

But how enable multithread ... ?


configure --enable-avis-input --enable-mp4-output --enable-pthread --extra-cflags="-Ic:/gpac/include" --extra-ldflags="-Lc:/gpac/bin/gcc"

Don't work for me ... ???It'll enable automatically if you have the proper libraries installed in GCC. You need pthreads for windows, I believe.

[Sharktooth]

yep, get pthread for win and it will work.
i usually compile myself pthreads with -O3 -march=pentium2 -fomit-frame-pointer too

[Sagittaire]

yep, get pthread for win and it will work.
i usually compile myself pthreads with -O3 -march=pentium2 -fomit-frame-pointer too

Where I can find pthread for win?

[Dark Shikari]

yep, get pthread for win and it will work.
i usually compile myself pthreads with -O3 -march=pentium2 -fomit-frame-pointer too
Add -funroll-loops to that, very useful.

[Sharktooth]

i think it's already there too... ;)

@Sagittaire: http://sourceware.org/pthreads-win32/

[Sagittaire]

i think it's already there too... ;)

@Sagittaire: http://sourceware.org/pthreads-win32/

last question ... :helpful:

where install these .dll, .lib ... ???

[bob0r]

cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/pthreads-win32 checkout pthreads

configure
make clean GC-static
copy *.h to include dir
copy libpthreadGC2.a to lib dir

[muneebel]

Hi All

I have am new to x264. I have downloaded snapshot of x264. I want to compile x264 under linux. when I ran the configure script and ran make it compiles successfully. But when I ran the configure script and want to compile it under the code::blocks IDE using gcc under linux I get error messages. I have checked the source tree and there are some files in the encoder and common folder that have the same name and I think thats where the problem lies. I would appreciate if anyone can help me in compiling the x264 under Linux IDE environment such as code::blocks.

Thanks

[vicfred]

im gettin this error when i use configure (i used hpn tutorial)

Vicfred@PC /c/gpac
$ configure
error: zlib not found on system or in local libs

any idea?

[foxyshadis]

gpac compilation doesn't really go here, but the message is pretty explicit. You just need to download zlib, make and make install it. (Along with any dependencies it may have... lots of fun chasing down everything the first time.)

[mitsubishi]

Has anyone got any hints to compiling with VS2008? I got it compiled and running fine, but only with pthreads.dll. It runs as quick as official builds single threaded, but is a bit slower multithreaded. I managed to convince it to compile with pthreads statically, but then it throws an exception when running :(

I don't suppose it really matters, since I don't know c, so it's unlikely I can contribute, I just wanted to find out more about how rate control works for something I was working on, which I can do as-is.

EDIT: NM, I fixed it, I had defined "PTW32_STATIC_LIB" in libx264, but not in x264 project

[mitsubishi]

For those that are interested, it appears to be a fraction quicker when compiled with VS2008 to the x264.nl builds, on my machine at least. Over a series of tests, I'm getting a 1%ish increase.

The quickest build I got (this is really far too close to call though, so a fairly meaningless statement) seemed to be with yasm and not telling VS to use SSE2.

[hpn]

For those that are interested, it appears to be a fraction quicker when compiled with VS2008 to the x264.nl builds, on my machine at least. Over a series of tests, I'm getting a 1%ish increase.

Would you upload your build somewhere so I can test it?

[mitsubishi]

Would you upload your build somewhere so I can test it?

Sure, this is the one which seemed fastest on my my c2d: http://www.mediafire.com/?dsz3znil34l

BTW it was built from svn 719 and doesn't contain mp4 support.

[bob0r]

Compiling Gpac lib on Mingw is broken:

cvs -z3 -d:pserver:anonymous@gpac.cvs.sourceforge.net:/cvsroot/gpac co -P gpac
cd gpac
configure
make lib

Results in:
gcc -O3 -fno-strict-aliasing -Wall -I/home/user/gpac/include -c -o terminal/inline.o terminal/inline.c
terminal/inline.c:1513: error: conflicting types for 'gf_inline_set_fragment_uri'
F:/msys/home/user/gpac/include/gpac/internal/terminal_dev.h:206: error: previous declaration of 'gf_inline_set_fragment_uri' was here
terminal/inline.c:1513: error: conflicting types for 'gf_inline_set_fragment_uri'
F:/msys/home/user/gpac/include/gpac/internal/terminal_dev.h:206: error: previous declaration of 'gf_inline_set_fragment_uri' was here
make[1]: *** [terminal/inline.o] Error 1
make[1]: Leaving directory `/home/user/gpac/src'
make: *** [lib] Error 2

What would be the best way of contacting the coder(s)?

[bob0r]

1.68 is compiling again :)

[vicfred]

i need some help installing pthreads to compile it with x264 source :)

trying this
http://forum.doom9.org/showpost.php?p=1046796&postcount=469

but i get this error when i try configure
Vicfred@MAGGIE ~/pthreads
$ ./configure
sh: ./configure: No such file or directory

[leoenc]

i need some help installing pthreads to compile it with x264 source :)


See end of this thread:
http://forum.doom9.org/showthread.php?t=134260&highlight=pthreads

[bob0r]

1: cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/pthreads-win32 checkout pthreads
2: cd pthreads
3: make clean GC-static
4: copy libpthreadGC2.a to your LIB dir.
5: copy pthread.h, sched.h and semaphore.h to your INCLUDE dir.

(6: run configure with no options for x264 and let it detect pthreads: pthread: yes)

[techouse]

Hey!

I tried cross compiling x264 with Debian Lenny/Sid (amd64) today and I can't seem to get pthreads working. Here's what I did:

1. apt-get install mingw32 mingw32-binutils mingw32-runtime
2. cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/pthreads-win32 checkout pthreads
3. cd pthreads
4. make CROSS=-i586-mingw32msvc- clean GC-static
5. cp libpthreadGC2.a /usr/i586-mingw32msvc/lib
6. cp pthread.h /usr/i586-mingw32msvc/include
7. cp semaphore.h /usr/i586-mingw32msvc/include
8. cp sched.h /usr/i586-mingw32msvc/include
9. cd x264
10. ./configure --host=i586-mingw32msvc

I got this output:

techouse@Mk2:/x264$ sudo ./configure --host=i586-mingw32msvc
Platform: X86
System: MINGW
avis input: yes
mp4 output: no
pthread: no
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no

I got the same with these additional ./configure options:
--extra-cflags=-I/usr/i586-mingw32msvc/include
--extra-ldflags=-I/usr/i586-mingw32msvc/lib

--extra-cflags=-I/pthreads
--extra-ldflags=-I/pthreads



Can anyone help me out on this one?

EDIT

LOL! I just did the same thing on my laptop (Debian Lenny/Sid i386) and i get this output:

memi@Satellite:/x264$ sudo ./configure --host=i586-mingw32msvc
Platform: X86
System: MINGW
avis input: yes
mp4 output: no
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no

Must be cause I'm using i386.

EDIT v2

I get errors when running make.

memi@Satellite:/x264$ sudo ./configure --host=i586-mingw32msvc
Platform: X86
System: MINGW
avis input: yes
mp4 output: no
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no

You can run 'make' or 'make fprofiled' now.
memi@Satellite:/x264$ sudo make CROSS=-i586-mingw32msvc-
rm -f .depend
( echo -n "`dirname common/mc.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer common/mc.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname common/predict.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer common/predict.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname common/pixel.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer common/pixel.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname common/macroblock.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer common/macroblock.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname common/frame.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer common/frame.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname common/dct.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer common/dct.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname common/cpu.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer common/cpu.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname common/cabac.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer common/cabac.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname common/common.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer common/common.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname common/mdate.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer common/mdate.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname common/set.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer common/set.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname common/quant.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer common/quant.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname encoder/analyse.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer encoder/analyse.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname encoder/me.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer encoder/me.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname encoder/ratecontrol.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer encoder/ratecontrol.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname encoder/set.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer encoder/set.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname encoder/macroblock.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer encoder/macroblock.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname encoder/cabac.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer encoder/cabac.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname encoder/cavlc.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer encoder/cavlc.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname encoder/encoder.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer encoder/encoder.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname encoder/eval.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer encoder/eval.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname common/i386/mc-c.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer common/i386/mc-c.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname common/i386/predict-c.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer common/i386/predict-c.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname x264.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer x264.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname matroska.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer matroska.c -MM -g0 ) 1>> .depend; ( echo -n "`dirname muxers.c`/" && gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer muxers.c -MM -g0 ) 1>> .depend;
gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer -c -o x264.o x264.c
gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer -c -o matroska.o matroska.c
gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer -c -o muxers.o muxers.c
muxers.c:33:21: error: windows.h: No such file or directory
muxers.c:34:17: error: vfw.h: No such file or directory
muxers.c:328: error: expected specifier-qualifier-list before ‘PAVISTREAM’
muxers.c: In function ‘open_file_avis’:
muxers.c:335: error: ‘AVISTREAMINFO’ undeclared (first use in this function)
muxers.c:335: error: (Each undeclared identifier is reported only once
muxers.c:335: error: for each function it appears in.)
muxers.c:335: error: expected ‘;’ before ‘info’
muxers.c:340: warning: implicit declaration of function ‘AVIFileInit’
muxers.c:341: warning: implicit declaration of function ‘AVIStreamOpenFromFile’
muxers.c:341: error: ‘avis_input_t’ has no member named ‘p_avi’
muxers.c:341: error: ‘streamtypeVIDEO’ undeclared (first use in this function)
muxers.c:341: error: ‘OF_READ’ undeclared (first use in this function)
muxers.c:343: warning: implicit declaration of function ‘AVIFileExit’
muxers.c:347: warning: implicit declaration of function ‘AVIStreamInfo’
muxers.c:347: error: ‘avis_input_t’ has no member named ‘p_avi’
muxers.c:347: error: ‘info’ undeclared (first use in this function)
muxers.c:349: warning: implicit declaration of function ‘AVIStreamRelease’
muxers.c:349: error: ‘avis_input_t’ has no member named ‘p_avi’
muxers.c:355: warning: implicit declaration of function ‘MAKEFOURCC’
muxers.c:361: error: ‘avis_input_t’ has no member named ‘p_avi’
muxers.c:367: error: ‘avis_input_t’ has no member named ‘width’
muxers.c:369: error: ‘avis_input_t’ has no member named ‘height’
muxers.c: In function ‘get_frame_total_avis’:
muxers.c:386: error: ‘AVISTREAMINFO’ undeclared (first use in this function)
muxers.c:386: error: expected ‘;’ before ‘info’
muxers.c:388: error: ‘avis_input_t’ has no member named ‘p_avi’
muxers.c:388: error: ‘info’ undeclared (first use in this function)
muxers.c: In function ‘read_frame_avis’:
muxers.c:400: warning: implicit declaration of function ‘AVIStreamRead’
muxers.c:400: error: ‘avis_input_t’ has no member named ‘p_avi’
muxers.c:400: error: ‘avis_input_t’ has no member named ‘width’
muxers.c:400: error: ‘avis_input_t’ has no member named ‘height’
muxers.c: In function ‘close_file_avis’:
muxers.c:409: error: ‘avis_input_t’ has no member named ‘p_avi’
make: *** [muxers.o] Error 1
memi@Satellite:/x264$

Has anyone got any idea how to solve this windows.h and vfw.h (I HAVE THEM BOTH INSTALLED!!!) dependency error.

memi@Satellite:/usr/i586-mingw32msvc/include$ ls windows.h vfw.h
vfw.h windows.h

[Henrikx]

x264 core:59 r820+7 bd7b626 (Ubuntu 7.10)
What does mean +7?

[SpAwN_gUy]

does anyone has troubles with r821.. under MSVC?

i've changed frame.c from (diff from 820 to 821... part of..)
@@ -55,20 +56,20 @@ x264_frame_t *x264_frame_new( x264_t *h )
frame->i_stride[i] = i_stride >> !!i;
frame->i_width[i] = i_width >> !!i;
frame->i_lines[i] = i_lines >> !!i;
- CHECKED_MALLOC( frame->buffer[i],
- frame->i_stride[i] * (i_lines + 2*i_padv) >> !!i );
- frame->plane[i] = ((uint8_t*)frame->buffer[i]) +
- ((frame->i_stride[i] * i_padv + PADH) >> !!i);
}

- frame->filtered[0] = frame->plane[0];
- for( i = 0; i < 3; i++ )
+ luma_plane_size = (frame->i_stride[0] * ( frame->i_lines[0] + 2*i_padv ));
+ for( i = 1; i < 3; i++ )
{
- CHECKED_MALLOC( frame->buffer[4+i],
- frame->i_stride[0] * ( frame->i_lines[0] + 2*i_padv ) );
- frame->filtered[i+1] = ((uint8_t*)frame->buffer[4+i]) +
- frame->i_stride[0] * i_padv + PADH;
+ CHECKED_MALLOC( frame->buffer[i], luma_plane_size/4 );
+ frame->plane[i] = (uint8_t*)frame->buffer[i] + (frame->i_stride[i] * i_padv + PADH)/2;
}
+ /* all 4 luma planes allocated together, since the cacheline split code
+ * requires them to be in-phase wrt cacheline alignment. */
+ CHECKED_MALLOC( frame->buffer[0], 4*luma_plane_size);
+ for( i = 0; i < 4; i++ )
+ frame->filtered[i] = (uint8_t*)frame->buffer[0] + i*luma_plane_size + frame->i_stride[0] * i_padv + PADH;
+ frame->plane[0] = frame->filtered[0];

if( h->frames.b_have_lowres )
{ is it the proper solution?

[audyovydeo]

if anyone has made a windows build with visualize=yes, I'd love to try it. Even oldish version is OK.


cheers
a/v

[SpAwN_gUy]

if anyone has made a windows build with visualize=yes, I'd love to try it. Even oldish version is OK. .. and anyone knows what is needed? to compile with it?
some visualize library? (i guess i've seen some lib in linux for that)

UPD: i guess... it is NOT possible under Win (at least as i can see)... it is X11 (www.x.org) only.. and that is, Linux, Solaris and BSD systems...

btw... what does it do? outputs video in textmode?

[nm]

btw... what does it do? outputs video in textmode?
x264 --longhelp:
--visualize Show MB types overlayed on the encoded video

[DarkZell666]

x264 --longhelp:
--visualize Show MB types overlayed on the encoded video

Which means you'll have Dark Shikari's avatar all over the place :D

[SpAwN_gUy]

Which means you'll have Dark Shikari's avatar all over the place :D
yeah...looks like that :)
(i've found A picture: http://akuvian.org/src/x264/visualize.png )

what a shame... i thought, that i'd see lots of ASCIIart :(

btw... isn't one of the ffdshow's filters otputs motion vectors when video is played?

[techouse]

LOL :p

[LoRd_MuldeR]

According to Gruntster (Avidemux developer) the compilation of x264 as shared library (DLL) is broken on Win32 :(

x264 r826 is hereIt no longer compiles with MSVC6 and the MinGW compilation is still borked. It seems like no one else uses x264 as a DLL.


Can this be confirmed? And if so, any chance it will be fixed?

[bob0r]

Then http://files.x264.nl/libx264-59.826.dll is not working?
Let me know please...

[LoRd_MuldeR]

Nope, Avidemux simply fails with "Filter Init Faild" error message :o

I cannot see any error messages on the log...

[LoRd_MuldeR]

Bobor, where any patches included in your DLL?

Most important: x264.h changed? If so, this might explain the problem...


// EDIT

Gruntster has made a "patched" build with MSVC6 compiler and this one seems to work okay:
http://www.razorbyte.com.au/dev_dump/libx264_r828.zip

[bob0r]

Yes it is this build:
http://forum.doom9.org/showthread.php?p=1127870#post1127870

I should add modified to the .dll filename also, ill do this when i got time, then also compile a clean .dll for you to try :D

[LoRd_MuldeR]

Well, if the interface of the DLL has changed, it won't work with existing Avidemux builds for obvious reasons ;)
It seems Gruntster has manged to build a working x264 DLL with MSVC6. Fresh Avidemux build is available!

So this problem is solved for now...

[Sagittaire]

I have bug with all "git" version (error on cabac).
Someone can help to solve that.

[bob0r]

What error?

[gigah72]

maybe someone can help me with my questions about compilation:
(using mingw 4.3.0 alpha)
1.
i made the pthread.a and put it into the lib folder, also the 3 *.h files in include folder. on configure pthreads is YES, but the resulting exe file needs the pthreads.dll to run. why?

2.
i wanted to apply 2 patches, progressindicator, psyrdo, but both fail:

Administrator@SDFBF-9RX23LR8A /c/x264
$ patch < x264.progress.indication.01.diff -p0
patching file `x264.c'
Hunk #2 succeeded at 776 (offset 25 lines).
Hunk #3 succeeded at 816 (offset -1 lines).
patch unexpectedly ends in middle of line
patch unexpectedly ends in middle of line


Administrator@SDFBF-9RX23LR8A /c/x264
$ patch < x264_psyRDO_0.5.diff -p0
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/common/common.c b/common/common.c
|index 71a29b1..301b9ed 100644
|--- a/common/common.c
|+++ b/common/common.c
--------------------------
File to patch: ./common/common.c
Skip this patch? [y] n
File to patch: /c/x264/common/common.c
Skip this patch? [y] n
File to patch:


source is downloaded with git clone.

3.
then i run make, the build just starts, with fprofiled, i'm asked for avisynthfiles. what do i have to type here, and what is the advantage of fprofiled?

[LoRd_MuldeR]

Maybe "patch -p1 < x264_psyRDO_0.5.diff" works better? Make sure current directory is x264 root directory (that's where x264.h is located).

[martino]

Progress indication patching doesn't really fail. If you inspect the patched x264.c you'll find out that the diff changes have been applied, however I'd like to know myself why it spits out "patch unexpectedly ends in middle of line".

[Sharktooth]

malformed patch file.
try deleting/adding the/a bottom blank line.

[Trahald]

pthreads comes in more than one version.. you have to compile the static library which will then link as part of x264.exe, not the dynamic (dll) version. see post 481

[gigah72]

patching with "patch -p1 < file.diff" works now, also linking with pthreads works now, i'm not shure if it was correct, but libpthread.a and libpthreadGC2.a is now the same file and the resulting exe works without the dll.
only question remains is about make fprofiled. i cut a scene in vdub, exporting it via ffdshow as uncompressed yv12 avi, but x264 doesn't recognize it. so what exactly do i need to do, to export this scene, that i can use it for fprofile or has someone a source for some free video that makes the job?

[Dark Shikari]

patching with "patch -p1 < file.diff" works now, also linking with pthreads works now, i'm not shure if it was correct, but libpthread.a and libpthreadGC2.a is now the same file and the resulting exe works without the dll.
only question remains is about make fprofiled. i cut a scene in vdub, exporting it via ffdshow as uncompressed yv12 avi, but x264 doesn't recognize it. so what exactly do i need to do, to export this scene, that i can use it for fprofile or has someone a source for some free video that makes the job?It needs a .yuv file--or on Windows, a .avs file.

[LoRd_MuldeR]

Try like this:
make fprofiled VIDS="/c/sample.avs"

BTW: What kind of video is recommended? Resolution? Length? etc... And why is my fprofiled DLL so much smaller? (721 vs. 575 KB)

[Dark Shikari]

Try like this:
make fprofiled VIDS="/c/sample.avs"

BTW: What kind of video is recommended? Resolution? Length? etc... And why is my fprofiled DLL so much smaller? (721 vs. 575 KB)Any ordinary video.

Profiled is smaller because it uses -Os on sections of code that are rarely run.

[LoRd_MuldeR]

Profiled is smaller because it uses -Os on sections of code that are rarely run.

:thanks:

[cacepi]

BTW: What kind of video is recommended? Resolution? Length? etc...
Resolution shouldn't matter much as don't need much information to generate the profile. A few hundred frames are plenty. (In fact, tests 6 & 8 for x264 only use 50 frames). I personally use test sequences:

http://meru.cecs.missouri.edu/free_download/videos/
http://www.w6rz.net/

[gigah72]

great, now fprofiled works, too. :)
but again, some questions:
OPT3 uses -t1, but i patched with psyrdo, so i get a warning. is this something that need to be changed in the makefile to -t0 or -t2, or leave it like it is?
and about optimization: i'm building "-march=k8", but on a coreduo, the k8 is my encoding/htpc and the coreduo my notebook. does this affect the resulting x264.exe in a negative way, e.g. not being fast as possible due to .... (technical stuff)?

[bob0r]

Any ordinary video.

Profiled is smaller because it uses -Os on sections of code that are rarely run.

My fprofiled builds are always bigger than normal builds.
"fprofiled is more information and thus bigger, thats what i thought, hmm"

[LoRd_MuldeR]

My fprofiled builds are always bigger than normal builds.
"fprofiled is more information and thus bigger, thats what i thought, hmm"

I don't think more information will be in the build. More information are collected/analyzed to optimize the build, at compile time.

My fprofiled "libx264.dll" is ~20% smaller than the normal one, using MinGW GCC 4.3.1-tdm-1 and the first 500 frames of the well-known "parkrun" video.

[LoRd_MuldeR]

I just compiled x264 r922 with PsyRDO patch (no B-Frames patch) as DLL, but it crashes on me:
http://www.avidemux.org/admForum/viewtopic.php?id=4945

x264 r920 did work okay for me. Any ideas? :confused:

:thanks:

[bob0r]

@LoRd_MuldeR

Can you try my .dll to confirm?
http://forum.doom9.org/showthread.php?p=1164668#post1164668

[LoRd_MuldeR]

@LoRd_MuldeR

Can you try my .dll to confirm?
http://forum.doom9.org/showthread.php?p=1164668#post1164668

I can't test that DLL with Avidemux, because it includes the "hrd_pulldown" patch, which changes the interface.
For current Avidemux I need either "Psy RDO" patch only, or you need to insert dummy fields for "i_psy_rd" and "f_psy_rd".
Also Gruntster's alignment fix patch is mandatory...

[bob0r]

libx264-60.928.test.01.dll (http://files.x264.nl/libx264-60.928.test.01.dll)

GIT 928 + psyrdo 0.5 patch (TEST ONLY)

configure --enable-shared
make

I see "Add missing x264util.asm", maybe that was the problem... please test :)

[Comatose]

Does fprofiled optimize the compile for a specific kind of video (the kind you give it)?

For example, will a x264 encode that was fprofiled with real life video produce lower quality anime encodes than one that was fprofiled with anime?
What exactly does it do? D:

[bob0r]

Lower quality: NEVER

fprofiled is to optimize for certain x264 options, speedwise.
It never has a negative effect.

[Shinigami-Sama]

Does fprofiled optimize the compile for a specific kind of video (the kind you give it)?

For example, will a x264 encode that was fprofiled with real life video produce lower quality anime encodes than one that was fprofiled with anime?
What exactly does it do? D:

its already been explained in this thread a couple times :P

it anaylizes the code as its running to see if it can figure out ways to make it faster
similar idea to just turning up -O#(s) w/e

[Comatose]

Well, this is a 26 page thread that I expect to be filled with the phrase fprofiled, so... :P

Anyway, thanks =)

[Sharktooth]

there is a "search this thread" function

[K0zi]

I'm trying to compile my own first x264 build using the guide from #166 (hpn) http://forum.doom9.org/showthread.php?p=723782#post723782
Step 18 runs into errors, no matter what versions of tools I use. I copied config.h from the gpac source folder to include/gpac/internal/config.h to work around the first one, but still, end up with this:
http://img6.imageshack.us/img6/2547/70594335.png

[skystrife]

You don't necessarily need a cvs gpac to do the muxing for x264--you could try building from one of the older snapshots on their main page and see if that works.

[Kurtnoise]

seems like compilation fails on Ubuntu 9.04 using the main branch...

ranlib libx264.a
gcc -o x264 x264.o matroska.o muxers.o libx264.a -lm -lpthread -s
libx264.a(ratecontrol.o): In function `init_pass2':
ratecontrol.c:(.text+0x1963): undefined reference to `isfinite'
ratecontrol.c:(.text+0x1bee): undefined reference to `isfinite'
libx264.a(ratecontrol.o): In function `rate_estimate_qscale':
ratecontrol.c:(.text+0x5d40): undefined reference to `isfinite'
ratecontrol.c:(.text+0x62f3): undefined reference to `isfinite'
collect2: ld a retourné 1 code d'état d'exécution
make: *** [x264] Erreur 1
lionel@ubuntu:~/x264$

$ uname -a
Linux ubuntu 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux

$ gcc -v
Utilisation des specs internes.
Target: i486-linux-gnu
Configuré avec: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Modèle de thread: posix
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)


Quite strange though coz it worked last week :confused:...Any hint ?

[Henrikx]

Ubuntu 9.04
$ x264 --help
x264 core:67 r1145 d2e1e1c

De-Install libx264.dev

[Kurtnoise]

I don't use dev package for this compressor...

lionel@ubuntu:~$ find /usr/lib/ -name 'libx264*'
lionel@ubuntu:~$ find /usr/local/lib/ -name 'libx264*'

returns nothing...

[Henrikx]

HOWTO: Install and use the latest FFmpeg and x264
The instructions on the page are for Ubuntu Jaunty Jackalope 9.04

http://ubuntuforums.org/showthread.php?t=786095

[Kurtnoise]

useless for me...it was a conflict with a file header. Problem solved. :)

[LoRd_MuldeR]

I tried to compile x264 with MinGW 4.4.0, but configure fails:

./configure: line 320: die: command not found
Platform: X86
System: MINGW
asm: yes
avis input: no
mp4 output: no
pthread: no
debug: no
gprof: no
PIC: no
shared: yes
visualize: no

You can run 'make' or 'make fprofiled' now.

The line that fails is that one:

$CC $CFLAGS conftest.c -c -o conftest.o 2>$DEVNULL || die "endian test failed"

Any ideas? Did I miss something or is the compiler binary broken?

I used an "unofficial" MinGW build that I found here:
http://www.equation.com/servlet/equation.cmd?call=fortran

[kemuri-_9]

that's the first line something is actually compiled so the compiler is probably broken.

which is not surprising as i've been trying to compile 4.4.0 for mingw and it keeps failing as well.

[LoRd_MuldeR]

that's the first line something is actually compiled so the compiler is probably broken.

which is not surprising as i've been trying to compile 4.4.0 for mingw and it keeps failing as well.

Thanks for info :)

If you get your hands on a working MinGW 4.4.x binary, please let me know ;)

[Mr VacBob]

It's probably a compiler bug; you could take out the "2>$DEVNULL" to see what it prints before failing.

[LoRd_MuldeR]

It's probably a compiler bug; you could take out the "2>$DEVNULL" to see what it prints before failing.

Yeah, it says that the application caused the runtime to terminate in an "unusual" way.

[kemuri-_9]

Thanks for info :)

If you get your hands on a working MinGW 4.4.x binary, please let me know ;)

i got it working finally (at least enough to properly compile x264), but for x264 it's still slower than 3.4.x

on a note on this, due to how x264's configure writes values to TMP (in as_check() and cc_check())
this was crashing my gcc build as this does overwrite the temporary folder location (strangely is only affecting my gcc 4.4.0 x86/x64 builds)
as they were then trying to write to a nonexistent folder.
changing TMP to say TMPVAL and it works like a charm.
you should try this on the build you have, chances are it is the culprit on your side as well.

[LoRd_MuldeR]

on a note on this, due to how x264's configure writes values to TMP (in as_check() and cc_check())
this was crashing my gcc build as this does overwrite the temporary folder location (strangely is only affecting my gcc 4.4.0 x86/x64 builds)
as they were then trying to write to a nonexistent folder.
changing TMP to say TMPVAL and it works like a charm.
you should try this on the build you have, chances are it is the culprit on your side as well.

Hey thanks!

That solved the problem for me too, although I don't understand why renaming a variable in the bash script did fix the crash in GCC :)

In case anybody is interested, my patch is here:
http://mplayer.somestuff.org/misc/libx264/patches/configure-gcc440-fix.diff

Also I noticed that TDM finally has a MinGW 4.4.0 binary too:
http://www.tdragon.net/recentgcc/

BTW: GCC 4.4.0 is flooding the console with even more strange warning when compiling x264 than GCC 4.3.3 did :D

[kemuri-_9]

That solved the problem for me too, although I don't understand why renaming a variable in the bash script did fix the crash in GCC :)

BTW: GCC 4.4.0 is flooding the console with even more strange warning when compiling x264 than GCC 4.3.3 did :D

for the first part, it seems that GCC 4.4.0 is reading the TMP env variable for the location of the temporary folder for writing temp files.
x264's configure currently overwrites the location with the *_check() functions saving to the TMP variable.
so basically trying to save temporary files to a place that doesn't exist is naturally going to cause some failures.

I mentioned this in the dev channel, so it should probably get fixed along side with whatever the next commit will be.

i also noticed that gcc 4.4.0 was extremely angry at x264 with its mountain of "dereferencing pointer {} will break strict-aliasing rules" warnings.