[FFmpeg-devel] [GSoC] Qualification Task
Mina Nagy Zaki
mnzaki at gmail.com
Wed Mar 23 04:44:48 CET 2011
On Tuesday 22 March 2011 16:14:28 Stefano Sabatini wrote:
> From a private mail I received on 2011-01-28:
> > Attached is the most recent patch I could find. There is a bottleneck
> > however with sox:
> > The sox API that starts off the filtering of data - sox_flow_effects() -
> > keeps trying to pull data from the input effect defined in lavfi until
> > it sends EOF, otherwise doesn't return. So I changed the af_sox input
> > effect behavior in the patch below to always send EOF after giving every
> > buffer to the sox chain. This means the sox chain would be reinitialized
> > when calling sox_flow_effects for each audio buffer. This causes sox to
> > crash after playing out a few buffers.
> > Instead, it might be better to call sox_flow_effects once in a new
> > thread and let it fetch and output its buffers from/to the FIFOs at the
> > input and output.
> > Hope that helps.
> > Regards,
> > Hemanth
> Attached patch, compile but completely untested. You need to configure
> FFmpeg with --enable-libsox.
This continuously re-initializes all the effects, and then drains all the
effects, on every new lavfi buffer. The only way to get this to work is to put it
in a thread and let it block on input, or create our own customized
I tested it with the earwax effect (which doesn't even need draining...) and as
expected it eats up the buffer then segfaults when it tries to sox_flow_effects()
The solution I see best is IMHO simply doing one sox effect per lavfi sox
wrapper instance as I mentioned earlier, and as Peter later added. We simply
create and initialize one effect and flow samples through it as they arrive.
This way we can bypass a lot of the problems, and we don't have to write code
to handle sox chains, but instead let the lavfi code do its thing.
More information about the ffmpeg-devel