[MPlayer-dev-eng] [BUG] surround audio plugin broken

[D Richard Felker III]

On Mon, Jan 06, 2003 at 03:29:08AM +0100, Arpi wrote:
> Hi,
> 
> > > > Disagree, resampling when the movie is 48000 hz and the soundcard only
> > > > supports 44100 should be done by default, just like -vop scale is
> > > > auto-inserted when the output device is rgb. Otherwise the output is
> > > > just wrong.
> > > 
> > > yep. but for example automatic resampling of 44100 to 44098 is just dumb.
> > > (and slow and causes big delay and whatever)
> > 
> > Hmm, perhaps the ao drivers should be modified to report the requested
> > samperate back to libaf (rather than the actual one) if the two only
> > differ by a very small amount. Sound good?
> 
> not sounds good (it ins;'t teh job of ao drivers, and it means adding teh
> same code to every single ao_*.c), but it seems the only way now.

IMHO it's not so bad. I consider such bogus rounding to be a hardware
or driver bug, and the best place to work around hardware/driver bugs
is in the ao 'driver' layer.

> actually we should extend the libao2 api by query_format()-like function,
> and the same for libaf too, and then codecs-filters-ao could handshake teh
> best data exchange format, just like it's done for video now in libmpcodecs.
> unfortunatelly(?) libaf was designed to be mplayer-independent, so it isn't
> easy to add now.
> 
> the current method is a bit broken/lazy:
> - codecs has single output dataformat (maybe depends on input file's
>   headers, maybe constant per codec)
> - codecs tries to produce N channel output where N is set by opt. -channels
>   (afaik only liba52 supports it, where the codec can do the downsampling)
> - codecs always produce integer (or compressed, for ac3 passthru) output,
>   signed or unsigned, 8 or 16 bits. if teh codec's internal format is float,
>   the codec (or ad_*.c wrapper) converts it to integer (see vorbis or faad).
>   (liba52 is similar, but there are optimized float->int helped by the
>    decoding process so it's better than decoding-to-float->float-to-int)
> - now mplayer goes to libao2's config() and ask it for the
>   format,channels,rate got from the codec
> - the selected ao driver tries to setup output device to the requested
>   parameters, if fails then it tries to get something similar config, and
>   updates the parameters in ao_data struct.
> - now mplayer asks libaf to convert from codec's output fmt+chans+rate to
>   the one returned by libao2 in ao_data. it will auto-insert filters.
> 
> maybe we should change all codecs to output in their native formats only,
> and left all kind of downsampling, float2int etc to libaf.
> this way we lose conversions helped by the codecs (examples: liba52's
> float2int, channels downsampling, mp3lib's half or quarter freq decoding,
> mono decoding of stereo sterams, stereo decoding of mono streams).

This seems like something of a negative to me, especially with ac3
decoding...but I'm not sure how it works now. If there are only 2
output channels but the stream is 5.1 ac3, does liba52 really decode
all the channels and then downmix them, or can it just skip the
surround stuff and decode only l/r for better performance? If it can't
do that, it seems like a really desirable feature, especially since
ac3 decoding is so damn slow to begin with.

> but this way we could ask the soundcard to accept the codec's native format,
> and do the conversion only if it cannot be done. if both codecs & ao
> supports float, then prefer float in filters, otherwise if both codec & ao
> are integer, then don't convert it to & back from float, it just eats cpu.
> if the user wants hi-fi quality, he can still force float filters on
> commandline.

Agree totally. IMHO it's similar to the gamma issue in video that came
up a while back. Yes you have to do gamma in rgb space for it to be
entirely correct, but it's prohibitively slow and nonsensical to do
yuv->rgb->gamma->rgb->yuv just to do the gamma correction 'exactly'
right. And from what I've seen, the error with the integer audio
filters is much less significant even.

> the best would be if codecs could support multiple output formats, rates,
> channels, and libaf could handle the handshaking between the selected (by
> user) filters, codec and ao. then auto-insert converters where it's needed.
> but it requires ig api changes and will result in many problems, see -vop :)

I agree. I was hoping the af layer would be just like the vf layer to
begin with, and somehow it didn't quite turn out that way... :( It
should still be possible to improve it in that direction though.

Rich