[MPlayer-dev-eng] New audio filter layer finished

[Arpi]

Hi,

> > > I will commit in three days if no one has any objections.
> > please commit the libaf dir content asap. but only that!
> 
> Done, I committed changes to main Makefile and added define in mp_msg.h
> as well. Hope it was OK to add stuff to the main Makefile.

yes, but i wouldn't add libav at the end, after -lm

> > it looks ok for me, but your modifications to libmpcodecs aren't ok.
> > i see that you also have problems with buffering there, and there are
> > other issues too: some codecs decodes at initialization state too!
> > also this check/workaround isn't too nice:
> > 
> > +    // Make sure the output data chunk will fit in the buffer
> > +    if(af_outputlen(sh_audio->audio_out_minsize) > maxlen)
> > +      return 0;
> 
> I know - was never completely happy with it.
ok

> > i would introduce a middle buffer. or even better using the current
> > audio_out buffer as 'decoded audio' and add a new buffer, probably outside
> > of sh_audio (it has no use to put it there) for the filtered audio waiting
> > for playback.
> >
> > so:
> > demuxer -> (sh->audio_in_buf) -> decoder -> sh->audio_out_buf -> libaf -> playback_buf
> > 
> > the playback buffer could be allocated after decoder & af initialization, to
> > size af_outsize(size of sh->audio_out_buf)
> > 
> > we can either move af calls out of libmpcodecs (to mplayer/mencoder core) or
> > left it there, but fixing it to do filtering after codec initialization too,
> > as some codecs decodes small chunk of audio data at init state, to verify
> > that the DLL work or to detect various parameters, like frame size (exported
> > by audio decoder)...
> > while the later is not so clean, it's preferred as no duplicated code in
> > mplayer/mencoder/xxx (xxx=future projects using libmpcodecs :))
> 
> I was trying to avoid double buffering the audio data, thats why I

but actually your code does it, too.
you decode to the audio_out buffer, then af layer filters/transfers it to
it's af_data buffer and finally you memmove() it back to audio_out at the
end of dec_audio.c::decode

> put the code in dec_audio. I will have another look at it and send a
> new patch. If anyone familiar with the code can come up with a better
> solution please send a patch.
i'll work on this, hopefully today but more probably only tomorrow.
i've the code in my mind, just needs to be organized and typed ;)

> > > If you want to test it apply the patch and try this:
> > > ./mplayer  -channels 4 -srate 48000  movie.avi
> > 
> > btw -srate is a different thing, at leats in mplayer.
> > it sets teh soundcard's playback rate but it isn't used for a-v calculation,
> > so using it in filters will confuse a-v sync.
> 
> I know that why I had to tinker with o_bps
> 
> > we should either change -srate behaviour for mplayer or add a new switch.
> 
> I think my usage of -srate is quite intuitive - If you want to have 48kHz
> playback speed in 4 channels then just give the parameters and the
> software figures out the details. 

agree, so we have to add new switch for the old behaviour of -srate
(changing playback speed)

> > btw 2.
> > your code seems to use statics for some important context/config storage.
> > it's ok _now_, but it will make paralell processing of multiple audio tracks
> > (interesting for mencoder) impossible :(
> 
> I didn't think of this, quite easy to change though.
then change it, please

> > you should introduce a context/handle type parameter for the af API,
> > pointing to a struct conatining config/etc parameters of teh given audio
> > stream. i mean something like vf->priv for video filters.
> 
> I'll put it on my todo list. 
ok

> A patch which makes it possible to test the code I committed to CVS is
> attached to this mail. 
ok


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu