[MPlayer-dev-eng] Re: [RFC] including x264 with MPlayer tarballs

[Alexander Izvorski]

On Tue Aug 23 17:49:09 CEST 2005, Dominik 'Rathann' Mierzejewski
dominik at rangers.eu.org wrote:

>> * Assembler detection, which people have mentioned: assembler is not
>> _required_ for x264 but it is certainly nice to have.  We can either
>> disable x264 if there is no assembler, or just build it without the
>> assembly optimizations? (and perhaps print a warning)  x264 doesn't
>> test whether there is a working assembler present now, but it really
>> should ;)   I think this will be fixed upstream in x264.  I'm working
>> on it now, but it's not in this patch.
>
>I think we shouldn't require the presence of external assembler, but we
>should make use of it if it is available. We should print a warning, just
>as we do when MPlayer is built with runtime CPU detection.

Ok, this will be in the next patch.

>> This patch will however try to
>> use the correct assembler for the platform it's on.
>
>I don't see anything in your patch that would do that, but I assume
>that's why you wrote you're working on it.

x264's configure script already picks the right one, it just doesn't
check that it actually exists ;)

Jindrich Makovicka has a suggestion that may actually avoid the
assembler problem entirely: auto-converting x264 from nasm to gas. 
I'm looking at that now as well, it is promising.

>> * Creating x264/config.mak : now, I'm just running x264's configure
>> script, although I also have the code (commented out) that would
>> create a x264/config.mak directly from mplayer's configure.  The main
>> problem with creating it directly is that the ARCH and SYS* names are
>> not exactly the same, so we'd need to translate (although possibly a
>> patch that makes the names the same can be applied upstream in x264).
>> Also there are a few platform-specific linker flags.  I'm not sure
>> whether there is any problem with running x264's configure? (although
>> I noticed that other packages don't do it that way).  Thoughts?
>
>Well, I think running x264's configure script would be acceptable if you
>could guarantee it'll use the same config as MPlayer and I mean any
>external libs that x264 may require that can be enabled/disabled in
>MPlayer's configure.

x264 for use in mplayer does not require any external libraries except
libm and optionally pthreads.  I will pass the correct options through
in the next patch.

Question about libm: when $_ld_lm="", functions like exp2 and powf can
still be assumed to be available, they just don't require the linker
option, correct?

>> * CPU capabilities and autodetection: x264 always detects cpu
>> abilities at runtime.  Because of that, by default it will build with
>> everything on x86.  We can make it rely on the USE_* cpu flags from
>> mplayer's configure instead.  Is there any reason to do that?
>
>I think it should behave in accordance with MPlayer's
>--enable-runtime-cpudetection.

That's tough:  because of the design of x264 all of the potentially
cpu-dependent functions are already in function pointers, there is no
provision to disable cpudetection.  Isn't
--disable-runtime-cpudetection more of a performance option anyway? 
x264 will not see a performance gain from that without significant
redesign, so I don't see that it really matters in this case.  The
only thing we can do is not compile some of the functions based on the
USE_* flags at compile-time, if desired.

>> * The x264 patch would need to be applied to the version of x264 which
>> is in the tarballs.  I'm not sure how to automate that as part of the
>> tarball creation script?  It's a really simple patch, but in any case
>> I volunteer to maintain it.
>
>What tarballs? If we include x264 in MPlayer's sources, we'll keep it
>patched and keep the diffs from official sources in CVS, too, for as long
>as they're needed.

Whatever you think is best.  I didn't realize that mplayer cvs
included all of the other projects it ships with, hence my original
suggestion.  But the other way is fine as well.

Thanks you for your suggestions.  I hope to have a more polished patch soon.

Sincerely,
Alex Izvorski