Trouble running mplayer

1

Hello. I installed the recent mplayer package from HaikuDept. However, I get the following error when play any video:

mplayer Mazinger.mp4 
MPlayer 1.1-4.8.4 (C) 2000-2012 MPlayer Team
3DNow supported but disabled
3DNowExt supported but disabled

Playing Mazinger.mp4.
libavformat version 54.6.100 (internal)
libavformat file format detected.


MPlayer interrupted by signal 4 in module: demux_open
- MPlayer crashed by an 'Illegal Instruction'.
  It usually happens when you run it on a CPU different than the one it was
  compiled/optimized for.
  Verify this!
- MPlayer crashed by bad usage of CPU/FPU/RAM.
  Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and
  disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.
- MPlayer crashed. This shouldn't happen.
  It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
  gcc version. If you think it's MPlayer's fault, please read
  DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
  won't help unless you provide this information when reporting a possible bug.

I’m using hrev49210 -x86_gcc2 build.

Anyone get the same error?

Thank you!

2 
It usually happens when you run it on a CPU different than the one it was
  compiled/optimized for.
3DNow supported but disabled
3DNowExt supported but disabled

Is it possible that you are trying to run it on an AMD CPU?

3

Is it possible to extract a debug report with Debugger in that situation, or does mplayer intercept the crash? It would be interesting to know which invalid instruction was hit (and which CPU model you have).

4

Yes, I had an AMD cpu (an old Athlon). This is the sysinfo:

1 AMD Athlon XP, revision 0681 running at 1822MHz

CPU #0: "AMD Athlon(TM) MP 1700+"
        Raw CPUID: 0x000681,    Type 0, family 6, model 8, stepping 1, features 0x0383fbff
                FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT
                PSE36 MMX FXSTR SSE
        Extended Intel: 0x00000000
        Extended AMD: type 0, family 7, model 8, stepping 1, features 0xc1cbfbff
                SCE AMD-MMX 3DNow+ 3DNow!
        Power Management Features: TS

        Inst TLB: 2M/4M-byte pages, 8 entries, fully associative
        Data TLB: 2M/4M-byte pages, 8 entries, 4-way set associative
        Inst TLB: 4K-byte pages, 16 entries, fully associative
        Data TLB: 4K-byte pages, 32 entries, fully associative
        L1 inst cache: 64 KB, 2-way set associative, 1 lines/tag, 64 bytes/line
        L1 data cache: 64 KB, 2-way set associative, 1 lines/tag, 64 bytes/line
        L2 cache: 256 KB, 16-way set associative, 1 lines/tag, 64 bytes/line

Maybe my CPU is too old for this version of mplayer?

5

Unfortunately, I don’t get the ussually Debbugger message and option to save the crash report.

6

Apparently it doesn’t support SSE2. We try to not make use of SSE2 in Haiku for these CPUs. FFMPEG detects the CPU features at runtime and selects different variations of the code. I don’t know of mplayer can do this, it’s possible that it doesn’t, and try running SSE2 instructions for you.

7

I have enabled runtime cpu detection in MPlayer recipe.
https://bitbucket.org/haikuports/haikuports/commits/d0e12d16b11cf493d677f742fe87510f13054344

Now someone needs to build and upload new package to HaikuPorts repo.

8

Hit the repo with hrev49220.

Regards,
Humdinger

9

Diver, PulkoMandy, Humdinger: Thank you guys! I updated to a recent build and mplayer works perfect! :slight_smile:

Just for curiosity, I see that mplayer can’t detect the presence of SSE instructions:

MPlayer 1.1-4.8.4 (C) 2000-2012 MPlayer Team
Cannot test OS support for SSE, leaving disabled.

the sysinfo shows that my CPU had SSE capabilities. This is because mplayer doesn’t “recongnize” the S.O. specifically?

10

It seems we need to tell mplayer how to use get_system_info (Haiku specific API) to get information about the CPU. On Linux it would look in /proc, but we don’t provide that.

11

It’s a bit more subtle than that. mplayer is perfectly capable of using CPUID on its own, the problem isn’t that mplayer can’t tell whether the CPU supports these instructions, but that it can’t tell whether it would be safe to use them with your OS. Exactly as written in the message.

A pre-emptively multi-tasking operating system takes responsibility for preserving the values of all the CPU registers during a context switch. Without this from the perspective of a userspace program the contents of registers could seemingly change suddenly from one instruction to the next without warning and writing programs would be impossible. Unlike its predecessor MMX, SSE adds completely new CPU registers. For compatibility reasons a new CPU instruction is used to preserve these registers during a context switch, older instructions for preserving register values do not include the SSE registers. Only an OS written (or updated) after the invention of SSE and with it in mind will therefore correctly preserve these values across context switches.

Thus, mplayer needs to be explicitly informed either that Haiku always correctly preserved SSE registers, or how to determine whether a particular version of Haiku will preserve these registers. Otherwise it has to assume that they won’t be preserved and thus it can’t really use SSE.

There are a bunch of clever optimisations possible in this space, but all mplayer cares about is whether SSE can be relied upon in Haiku. I would imagine the answer is simply “Yes” because Haiku is less than 15 years old.