[FFmpeg-devel] [GSoC] Qualification Task

[Mina Nagy Zaki]

On Wednesday 23 March 2011 18:13:23 Michael Niedermayer wrote:
> On Wed, Mar 23, 2011 at 05:44:48AM +0200, Mina Nagy Zaki wrote:
> > 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.
> 
> i agree that 1 wraper instance should only contain 1 filter instance

I have a working sox wrapper, but let me paste my commit message:

commit 9022e7cdb686c7397d82b00ee9c8e70ed7ddeef4
Author: Mina Nagy Zaki <mnzaki at gmail.com>
Date:   Thu Mar 24 09:21:49 2011 +0200

    Added a sox wrapper filter.
    
    Loads and initializes a single sox filter and passes samples to it
    during filter_samples.
    
    It is currently very limited due to several problems that need
    to be figured out, including:
    - Draining is not handled yet until I figure out finding EOF
    - Using config_props to set rate/fmt/etc from an output pad
      does not propagate the changes
    - No channel negotiation mechanism or means to choose between
      planar or packed data
    - No way to tell the filter system that we were unable to consume
      all the given input
    - ...

I have tested with the sox earwax filter and it works fine. Testing with sox's 
rate filter though messes up the file due to the 2nd point above, though I'm 
unsure if it's only me doing something wrong.

-- 
Mina