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

[Anders Johansson]

> 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.

This coild be solved by making the ac3 decoder become  part of libaf :).

> > 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.

What is required in terms of API changes to achive this?

> Rich

//Anders