[FFmpeg-devel] [PATCH] Add NULL mixer to AVSequencer.

Ronald S. Bultje rsbultje
Mon Aug 16 03:04:32 CEST 2010


On Sun, Aug 15, 2010 at 12:05 PM, Sebastian Vater
<cdgs.basty at googlemail.com> wrote:
> Ronald S. Bultje a ?crit :
>> On Sat, Aug 14, 2010 at 8:06 AM, Sebastian Vater
>> <cdgs.basty at googlemail.com> wrote:
>>> The NULL mixer does not output any PCM data but internally
>>> simulates the whole mixing process (i.e. calculation of
>>> sample positions and running the playback handler at
>>> correct timing), which is useful for playtime calculation.
>> For those of us that know less than you about mod files, can you
>> explain in a few sentences what this patch is useful for? Why do we
>> want it, why do we need it, why would it be important to commit this
>> patch before - say - a demuxer/decoder, and what does the patch in the
>> end accomplish, i.e. what is the place of this patch w.r.t. the big
>> picture of ffplay playing back a mod file?
> Consider it like /dev/null and /dev/zero. Although they don't do
> anything "useful" they have their pretty places. ;-)
> The purpose of the null mixer is:
> a) exact playtime calculation. For TuComposer files you can't anymore
> simply parse the pattern data and go through the order list, since it
> features a full-featured synth sound assembler which makes it otherwise
> impossible to get always correct results (unless you solve the famous
> halting problem of a turing machine).
> The point here is, that the synth assember can also call the normal
> effects (that means also position jump and pattern changing, which
> affect playback time). It also can read the current sample position of a
> certain channel and do actions based on that, i.e. you can write code
> with the synth sound assembler that does a pattern jump if current
> sample position is between 7000 and 9000 (yes that's weird, but the
> power is there).

Apart from tucomp files, is this used? If not, is there a reason for
that (e.g. needing a specialized mixer for that, which was too
CPU-intensive on Amiga CPUs at that time)? Should we support it?

> b) for transcoding from module to module when translate NNA channels to
> non-NNA supporting trackers, the null mixer does it well enough to do
> this correctly.
> c) it's waaaay faster than even the low quality mixer, on my Amiga the
> null mixer is around 10-30 times faster than the low quality mixer.
> Imagine you are setting up an FFmpeg server which has PCM output
> disabled for modules, then you can disable the low quality mixer and
> just get stick with the null quality mixer. This is also useful for size
> reduction, since the low quality mixer is around 450k (object file),
> while the null mixer is only around 23k.

This will never happen. I don't see FFmpeg having flags for disabling
particular features of several obscure mod files.

FFmpeg will have compilation flags to disable mod demuxers/decoders,
or for disabling the synth mixer. That's it.

> d) It's good for review, since it's less than 1000 lines but these lines
> share 95% with the low quality mixer, i.e. if this passes review, the
> low quality mixer will most likely also (it's 23k lines now, but no
> panic, most of the rest 22k lines are VERY similar, so just review in
> the low quality mixer one or five functions which would follow after the
> null mixer, and I'll apply the critics to the remaining functions, too,
> saving us all LOTS of time).

My impression is:
- 23k source is too big. You have to simplify it.
- 405k object file is unacceptable, but I think you took one with
debug symbols, so let's revisit that with real numbers.
- If null mixer and real mixer duplicate code, that duplication needs
to be solved without duplicating it. If various functions in the
23k-source-mixer duplicate functionality, that should be prevented in
a useful way also.

We will not review one function and keep the design intact, if the
design itself is flawed. My intention here is to come up with an
optimal design that is better than anything any single person could
have thought of by themselves, by evolving it to something better
through review iterations.

My question to you: can the null mixer problem be prevented by writing
a smarter non-null-mixer that is faster when presented with a NULL
output buffer? Does that lead to significantly smaller object file
size with an insignificant effect on speed? Why / why not? If done
correctly, can we live without the null mixer, thus only requiring a
single synth mixer thus not needing a mixer interface, thus greatly
simplifying the code that is to be submitted, thus making FFmpeg
simpler and easier to maintain?


More information about the ffmpeg-devel mailing list