[MPlayer-users] compiling and using mplayer/mencoder on AMD 64 bit architecture

[Phil Oleynik]

Guillaume POIRIER wrote:

>Hi,
>
>On 11/25/05, Phil Oleynik <Oleynik.Phil at mail.ioffe.ru> wrote:
>
>  
>
>>First thing that made me sad, is that win32 DLLs are no longer usable
>>when compiled on Athlon 64. Some old programs distributed as static
>>binaries work fine, although they're true 32-bit. So I do not see any
>>serious problems to use win32 DLLs, but mplayer fails to do it.
>>    
>>
>
>You can't mix 32 bit code and 64 bit code (at least, not without big hacks).
>Just compile MPlayer in 32 bits (read the FAQ to learn how to do it)
>  
>
I know exactly how to do it, but this is not the point. If an application
can be 64-bit, I'd prefer it to be. It really works in 64 it mode, but 
without these libs.
I am considering a rebuilt, something like mplayer_32 binary, to use 
win32 when its the only way.

>
>  
>
>>Another thing is that despite configure detects AMD64 fine, there are
>>some places in vf_overlay.c, where "movl" and "decl" assembler instructions
>>are still used. They should be replaced with mov and dec, since what is
>>long for ia32, is normal for ia64 and amd64.
>>    
>>
>
>Nope, it all depends on what you want to do. No need to use large data
>types when there's no use for it. That's what is written on AMD's
>manuals.
>  
>
Well, it's not about it :)
It is about the fact, if you would try to compile it as it is, assembler
will say "illegal" for using suffix 'l' with register %rcx, as it was in
vf_overlay.c case. I could provide a patch, but I am not sure, since
I'm not a great programmer ;) With edited sources mplayer builds
just fine and works for some media files. I haven't tested it much yet.

>  
>
>>I have not noticed any other bugs, I'll keep informing if any. I use latest
>>CVS of ffmpeg, mplayer, XviD, lame, x264.
>>    
>>
>
>It's good that you tried CVS (as most reports we get are against
>releases)... but next time, try to be more creative and provide patch
>that you would have thoroughly tested instead of just saying smth 
>such as "you should do that", because it sounds like you're bossing
>around.
>  
>
The only things I get working by editing the source were making a dicision
about 67th command in /input/input.h, its name changed and CVS noted it
with ">>>>>>>>" line and version reference.

<<<<<<< input.h
#define MP_CMD_VF_OVERLAY 67
=======
#define MP_CMD_VO_BORDER 67
 >>>>>>> 1.59

My mplayer CVS root is updated every night. In some portions of code
67th command bears old name, and I was to remove old name and put a new  
one.

Other thing was to replace
==============
901-                ".balign 16 \n\t"
902:                "movl %4, %%"REG_c"\n\t"

===============
to
==============
901-                ".balign 16 \n\t"
902:                "mov %4, %%"REG_c"\n\t"

==============
and
=============
942-                "add $8, %3\n\t"
943:                "decl %%"REG_c"\n\t"
944-                "jnz 1b \n\t"
=============
to
=============
942-                "add $8, %3\n\t"
943:                "dec %%"REG_c"\n\t"
944-                "jnz 1b \n\t"
=============
in /libmpcodecs/vf_overlay.c

I am not sure whether I am right, so these are just my guess, how it 
should be.

Philipp