[MPlayer-dev-eng] [PATCH] Mac OS X updates for darwinfixlib, libmpeg2 and ao_macosx

[Dan Christiansen]

On Tuesday, June 10, 2003, at 05:21 AM, D Richard Felker III wrote:

> On Tue, Jun 10, 2003 at 12:59:09AM +0200, Dan Christiansen wrote:
>> Hi,
>>
>> Attached are three patches for MPlayer :)
>>
>> mplayer-makefile.diff:
>>
>> I've found it rather annoying that MPlayer would run ranlib on all
>> libraries even though only one of them where changed. It meant that
>> mplayer and mencoder would be relinked when running "make install" -
>> very annoying indeed. This patch will change the behaviour from 
>> running
>> ranlib on all libraries prior to linking to processing libraries one 
>> at
>> a time after their compilation.
>
> If this really happens, it should be fixed, but it never happens to
> me. Nothing should have changed when you run make install...

I'm not quite sure why it happens, but it is what happens, and it's 
been happening as long as I have been compiling MPlayer. It may be due 
to ranlib touching the libraries and altering their modification date, 
so make will believe that they were altered since the linking.

I just discovered that the way I do it in the patch isn't the best. 
I'll send a better one later. (If making in a directory, and then in 
mplayer, ranlib doesn't get run.) Anyway, the reason it happens to you 
is probably that you don't use Darwin, and therefore darwinfixlib has 
no effect on you computer ;)

>> mplayer_ao.diff:
>>
>> I figured out what the issue was with the resampling of movies, etc; I
>> was simply setting ao_data.outburst incorrectly. I guess I shouldn't
>> have blamed the resampler so quickly ;) I tested it with various
>> sampling rates, mono and stereo, and all seem to work well. Unless
>> there are more bugs, I believe this is good enough to replace make
>> ao_sdl obsolete on Mac OS X. Other than that the patch contains volume
>> control and some cleanups.
>
> Didn't we already go over the fact that volume emulation through
> software does NOT belong in ao drivers?? Use pl_volume for the time
> being (-aop list=volume) or fix mplayer to be able to control
> af_volume interactively. But don't add ugly hacks like this.

I'm quite surprised that you call this an "ugly hack". Yes, it may not 
be the optimal way of doing this, but I wouldn't call it an ugly hack; 
it could be a _lot_ worse ;)

I do understand your need for consistency in the design for MPlayer, 
but there are some disadvantages to using pl_volume. First of all, in 
it's current incarnation, it doesn't support float. Second, it adds IMO 
unnecessary features like clipping. Third, it applies the same volume 
to left and right, so it can't handle balance. Fourth, I suspect that 
the volume control that the other AOs use is emulated too, it's just 
that the library handles it.

Of course, if you really believe that not having volume emulation in 
_one_ audio output module is so important it justifies all these 
changes and the missing features, I'll do it (eventually). IMHO it's 
not worth it.

- Dan