x264 64-bit version,when?

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