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

[D Richard Felker III]

On Mon, Jan 06, 2003 at 06:55:15AM +0100, Herman Tamas wrote:
> 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...

I only have one question... should the interpreter be written in
forth? ;))))

Rich