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

[Herman Tamas]

On Mon, 6 Jan 2003 03:29:08 +0100
Arpi <arpi at thot.banki.hu> 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.
> 
> 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.
> 
it doesnt sound good 2 me either. tho the comprehension of the current
structure of mplayer is a lil bit beyond my capabilities yet, but i feel.
it would b a better approach 2 have an expert system what writes an
optimal "program" 4 the actual videofile depending on its actual parameters
(frame rates, number of various datastreams, dimensions &so on)
this program would b natively compiled w an optimizing compiler...
but this requires a much more "modular" mplayer again...
let me show what do i think of
there would b lil operations 4 inputing demuxing decodeing postprocessing
& outputting data & timing
ms - wait some milisecs (abs or rel)
i - input a chunk
dx - demux it
deb - decode a block of a video frame
dI - decode a full I frame
dP - decode a full P frame
dea - decode an audio chuck
c - color space conversion
ol - output a video line
oa - output audio

& things like that
the expert system would use these primitives as an instruction set
and could make up simple sequence of them - if u will inlining them -
this way u can even mix various output activities in the middle of
decoding if u wanna ensure a very precise timing. or u can do
whatever u like ;) like this
i dx deb deb .... deb c c c c ... c c dea dea dea ... ol dea dea
oa deb deb deb ... deb c c c c .. c ..... ol oa osub ...

u can unroll cycles @ least so the color space conversion code would b
 c c c c c ... c c ( "width of the actual movie" pieces of "c")
im not sure about how does it interferes w the cachin mechanisms of
x86s but it has so huge caches so probably it wont b a problem.
nah, got the point? (just try 2 not think of such things as
 "it is 2 slow 2 generate meta code 1st, the compile it in various
 stages in2 machine code" 1st. speed is another issue.. anyway,
 i already have solutions 4 such issues. u wont need 2 issue
 gcc or as 2 compile such an intermediate...)
and yes, i was talkin about meta programming...