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

[Clément Bœsch]

On Thu, Jan 12, 2012 at 11:15:38AM +0100, Nicolas George wrote:
> Le duodi 22 nivôse, an CCXX, Clément Bœsch a écrit :
> > 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.
> 
> IMHO, the goal of the filters is what we want it to be, and we should focus
> on questions that have actual consequences: how clear/confusing is it for
> the users? how much work is it maintaining? There are cases where writing a
> simple tool overlapping with a more powerful one is relevant, but I do not
> think this is true here.
> 
> > 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.
> 
> You are right that af_pan handles less formats and will be slower, but that
> can be fixed by extending af_pan itself, and it is IMHO a more efficient use
> of the programming efforts.
> 
> What about this plan: ?
> 
> - In af_pan:init, near the end, detect if the coefficient matrix can be
>   expressed with the channel mapping feature of libswr (the conditions will
>   probably be: only exact zeroes and ones, at most one one per line, no more
>   than SWS_CH_MAX channels).
> 
> - If this is true, in query_formats, accepts all formats supported by your
>   patch.
> 
> - ... and in filter_samples, use libswr.
> 
> - Document clearly that af_pan should be used for channel remapping (and
>   that it is specially optimized for it).
> 
> That way, the functional part of your patch stays as a part of af_pan, and
> we save the maintenance burden of the glue part.
> 

I like this idea, I'll try to come with something like this.

[...]

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120112/dd5084fc/attachment.asc>