[MPlayer-dev-eng] Runtime CPU detection and fastmemcpy

[D Richard Felker III]

On Sun, Apr 28, 2002 at 10:50:37AM +0200, Dominik Mierzejewski wrote:
> On Sunday, 28 April 2002, Arpi wrote:
> > Hi,
> [snip] 
> > > So you're opting for a minimalist package that has a small number
> > > of dependecies? That's fine by me. I'll make all optional features
> > > disabled by default then (one will still be able to use them after
> > 
> > nope
> > atmos just said - and i agree - that libavcodec has much better quality than
> > divx4 or xvid, so no much sense of includong those
> > anyway xvid is supported, if yo include it, it doesn't hurt...
> 
> OK, but I want to keep the dependencies list small. So it hurts in that
> the user has to install additional packages. And if not including it
> doesn't decrease functionality, then why not just leave it as a build-time
> option?

Well libavcodec is basically essential and it's static linked anyway,
so it doesn't add dependencies for the user. XVID could easily be
static linked too, but there may be some license issues remaining with
it -- be sure to check if you care.

> > libdvdread, libdvdnav, libmpdvdkit) it's enough to keep one (dvdkit)
> 
> OK, but it's not in the distro. I'll have to make a package.

No, dvdkit is part of the mplayer source tree, so no need to make a
separate package, unless you really insist on it.

> What about GGI, SDL and OpenGL? I can build with the last two. GGI is not
> in the distro.

I doubt anyone cares about GGI for most practical purposes. Those who
want to play with it can compile mplayer themselves for sure.

> What about ALSA, arts and NAS? I can build with arts and I don't think
> there's any point in supporting NAS, it's no longer being developed, AFAIK.

AFAIK, arts/nas/esd/etc are basically useless with mplayer since they
introduce unpredictable audio latency that breaks a/v sync. I may be
wrong though. Can someone else comment?

> ALSA is not in the distro, either.

Probably not needed, I think everything works fine with ALSA's OSS
emulation even if the user is using ALSA sound drivers. Again though,
wait for more opinions.

> What about lirc? I don't have it and it's not in the distro.

Not sure. Anyone else have opinions?

> I suppose I should include vorbis ogg.

Yeah.

> And, last but not least, what about win32/dshow codec support?

This doesn't require any external libraries, so you might as well
include it. It just adds a bit of size to the binary. Then users can
download and use win32 codecs if they want, and ignore it otherwise.

> > using --enable-sse etc will result signal4, unless your cpu support these
> > instruction sets... it is the non-runtime (default in cvs and pre2) way.
> 
> So if I --enable-runtime-detection, then I can safely turn all these
> features on, is that it? Good.

NO. If you use --enable-runtime-detection, the code for all of them
will always be included, and then selected at runtime. The options
such as --enable-sse are for when runtime cpu detection is DISABLED.
Didn't Arpi just explain that to you??


Rich