Module submission - MPlayer

[Zbigniew Luszpinski]

> just got off the phone with #mplayer. Apparently, they broke optimizations
> even further and -march=i686 will NOT WORK on some cpu's.

This is due to asm optimizations in source code to speed up video. Setting 
generic i686 has no sense. MPlayer's configure script correctly autodetects 
and fine tunes cpu arch (e.g. -march=k8 -mtune=k8 for my machine: A64 3000+ 
Venice E6) so forcing any CFLAGS will probably leave you with slower MPlayer 
than it would be by default (if it will not break during compilation). If you 
browse Lunar's compilation log for MPlayer you'll see that cflags used by 
mplayer are very aggressive so any 'home made' casual cflags will not give 
more speed, rather slowdown.

To compile MPlayer I use CFLAGS="" so allow MPlayer to use its CFLAGS 
configuration. Your bad_flags idea is more elegant than my lazy hack :-)
Someday I'll get used to bad_flags. :-D

> We need to add `bad_flags ALL` to the top of the BUILD before 1.0rc1 will
> work on a lot of cpu's. Benefit: MPlayer will pass it's own optimizations
> anyway making lunar optimizations unneeded.

Good idea. I'm for. I'd rather suggest 'bad_flags compiler'. I left my 
favourite, crazy LDFLAGS="-s -Wl,-Os -z combreloc" and MPlayer works great 
(78 movie clips watched, different formats, codecs). Ldflags usually do not 
interfere with asm inline code so think we can consider 'home made' ldflags 
as safe for mplayer. However YMMV.
I think there is no reason to wait for cpu compability patches for mplayer. 
Mplayer will keep using asm optimizations, so mplayer team have to maintain 
cpu autodetection and compability internally, because selecting external 
cflags manually is just minefield for everybody except mplayer code gurus.

> Auke

This is how it looks like IMHO,
zbiggy