[FFmpeg-devel] [PATCH 2/2] lavfi: add channelremap audio filter.

[Stefano Sabatini]

On date Wednesday 2012-01-11 23:33:44 +0100, Clément Bœsch encoded:
> On Wed, Jan 11, 2012 at 09:35:58PM +0100, Nicolas George wrote:
> > Le duodi 22 nivôse, an CCXX, Clément Bœsch a écrit :
> > > +Remap the channels of an audio stream using channel indexes.
> > > +
> > > +This filter allows to re-order, copy, remove or insert muted channels in an
> > > +audio stream. It accepts a list of channel indexes separated by ":". Using "-1"
> > > +as channel index means it is a muted channel.
> > > +
> > > +For example, if you have a 5.1 source and want a stereo audio stream by
> > > +dropping the extra channels:
> > > + at example
> > > +channelremap=0:1
> > > + at end example
> > > +
> > > +Given the same source, you can also switch front left and front right channels
> > > +and keep the input channel layout:
> > > + at example
> > > +channelremap=1:0:2:3:4:5
> > > + at end example
> > > +
> > > +If the input is a stereo audio stream, you can mute the front left channel (and
> > > +still keep the stereo channel layout) with:
> > > + at example
> > > +channelremap=-1:1
> > > + at end example
> > > +
> > > +Still with a stereo audio stream input, you can copy the right channel in both
> > > +front left and right:
> > > + at example
> > > +channelremap=0:0
> > > + at end example
> > > +
> > 
> > I did not yet look at the code, but I must say I do not like it very much,
> 
> :(
> 
> > for two major reasons:
> > 
> > - As far as I can see, all it can do, af_pan can do as well. Possibly,
> >   af_pan may be slower and/or support less formats, but this is just a
> >   matter of optimization and coverage.
> > 
> > - It does not take the channel layout into account at all.
> > 
> > More broadly speaking, having several implementations of roughly the same
> > features is very confusing for the users: they always wonder why there are
> > several versions, which one they are supposed to use. And for us, it makes
> > twice the amount of work to maintain.
>
> 
> Yes you are right af_pan can do all channelremap does AFAIK (with a
> slightly more complicated syntax though), but I believe the goal of the
> two filters are not actually the same. af_pan really is to fine tune
> channel levels while channelremap is basically just to filter out or
> re-order channels with a really simple syntax.

I agree with both, so really can't say a last word to it.
 
> This filter is also a demonstration on how to use the channel mapping
> feature of libswr (maybe that one could be improved to actually make
> af_pan use these features instead?), which indeed should be faster and
> possibly safer; I'm not so sure af_pan can for instance keep the lossless
> aspect of map_channel when dealing with unsupported sample formats.

I suppose some benchmarks may help to see how faster is
channelremap. But I see pan is really a more general filter, for the
more specific use case channelremap should be used.

BTW I really like the flexible syntax of pan for specifying the
channel, we should try to make channelremap understand it as well
(->reusing the parsing code in af_pan.c).

> > For this particular case, I really see no reason not to use and improve
> > af_pan rather than start a new filter.
> > 
> 
> As you wish, I don't mind much dropping that patch if that really matters.
-- 
FFmpeg = Forgiving & Fundamentalist Mythic Portentous Embarassing God