Because of incompatibilities between /proc/cpuinfo on 'normal' kernels and the one by benh, the mplayer configure script does not detect altivec, so it will build without altivec-optimizations. I added a small fix, which is by all means not a very beautiful patch, but it works for me.
Created attachment 10050 [details, diff] Patch to mplayer to enable altivec on benh kernels
Did you submit this to mplayer-dev-eng@mplayerhq.hu yet ?
svmaris actually we get a little cpufeature checker application from the people at #mklinux and Pylon is completing the cpuparser script, once finished we'll send everything to upstream, please wait
I added some ability to the configuration file to set the right mcpu and mtunes settins in case of the info that /proc/cpuinfo results. The patch is built upon the one of svmarvis. Maybe somebody with a G4 can test it? And somebody with a non-benh-kernel? During the configure-process there should be a line similar to Checking for Using ppc (745/755) optimizations ... -mtune=750 and -mcpu=750 with the right options for G4s. Furthermore altivec should be detected. If this will fail on non-benh-kernels we have to scan, which kernel is used (uname will help here) and do the changes only for benh-kernels. Or can somebody paste here a /proc/cpuinfo for the "official" gentoo-ppc-kernel?
Created attachment 10308 [details, diff] mplayer-ppc.patch The patch for locating in the files-directory
Created attachment 10309 [details, diff] mplayer-ppc.patch The patch for locating in the files-directory
Created attachment 10310 [details] mplayer-0.90_rc5.ebuild ebuild that will inherit the mplayer-ppc.patch
Comment on attachment 10308 [details, diff] mplayer-ppc.patch dubble clicked ;) one is enough
The patch will also work on the new stable mplayer-0.90! Just rename the ebuild mplayer-0.90.ebuild and everything will run without problems.
Ok, get it tested, and if fine, Ill commit 0.90.
Created attachment 10347 [details] my configure patched, yet to be merged with Pylon's one
Created attachment 10348 [details] auxtable parser, just shows if the altivec is present.
Ok, I need to get 0.90 out. Ill commit with attachment 10308 [details, diff]. If you guys are good to go, let me know. Also, please submit as patches against the mplayer tree.
I discussed with lu_zero about releasing the new mplayer. He tells that he has problems with altivec and playing mpegs. We can apply my patches to it, but should leave it ~ppc for a while and watch for users who also receive only mpeg-salad. During this phase we do some more tests. Get it out that baby ;-)
I'm running a rev-III Powerbook G4 (667mhz) with benh's sources (2.4.20-ben10) the ./configure on media-video/mplayer-0.90 now says: Checking for CPU vendor ... (::) Checking for CPU type ... 7455, Checking for Using ppc (7455,) optimizations ... -mtune=750 and -mcpu=750 -maltivec -mabi=altivec So, apart from some cosmetical issues, this looks fine to me. Compiling shows the altivec-cflags, so that's good too. There are some minor audio/video-sync problems while playing an mpeg, but this has nothing to do with the altivec-stuff (I had the same problem before).. so: it works! Good job guys.
Hell, I forgot that the switch-line 7[45][50]*) will also choose a 7455-CPU :-( So we should change the order of the switches and place the 745[570]*) before the one for the 740/745/750/755*-G3-CPUs. That there's a ',' in the 'Checking for CPU type' line comes from the cut-command. But that doesn't harm anything because this string is only used for the switch and the mtune and mcpu will be set right (yes, it is only cosmetical).
Created attachment 10550 [details, diff] mplayer-0.90-ppc-benh.patch The patch with the switches in (hopefully) right order.
Sorry I didn't notice this before. But since the last emerge of mplayer (0.90 with the altivec-stuff), I'm having weird problems playing DiVX4/5 files. MPlayer switches to fullscreen and it stays black. It does not respond to any input, until I switch out of X to a virtual console and then go back. Then the DiVX is playing, but it looks awful; mainly green garbage. On x86, the files play fine. Anyone else having this problem?
I think that is the "salade problem" seems that applies to libmpeg altivec and to ffmpeg altivec (mplayer doesn't use libmpeg altivec) the issues has already reported upstream, seems that their code is working fine on gcc3.1apple on osx/darwin. still investigating
The culprit is gcc that doesn't handle correctly the mergel instructions, gcc, libmpeg2 and ffmpeg authors are already informed. Michel Lespinasse, who discovered the issue has already found a workaround. hopefully the issue will be fixed in the next gcc release.
mplayer now supports very well ppc and my workaround works good enough for now, the gcc-3.3.3 fixes the problem on the root but has other issue that prevent me to push it on ~ppc before some fix on some core application.
