[MPlayer-dev-eng] Audio filters first design proposal

[Arpi]

Hi,

> I have written a design proposal for the new audio filter structure,
> it is attached to this mail. Have a look, at it. I have so far not
> addressed the problem of memory buffers. I would still like to make
> them dynamic all the way into the buffering that is made by mplayer. I
> need to start looking at where I should put the calls to init, uninit,
> play, etc - please advise me on this.

sorry for long delay, i forgot this one ;(
now checked, and it looks ok for me, with small note that filter list
shouldn't be declared in .h but in .c

anyway, it is not clean how did you imagine buffering in this
implementation. i think it's a key thing we should discuss in this topic.

for video it was simple, there are separated, complete video frames.
(except interlacing, it's an issue to be solved soon)

for audio, stuff is more problematic. there are buffers, but filters may not
process every sample of the buffer, as some of them operates on block of
samples, or even worse: some needs previous samples, like delay or resample.

the current libao2 way is:
- asking the ao driver (filter) for how many bytes it can process -> MIN
- decode MIN <= N < MAX bytes (MAX = free buffer space, >=MAX_OUTBURST)
- pass the decoded N bytes to the ao driver/filter, but don't expect it to
process all samples, it should return the amount of processed data.
remaining bytes will be passed again one loop later.

i think it's good, anyway there is a small(?) issue: we're using memcpy() to
same unprocessed bytes, it may be slow for some cases - byt as audio data is
usually small (max ~1MB for 6ch stereo uncompressed for 1 second) it shouldn't
be a big problem. anyway it's easy to workaround: increase buffer size, and
introduce 'buffer start' pointer, so instead of memcpy we could just
increase this pointer. it was done as a hack in the old libmad decoder.

but, that's very important that we cannot expect that filters / ao drivers
will process every sample we give to them.

i would change the interface of your above sample to use separated buffer
pointer+len and data format descriptor (struct with channels, format etc),
instead of passing the data in that struct, and the functions processing
this data should return the amount of processed bytes/samples. so the caller
could handle buffering: save the unprocessed samples for the next round.

using the new audio filter layer, we have to convert audio encoders to
filters and make an af->ao2 wrapper.

for video, the player/encoder calls the codec (decoder), and it calls the
filters and vo. for audio, we should call the ao (or ae), and it should call
the filters up to the decoder. why? because only teh ao/ae drivers know how
many bytes do they need, and the filters can tell the previous filter how
many bytes/samples do they need. so the whole thing is reversed:
- ao/ae determines how many samples it wants, calls last af
- last af determines how many samples it needs to produce the wanted (by
ao/ae) amount of samples
- previous af does the same...
- first af calls the decoder to decode enough samples.

in every case you have to handle the case when too many or not enough
samples are available. the former will happen for most audio codecs, you
can't tell it that decode 345 samples, it will decode 8192 or whatever,
depend on the codec block size.
the later (not nough samples) will happen at EOF, and when rounding cause
some less samples than wanted.

as most audio filters actually copy the data while converting (am i wrong?)
something like vf's EXPORT should work. it's the same method as used now by
ad/ao2. anyway it makes things like 'direct rendering' impossible.
(it sounds mad, but i can imagine codec decoding to sdl's audio buffer or so)

the question is that do we really want direct rendering (with its <0.01%
speed increase and lots of mess in the code) or not.


A'rpi / Astral & ESP-team

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