Re: mplayer / divx
Wichert,
I'm moving this to -devel. Seems more appropriate for "technical"
issues.
On Wed, Aug 29, 2001 at 08:23:57AM +0200, Wichert Akkerman wrote:
> Previously Aaron Lehmann wrote:
> > mmmkay, well, could I put mplayer (with or without CSS decryption) in
> > non-free? That's basically what I'm looking for.
>
> A technical problem is that mplayer optimizes itself for the machine
> you compile it on, which is quite impractical when you are packaging
> it. Any plans on solving that?
Considering that I'm planning to do pretty extensive modifications to
the upstream source anyway (to a remove non-free component), I don't
think it will be too hard to change.
I'd *like* to optimize the package at least for a Pentium, because I
imagine that MMX may be useful and I really doubt that the package
would have any utility whatsoever on anything < i586. I wonder what
policy says about this. Failing that, I would probably prefer to
compile it with -mcpu=pentium, which as we know will not break it on
486 processors and lower.
Of course, the above specifically is about "i386" architecture. Other
platforms are another hell entirely. I noticed that mplayer has its
own custom "configure" script that happens to be one of the idiotic
variety that requires specific information about every architecture,
otherwise it will refuse to build, even with generic options. GAR.
*)
echo "The architecture of your CPU ($host_arch) is not supported by this configure script"
echo "It seems, as if noone has ported MPlayer to your OS or CPU type yet."
exit 1
;;
I'm not sure what I'd do about *that*. Probably change the default to
something sane. The only thing it sets based on CPU type anyway is
endianness, and that can easilly be determined by a standard GNU
header file or a bit of ANSI C code that is optimized out by any
decent compiler.
P.S. mplayer doesn't seem to have any DeCSS code in the first place.
It only has hooks. If that's considered a crime, then, well, I don't
know what to say.
Reply to: