Module submission - MPlayer

[Auke Kok]

Zbigniew Luszpinski wrote:
>> 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.

that sounds like a good suggestion and adequate in this situation.

> 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.

don't bother there, next release they'll mess up something else ;)

Cheers,


Auke