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

[Anders Johansson]

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.

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

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

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

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

> A'rpi / Astral & ESP-team

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

//Anders
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libaf.diff.gz
Type: application/octet-stream
Size: 1676 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20021001/07924b74/attachment.obj>