[MPlayer-dev-eng] [patch] prefer ALSA over OSS

[Rich Felker]

On Fri, May 04, 2007 at 11:39:04PM +0400, Vladimir Mosgalin wrote:
> > I just don't download such crap, and certainly don't try to repair
> > bad source material in realtime as I watch it because that's
> > impossible.
> 
> OK, replace dvd-sized with 640x480, take typical anime fansubs, and
> well.. here is a target for fspp/pp7.

The ones I get all look best to me with no postprocessing.

> Anyway, there is no point in discussing this. Even 720p and 1080p
> material sometimes needs filtering. No pp filter is needed, but

Linear sharpening filters are fundamentally mathematically incorrect
and also visually incorrect. All they do is make nasty halos around
borders. If you want real sharpening you'll need a nonlinear
warp-based filter, and good luck getting that to run in realtime on
ANY machine...

The correct solution is always to encode the video correctly to begin
with. Not to waste resources on every single machine that's ever going
to play the video.

> > But it still works just fine. Why should an app with nice software 3d
> > have to use your (*)#()$ opengl just because you have a new computer??
> 
> Because of texture filtering, antialiasing and transparent use of higher
> resolutions.

But this is not how the application was intended to be run. And in
fact from my experience it looks extremely bad. If you're going to use
high resolution, you need millions of polys. Just taking a game made
to run at 320x200 with soft 3d and running it at 1600x1200 with 3d
accel just shifts the "offensively" bad resolution from an issue of
pixel resolution to an issue of polygon resolution. That is, instead
of seeing pixels glaring at you, you see polygons glaring at you.

In any case, the point is that the program runs just fine. And
_predictably_. It runs exactly as it was intended to. Maybe you wish
it would dynamically evolve to the capabilities of your new system you
wasted lots of money on, but that's irrelevant.

> > audio samples directly in whatever format/samplerate/etc. is native
> > for the output device to maximize quality and minimize the filtering
> > artifacts from resampling (which are horrible with ALSA's resampler,
> > btw...)
> 
> Alsa resampler IS configurable. I already discussed this once. It can
> provide very high-qualit output. Not with default setting, but then
> again, most people don't care about quality.

In the fastest mode, it's slower than libavcodec's resampler.
In the best quality mode, it's lower quality than libavcodec's
resampler.

Now why on earth would anyone want to use this crap?? It's only
configurable between two extremes of sucking: very bad quality, or
very bad performance.

Rich