Jump to content

Mplayer?


nmol010
 Share

38 posts in this topic

Recommended Posts

EDITE 11/15/05

 

WE NEED A NEW LINK PLEASE PM ME OR TALK TO ME IN IRC WITH THE LINK OR MIRROR.

 

thanks

--sportman

 

 

 

 

Hi,

 

 

I have been trying to compile a basic console version of Mplayer for a couple of days now and I havent got very far. Has anybody else tried? any sucesses?

Link to comment
Share on other sites

Hi,

I have been trying to compile a basic console version of Mplayer for a couple of days now and I havent got very far. Has anybody else tried? any sucesses?

 

http://free.x3.hu/magveto/mplayerosx86_wit..._and_sdlfix.zip

 

needs gfx accel

 

doesn't have libavcodec (has xvid and mpeg2 support though)

 

apparently quicktime supplied colorspace conversion crashes it YUV420ToRGB32BitColorARGB_W1x for example which it wants to use for unsupported gfx

 

YV12 colorspace appears to be reported working by the driver but actually broken (green sometimes corrupted video if trying to use it, I'm guessing the green screen in VLC with the CoreVideo(macosx) output suffers from this issue as well) mplayer's builtin fastconverter solves this problem for ppl with supported gfx

 

read the readme before using <_<

 

if anyone wants to port the optimized part of libavcodec, make this work on unsupported gfx, or do whatever constructive with it let me know and i'll put together a compile guide

Link to comment
Share on other sites

I've been working with the normal MPlayer source rather than the OSX version.

 

So far I have:

  Enabled optional drivers:
   Input: ftp network edl tv matroska mpdvdkit2 vcd
   Codecs: xvid libavcodec libmpeg2 liba52 mp3lib tremor(internal)
   Audio output: sdl mpegpes(file) macosx
   Video output: sdl md5sum pnm mpegpes(file) opengl xv x11 xover tga quartz
   Audio filters:

opengl and xv both fail, presumably because they go through Apple's X11, and quartz doesn't work because I don't have quartz support. x11 works but doesn't scale. Should I try to enable vesa or vidix?

 

I'm really interested in getting the assembly to work. Now I have everything disabled because of differences between Apple as and GNU gas. Regrettably this means the win32 codecs must be disabled because the loader uses assembly. What's the best way to deal with this? Use a different assembler? Convert to Apple assembly?

 

EDIT: vesa is only for x86 Linux, so I don't suppose there's much hope of enabling it

Link to comment
Share on other sites

http://leechar.5gigs.com/mplayerosx86.zip

 

needs gfx accel

 

doesn't have libavcodec (has xvid and mpeg2 support though)

 

apparently quicktime supplied colorspace conversion crashes it YUV420ToRGB32BitColorARGB_W1x for example which it wants to use for unsupported gfx

 

YV12 colorspace appears to be reported working by the driver but actually broken (green sometimes corrupted video if trying to use it, I'm guessing the green screen in VLC with the CoreVideo(macosx) output suffers from this issue as well) mplayer's builtin fastconverter solves this problem for ppl with supported gfx

 

read the readme before using :)

 

if anyone wants to port libavcodec, make this work on unsupported gfx, or do whatever constructive with it let me know and i'll put together a compile guide

 

I would really appreciate it if you would post a compile guide. Doenst neeed to be too descriptive... Im fimilar linux build tools (configure/make...) cheers.

Link to comment
Share on other sites

I've been working with the normal MPlayer source rather than the OSX version.

 

So far I have:

  Enabled optional drivers:
   Input: ftp network edl tv matroska mpdvdkit2 vcd
   Codecs: xvid libavcodec libmpeg2 liba52 mp3lib tremor(internal)
   Audio output: sdl mpegpes(file) macosx
   Video output: sdl md5sum pnm mpegpes(file) opengl xv x11 xover tga quartz
   Audio filters:

opengl and xv both fail, presumably because they go through Apple's X11, and quartz doesn't work because I don't have quartz support. x11 works but doesn't scale. Should I try to enable vesa or vidix?

 

I'm really interested in getting the assembly to work. Now I have everything disabled because of differences between Apple as and GNU gas. Regrettably this means the win32 codecs must be disabled because the loader uses assembly. What's the best way to deal with this? Use a different assembler? Convert to Apple assembly?

 

EDIT: vesa is only for x86 Linux, so I don't suppose there's much hope of enabling it

 

There is no OSX version B) Mine was compiled from CVS pulled about a week ago.

I just put the compiled console mode mplayer into the compiled frontend's bundle.. if you want to get to it right click on the bundle select show package contents then go to

Contents->Resources->mplayer (show package contents again) -> Contents -> MacOS and there you have it.

or from terminal cd MPlayer\ OS\ X\ 2.app/Contents/Resources/mplayer.app/Contents/MacOS/

 

uhh I dunno what you did to get quartz enabled but not corevideo, did you tweak the configure file? theres a line there saying darwin && ppc or did you just disable that because of asm issues?

 

as for libavcodec you need to port nasm code to gas code with that.. I didn't fiddle around much with it as that is beyond my abilities. CORRECTION i'm looking into it right now --okay libavcodec compiles if you butcher it into not using MMX and stuff so the things to port to Gas syntax are in libavcodec/i386

 

well anyway I had to modify and recompile the apple assembler to get this to work, and I had to use two different GCCs (4.0 and 3.5(from the darwin 8.0.1 cd)) as mp3lib fails to compile with 4.0

 

I've written a guide a few days ago when I was still having problems I'll update that asap but until then and i'm too lazy to update it, but anyway here it is:

http://leechar.5gigs.com/mp.html

 

what you need to edit in that source tree to get it to link is mangle.h and cpudetect.h

with mangle.h either add darwin to the list of oses to use the _ mangling with, or edit both sides of the if to contain "_"

 

as for cpudetect search of check_os_katmai_support and either break the if again by hardenabling SSE and SSE2 or add darwin.

Link to comment
Share on other sites

I enabled quartz by removing the ppc condition from the configure script. It doesn't detect finder or bundle file, but I don't think I need those. How do I use this "corevideo"? Which -vo option is it? -vo quartz crashes.

 

Your suggestion about changing the macro in mangle.h didn't make a difference, and I don't have check_os_katmai_support in cpudetect.h. Linking works if I force -fPIC by adding it to the CFLAGS, but I don't think it's technically correct.

 

gcc 3.5.0 gives me the same absolute zero error as 4.0 in mp3lib. Have you found a better fix?

 

You mention patching the assembler. Would that solve anything other than the / problem? I fixed that by changing the /s to #s, but I still have to disable assembly because of the absolute zero problem. If I try to disable assembly only for mp3lib, mp3lib builds but it still looks for the MMX stuff during the final linking.

 

If you're interested in a proper fix for the .baligns, I looked at the documentation and Apple's .align does the same thing, except you have to take the log base 2 of the argument (.balign 8 becomes .align 3, .balign 16 becomes .align 4, etc.). .endm needs to be changed to .endmacro, and there are some other subtle differences. Would it be possible to get the win32 codecs working if I changed the loader to Apple-friendly assembly, or would more drastic changes be required because of the Mach-O format? If you're working on the win32 loader too, #pragma pack() needs an argument with Apple's gcc. I think it's supposed to be 4, but I'm not sure.

Link to comment
Share on other sites

I enabled quartz by removing the ppc condition from the configure script. It doesn't detect finder or bundle file, but I don't think I need those. How do I use this "corevideo"? Which -vo option is it? -vo quartz crashes.

 

Your suggestion about changing the macro in mangle.h didn't make a difference, and I don't have check_os_katmai_support in cpudetect.h. Linking works if I force -fPIC by adding it to the CFLAGS, but I don't think it's technically correct.

 

gcc 3.5.0 gives me the same absolute zero error as 4.0 in mp3lib. Have you found a better fix?

 

You mention patching the assembler. Would that solve anything other than the / problem? I fixed that by changing the /s to #s, but I still have to disable assembly because of the absolute zero problem. If I try to disable assembly only for mp3lib, mp3lib builds but it still looks for the MMX stuff during the final linking.

 

If you're interested in a proper fix for the .baligns, I looked at the documentation and Apple's .align does the same thing, except you have to take the log base 2 of the argument (.balign 8 becomes .align 3, .balign 16 becomes .align 4, etc.). .endm needs to be changed to .endmacro, and there are some other subtle differences. Would it be possible to get the win32 codecs working if I changed the loader to Apple-friendly assembly, or would more drastic changes be required because of the Mach-O format? If you're working on the win32 loader too, #pragma pack() needs an argument with Apple's gcc. I think it's supposed to be 4, but I'm not sure.

 

eh.. which version exactly are you trying to compile? last stable? symbol mangling needed to be changed for me otherwise i'd get a page of undefined symbols.

as for the check_os_katmai_support that might've been cpudetect.c if there is such a file and i'm sure it was the second match in the file.

If you're not trying to compile the cvs then I can't really help.

For mp3lib if I have gcc 3.5 selected it just works for me. I don't really understand what it's problem is with 4.0 or why it fails to work for you.

corevideo output is vo_macosx.c

The patched assembler shouldn't be responsible for anything else than the / comment character fix, but I think it's a slightly different version from the included one so you could try, but I doubt that it'd solve anything else.

 

What do you mean by win32 codecs? :D

 

btw my last compile: http://leechar.5gigs.com/mplayerosx86_with_libavcodec.zip

Link to comment
Share on other sites

I've been trying to compile 1.0pre7, but I'll switch to CVS. It seems I don't even have a vo_macosx.c.

 

How do you not know about the win32 codecs? It's one of MPlayer's best features. Using some code from WINE, MPlayer is able to load and use binary codecs from Windows for Quicktime, Real, and Windows Media support. Get the essential codecs tarball and extract it to /usr/local/lib/win32 or somewhere else if you tell configure where to find it. Then you should start seeing the errors I mentioned in my previous post.

 

EDIT: I finally built an optimized binary with core video support, but with both your first build and my current build, the MPlayer window is solid black. x11 is still the only working -vo.

Link to comment
Share on other sites

I've been trying to compile 1.0pre7, but I'll switch to CVS. It seems I don't even have a vo_macosx.c.

 

How do you not know about the win32 codecs? It's one of MPlayer's best features. Using some code from WINE, MPlayer is able to load and use binary codecs from Windows for Quicktime, Real, and Windows Media support. Get the essential codecs tarball and extract it to /usr/local/lib/win32 or somewhere else if you tell configure where to find it. Then you should start seeing the errors I mentioned in my previous post.

 

EDIT: I finally built an optimized binary with core video support, but with both your first build and my current build, the MPlayer window is solid black. x11 is still the only working -vo.

 

What kind of gfx do you have? It's been tested on GMA900 to work with sdl,quartz(to some extent),and corevideo (not just by me). I'll include the X11 vo in the next build if that works on unsupported gfx. Never heard of that feature but if it requires nasm -> gas porting then i'm not the one to do it :D

 

did you include -vf yuvcsp as described in my readme?

Link to comment
Share on other sites

I have a Radeon 9000. It loads the Radeon8500 kext with my card's PCI ID added, but it ends up falling back on Vesa 3.0. Neither of our builds works with -vo macosx -vf yuvcsp.

 

The win32 loader includes two relatively short assembly files, both AT&T syntax. The porting involved is GAS / ELF to Apple AS / Mach-O. I can tweak the files to assemble, but mplayer doesn't link at the end, failing to find the symbols from the pure assembly files.

Link to comment
Share on other sites

I fixed the assembly in the win32 loader, and I'm reasonbly confident my fixes are correct. For wrapper.S I changed the .baligns and added symbols starting with underscores to fix a weird linking problem. For stubs.s I fixed a symbol, changed .baligns, and added a stub for printf (copied from the gcc assembly output of a hello world program).

 

When I run it, I get

 

Opening audio decoder: [dmo] Win32/DMO decoders
ERROR: Couldn't allocate memory for fs segment: Operation not supported by device

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand.
0x00085f61 in Setup_FS_Segment () at ldt_keeper.c:126
126         __asm__ __volatile__(
(gdb) backtrace
#0  0x00085f61 in Setup_FS_Segment () at ldt_keeper.c:126
#1  0xbfffe868 in ?? ()
#2  0x00096e86 in DMO_AudioDecoder_Open (dllname=0x20cdb4 "wmadmod.dll", guid=0x295680, wf=0xb0d9d0, out_channels=2) at DMO_AudioDecoder.c:50
#3  0x00074dc4 in preinit (sh_audio=0xb0db20) at ad_dmo.c:38
#4  0x00041d23 in init_audio_codec (sh_audio=0xb0db20) at dec_audio.c:60
#5  0x000420d4 in init_audio (sh_audio=0xb0db20, codecname=0x0, afm=0x0, status=1) at dec_audio.c:184
#6  0x0004228b in init_best_audio_codec (sh_audio=0xb0db20, audio_codec_list=0xbfffe93c, audio_fm_list=0x0) at dec_audio.c:229
#7  0x0000442e in main (argc=4, argv=0xbffffbb4) at mplayer.c:1995

 

#define       LDT_SEL(idx) ((idx) << 3 | 1 << 2 | 3)
...
void Setup_FS_Segment(void)
{
   unsigned int ldt_desc = LDT_SEL(fs_ldt);

   __asm__ __volatile__(
"movl %0,%%eax; movw %%ax, %%fs" : : "r" (ldt_desc)
:"eax"
   );
}

The illegal instruction is "movw %ax,%fs". I'm not sure how to proceed.

Link to comment
Share on other sites

I fixed the assembly in the win32 loader, and I'm reasonbly confident my fixes are correct. For wrapper.S I changed the .baligns and added symbols starting with underscores to fix a weird linking problem. For stubs.s I fixed a symbol, changed .baligns, and added a stub for printf (copied from the gcc assembly output of a hello world program).

 

When I run it, I get

 

Opening audio decoder: [dmo] Win32/DMO decoders
ERROR: Couldn't allocate memory for fs segment: Operation not supported by device

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand.
0x00085f61 in Setup_FS_Segment () at ldt_keeper.c:126
126         __asm__ __volatile__(
(gdb) backtrace
#0  0x00085f61 in Setup_FS_Segment () at ldt_keeper.c:126
#1  0xbfffe868 in ?? ()
#2  0x00096e86 in DMO_AudioDecoder_Open (dllname=0x20cdb4 "wmadmod.dll", guid=0x295680, wf=0xb0d9d0, out_channels=2) at DMO_AudioDecoder.c:50
#3  0x00074dc4 in preinit (sh_audio=0xb0db20) at ad_dmo.c:38
#4  0x00041d23 in init_audio_codec (sh_audio=0xb0db20) at dec_audio.c:60
#5  0x000420d4 in init_audio (sh_audio=0xb0db20, codecname=0x0, afm=0x0, status=1) at dec_audio.c:184
#6  0x0004228b in init_best_audio_codec (sh_audio=0xb0db20, audio_codec_list=0xbfffe93c, audio_fm_list=0x0) at dec_audio.c:229
#7  0x0000442e in main (argc=4, argv=0xbffffbb4) at mplayer.c:1995

 

#define       LDT_SEL(idx) ((idx) << 3 | 1 << 2 | 3)
...
void Setup_FS_Segment(void)
{
   unsigned int ldt_desc = LDT_SEL(fs_ldt);

   __asm__ __volatile__(
"movl %0,%%eax; movw %%ax, %%fs" : : "r" (ldt_desc)
:"eax"
   );
}

The illegal instruction is "movw %ax,%fs". I'm not sure how to proceed.

 

I have no idea :angry:

 

My last compile.. fixed SDL fullscreen and tested with a VESA3 unsupported card

read the readme. If anyone wants my source tree let me know, altough it's very messy and most of the time I just turned IFs around to get the desired effect.

 

http://free.x3.hu/magveto/mplayerosx86_wit..._and_sdlfix.zip

 

Not going to do any more

Link to comment
Share on other sites

Quit w/the mememe spamming! Every thread with ports ends up being like 75% people who can't download something wanting a link. I'm sure someone who has it will post a mirror at some point, spamming the boards won't get it to happen any sooner.

Link to comment
Share on other sites

 Share

×
×
  • Create New...