[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 
sox_flow_effects()

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() 
again.

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.

-- 
Mina



More information about the ffmpeg-devel mailing list