[MPlayer-dev-eng]

[Romain Dolbeau]

Arpi wrote:

> about the altivec stuff: imho it is not needed to be detected, if
> the code is compiled with --enable-altivec (or what, i don't remember how
> is the checkmade in ./configure) then it's ok to use altivec code.
> 
> even on x86 the default is no detection, but you can do
> --runtime-cpudetection to compile cpu-independent code which does
> runtime detection and enabling optimizations.

I think that runtime-detection is better ; in particular
in MacOSX, user expect stuff to "just work", as it used
to do in old MacOS. A single binary that works on both
G3 (no AltiVec) and G4 is IMHO simpler.

> maybe as for a temp. solution you could try to backport altivec code.
> the optimization specific code (idct, mc) didn't changed since 0.2.0, imho

Honestly I only improved functions that I've seen used
by my files :-) I just noticed that libmpeg2 wasn't
up-to-date when I looked for the AltiVec detection code.

I'll wait for inclusion of the new libmpeg2 before
changing stuff in it, no need to make the merge
more complicated that it is already.

> hope it won't cause symbol name conflict with ffmpeg at linking.

It won't, I only used the functionality not the whole
function. In ffmpeg it's a function called has_altivec()
while I've added code to mplayer function GetCpuCaps().
The flag set is then used for both liba52 and mp3lib.

BTW it is duplication of code, but I wasn't sure it was
OK to call a libavcodec function from code outside
libavcodec.

-- 
Romain Dolbeau