Bug#448105: mplayer: Illegal Instruction in init_audio_codec
Mario Frasca
Version: 1.0~rc2-4
Severity: important
I've downgraded the package to 1.0~rc1-12etch1 and it works, I don't
understand all the problems it meets, but the main point is that it
works and that's good enough:
MPlayer 1.0rc1-4.1.2-DFSG-free (C) 2000-2006 MPlayer Team
AltiVec not found
CPU: PowerPC
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Playing 05 Yellow - Coldplay.wma.
ASF file format detected.
Clip info:
... and then after some more logging playback starts...
with 1.0~rc2-4 it crashes this way:
MPlayer 1.0rc2-4.2.3-DFSG-free (C) 2000-2007 MPlayer Team
AltiVec not found
CPU: PowerPC
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Playing /tmp/17_Qualcosa_che_non_c___-_Elisa.wma.
ASF file format detected.
[asfheader] Audio stream found, -aid 1
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
MPlayer interrupted by signal 4 in module: init_audio_codec
- MPlayer crashed by an 'Illegal Instruction'.
It may be a bug in our new runtime CPU-detection code...
Please read DOCS/HTML/en/bugreports.html.
- 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.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.21-2-powerpc
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages mplayer depends on:
ii debconf [debc 1.5.15 Debian configuration management sy
ii libasound2 1.0.14a-2 ALSA library
ii libatk1.0-0 1.20.0-1 The ATK accessibility toolkit
ii libaudiofile0 0.2.6-7 Open-source version of SGI's audio
ii libc6 2.6.1-6 GNU C Library: Shared libraries
ii libcaca0 0.99.beta12.debian-3 colour ASCII art library
ii libcairo2 1.4.10-1+b2 The Cairo 2D vector graphics libra
ii libcdparanoia 3.10+debian~pre0-5+b1 audio extraction tool for sampling
ii libconfhelper 0.12.5 Library for editing configuration
ii libcucul0 0.99.beta12.debian-3 low-level Unicode character drawin
ii libdirectfb-0 0.9.25.1-6 direct frame buffer graphics - sha
ii libdvdread3 0.9.7-3 library for reading DVDs
ii libesd0 0.2.36-3ubuntu4 Enlightened Sound Daemon - Shared
ii libfontconfig 2.4.2-1.4 generic font configuration library
ii libfreetype6 2.3.5-1 FreeType 2 font engine, shared lib
ii libgl1-mesa-g 7.0.1-2 A free implementation of the OpenG
ii libglib2.0-0 2.14.2-1 The GLib library of C routines
ii libgtk2.0-0 2.12.1-1 The GTK+ graphical user interface
ii libjpeg62 6b-14 The Independent JPEG Group's JPEG
ii liblircclient 0.8.1+cvs20070310-0ubuntu2 LIRC client library
ii liblzo1 1.08-3 data compression library (old vers
ii libmad0 0.15.1b-2.1 MPEG audio decoder library
ii libncurses5 5.6+20071013-1 Shared libraries for terminal hand
ii libogg0 1.1.3-2ubuntu2 Ogg Bitstream Library
ii libpango1.0-0 1.18.3-1 Layout and rendering of internatio
ii libpng12-0 1.2.15~beta5-3 PNG library - runtime
ii libsdl1.2debi 1.2.12-1 Simple DirectMedia Layer
ii libspeex1 1.1.12-3 The Speex Speech Codec
ii libtheora0 1.0~beta2-1 The Theora Video Compression Codec
ii libungif4g 4.1.4-5+b1 shared library for GIF images
ii libx11-6 2:1.1.1-1ubuntu3 X11 client-side library
ii libxcursor1 1:1.1.9-1 X cursor management library
ii libxext6 2:1.0.3-1build1 X11 miscellaneous extension librar
ii libxfixes3 1:4.0.3-2 X11 miscellaneous 'fixes' extensio
ii libxi6 2:1.1.3-1 X11 Input extension library
ii libxinerama1 2:1.0.1-4build1 X11 Xinerama extension library
ii libxrandr2 2:1.2.2-1 X11 RandR extension library
ii libxrender1 1:0.9.4-1 X Rendering Extension client libra
ii libxv1 2:1.0.1-3ubuntu2 X11 Video extension library
ii libxvmc1 2:1.0.2-0ubuntu2 X11 Video extension library
ii libxxf86dga1 2:1.0.2-1 X11 Direct Graphics Access extensi
ii libxxf86vm1 1:1.0.1-2 X11 XFree86 video mode extension l
ii mplayer-skin- 1.6-2 blue skin for mplayer
ii zlib1g 1:1.2.3.3.dfsg-6 compression library - runtime
mplayer recommends no packages.
-- debconf information:
mplayer/replace-existing-files-bail:
mplayer/replace-existing-files: false
mplayer/no-ttfont:
mplayer/install_codecs:
mplayer/voutput: autodetect
mplayer/rtc: false
mplayer/ttfont: Sans
mplayer/cfgnote:
mplayer/dvd_device: /dev/cdrom
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Reimar Döffinger
On Fri, Oct 26, 2007 at 07:25:11AM +0200, Mario Frasca wrote:
> Package: mplayer
> Version: 1.0~rc2-4
> Severity: important
>
>
> I've downgraded the package to 1.0~rc1-12etch1 and it works, I don't
> understand all the problems it meets, but the main point is that it
> works and that's good enough:
>
> MPlayer 1.0rc1-4.1.2-DFSG-free (C) 2000-2006 MPlayer Team
> AltiVec not found
AltiVec runtime detection never worked reliably (compiler dependant) and
the way it was detected in libavcodec was an unacceptable hack.
Since the PowerPC architecture does not offer a sane way to distinguish
between with and without Altivec we now treat them as different
architectures, meaning you need a different build for each.
Greetings,
Reimar Döffinger
Mario Frasca
> AltiVec runtime detection never worked reliably (compiler
> dependant) and the way it was detected in libavcodec was
> an unacceptable hack. Since the PowerPC architecture does
> not offer a sane way to distinguish between with and without
> Altivec we now treat them as different architectures, meaning
> you need a different build for each.
Hi Reimar,
thanks for your reply,
let me understand better...
when you say :
* "never worked", "it was", "we now treat":
does it mean "in rc2 as compared to rc1"?
* "you need a different build":
in the sense that I am using a mplayer which was not compiled for my system?
in this case, how do I specify that I have a PowerPC without AltiVec?
must I compile mplayer myself or can I still use a debian distributed binary?
or were you just explaining the message "AltiVec not found" and implicitly
telling me not to worry about it?
thanks,
Mario
--
il melo fa la mela
il pero fa la pera
il fico fa eccezione
-- Peppe Barra
Diego Biurrun
> On 2007-1026 10:32:55, Reimar Döffinger wrote:
> > AltiVec runtime detection never worked reliably (compiler
> > dependant) and the way it was detected in libavcodec was
> > an unacceptable hack. Since the PowerPC architecture does
> > not offer a sane way to distinguish between with and without
> > Altivec we now treat them as different architectures, meaning
> > you need a different build for each.
>
>
> when you say :
>
> * "never worked", "it was", "we now treat":
> does it mean "in rc2 as compared to rc1"?
>
> * "you need a different build":
> in the sense that I am using a mplayer which was not compiled for my system?
>
> in this case, how do I specify that I have a PowerPC without AltiVec?
> must I compile mplayer myself or can I still use a debian distributed binary?
You need a PowerPC binary without AltiVec support. Debian does not
currently distribute such a thing.
Diego
Lorenzo
On Fri, 26 Oct 2007 10:32:55 +0200 Reimar =?iso-8859-1?Q?D=F6ffinger?=
<Reimar.D...@stud.uni-karlsruhe.de> wrote:
> AltiVec runtime detection never worked reliably (compiler dependant)
> and the way it was detected in libavcodec was an unacceptable hack.
> Since the PowerPC architecture does not offer a sane way to
> distinguish between with and without Altivec we now treat them as
> different architectures, meaning you need a different build for each.
>
> Greetings,
> Reimar Döffinger
>
ways to do runtime detection were suggested
https://lists.debian.org/debian-powerpc/2023/06/msg00030.html
could you please check again if it's still unfeasible to detect altivec
at runtime in mplayer/mencoder?
Thanks,
Lorenzo
Reimar Döffinger
> On 5 Jun 2023, at 00:08, Lorenzo <plor...@disroot.org> wrote:
>
> Hi Reimar,
>
[...]
> The above was 16 years ago; on Debian powerpc list a couple a
> ways to do runtime detection were suggested
>
> https://lists.debian.org/debian-powerpc/2023/06/msg00030.html
>
> could you please check again if it's still unfeasible to detect altivec
> at runtime in mplayer/mencoder?
But I don't think it works, the problem is the compiler options:
- to be able to compile code using altivec and have the optimizations available, -maltivec must be used
- if -maltivec is used, even normal C code will use altivec instructions, thus crashing
The first thing to check would be whether FFmpeg (ffplay in particular) works (supporting both altivec optimized playback and not crashing without altivec).
But in the end I don't know if it is realistic to change the situation:
- implementing and testing is hard since not much hardware is around (and at least some build system adjustments will be needed)
- without altivec, the machines are so slow, certainly nothing but ancient video files will be playable, putting the benefit a bit in question of running on non-altivec machines
- building the base code without -maltivec will make MPlayer slower on machines with altivec like G4, which might be enough to push them over the edge to not be able to play certain videos that they can otherwise
So maybe it is possible to get to work now, but probably separate builds would remain the better approach.
On the plus side, if FFmpeg works, and since Debian links MPlayer to FFmpeg dynamically, --disable-altivec should be all that is needed - assuming the performance degradation on altivec enabled systems mentioned above is considered acceptable.
Best regards,
Reimar
Lorenzo
On Mon, 5 Jun 2023 20:33:15 +0200 =?utf-8?Q?Reimar_D=C3=B6ffinger?=
<Reimar.D...@gmx.de> wrote:
> While it's still plenty messy, FFmpeg has runtime detection of
> altivec, and MPlayer itself has no altivec code itself. But I don't
> think it works, the problem is the compiler options:
> builds would remain the better approach. On the plus side, if FFmpeg
> works, and since Debian links MPlayer to FFmpeg dynamically,
> --disable-altivec should be all that is needed - assuming the
> performance degradation on altivec enabled systems mentioned above is
> considered acceptable.
going to build twice on powerpc and let the user decide which one to use
Best,
Lorenzo
>
> Best regards,
> Reimar
>
>
>
Reimar Döffinger
> On 6 Jun 2023, at 14:57, Lorenzo <plor...@disroot.org> wrote:
>
> Thanks for looking at this again
>
>> builds would remain the better approach. On the plus side, if FFmpeg
>> works, and since Debian links MPlayer to FFmpeg dynamically,
>> --disable-altivec should be all that is needed - assuming the
>> performance degradation on altivec enabled systems mentioned above is
>> considered acceptable.
>
> Disable altivec for everyone doesn't seem a good compromise to me, I'm
> going to build twice on powerpc and let the user decide which one to use
So --disable-altivec is not obviously unacceptable, but I do think separate builds would be better, as 10% can matter on these systems.
(I am rather mystified how FFmpeg handles this, since as said the runtime check code does not look like it would actually work - if it does not work, a separate non-altivec MPlayer build will not help as it will still crash for ~90% of media files, just in FFmpeg codecs now instead of MPlayer itself - is there a good way to test any of this?).
Reimar Döffinger
> On 6 Jun 2023, at 15:17, Reimar Döffinger <Reimar.D...@gmx.de> wrote:
>
>> Disable altivec for everyone doesn't seem a good compromise to me, I'm
>> going to build twice on powerpc and let the user decide which one to use
>
> To be clear: as MPlayer has no hand-written altivec, I I expect only a maybe 5-10% or so degradation (pure guess), the most performance critical stuff in FFmpeg should not be affected.
What did I find out:
- xfce4 crashes with illegal instruction
- ffmpeg does not crash, but only because it is built with --disable-altivec which makes it basically unusably slow on e.g. G4 systems.
So there is no winning.
So for practical purposes, you can just as well compile MPlayer with --disable-altivec, since FFmpeg is compiled this way the speed of MPlayer won't make a relevant difference.
On the details what goes on here (skip if you do not like rants):
What is the source of all these issues? gcc
In the past, -maltivec was used to just enable support for altivec intrinsics.
However gcc then changed and generated Altivec instructions even from plain C code.
While that makes sense in a way, it meant code everywhere broke on non-altivec systems.
This includes FFmpeg.
For packages important enough/depending on maintainer, the "solution" was to disable altivec completely, making these programs vastly slower on Altivec enabled computers.
Others like xfce4 and MPlayer only work on PPC systems with Altivec.
Without extensive code and build system changes, this seems now an unsolvable situation.
Unless someone adds an option like -faltivec that Apple had, which allows the intrinsics but not compiler generation of altivec instructions (I think gcc maintainers at one point said they could not do that).
clang has both -faltivec and -maltivec, but neither are properly documented, so who knows if they would help here or not.
Either way, without someone EXTREMELY motivated, this seems not solvable (switching to clang with -faltivec if it were to work just MIGHT have a chance).
I guess it's a lesson in not buying into architectures where the creators don't have their shit together enough to get even the basics right - and upstreamed... (I guess it's mostly solved by PPC being as good as dead now).
(don't get me wrong, I still sometimes boot my old MacMini with G4 and update to latest Debian, but I think the ISA is just dead at this point, unfortunately).
Sorry for the long rant,
Reimar
Reimar Döffinger
> On 6 Jun 2023, at 21:14, Fabian Greffrath <fab...@greffrath.com> wrote:
>
> I remember that back then, when powerpc was still a release architecture in Debian, we built two flavors of the ffmpeg libraries -- one with altivec and one without:
>
> https://salsa.debian.org/multimedia-team/ffmpeg/-/blob/debian/master/debian/rules#L184
>
> That code is still there, so I wonder why your linker doesn't pick up the flavor that matches your processor's instruction set.
Ah, thanks, that is probably just me being dumb since I was testing on a G3 only!
I guess that only works for libraries though, no such auto-selection for executables, right?
Seems ffmpeg and ffplay are built only without altivec (which is kind of ok, and as said might be ok for MPlayer but would be nice to check).
Thanks for the hint,
Reimar