x264 64-bit version,when?

[Kostarum Rex Persia]

I want to know when will arrive a 64-bit version of x264 codec.In September,or sooner.

[CruNcher]

Be patient. It will be out when it's done. Until that you can always compile your own builds with 64bit support. ;)

[Sirber]

IMO XP64 is not ready for "home uses". Also, x264 is pretty MMX optimized, which has issues in 64bit on XP64.

[yokem55]

If you want a 64 bit version of x264, setup 64-bit linux and compile x264 on it. It is unlikely (unless MS fixes the problems on thier end) that there will be a 64 bit version on windows that is any faster than the 32 bit version.

[Sharktooth]

If you want a 64 bit version of x264, setup 64-bit linux and compile x264 on it. It is unlikely (unless MS fixes the problems on thier end) that there will be a 64 bit version on windows that is any faster than the 32 bit version.
What? It's already faster... read the 64 bit xvid thread or other 64 bit software benchies done by various websites on Win64...

[Kostarum Rex Persia]

Ok,but I expect a 64 bit version of x264 until the november.I hope that is possible.

[Sharktooth]

expectations leads to rumors... and rumors are usually bad...
dont expect a win64 x264 version until (and IF!!!) it gets announced.

[Doom9]

Ok,but I expect a 64 bit version of x264 until the november.If you have a signed and paid for contract I'm sure you can expect that to happen.. but since you're not paying anything you cannot expect anything ;)

[yokem55]

What? It's already faster... read the 64 bit xvid thread or other 64 bit software benchies done by various websites on Win64... The problem is that Win64 does not support 64-bit fpu and mmx instructions, only 32 bit ones. The only architecture extensions that Win64 supports in 64-bit mode is sse/2/3 code. As the current AMD64 asm (as is the 32-bit x86 asm) is heavily dependent on the fpu and mmx units, the current situation in Win64 is not conducive to a port of x264. If x264 does get going in 64-bit mode on win64, it will require the asm to be rewritten for sse, which would be very difficult to get worthwhile performance out of....

[Sharktooth]

Well... forget about FP and MMX coz the MS plan is to NOT SUPPORT them in future OSes (including Longhorn).
Once the transition to 64bits is complete even Intel wont support them in the future chips... they will keep SSEx only and remove MMX and FP stuff (even 32 bit support) to spare $$$ and avoid heat (and other) problems...
That's why win64 supports only SSEx...

[yokem55]

Intel wont support them in the future chips...Oh, Intel will support them, but they will be simply implimented with the sse units, but we are still at least a couple of years out from that. Intel won't completly get rid of x87 fp and mmx support for quite a long time as there is still a LOT of software out there that depends on it. In the meantime, linux handles 64-bit fp and mmx code just peachy...

[Sharktooth]

well... the story is: DRM. Intel wont support Linux anymore...( http://www.theinquirer.net/?article=24638 ) and from longhorn on, MS OSes will be 64bit only...so they dont care about the old software...
oh.. and that's not "a couple of years"... it's in 2006.

[Latexxx]

well... the story is: DRM. Intel wont support Linux anymore...( http://www.theinquirer.net/?article=24638 )
This is getting completely hilarious. Of course Intel knows that they can't afford to cut out Linux from their processors because it would make every Linux user buy an amd rig. Content protection using drm is completely different than locking out an operating syste.

[Sharktooth]

AMD has the same locking mechanisms... or it wont be able to run Longhorn and future MS OSes...
DRMed software will run ONLY on DRMed hardware and vice versa.
This is the (in)famous Palladium...

http://www.epic.org/privacy/consumer/microsoft/palladium.html
http://www.microsoft.com/presspass/features/2002/jul02/0724palladiumwp.mspx (hah... they removed it but it's still on google...)
http://www.theregister.co.uk/2002/06/28/ms_palladium_protects_it_vendors/
...

[dinolib]

It seems that DRM will not be included in Windows Longhorn. But it is just a delay...

http://punto-informatico.it/p.asp?i=54160&r=PI (italian)

http://www.eff.org/deeplinks/archives/003804.php#003804

[Sirber]

DRMed hardware will only talk (LAN, internet) with other DRMed hardware. So old servers and ols WS will not be able to communicate with the new ones.

Futur is filled with crap.

[Revgen]

...Until that you can always compile your own builds with 64bit support. ;)

COOL!

I'll have it done by tommorow. :D

[Sharktooth]

COOL!

I'll have it done by tommorow. :D
... for linux/BSD ...

[bill_baroud]

Intel wont support them in the future chips...

we still have a 8-bits mode inherited from the first x86 and they are still using this crap, so i don't see Intel dropping that easily a feature from their cpu... at least it doesn't go along the policy they seem to have for years now.

[Sharktooth]

bill_baroud: the point is the non "certified" software wont run on those systems, so old software will not be supported at all, and the same end is planned for the 8, 16 and even 32 bit modes...
however if there will ever be a win64 version of x264 it will run only on non DRMed systems/OSes...

[bill_baroud]

yeah, and that's for win64, i'm talking about cpu. And, well, i don't trust anything coming from "theinquirer".

But i'll stop here, because there is too much to say on the subject and the world-taking-over-by-microsoft-and-intel-feaar!

[Latexxx]

bill_baroud: the point is the non "certified" software wont run on those systems, so old software will not be supported at all, and the same end is planned for the 8, 16 and even 32 bit modes...
however if there will ever be a win64 version of x264 it will run only on non DRMed systems/OSes...
The point is that certified software will run in sandbox which no other program can access. Current software will run just as nowadays. The only change will be that non-certified software can't access the drm components and keys stored by the operating system.

[Revgen]

... for linux/BSD ...

I was just kidding.

I guess I'll have to work on my joking skills.

[Sharktooth]

doh!!!

[Sharktooth]

The point is that certified software will run in sandbox which no other program can access. Current software will run just as nowadays. The only change will be that non-certified software can't access the drm components and keys stored by the operating system.
Well that's for the fist palladium implementation... let's wait and see...

[Kostarum Rex Persia]

Another question from me? What about SSE2 and SSE3 implementation in future 64-bit version of x264.Is it possible,and if the answer is yes,how much time is need for this work.

[Sirber]

Having them in 32-bit could be a start... but is it usefull?

[bill_baroud]

not much, it had already discussed somewhere (remember the "fake" SSE3 optimized build ?)

[Sirber]

yeah, was just ICL compiled.

[Kostarum Rex Persia]

But guys,remember that Intel compilers can't work very well on AMD processors.What you need is AMD compiler,and then SSE2 and SSE3 instructions should behave much better.

[Episode]

There is no such thing as AMD compiler. If you are referring to patches that AMD has commited to GCC project, I can tell you that even with those patches Intel compiler is still faster than GCC on AMD.

[Kostarum Rex Persia]

Perhaps,but a difference is certanly much smaller.

[Episode]

No, actually GCC is really really slow when compared to Intel compiler on AMD platform. Even Microsoft's compiler is much faster.

Yes, Intel compiler is not optimizing code as much as it could for AMD, but it's still a lot better than other alternatives.

[ChronoReverse]

Intel's compiler compiles excellent code for AMD chips in fact.

Albeit, the CPU detection routine is broken (doesn't detect SSE and SSE2 on the Athlon64s) but still by far the fastest code. (actually I'd say that Intel purposefully crippled the code generation for AMD too but the code is still faster)

However, ICL also produces broken code for me sometimes so I guess it depends on what you're compiling.

[Kostarum Rex Persia]

Albeit, the CPU detection routine is broken (doesn't detect SSE and SSE2 on the Athlon64s) but still by far the fastest code. (actually I'd say that Intel purposefully crippled the code generation for AMD too but the code is still faster)



Yes,I agree with you.I hope that AMD will cruch Intel on court later this year.Intel is failed in many ways,so far.

[Sharktooth]

The "excellent" code produced by Intel Compiler is still suboptimal (a wanted behaviour).
That's one of the advantage you (intel in this case) may gain from being in a monopoly...

[Kostarum Rex Persia]

Yes.But I am suprised that AMD doesn't have own compiler for AMD64 processors.Someone told me that AMD have this compiler,but it cost too much.

[Doom9]

Well, it takes time and resources to develop an optimized compiler. Intel reaps huge benefits every year because almost everybody buys their chips.

[Kostarum Rex Persia]

Well, it takes time and resources to develop an optimized compiler. Intel reaps huge benefits every year because almost everybody buys their chips.

Yes,unfortunately,you are right.One notice for all members of Doom9 forums.I just send a e-mail to AMD developer support,and I think that,perhaps,one or more AMD people will join us as members of Doom9 forums.Well,I hope that they are interested.

[squid_80]

Just getting back to the start of the thread...
I want to know when will arrive a 64-bit version of x264 codec.In September,or sooner.

I think I'm up to the challenge. Are you talking about a version for windows 64, using the vfw interface?

[Doom9]

I think that,perhaps,one or more AMD people will join us as members of Doom9 forumsThat may just be wishful thinking. I remember the days of Flaskmpeg idct optimizations just too well.. both Intel and AMD got into it a little but quickly lost interest.
Basically somebody needs to write a patch for ICL that performs a proper CPU identification.. that still doesn't yield perfect AMD optimized code, but it'll be faster anyway. And you cannot expect Intel to spend time to write optimized code for the main competitor's platform.. that's really up to AMD, and AMD's strategy has always been a bit different from Intel. Intel has an entire platform: cpu, chipset, flash, wireless chipset, and a lot of other stuff (they are into telephony for instance). AMD only has cpu and flash. In a perfect world, AMD could exactly match Intel's offering but that's just wishful thinking and we're lucky to have NVidia to create very good chipsets for the AMD platform.

[Kostarum Rex Persia]

Just getting back to the start of the thread...


I think I'm up to the challenge. Are you talking about a version for windows 64, using the vfw interface?

Yes,certanly.I mean x264 vfw 64-bit for Windows XP 64-bit edition.What can you tell me about that.Can you contribute in developing of x264 64-bit edition.

[Sharktooth]

I think I'm up to the challenge. Are you talking about a version for windows 64, using the vfw interface?
the vfw interface needs cli to be compiled first. also the vfw interface is entirely made in C... what needs to be ported are the ASM routines.
some MMX stuff was already ported to SSE2 ( http://forum.doom9.org/showthread.php?t=97683 ) and there's already a SSE2 patch for amd64 (in the same thread: http://forum.doom9.org/showthread.php?t=97683&page=3&pp=20 ) but some MMX stuff is still there...

[Kostarum Rex Persia]

Sharktooth,I need your opinion on this.Can you tell me,how x264 will behave,if x264 code is written in Delphi,or even Microsoft Visual Studio.

[ChronoCross]

Sharktooth,I need your opinion on this.Can you tell me,how x264 will behave,if x264 code is written in Delphi,or even Microsoft Visual Studio.

The only difference between writing C code in Ms visual Studio and notepad(then being compiled by gcc using make is that the Ms compiler will be used. You can use additional compiler flags in MS Visual Studio same as in gcc and possibly in theory the compiler might produce a tiny bit more speed on the windows platform. Additionally I think the coding environment is much to my liking and could be more organized if one wanted. But other than that the program used to code plays almost a non-esential role in the actual speed an performance of ones program.

[Sharktooth]

well... however C is faster than delphi.
for what concerns Visual Studio, it is not a programming language but a development suite.
The actual code can be already compiled with Visual Studio...

[plonk420]

well... the story is: DRM. Intel wont support Linux anymore...( http://www.theinquirer.net/?article=24638 ) and from longhorn on, MS OSes will be 64bit only...so they dont care about the old software...
oh.. and that's not "a couple of years"... it's in 2006.

that is so entirely stupid. i work in customer service for a cable/isp/telephony company and a majority (over half) of the internet installs are on computers running win98 or me. we only cover 4 states, but i'm SURE there'll at least be 1/3 or 1/4 of users not using even 2000 or xp in 2-4 years, even in the rest of the states, let alone world. and they can't force vendors to stop supporting those OSes as the business of support for those OSes would go elsewhere and maybe even increase in cost/value... wtf.

Yes,unfortunately,you are right.One notice for all members of Doom9 forums.I just send a e-mail to AMD developer support,and I think that,perhaps,one or more AMD people will join us as members of Doom9 forums.Well,I hope that they are interested.

until a year or two ago, i didn't even know they had CLASSES to program compilers. i hate programming as it is, but programming a compiler... :X that's GOTTA be a bitch...

[squid_80]

the vfw interface needs cli to be compiled first. also the vfw interface is entirely made in C... what needs to be ported are the ASM routines.
some MMX stuff wes already ported to SSE2 ( http://forum.doom9.org/showthread.php?t=97683 ) and there's alread a SSE2 patch for amd64 (in the same thread: http://forum.doom9.org/showthread.php?t=97683&page=3&pp=20 ) but some MMX stuff is still there...

Porting the MMX stuff is really not a problem... It's sort of preferable because the registers have no restrictions, unlike SSE2 where xmm6 & xmm7 are non-volatile in 64-bit mode (unlike 32-bit mode). MS really screwed up portability by doing that, IMO.
If the MMX code is easy enough to comprehend I might make my own SSE2 functions, implemented using intrinsics (does GCC handle intrinsics?). Whole program optimization should then be able to pick the best registers to use, which in my experience produces faster code than using external assembly compiled with yasm.

I want to try and keep the asm files OS independent, so the same files can be used to compile for linux or windows. But once it's done someone will need to check that it still works on linux, since I don't a 64-bit distro installed.

[Kostarum Rex Persia]

Good work squid_80,you are right.But writing a 64-bit version of x264 is, certanly,much harder than 32-bit.

[Sharktooth]

i dont think using intrinsics is a good idea coz gcc is not as good as Visual Studio.
Using intrinsics could lead to a huge drop in performance nullifying the speed advantage.
a proper xp64 implementation using yasm is the best choice.
also if your implementation works it could be submitted to the svn.

[squid_80]

If I isolated the intrinsics with #ifdefs so they were only used by MS's compiler, it shouldn't be a problem - 64-bit linux version would compile the same as it does now. The issue with using yasm is that complex functions in xp64 need special prologs and epilogs to support unwinding. Microsoft's compiler of course produces all this automatically, but doing it by hand in yasm is a bit harder. The need for this is eliminated if the function is simple, but this means it can't modify the stack or any of the non-volatile registers (rbx, rbp, r12-r15, rsi, rdi, xmm6-xmm15). So there goes the "more registers" advantage.
(I hate MS, have I mentioned that?)
I will try and work with yasm first though, the intrinsics stuff will only be used if I think it will give a big advantage.

[Sharktooth]

another thing, x264 uses external libraries for MP4 output.
those external libraries (part of gpac) need to be compiled in 64bit mode too...

[squid_80]

Aw crap. :( I hope they don't use too much assembly or cast pointers to ints.

[Sharktooth]

mp4 output is "optional" in x264. it gets enabled thru the configure script.
however almost everyone use mp4... it could be a problem...
however gpac needs to be patched to run on x64 too... :(

[squid_80]

x264vfw only appears to need libx264.lib - so why do I need to compile the whole CLI, why not just the libx264 project?

Edit: I'm getting unresolved externals for x264_cqm_init and x264_cqm_parse_file. Anyone know where they're hiding?
Edit2: Nevermind, found them in common\set.c which hadn't been added to the project file. Obviously not many people compile with Visual Studio.

[akupenguin]

however gpac needs to be patched to run on x64 too...

I've been using GPAC on 64-bit linux for a while. No patches needed.

[Sharktooth]

no patches on linux... but win x64 is a different story...

[squid_80]

There's 3 globals listed in the assembly code that don't seem to exist: mc_copy_w8, mc_copy_w16 and x264_vertical_filter_mmxext. They were causing the build process to halt with unresolved externals so I've commented them out, but I just thought I'd check to see if anyone knows what the story is.

[akupenguin]

There's 3 globals listed in the assembly code that don't seem to exist: mc_copy_w8, mc_copy_w16 and x264_vertical_filter_mmxext. They were causing the build process to halt with unresolved externals so I've commented them out, but I just thought I'd check to see if anyone knows what the story is.

mc_copy_w* are left over from when MMX was controlled only by conditional compilation instead of function pointers. (They are now named x264_mc_copy_w*_mmxext.)
x264_vertical_filter_mmxext was merged into x264_vertical_center_mmxext since they share some computations.

[squid_80]

Finished a quick'n'dirty build: http://home.iprimus.com.au/ajdunstan/x264vfw64.zip

If you manage to break it (try hard) please give detailed steps to reproduce.

[Sharktooth]

uhm... seems to work...testing...

[Kostarum Rex Persia]

I'm sorry,but I ask this because I don't sure.About 64-bit x264 developing,someone in Serbia told me that Edouard Gomez(Gom Gom) will join our efforts in developing x264 codec.

Is this true,or not.

[squid_80]

uhm... seems to work...testing...
Is no news good news in this case?

I'm trying to clean the source code up for submission but $#@$ing yasm won't behave for me. If anyone knows how to make it use type 3 relocations (wrt ..got) in win32 output PLEASE tell me how. Otherwise exception handling will be broken on win64 and I don't want Avery Lee kicking my ass. (http://www.virtualdub.org/blog/pivot/entry.php?id=10)

[Doom9]

I'm sorry,but I ask this because I don't sure.About 64-bit x264 developing,someone in Serbia told me that Edouard Gomez(Gom Gom) will join our efforts in developing x264 codec.Why don't you ask the guy directly? We don't play he said she said here.

[Kostarum Rex Persia]

Why don't you ask the guy directly? We don't play he said she said here.

Well,yes,but I don't know his username on Doom9 forum.Is he member of Doom9 forum.

[Sharktooth]

Is no news good news in this case?
crashed. but it's not your fault... it's the room temperature that's too high (44°C).
i need to install an industrial AC coz there are too much computers in that room and the temps are so high it makes them crash.

[squid_80]

Yasm has been taught to behave. (http://cvs.tortall.net/cgi-bin/viewcvs.cgi/trunk/yasm/modules/objfmts/coff/coff-objfmt.c?rev=1215&view=log) So I'll get the exception handling stuff done, run it through a profiler and see what can be improved. I want to see this thing go fast, none of this 4 fps business.

[Kostarum Rex Persia]

uhm... seems to work...testing...

Well,any news,Sharktooth.I mean,did you,finaly,manage to test raw 64-bit edition of x264 codec.Is that version good,or......

[squid_80]

I applied the matroska patches (easy) and built the GPAC libs (not so easy) so a windows x64 version of the CLI with avisynth input and mkv+mp4 output is available from http://home.iprimus.com.au/ajdunstan/x264cli_x64.zip .
(Note that avisynth input will only work with the 64-bit version of avisynth - using resizing will kill any speed gains since I've been too slack to fix it.)

Seems only about 5-10% faster at this point, but oh well.

[riggits]

I'm sorry,but I ask this because I don't sure.About 64-bit x264 developing,someone in Serbia told me that Edouard Gomez(Gom Gom) will join our efforts in developing x264 codec.

Is this true,or not.

"Our efforts"??? You've contribute nothing but noise. I've rarely encountered a more presumptuous prat.


Well,any news,Sharktooth.I mean,did you,finaly,manage to test raw 64-bit edition of x264 codec.Is that version good,or......

Learn some patience. Compile your own version, learn asm, do something useful.
Here's a hint: in the best case, a 64-bit port of x264 can get maybe 5% improvement in speed over the 32-bit codec. 4 extra registers aren't a big deal. Accessing more than 4GB of RAM per program means nothing to most people. Why do you care so much about something you know so very little about?

[squid_80]

Here's a hint: in the best case, a 64-bit port of x264 can get maybe 5% improvement in speed over the 32-bit codec. 4 extra registers aren't a big deal.

See post directly above: 5% minimum gain. Also there's 8 extra GPR registers and 8 extra SSE2 registers.

[Sirber]

can 32bit avisynth and 64bit avisynth be installed at the same time?

[squid_80]

Yes, shouldn't be any problem having both installed. It's a bit tedious to have to keep changing Loadplugin lines in scripts to switch between 32-bit and 64-bit plugins, I keep meaning to fix that but haven't made up my mind how to do it.

[Sirber]

and not all filters are 64bit :(

[squid_80]

One man can only do so much (especially when he gets distracted by other projects very easily).

[Shinigami-Sama]

well... the story is: DRM. Intel wont support Linux anymore...( http://www.theinquirer.net/?article=24638 ) and from longhorn on, MS OSes will be 64bit only...so they dont care about the old software...
oh.. and that's not "a couple of years"... it's in 2006.
oh..
I need to give that link to a few profs. in my school, watch them read it as they realize what I say about fairuse dying is all true
granted I live in Canada which has more sane copyriht laws and a distinct lack or MPAA/RIAA
sure we have a version of the RIAA but I don't think they do anything..

to stay on topic
I'd love to see one of the RF's transcode a dvd with extensive filtering to h.264 in mkv :D
granted thats after I go at it with a soldering iron powered by an itel rep's tears as I use it as a space heater while using an amd64 w/gentoo :P

[Kostarum Rex Persia]

What's going on with 64-bit x264 codec.No news for very long time.Can someone explain to me what is the problem in compiling a 64-bit version,luck of knowledge or something else.

[celtic_druid]

You mean under windows or just 64-bit in general? No problems compiling a 64bit version under suse64 that I could see. Didn't have time to test it though.

[Kostarum Rex Persia]

I mean under Windows.I suppose that there is a problem,otherwise 64-bit x264 will be present today.

[ChronoCross]

I mean under Windows.I suppose that there is a problem,otherwise 64-bit x264 will be present today.


you can compile anything using 64-bit flags but the problem is that the software needs to be specially written to be 64-bit optimized to have any effect.

btw how many more times are you gonna ask. how about you learn to compile it yourself?

[squid_80]

What's going on with 64-bit x264 codec.No news for very long time.Can someone explain to me what is the problem in compiling a 64-bit version,luck of knowledge or something else.

There was no problem, I rewrote the assembly code to work with windows x64 and made both the vfw codec and the CLI. I never got any feedback about it working/failing so I lost interest. I still have the code on my hard drive but the download links in this thread won't work because I've changed ISP.

[nm]

you can compile anything using 64-bit flags but the problem is that the software needs to be specially written to be 64-bit optimized to have any effect.
Actually the speedup in x86-64 64-bit mode compared to the 32-bit mode is mostly based on having a lot more registers available in the CPU. These registers can be used by optimizing compilers and therefore just compiling C code with 64-bit flags will also have an effect. However, you are right that in the case of x264 this is not enough since many functions have been written in assembly code and they need to be ported to x86-64. Luckily that has already been done ages ago :)
There were problems with getting the MMX code to run on 64-bit Windows, but apparently squid_80 worked around that by rewriting a lot of code.

[Sharktooth]

@squid_80: what about submitting your work to x264devs?

[squid_80]

There were problems with getting the MMX code to run on 64-bit Windows, but apparently squid_80 worked around that by rewriting a lot of code.Not a lot of code, I just adjusted the functions to match windows x64's ABI (first 4 functions args in rcx, rdx, r8, r9 and rsi+rdi are non-volatile).

[Kostarum Rex Persia]

Well, I havn't 64-bit processor to test your version, squid_80, but I am hope that Sharktooth will test your 64-bit release. Please post a link to your code, squid_80.

[Sirber]

There was no problem, I rewrote the assembly code to work with windows x64 and made both the vfw codec and the CLI. I never got any feedback about it working/failing so I lost interest.I don't remember that :confused:

Would be my chance to go on XP64 :D

[berrinam]

Well, I havn't 64-bit processor to test your version, squid_80, but I am hope that Sharktooth will test your 64-bit release. Please post a link to your code, squid_80.Why on earth were you nagging about 'x264 64-bit version' if you can't use it?

[Kostarum Rex Persia]

Why on earth were you nagging about 'x264 64-bit version' if you can't use it?

You missed the point, I mean that I will soon buy 64-bit processor.So,then I can try 64-bit edition.

[squid_80]

I don't remember that :confused:

Would be my chance to go on XP64 :D

Huh? Look back in this thread to my posts dated 30th July and 28th August. If anyone wants the downloads give me a pm with an address to email or upload to. I haven't touched it in nearly 2 months so it's a bit out of date now - I think it matches r287 or thereabouts.

[celtic_druid]

http://celticdruid.no-ip.com/temp/x264cli_x64.7z
http://celticdruid.no-ip.com/temp/x264vfw64.7z

I believe those are the most current.

[squid_80]

I believe those are the most current.Yeah they would be, seeing as how they were never updated.

[squid_80]

I've update the x64 CLI to the latest version (r333). It's available (with other stuff) at ftp://squid80.no-ip.com

[bond]

I'm trying to clean the source code up for submission but $#@$ing yasm won't behave for me. If anyone knows how to make it use type 3 relocations (wrt ..got) in win32 output PLEASE tell me how. Otherwise exception handling will be broken on win64 and I don't want Avery Lee kicking my ass. (http://www.virtualdub.org/blog/pivot/entry.php?id=10)any news about the sources?

[squid_80]

Source is up as well now (x264cli_x64src.zip). Needs to be compiled with vs2003 or later and requires yasm r1215 or greater. If someone could check that the AMD64 assembly works for linux that would be really great.

[Death Knight®]

Thank You! :)

I think orginal source code needed to merge with this work.
Great work squid_80.

Could you make an update for vfw r333?

[squid_80]

Updated VFW is now available. Not tested much, please let me know of any problems.

[Death Knight®]

I have tried to encode 2 file...
One of them DTS Landscape clip, other one is dolby digital egypt clip.
I make clips to "uncompressed" and 1 pass 750Kbit. Same settings for both...

DTS Landscape clip:
32 Bit x264 with 32 bit Virtual Dub 1.6.11: 34 seconds.
64 Bit x264 with 64 bit Virtual Dub 1.6.11: 28 seconds.

DolbyDigital Egypt clip:
32 Bit x264 with 32 bit Virtual Dub 1.6.11: 50 seconds.
64 Bit x264 with 64 bit Virtual Dub 1.6.11: 61 seconds.

64 bit build is %18 percent "faster" than 32 bit one.
OR its same to say that
32 bit build is %19.6 percent "slower" than 64 bit one...

I think it's HUGE acceleration.

[Shinigami-Sama]

well it seems your egypt scene was slower on 64bit somehow :\

[squid_80]

I have tried to encode 2 file...
DolbyDigital Egypt clip:
32 Bit x264 with 32 bit Virtual Dub 1.6.11: 50 seconds.
64 Bit x264 with 64 bit Virtual Dub 1.6.11: 61 seconds.
Are those measurements the right way round?

[Sirber]

I think it's time I get XP64... :D

[Kostarum Rex Persia]

Have anybody try to measure x264 64-bit version encoding speed in program XMpeg 5.03 32-bit version, under Windows XP 64-bit edition? I only hope that Xmpeg 5.03 will work under 64-bit Windows.

So, Dark Knight, try testing x264 64-bit in this way, load any MPEG2 file into XMpeg 5.03 and try to test 64-bit version of x264.

[Death Knight®]

There was a little error which I corrected...( dolbydigital egyps is faster with 64 bit, not 32 bit, sorry for that)...

For testing...
Firstly, I have to use UNCOMPRESSED DATA SOURCE... Why? Because If I re-encode MPEG data, than it's not show us x264-x64's speed gain. But It shows mpeg2 decode and x264-64 encode gain...

Because of that, a measuring program must be use "uncompressed data". If you consist about using MPEG2 for input, than you cannot mesause x264-64 gain. It's clear....

"Kostarum Rex Persia" told about use of XMpeg...But I couldn't use that program for test 64 bit vfw driver.
"ONLY 64 BIT programs are compatible with 64BIT x264" like Virtual Dub AMD64.

But If you wonder MPEG2->x264 performance gain, I can calculate it via AviStynth64 and DGDecode64.dll (Special thanks for squid_80)

[Death Knight®]

I don't know where is the problem but I CANT VERIFY TESTS...

I tried same source with same programs now, but results are different. (32 bit and 64 bit had one or two seconds difference.). I have to warn to you my previous test MIGHT be wrong...

I will make detailed test when I stabilize my windows...

[Sharktooth]

Have anybody try to measure x264 64-bit version encoding speed in program XMpeg 5.03 32-bit version, under Windows XP 64-bit edition? I only hope that Xmpeg 5.03 will work under 64-bit Windows.

So, Dark Knight, try testing x264 64-bit in this way, load any MPEG2 file into XMpeg 5.03 and try to test 64-bit version of x264.
stop asking for the impossible. a 32bit program using a 32bit interface to a 64bit codec is not possible. stop it please.

[Kostarum Rex Persia]

stop asking for the impossible. a 32bit program using a 32bit interface to a 64bit codec is not possible. stop it please.

Calm down, I didn't know that. Too bad, xmpeg from www.xmpeg.net don't have, yet, 64-bit edition.

Death Knight®, can you test x264 64-bit in some other encoding program, not only in VirtualDub 1.6.11?

[squid_80]

There was a little error which I corrected...( dolbydigital egyps is faster with 64 bit, not 32 bit, sorry for that)...Um, the number are still say the opposite ;)
For testing...
Firstly, I have to use UNCOMPRESSED DATA SOURCE... Why? Because If I re-encode MPEG data, than it's not show us x264-x64's speed gain. But It shows mpeg2 decode and x264-64 encode gain...

Because of that, a measuring program must be use "uncompressed data". If you consist about using MPEG2 for input, than you cannot mesause x264-64 gain. It's clear....

"Kostarum Rex Persia" told about use of XMpeg...But I couldn't use that program for test 64 bit vfw driver.
"ONLY 64 BIT programs are compatible with 64BIT x264" like Virtual Dub AMD64.

But If you wonder MPEG2->x264 performance gain, I can calculate it via AviStynth64 and DGDecode64.dll (Special thanks for squid_80)
You're exactly right - using uncompressed source (preferably using the CLI) is the best way to test the performance of x264 by itself. As soon as you start involving other programs that aren't as optimised (avisynth in particular) the speed gain disappears. The problem with avisynth is that is uses lots of inline assembly code which isn't allowed by microsoft's compiler. So I have to rewrite it and it ends up slower. I have heard that Intel's x64 compiler does support inline assembly so I've been trying to download an evaluation copy but their website always gives me a 404. I might just end up forking out US$399 and buy the damn thing.

[Sirber]

I'm tempted to install XP64 and release 64bit RealAnime LE... Can all sharktooth patch be applied to 64bit x264?

[squid_80]

I'm tempted to install XP64 and release 64bit RealAnime LE... Can all sharktooth patch be applied to 64bit x264?
Yes, the patches can easily be applied if you want me to.

Not sure how you'd go with a 64-bit version of RealAnime... There's the issue of audio for one thing (though if you're just passing a commandline it would probably work) plus avisynth64 isn't really up to scratch... DirectShowSource isn't available since there's no codecs, and you'd be pretty restricted with filtering - undot for noise reduction, only the core resizers are available, no sharpening (I might do warpsharp soon), and decomb for deinterlace/ivtc.

My tests give a rough 4% increase with uncompressed input and default settings. It seems more complex settings (-m and --me in particular) give a greater gain.

[Shinigami-Sama]

it's strange they give so little gain, if it's 64 bit they should beable to access the data faster, and ad 64bit numbers fast, which is correct me of I'm wrong, the majority of filters and encoding?

either way, I might get win64 runing on this lil laptop soon, depends how much I have to pay or if theres still betas around

[jvrobert]

it's strange they give so little gain, if it's 64 bit they should beable to access the data faster, and ad 64bit numbers fast, which is correct me of I'm wrong, the majority of filters and encoding?

either way, I might get win64 runing on this lil laptop soon, depends how much I have to pay or if theres still betas around

Actually I would expect little change, the SSE* instruction sets are better at this stuff than native x86-64 instructions, no?

Unless the developer isn't playing fair(*), I would expect only a marginal general speed improvement in a native 64-bit compiled binary due to more registers, and of course the ability address more than 2-3G of memory per process. Some apps will benefit more than others, but I don't think encoding apps would be one of them.

* Witness the recent game, can't remember the name, where the developer made this laughable attempt to make it look like the 32-bit version didn't look nearly as good as the 64-bit version. Since this was all done in the GPU, they had obviously and blatantly just crippled the 32-bit version.

[squid_80]

Actually I would expect little change, the SSE* instruction sets are better at this stuff than native x86-64 instructions, no?
Took me a second to work out what you meant there - yes the majority of the code is done by SSE (mmxext) instructions which don't gain much from x64 mode. But there are a few little tricks e.g. a MMX register can be dumped into a GPR and multiplied by a constant to get the horizontal sum instead of doing movq-shift-add.Unless the developer isn't playing fair(*), I would expect only a marginal general speed improvement in a native 64-bit compiled binary due to more registers, and of course the ability address more than 2-3G of memory per process. Some apps will benefit more than others, but I don't think encoding apps would be one of them.

* Witness the recent game, can't remember the name, where the developer made this laughable attempt to make it look like the 32-bit version didn't look nearly as good as the 64-bit version. Since this was all done in the GPU, they had obviously and blatantly just crippled the 32-bit version.
How could I not be playing fair when the 32-bit versions aren't provided by me? :p

[akupenguin]

updated patch (http://students.washington.edu/lorenm/src/x264/x264_win64.1.diff).
Just a few lines broke on linux 64bit, but I'm not too sure of my fixes (particularly %macro pad), so I want to check that it still works on windows.

Also: I see that you've removed a bunch of lines like movsxd rsi, esi ; i_stride These lines are theoretically needed: At least in gcc's calling convention, any unused MSBs are allowed to contain garbage. It just so happens that when I compile x264 as is, it works. But I don't want to depend on whims of the optimizer. If you still want to remove them, the alternative is to change all strides everywhere to "long".

[squid_80]

updated patch (http://students.washington.edu/lorenm/src/x264/x264_win64.1.diff).
Just a few lines broke on linux 64bit, but I'm not too sure of my fixes (particularly %macro pad), so I want to check that it still works on windows.

That pad macro's a bitch. It's there because functions under windows are meant to have 6 bytes padding between them - theoretically for hot patching but seems like it's just laying out the red carpet for hackers if you ask me. It gives warnings "trailing garbage after macro name ignored" (or something like that) because I couldn't come up with a cleaner way.Also: I see that you've removed a bunch of lines like movsxd rsi, esi ; i_stride These lines are theoretically needed: At least in gcc's calling convention, any unused MSBs are allowed to contain garbage. It just so happens that when I compile x264 as is, it works. But I don't want to depend on whims of the optimizer. If you still want to remove them, the alternative is to change all strides everywhere to "long".
That wouldn't work on windows - a long is still 32 bits in 64-bit mode (yet the compiler starts spewing errors if you try and mix longs and ints). I know if the parameters are passed in memory not to touch the MSBs (hence the parm1q vs parm1d macros) but I couldn't find any definite information on parameters passed in registers, just assumed that any int operations on a register would use the 32-bit name (eax instead of rax) hence zero out the high dword. It would be pretty bad form for the compiler to act any other way but like you said it's bad to assume... I did find some information at x86-64.org (http://www.x86-64.org/documentation/abi-0.96.pdf) (page 23) that seems to imply the registers don't need zero-extending but it's not crystal clear. I think I'll leave it up to you ;)

[squid_80]

Has anyone tried testing multiple threads on a X2 chip? I just realised today the code wasn't being included, so there's a new build available.

[Death Knight®]

I have re-test x264-vfw-x64...

Problem is UNCOMPRESSED data takes much area from harddisk. Due defragmantation, results shows highly unstable values... Solution is using RAMDrive for testing :)

I used Dolby Digital's Rain for uncompressed source (807 MB) @ RamDrive...
I want slower compression than I set settings to:
500K one pass, Partition Decision: 6 - RDO ( Slowest) , Method: Exhaustive Search , Range 16, Chroma ME enabled...
Used higher priority. virtual dub.

32 Bit VirtualDub with x264-vfw: 2:04.6 = 124.5 seconds
64 Bit VirtualDub with x264-vfw: 1:53.0 = 113 secconds

x64 version is nearly %10 faster than x32 one at theese settings...

[Sharktooth]

Has anyone tried testing multiple threads on a X2 chip? I just realised today the code wasn't being included, so there's a new build available.
please send the patch to akupenguin so we can compile and test it.

[akupenguin]

Method: Exhaustive SearchWhich means you're essentially timing SAD and nothing else, since exhaustive search takes the majority of the CPU-time. And yes, 64bit SAD is 10% faster than 32bit SAD, just due to the calling convention.

please send the patch to akupenguin so we can compile and test it. What patch? Surely x264's current multithreading works on X2?

[Sharktooth]

the one used for the "new build":
Has anyone tried testing multiple threads on a X2 chip? I just realised today the code wasn't being included, so there's a new build available.

[Death Knight®]

squid_80, can you tell me how can I compile for Windows X64 Bit?
I have nasm,yasm, VC 2003, cygwin tools...

I can compile 32 version with cygwin, but I think 64 bit version is different from it.
(I am trying to compile original version 341, because after 336 native code is compatible with win X64, isn't it?..)

[squid_80]

please send the patch to akupenguin so we can compile and test it.
Easy, just add __WIN32__ to the preprocessor definitions for libx264. (Sorry, I probably confused things by saying there was code missing when it was really just a #define.) It does seem to work under windows x64 but I don't have a dual core so I can't test properly.

[squid_80]

squid_80, can you tell me how can I compile for Windows X64 Bit?
I have nasm,yasm, VC 2003, cygwin tools...

You only need VS2003, the windows 2003 platform sdk with AMD64-bit tools and libraries (NOT Itanium stuff) and a copy of yasm later than r1215. Once the platform SDK is installed open a build environment window for xp64 retail and start visual studio from the command line using devenv /useenv. Then add the path to yasm to the executable files directories.

I know these instructions are very short but I'm in a hurry. I can write better instructions later if you can't get it to work.

[squid_80]

Re rev337: Oops, sorry about the SSE2 pixel breakage stuff. I should have mentioned that I hadn't finished it yet, forgot that I'd made some changes and left it broken.

Edit: Just looked at amd64/deblock-a.asm: using xmm6-xmm9? This is gonna take some thinking, better I leave it for the weekend.

[Death Knight®]

Yes I need help!

First VC2003 doesn't recognise YASM.exe. It searches for nasm.exe...
Returns error with 'nasm' is not recognized as an internal or external command,
operable program or batch file.

If I rename yasm.exe to nasm.exe, than gives error:
yasm: could not open file `.\Release"predict-a.obj x:\x264\common\i386\predict-a.asm'

Second, I think 2003 and SDK does not have "inttypes.h" file. Have I needed to find somewhere?

Thank you squid_80 :)

[squid_80]

You need to use the Release64 configuration. Make sure you open the .vcproj files in VS2003, not the .dsp files. libx264 should compile, there might be issues compiling the cli since I've set it up to link with gpac. The x64 modifications for the vfw haven't made it into the SVN and it's probably better that they're left out because older compilers won't like them (unless we set up our own defines for DWORD_PTR, INT_PTR etc).

[sh0dan]

Edit: Just looked at amd64/deblock-a.asm: using xmm6-xmm9? This is gonna take some thinking, better I leave it for the weekend.
I've wondered why this is considered such a problem. Couldn't xmm6->9 just be saved to memory when entering the assembly, and read back when leaving it?

Of course, making it thread-safe is a bit more difficult, but it shouldn't be that much work.

[akupenguin]

Of course, making it thread-safe is a bit more difficult, but it shouldn't be that much work.Save it on the stack, like any other spillage?

[squid_80]

Save it on the stack, like any other spillage?
Yeah... grab 72 bytes from the stack (4xXMM+8 for 16-byte alignment), which on windows means __chkstk() should be called to make sure we don't land on a non-allocated page plus a non-volatile register needs to be setup as a frame pointer. So it's not that hard, but it'll slow things down a bit.

[Death Knight®]

You need to use the Release64 configuration...
There is no Release64 configuration @ svn r341...
I am trying to compile original source code, not your specialized src. Is there a way to compile? Or Original sourse is not compatible with winxp64 bit? (I think it's compatible after release 336)

[squid_80]

Yes there is, like I said use the .vcproj files found in /build/win32/.

[Death Knight®]

Sorry, I have tried but I can't see at first. Now, I saw Release64 config... Thank you. But problems doesn't end.

YASM gives error...

Performing Custom Build Step
yasm: FATAL: unable to open include file `amd64inc.asm'
Project : error PRJ0019: A tool returned an error code from "Performing Custom Build Step"

Build log was saved at "file://x:\C++\Project\x264\build\win32\Release64\BuildLog.htm"
libx264 - 1 error(s), 0 warning(s)


(Release 347)

I fell my-self like idiot even I'm computer engineer. I can't compile :(

[squid_80]

Aargh, I knew that would come back to bite me.

When I made my changes to the amd64 .asm files, I had to include amd64inc.asm like so:
%include "..\..\common\amd64\amd64inc.asm"because if I tried to pass an include dir to yasm using -I it always failed - I think it was due to the command line being too long. So you can either change the .asm files, or as a quick fix copy common/amd64/amd64inc.asm to the build/win32 directory.

[Death Knight®]

I have copy amd64inc.asm to win32 directory...
But there is a
#include <inttypes.h>
error at "frame.h". There is no inttypes.h at winx64 SDK...
I have comment out that via
//#include <inttypes.h>
It's compiled with 143 warnings, 0 errors
I think I have succesfuly compiled libx264 :)

But when I compiling x264, I got a LINKer error.

------ Build started: Project: x264, Configuration: Release64 Win32 ------

Linking...
MSVCRT.lib(msvcrt.dll) : error LNK2005: malloc already defined in LIBCMT.lib(malloc.obj)

This repeats for free.obj,fclose.obj,fread.obj,fopen.obj,realloc.obj,
fwrite.obj,_ctype.obj,sprintf.obj,fflush.obj,strdup.obj,strstr.obj,
ftime.obj,fprintf.obj,stricmp.obj AND strnicmp.obj.

LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
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
bin/x264.exe : fatal error LNK1120: 6 unresolved externals

Build log was saved at "file://x:\C++\Project\x264\build\win32\Release64\BuildLog.htm"
x264 - 23 error(s), 1 warning(s)


Before I "Ignored Specific library = LIBCMT.lib", than this link errors gona hell!
did you make this step too? Am I on the correct way?

But there is another link errors with libx264. I did included libx264.lib to project.

[squid_80]

I have copy amd64inc.asm to win32 directory...
But there is a
#include <inttypes.h>
error at "frame.h". There is no inttypes.h at winx64 SDK...
I have comment out that via
//#include <inttypes.h>
It's compiled with 143 warnings, 0 errors
I think I have succesfuly compiled libx264 :)It seems frame.h was recently modified and isn't checking HAVE_STDINT_H like it should.


But when I compiling x264, I got a LINKer error.
Do you know why?


------ Build started: Project: x264, Configuration: Release64 Win32 ------

Linking...
MSVCRT.lib(msvcrt.dll) : error LNK2005: malloc already defined in LIBCMT.lib(malloc.obj)
MSVCRT.lib(msvcrt.dll) : error LNK2005: free already defined in LIBCMT.lib(free.obj)
MSVCRT.lib(msvcrt.dll) : error LNK2005: fclose already defined in LIBCMT.lib(fclose.obj)
MSVCRT.lib(msvcrt.dll) : error LNK2005: fread already defined in LIBCMT.lib(fread.obj)
MSVCRT.lib(msvcrt.dll) : error LNK2005: fopen already defined in LIBCMT.lib(fopen.obj)
MSVCRT.lib(msvcrt.dll) : error LNK2005: realloc already defined in LIBCMT.lib(realloc.obj)
MSVCRT.lib(msvcrt.dll) : error LNK2005: fwrite already defined in LIBCMT.lib(fwrite.obj)
MSVCRT.lib(msvcrt.dll) : error LNK2005: isalnum already defined in LIBCMT.lib(_ctype.obj)
MSVCRT.lib(msvcrt.dll) : error LNK2005: sprintf already defined in LIBCMT.lib(sprintf.obj)
MSVCRT.lib(msvcrt.dll) : error LNK2005: fflush already defined in LIBCMT.lib(fflush.obj)
MSVCRT.lib(msvcrt.dll) : error LNK2005: _strdup already defined in LIBCMT.lib(strdup.obj)
MSVCRT.lib(msvcrt.dll) : error LNK2005: strstr already defined in LIBCMT.lib(strstr.obj)
MSVCRT.lib(msvcrt.dll) : error LNK2005: _ftime already defined in LIBCMT.lib(ftime.obj)
MSVCRT.lib(msvcrt.dll) : error LNK2005: fprintf already defined in LIBCMT.lib(fprintf.obj)
MSVCRT.lib(msvcrt.dll) : error LNK2005: _stricmp already defined in LIBCMT.lib(stricmp.obj)
MSVCRT.lib(msvcrt.dll) : error LNK2005: _strnicmp already defined in LIBCMT.lib(strnicmp.obj)
LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:libraryThis should be fixed if you set code generation to Multi-threaded (for both libx264 and x264). I must have left it set to something else by accident.
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
bin/x264.exe : fatal error LNK1120: 6 unresolved externals

Build log was saved at "file://x:\C++\Project\x264\build\win32\Release64\BuildLog.htm"
x264 - 23 error(s), 1 warning(s)
These errors are from the new mmx deblocking, the AMD64 routines aren't included in the project file and they wouldn't work for windows anyway. Try editing x264_deblock_init (found at the bottom of frame.c) so it looks like this:void x264_deblock_init( int cpu, x264_deblock_function_t *pf )
{
pf->deblock_v_luma = deblock_v_luma_c;
pf->deblock_h_luma = deblock_h_luma_c;
pf->deblock_v_chroma = deblock_v_chroma_c;
pf->deblock_h_chroma = deblock_h_chroma_c;
pf->deblock_v_luma_intra = deblock_v_luma_intra_c;
pf->deblock_h_luma_intra = deblock_h_luma_intra_c;
pf->deblock_v_chroma_intra = deblock_v_chroma_intra_c;
pf->deblock_h_chroma_intra = deblock_h_chroma_intra_c;

#ifndef _AMD64_ //ugly but should do the trick for now
#ifdef HAVE_MMXEXT
if( cpu&X264_CPU_MMXEXT )
{
pf->deblock_v_chroma = x264_deblock_v_chroma_mmxext;
pf->deblock_h_chroma = x264_deblock_h_chroma_mmxext;
pf->deblock_v_chroma_intra = x264_deblock_v_chroma_intra_mmxext;
pf->deblock_h_chroma_intra = x264_deblock_h_chroma_intra_mmxext;

#ifdef ARCH_X86_64
if( cpu&X264_CPU_SSE2 )
{
pf->deblock_v_luma = x264_deblock_v_luma_sse2;
pf->deblock_h_luma = x264_deblock_h_luma_sse2;
}
#else
pf->deblock_v_luma = x264_deblock_v_luma_mmxext;
pf->deblock_h_luma = x264_deblock_h_luma_mmxext;
#endif
}
#endif
#endif
}

[ChronoCross]

does anyone have experience building x264 with full support using cygwin? I'm having problems getting gpac to work. Throws a boatload of errors(aka I can't build and install gpac.) . any suggestions?

[squid_80]

Nope, I only use VS2003 (for both x264 and gpac). Maybe someone in the x264 development thread might know.

(actually I just noticed the build/cygwin folder has been removed from SVN. Maybe that's got something to do with it?)

[ChronoCross]

it looks like my cygwin install is missing something. however I'm not sure what cause I installed ALL the packages available at the time of install.

http://www.chronocrossdev.com/images/error.PNG

seems that it was a problem with the location of the compiled gpac include directories. but it still won't compile with avs support mp4 support or pthreads. even thought the ./compile options were chosen to use them.....strange indeed. I'll keep investigationg tomorrow. anyone have any suggestions?

[berrinam]

@ChronoCross: I had the same problems as you with cygwin. I have no solution except to use MinGW, which works flawlessly given these instructions (http://forum.doom9.org/showthread.php?p=723782#post723782)

[stephanV]

you seem to be missing the gpac lib.

[ChronoCross]

@ChronoCross: I had the same problems as you with cygwin. I have no solution except to use MinGW, which works flawlessly given these instructions (http://forum.doom9.org/showthread.php?p=723782#post723782)

yeah I was working off that for awhile. I'll continue to work on the cygwin solution. I've got some time. after I get it to work I'll see about making a faq....that's if I get it finished lol.

[squid_80]

http://www.chronocrossdev.com/images/error.PNG

seems that it was a problem with the location of the compiled gpac include directories. but it still won't compile with avs support mp4 support or pthreads. even thought the ./compile options were chosen to use them.....strange indeed. I'll keep investigationg tomorrow. anyone have any suggestions?
stephanV is right, it's saying it can't find the gpac library which is needed for mp4 output. If there was a problem finding the include files it wouldn't have made it to the linking stage. Have you actually compiled the gpac library and has it been placed in a directory that is searched by ld?

[ChronoCross]

stephanV is right, it's saying it can't find the gpac library which is needed for mp4 output. If there was a problem finding the include files it wouldn't have made it to the linking stage. Have you actually compiled the gpac library and has it been placed in a directory that is searched by ld?

that's the problem. gpac isn't ever able to fully compile. it always quits with about a thousand warnings and then a critical error. I'm trying to discover why as it shouldn't throw any errors.

[squid_80]

Might as well show us what those errors are then. ;)

[stephanV]

have you already tried to compile gpac with "make lib" instead of "make"?

[ChronoCross]

have you already tried to compile gpac with "make lib" instead of "make"?

indeed I have. I would show you the warnings and errors however I have no way to. I can give you like the last....15 lines later today. I have a full cygwin install running while I work and I should be able to try again soon. Thanks for the help. hopefully I can knock out this problem.

[Death Knight®]

libx264.lib(frame.obj) : error LNK2019: unresolved external symbol x264_deblock_v8_luma_mmxext referenced in function x264_deblock_v_luma_mmxext
is not appeared with ifndef Patch :)

And MSVCRT.dll errors don't fade out with Multithreading, I am continue to use ignore Libcmt.lib instead of it.

[movax]

You link to MSVCRT when Multithread DLL is specified, IIRC. If you search MSDN, they have a chart I keep forgetting to bookmark that lists the libraries and what switch they match up with. (/MT, MTd, etc).

[squid_80]

libx264.lib(frame.obj) : error LNK2019: unresolved external symbol x264_deblock_v8_luma_mmxext referenced in function x264_deblock_v_luma_mmxext
is not appeared with ifndef Patch :)

And MSVCRT.dll errors don't fade out with Multithreading, I am continue to use ignore Libcmt.lib instead of it.
OK, in frame.c again just above where we made the last edit:#ifndef _AMD64_
void x264_deblock_v_luma_mmxext( uint8_t *pix, int stride, int alpha, int beta, int8_t *tc0 )
{
x264_deblock_v8_luma_mmxext( pix, stride, alpha, beta, tc0 );
x264_deblock_v8_luma_mmxext( pix+8, stride, alpha, beta, tc0+2 );
}
#endif
And I'm pretty sure the MSVCRT errors shouldn't happen if you set both projects to multithreaded (not multithreaded DLL) and run clean/rebuild.

[ChronoCross]

Well after working with cygwin for the last few hours it doesn't seem like it can compile gpac no matter what I try. I think it's missing a library that MinGW has cause gpac compiles fine on it. If anyone else has any suggestions on compilation in cygwin it'd be greatly appreciated.

Thanks.

[ChronoCross]

I wanted to give one final comment on some reading I did. it seems that cygwin and MinGW do different things with their environment that for some reason does some wierd things when trying to access the file cc1.exe as part of gcc. without that you can't compile the 2 missing libraries you need for the ./configure script in gpac.

[Death Knight®]

I have double checked that Multi Threading both projects doesn't fade out MSVCRT.dll...

There
Linking...
libx264.lib(eval.obj) : error LNK2001: unresolved external symbol _iob
x264.obj : error LNK2019: unresolved external symbol _iob referenced in function Help
libx264.lib(common.obj) : error LNK2001: unresolved external symbol _iob
libx264.lib(getopt.obj) : error LNK2001: unresolved external symbol _iob
libx264.lib(csp.obj) : error LNK2001: unresolved external symbol _iob
errors are generating @ x264 linking.

I have decided not to compile x64 version, which is not %100 ready for x264. I thought that I can compile every new version with x64 build. But I understand it's not an easy job. :) I will try it after 400.th release :) Good days.

[Kostarum Rex Persia]

Well, Microsoft is guilty for that. I mean, he is guilty because now it's extremely difficult to compile any program for Windows x64, because Microsoft don't support anymore MMX instructions and FPU.

[Sharktooth]

MMX/FPU will be faded out gradually with new CPU releases to lower the CPU heat and prices.

[Gabriel_Bouvigne]

Well, Microsoft is guilty for that. I mean, he is guilty because now it's extremely difficult to compile any program for Windows x64, because Microsoft don't support anymore MMX instructions and FPU.
My understanding is that in user mode the x87 registers are still saved unpon context switching, contrary to popular belief. (someone from AMD confirmed it to me). This means that we can still use x87/mmx/3dnow in most programs.
In ring 0 (ie drivers), however, it seems that the x87 context is not saved anymore.

[squid_80]

Well, Microsoft is guilty for that. I mean, he is guilty because now it's extremely difficult to compile any program for Windows x64, because Microsoft don't support anymore MMX instructions and FPU.
Not really, unless the code was written to use mmx via intrinsics or inline assembly. Most of the common problems come from having to use the platform SDK with VS2003, VS2005 should solve this when it is released.My understanding is that in user mode the x87 registers are still saved unpon context switching, contrary to popular belief. (someone from AMD confirmed it to me). This means that we can still use x87/mmx/3dnow in most programs.
In ring 0 (ie drivers), however, it seems that the x87 context is not saved anymore.Correct. Although task-switching is a better term, context-switching is a bit too ambiguous (I think it's what gave birth to this misconception in the first place).

[issa]

I think the term "context-switching" is being used, because we are switching the context in the cpu, for example register value, and it implement on cpu to due with IRQ handle.
In modern OS, we use context-swithching to implement the task-switching in OS.

[squid_80]

I think the term "context-switching" is being used, because we are switching the context in the cpu, for example register value, and it implement on cpu to due with IRQ handle.
In modern OS, we use context-swithching to implement the task-switching in OS.This is exactly why I said the term is ambiguous. I think what microsoft is referring to is the switching between kernel code and userspace code - as Gabriel_Bouvigne said, mmx can't be used in drivers.

[Kostarum Rex Persia]

Excuse me squid_80 and Bond, I have one question for you, guys. On 11 november, Microsoft will debut with Visual Studio 2005. Did Visual Studio 2005 make some difference for 64-bit compiling? I heard that, with VS 2005, it's much more easier to make 64-bit programs.

Is it true?

[squid_80]

Not really. I've been using VS2005 beta 2 for the past 6 months, it makes it slightly easier to switch between building for 64-bit or 32-bit but I won't be buying it just for that.

[Kostarum Rex Persia]

Ok,thank you for answering me.

[Sharktooth]

The VS2005 "express" versions are completely free...
Oh, someone said there's also a Windows Vista Express (free) edition on the way... but it's unconfirmed.

[Sirber]

OT: Vista with ads?

[CruNcher]

Sure for Free Sponsered by the MPAA and RIA ready to activate your TPMs, HDCP and other Restriction systems we don't know yet ;)

[squid_80]

The VS2005 "express" versions are completely free...The express editions have no support for building 64-bit applications.

[ChronoCross]

VS2005 is sweet. I like it alot. Building in 64 bit is way easier. Best part about it is I got it simply because I'm a CS major whoo hoo to the MSDNAA.

[Sirber]

The express editions have no support for building 64-bit applications.I have C# express and it compile 64bit on my XP64 :)

[squid_80]

Any c# app will run in 64-bit if the x64 .net framework is installed. At least that's my experience.

[Sirber]

So you're talking about plain C++?

[Doom9 clone is here]

Hi, Squid_80, what is new about 64-bit x264. Do you plan to finish what you started?

[squid_80]

What do you mean by finish? Whenever new code is added to CVS I merge it and make a new build.

[Doom9 clone is here]

Sorry, I mean on further developing 64-bit edition. It seems like 64-bit version isn't optimised well. Only 10-15 % speed-up is misery for 64-bit codec.

Problem is, I suppose, in additional 64-bit registers. Codec doesn't see those registers well.

[squid_80]

Yes it does. That's exactly where the speed up comes from.

[BoNz1]

Only 10-15 % speed-up is misery for 64-bit codec.

Yeah, that's a terrible disappointment isn't it? Only 10-15%? C'mon, that's a huge boost. Next time make sure to use all your registers before you post again, hmm'k?

[foxyshadis]

64-bit isn't like dual core. It won't be awesomely amazingly faster except for 64-bit integer arithmetic, more registers, and huge memory mapped-files. It's still the same clock speed as it is in 32-bit mode.

[Doom9 clone is here]

Ok, but I think that, if we want yo do good job for 64-bit x264 version, codec should be SSE, SSE2 and SSE3 optimised, because Windows XP x64 edition doesn't support FPU and MMX instructions any more.

What about other programs. I saw programs that, compared to 32-bit version, have a speed-up 50 and more %. Etc, programs for 3D, CAD. So, it's logically that x264 64-bit should be at least 35 % faster than 32-bit.

[Manao]

Why don't speak about things you know instead of making unfounded claims ?because Windows XP x64 edition doesn't support FPU and MMX instructions any moreFalsehave a speed-up 50 and more %. Etc, programs for 3D, CAD. So, it's logically that x264 64-bit should be at least 35 % faster than 32-bit.That's not logic, that's drawing parallels. x264 is already mmxed, sseed, and sse2ed. You won't speed these part with 64bits ( more registers will hardly help there, except for deblocking ). And you already noticed that the C code only gets 10 % faster. So obviously, you won't get 35%. It's not because badly written software, when rewritten properly and for 64bits, get a 50 % speed up that x264 will.

Finally : if we want yo do good job for 64-bit x264 versionThat may hurt the feeling of some devs, because it implies they didn't do a good job. You're not a native speaker, but do take care of what you're writting.

[Doom9 clone is here]

Ahhh, it's clear now. Thanks.

But, Manao, I have one question. If x264 codec be written in Delphi 2006, what then. Is it possible that in Delphi 2006 64-bit codec get more speed-up.

And, about Ati graphic cards x1600 Pro and x1800 XT, can x264 codec be optimised, in the near future, to fully support Avi Avivo encoder?

[Manao]

Ok, Kostarum, or whoever you are. Stop a minute, think about what you're writting, stop asking useless questions about what may / might happen if we did this or that. It's quite annoying.

[Romario]

Ok, guys, I find on site http://omion.dyndns.org/x264x64/ new x264 64-bit builds.

What's the main difference and new optimizations in omion builds.

Omion, give me some explanation how you optimised new 64-bit builds? About speed-up, can you tell me how much is 64-bit edition faster then 32-bit edition?

[shon3i]

I tryed lastest version on but only i get 6fps in second pass on AMD Vience 3000+ 64bit.

[Kostarum Rex Persia]

What was your settings from command line? Please post it here.

[shon3i]

There is C:\Program Files\x264\x264.exe --pass 2 --bitrate 737 --stats ".stats" --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --subme 6 --trellis 2 --analyse all --8x8dct --direct temporal --me umh --progress --no-psnr --output "C:\Documents and Settings\Nenad\Desktop\StealthDVD\Stealth.mkv" "C:\Documents and Settings\Nenad\Desktop\StealthDVD\Stealth.avs"

[squid_80]

:script:

[shon3i]

oh i am sorry

mpeg2source("C:\Documents and Settings\Nenad\Desktop\StealthDVD\Stealth.d2v")
crop( 0, 76, -2, -76)
LanczosResize(640,272)
RemoveGrain(mode=2)

[squid_80]

Are you sure? I didn't know there was a RemoveGrain plugin for x64. But ignoring that, resizing using avisynth64 is extremely slow and would definitely be the cause of the slowdown.

[shon3i]

Are you sure? I didn't know there was a RemoveGrain plugin for x64. But ignoring that, resizing using avisynth64 is extremely slow and would definitely be the cause of the slowdown.
Maybe you right i try that later

[Kostarum Rex Persia]

shon3i, did you finished testing. When you will post results without RemoveFrain and Resize filters?

[Romario]

Shon3i, where is your results, we wait.

[shon3i]

Shon3i, where is your results, we wait.
Oh sorry Romario i have big PC crash and i must back to 32-bit version of Windows. I am not planing to back to 64-bit until Vista come out. But if back in 64-bit for some reason, i post results.

[Romario]

Oh, sorry to hear that, shon3i.

[shon3i]

Oh, sorry to hear that, shon3i.
And me very sorry becouse i get very interesting results, and now everything is gone

[Death Knight®]

Hi, again me :)
I tried to compile x264's r523 with VC2005 x64 bit mode and I fail again :)


I used yasm 0.5r2. Yasm gives error at assembly files.

at quant-a.asm file gives error with this lines
quant-a.asm:480: DEQUANT_WxH x264_dequant_4x4_mmx, 4, 4
quant-a.asm:481: DEQUANT_WxH x264_dequant_8x8_mmx, 16, 6

\x264\common\amd64\
quant-a.asm:480: label or instruction expected at start of line
quant-a.asm:480: redefinition of `x264_quant_8x8_core32_mmxext.startfunc'
quant-a.asm:370: `x264_quant_8x8_core32_mmxext.startfunc' previously defined here

and also with this functions too
`x264_quant_8x8_core32_mmxext.lshift'
`x264_quant_8x8_core32_mmxext.rshift32'


if I delete that two lines, than pixel-a.asm raises error for
pixel-a.asm:504:SAD_X 3, 16, 16 lines...

pixel-a.asm:504: expression syntax error
pixel-a.asm:504: label or instruction expected at start of line
pixel-a.asm:505: expression syntax error
pixel-a.asm:505: label or instruction expected at start of line
and for 506, 507.......

Does any one succesfully compile x264's last revisions for Win64?
squid_80 did you compile it?
:thanks:

[squid_80]

Nah it's been broken since about r490, haven't got around to making it work.

[Death Knight®]

I digged in quant-a.asm file and I found that,
yasm cannot process %macro's properly

If you open (unroll) macro's within hand, ASM file compiles perfectly.
(its worked for
DEQUANT_WxH x264_dequant_4x4_mmx, 4, 4
DEQUANT_WxH x264_dequant_8x8_mmx, 16, 6
macro/functions)

It's may be not problem for quant-a.asm but pixel-a.asm.
It has many macros which has many macros in itself.
(My english is bad, but I think you understand situation.)

I wonder that how yasm could not process macros properly.

[Death Knight®]

I think I found a bug at pixel-a.asm...

line 109: SAD_X3_1x8P q, FENC_STRIDE, parm5q

triggers SAD_X3_1x8P with parm5q = %3

line91: mov%1 mm4, [parm2q+%3]
means

movq mm4, [parm2q + parm5q]

looks smooth but at amd64inc.asm file
line 68: %define parm5q [rsp+40]
causes
movq mm4, [parm2q + [rsp+40]]

and I think it's generates "expression syntax error" (due stack operation?).

For solution,
I think we have to change amd64inc.asm line 91 with something else like register. At win64, Stack operations are prohibited, isn't it?

I am ASM newbie, I don't have many knowledge. I will try to solve this but, what you think about it?

Edit:
I have chenged amd64inc.asm with this table

%define parm1q rcx
%define parm2q rdx
%define parm3q r8
%define parm4q r9
%define parm5q r10
%define parm6q r11
%define parm7q r12
%define parm8q r13
%define parm1d ecx
%define parm2d edx
%define parm3d r8d
%define parm4d r9d
%define parm5d r10d
%define parm6d r11d
%define parm7d r12d
%define parm8d r13d


I have som compiletion problems but I compiled x264 library now.
But x264 cannot compiled. It gives error...


------ Build started: Project: x264, Configuration: Release64 x64 ------
Linking...
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(pixel.obj) : error LNK2019: unresolved external symbol x264_pixel_sa8d_8x8_mmxext referenced in function x264_pixel_init
libx264.lib(pixel.obj) : error LNK2019: unresolved external symbol x264_pixel_sa8d_16x16_mmxext referenced in function x264_pixel_init
libx264.lib(dct-c.obj) : error LNK2019: unresolved external symbol x264_transpose_8x8_mmx referenced in function x264_sub8x8_dct8_mmx
libx264.lib(dct-c.obj) : error LNK2019: unresolved external symbol x264_ydct8_mmx referenced in function x264_sub8x8_dct8_mmx
libx264.lib(dct-c.obj) : error LNK2019: unresolved external symbol x264_pixel_sub_8x8_mmx referenced in function x264_sub8x8_dct8_mmx
libx264.lib(dct-c.obj) : error LNK2019: unresolved external symbol x264_pixel_add_8x8_mmx referenced in function x264_add8x8_idct8_mmx
libx264.lib(dct-c.obj) : error LNK2019: unresolved external symbol x264_yidct8_mmx referenced in function x264_add8x8_idct8_mmx
libx264.lib(predict-c.obj) : error LNK2019: unresolved external symbol x264_intra_sa8d_x3_8x8_core_mmxext referenced in function x264_intra_sa8d_x3_8x8_mmxext
libx264.lib(predict-c.obj) : error LNK2019: unresolved external symbol predict_8x8_ddr_mmxext referenced in function x264_predict_8x8_init_mmxext
bin/x264.exe : fatal error LNK1120: 15 unresolved externals
Build log was saved at "file://x:\C++\Compiled\x264\build\win32\x64\Release64\BuildLog.htm"
x264 - 36 error(s), 1 warning(s)
========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========

[squid_80]

There are errors like the one you pointed out (works for linux since parm5 is a register, not passed on the stack like in windows) but there's other stuff that won't show up as errors when you compile, such as xmm registers not being preserved upon entering a function that uses them.

[markrb]

Just installed the Beta 2 of Vista 64 bit and would love to try and test x264 in 64 bit.
If I install the 64 bit version of avisynth can I still use 32 bit Megui with it and the 64 bit x264?

In my way of thinking it should work, because Megui passes along commands and doesn't actually run inside those, but I could be way off here.

On that note does anyone know where to get the latest Megui (if possible) capable version of x264?
It now appears I can't locate avisynth64, dgdecode or any of the 64 bit filters. Seems all the links are down.
If someone knows where they are can you post a link.

Thanks,
Mark

[squid_80]

ftp://squid80.no-ip.com
or http://okejl.dk/dunstan/

I wouldn't recommend avisynth64 at this point, there are only a few filters and the resizing is still quite slow.

[markrb]

Luckily I don't resize.
The only filter I ever use is TITVC(sp?).
Is that available for Avisynth64?

I get an error on the first, but I can get to the second.

There doesn't seem to be a compiled Jun 06 Cli version.
I don't know how to do this can someone please compile it and post it if
it's not too much trouble?

Thanks,
Mark

[Kostarum Rex Persia]

I am very disappointed with development of 64-bit x264 and Avisynth.

Devs said it's hard to make 64-bit programs, but I think that's not the case at all. Who knows what's the reason!!!

[ChronoCross]

I am very disappointed with development of 64-bit x264 and Avisynth.

Devs said it's hard to make 64-bit programs, but I think that's not the case at all. Who knows what's the reason!!!

Listen KRP. It's not like just turning on a switch in the compiler suddenly turns it into a 64-bit application. In order to make it truely 64-bit you have to re-write ALMOST EVERYTHING. to make it all 64-bit. That's why it takes so long for this shit to get done. not to mention you can't just run it on any ol system. you have to be running a 64-bit OS. which at this moment is POINTLESS because almost no programs are fully 64-bit.

Please never post in this or any other thread again unless you have something to say other than how none of the developers are hardworking and that doing all these things is easy as pie. Which basically means you should stop posting because none of your posts ever have any real substance to them.

Which is one of the reasons you've already been mod queued once already.

[Audionut]

I am very disappointed with development of 64-bit x264 and Avisynth.
It's very very simple.
If you are disappointed, then get off your slack ass and do it yourself.


Devs said it's hard to make 64-bit programs, but I think that's not the case at all.

Well then. Show us all how it's done.

Oh wait. Have you a 64bit pc yet?
Any programming skills?

Didn't think so.

[squid_80]

Luckily I don't resize.
The only filter I ever use is TITVC(sp?).
Is that available for Avisynth64?

I get an error on the first, but I can get to the second.

There doesn't seem to be a compiled Jun 06 Cli version.
I don't know how to do this can someone please compile it and post it if
it's not too much trouble?

Thanks,
Mark
I haven't done TIVTC yet, but I have looked at the source and know what needs to be done. It's a matter of finding the time. Same goes for x264, I'm about half way through fixing all the changes from 12/05->now. (The source matches the available compiled version, I just recently editted the zip file to make it smaller hence the newer datestamp.) Omion was doing regular builds for a while, see here. (http://omion.dyndns.org/x264x64/)

I am very disappointed with development of 64-bit x264 and Avisynth.

Devs said it's hard to make 64-bit programs, but I think that's not the case at all. Who knows what's the reason!!!
Yeah, I want to complain to whoever's in charge of these things! Oh wait, IT'S ME.
What 64-bit stuff was around before I started? Nothing. Did I whine and complain until something was done? No, I got off my slack a** like Audionut suggested and did something about it. What do I get out of it? NOTHING, the same as nearly every other developer on this board. So unless you want to donate something to the community other than criticism I suggest you leave or be quiet.

[markrb]

I appreciate all your hard work.
I found another 64 bit detour along the way that will hinder me a bit though.
Daemon tools 64 does not run on Vista 64. It says it will on their download page, but in their forums they say it won't.

3.X versions will work on the 32 bit Vista though, but not the 4x ones FYI.

Everything I have is in ISO form ready to be converted. I really don't want to have to re-rip everything in file mode.

I do still want to test 64 bit x264, but this just makes using it everyday a bit impractical now.

Thanks,
Mark

[Guest]

ChronoCross, squid_80, and AudioNut, profanity and insults are not tolerated. Please read and follow forum rules, specifically: rule 4.

http://forum.doom9.org/forum-rules.htm

[berrinam]

ChronoCross, squid_80, and AudioNut, profanity and insults are not tolerated. Please read and follow forum rules, specifically: rule 4.

http://forum.doom9.org/forum-rules.htm
In their defence, KRP has a reputation for useless/annoying requests without first thinking (foxyshadis's signature can testify to that -- 'If x264 codec be written in Delphi 2006, what then. Is it possible that in Delphi 2006 64-bit codec get more speed-up.' ~ Kostarum Rex Persia), and they were clearly just baited by his implicit insults. If we look at the posts individually:

I am very disappointed with development of 64-bit x264 and Avisynth.

Devs said it's hard to make 64-bit programs, but I think that's not the case at all. Who knows what's the reason!!!
The implication is that the devs are lying when they say it is hard to make 64-bit programs. I think it is pretty offensive to say someone is lying without evidence that there is, and criticising 64-bit development of x264 means criticising squid_80's work, which is clearly insulting, again without evidence.

Added to that, KRP is simply making a post without meaning, which disagrees with forum rule 11, no spam. I can say it lacks meaning because personal opinions (the first paragraph) don't actually aid video encoding, and the second paragraph is clearly not true.

On the other hand, while ChronoCross's post may have been slightly exaggerated (as I showed above, it isn't a complete lie, however) in saying that all of KRP's posts are meaningless, and Audionut wasn't completely politically correct by calling KRP slack (although looking KRP's history and non-contribution to Doom9 projects, this claim is also supported), the posts weren't specifically insulting, but rather embodying the well-known open source philosophy: "don't whine if something hasn't been done; do it yourself".

Furthermore, squid_80 has been struck although he didn't insult KRP at all.

I don't normally object to moderation, because I know that it is a difficult job and no-one enjoys playing the 'tough guy,' but
it is not fair to moderate individual posts out of their context; and
ChronoCross, Audionut and squid_80 are all valuable contributors to the Doom9 community, so it would be a shame to lose them or discourage them over a simple misunderstanding such as this one

All the best,

berrinam

[squid_80]

I used profanity so it's a fair call. I guess this is why we have a 3 strikes rule, rather than 1 strike = banned.

markrb: I haven't tried it myself, but I have heard about Virtual ISO. (http://www.braindonors.net/products/virtualiso.asp) It's not free, but there's a trial version that might work.

[foxyshadis]

He's always worth a chuckle even if his contributions are highly suspect. Every forum needs a crank or three.

Something I forgot to ask before, squid_80; is 64-bit much better than 32-bit for processing 16-bit pixels, or is it unimportant and just a matter of proper handling either way?

[Manao]

foxyshadis : you've got more registers on 64 bits platform, so pure "C" code will be around ~10% faster, whether you process 8 bits or 16 bits pixels

The drawback is that assembler isn't compatible, so you have to rewrite it completely. It's not necessarily that complicated for simple function, but a straightforward conversion doesn't let you benefit from the additionnal registers, so taking full advantage of the processor needs a complete rewriting ( with the associated bugs & co ).

Moreover, for avisynth comes another difficulty, since some of the assembler code used for resizers is compiled at the executation time, and, alas, the library used for that ( softwire ) isn't 64 bits compatible, and won't be anytime soon ( the author continued his worked closed source, and nobody's working on it anymore ). And, of course, making it 64 bits compatible doesn't only require "just" to recompile it...

Finally, for avisynth, you must also recompile all the plugins you planned to use. Since most are highly asm optimized, it's a huge task.

[squid_80]

Finally, for avisynth, you must also recompile all the plugins you planned to use. Since most are highly asm optimized, it's a huge task.
And to my knowledge no-one's even attempted it except me. Hence the lack of progress.

[Kostarum Rex Persia]

I didn't say that Devs lie, I just wondered why is so difficult to compile 64-bit build of x264 codec?

I'm sorry if I insult someone.

[Blue_MiSfit]

He's always worth a chuckle even if his contributions are highly suspect. Every forum needs a crank or three.

I second that.

Although I think a lot of it has to do with language barriers...

There's a lot of misunderstanding on this forum, but we're all one big happy family :D

[Kostarum Rex Persia]

I second that.

Although I think a lot of it has to do with language barriers...

There's a lot of misunderstanding on this forum, but we're all one big happy family :D

Yes, you are right. English isn't my native language, so I don't speak English very well. I understand all, but sometimes I have problem with grammar and spelling.

[sillKotscha]

KRP is the serbian answer to a well know austrian (german speaking) troll named tuvok - maybe they are related to each other?? who knows...

[Guest]

Gentlemen, please stay on topic and avoid personal comments about others, per forum rules. Thank you.

http://forum.doom9.org/forum-rules.htm

[pavelba]

Can anybody produce a VFW x264 decoder for XP64?
The latest ffdshow for X64 does not work on XP64.
In other hand I need x264 decoder only, no big package like ffdshow.

[slavickas]

Can anybody produce a VFW x264 decoder for XP64?
The latest ffdshow for X64 does not work on XP64.
In other hand I need x264 decoder only, no big package like ffdshow.

well x264 is just ENcoder, so at least wrong thread, as x264 have nothing common with decoding

[pavelba]

Yes. Tel me how to open h264 avi by VirtualDub64 under XP64 when ffdshow does not working?

[LoRd_MuldeR]

Yes. Tel me how to open h264 avi by VirtualDub64 under XP64 when ffdshow does not working?
1. There already are x64 builds of ffdshow-tryouts available! They are flagged as "experimental" though. See here (http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=229162).
2. Even if you had an x64 build of x264 VFW, it wouldn't help you to open H.264 video in VDub, as x264 VFW is an "Encoder only" codec :rolleyes: