x264 64-bit version,when?

[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