Comment 7 for bug 78426

When I tried the mplayer package from Edgy on a G3, I was very dismayed that my pleading to turn off Altivec in the Breezy ffmpeg package had not achieved any lasting effects. This time, it seems the mplayer packagers not only decided to naively trust the bogus upstream claims of runtime CPU detection on PPC, but through inaction due to insufficiently understanding the issues involved, added their own folly to the debian/rules file. It never got fixed in Edgy, and so far, not in Feisty, either. When using gcc to generate Altivec code that is executed conditionally upon the CPU present, that code MUST BE ISOLATED IN SEPARATE SOURCE FILES FROM ANY REFERENCE TO IT as a prerequisite for using Altivec when desired on a G4, while still supporting execution of equivalent code on a G3. The upstream mplayer developers can't seem to get this through their heads no matter how many bumps and bruises the VLC developers suffered on their way to achieving a reasonable facsimile of this claimed feature. The mplayer Altivec-handling code in the Feisty version (like the Edgy version before it, if not more so) is a horrid mess of properly isolated routines mixed in with stray code strewn around everywhere. In the hopes of getting upstream started on a true fix, I have applied clean-up hacks to it that allow for three modes of compilation:
1) Altivec disabled and runtime detection disabled
This would run G3 and G4 CPUs alike, without taking advantage of what a G4 has to offer beyond a G3. People who self-compile into /usr/local on a G3 would use this.
2) Altivec enabled and runtime detection disabled
This would run with maximum efficiency on a G4, and refuse to run at all on a G3. People who self-compile into /usr/local on a G4 would use this.
3) Altivec enabled and runtime detection enabled
This would run just fine on a G3, but would include Altivec code that would never be used. On a G4, Altivec code that is properly isolated would get used to increase efficiency and speed, but both generally Altivec-optimizable code and Altivec-specific code that was not properly isolated would be snubbed in favor of the same crap reserved for G3's. Ugly, but the mplayer developers have forced this hand to be played, by insisting everybody compile their own mplayer and not use any precompiled binary. This third variant is the one I make the package use.
Additionally, the stock package did not allow for the playing of mikmod, midi, or other such files, evidently because the upstream code for doing so was completely b0rked. I fix that here, too.
Please merge this patch into your bzr tree, and use your influence as mplayer packagers to get it merged upstream. Thank you. The diff was made against 2:1.0~rc1-0ubuntu3, IIRC.