Module submission - MPlayer
sofar at foo-projects.org
Wed Nov 15 04:49:13 CET 2006
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 ;)
More information about the Lunar