[MPlayer-dev-eng] [PATCH] audio channel remapping

[Corey Hickey]

Reimar Döffinger wrote:
> Hello,
> On Wed, Nov 08, 2006 at 10:00:47PM -0800, Corey Hickey wrote:
>> This patch makes mplayer and mencoder auto-insert the channels filter
>> when necessary in order to maintain the proper order. Remapping is
>> necessary when reading from or writing to formats that have a different
>> native order from what mplayer and mencoder use internally.
> 
> I am fine with changing the de/encoders to do the reordering, but I am
> against this remapping via filter, it is IMO immensely complex and there
> are already without it some bugs in filter chain building (like command
> line parameters lost on reinit).

There were some other patches posted which did the reordering in each 
individual decoder/encoder, and, assuming the ones I tested were 
representative, that approach was somewhat slower than using 
af_channels. For example, to quote myself from an earlier mail:

========================================================================
I tested on a 6-channel wav file made from The Matrix DVD. It is 8177.3
seconds long. Each number is the user-time average of three tests, but
there really wasn't much variation. The command is:
$ time mplayer -ao pcm:fast:file=/dev/null -channels 6 audiodump.wav


method                          user time     % of play time
------------------------------------------------------------
original (incorrect channels):     9.099s           0.11127%
using af_channels to remap:       15.057s           0.18413%
reading into each channel:        30.296s           0.37048%
========================================================================

There may have been better ways to handle the reordering at the decoder; 
I wouldn't know.

The other advantage of using af_channels is that adding remapping 
support to decoders/encoders is very easy, since the central code 
handles the actual reordering.

> I agree with whoever suggested on ffmpeg-devel that audio should
> preferably use a planar format, which each channel in a separate memory
> area. Although this will be a major effort, this allows reodering
> without any speed loss and for most decoders is closer to their original
> output anyway (AFAICT).

You're probably right, and, if a patch to do that were available, it 
would probably be the better choice. If I had any expertise in that 
area, I would try it myself, but, alas, I don't. So, I think the choices 
are:

(a) Use my patch, which is already written and runs reasonably quickly.
(b) Use the patches for reordering in each encoder/decoder, which are 
already written and run almost as quickly.
(c) Leave the bug alone and hope it motivates someone to spend a lot of 
time making a better solution.

If anyone steps forward and says they'll try to implement your 
suggestions in the near future, then I have no objections to (c). 
Otherwise, I think we ought to apply what we have, since this is a 
user-visible bug that people ask about once in a while. I prefer (a), as 
I explained earlier, but I won't be militant about it you have good 
reasons to prefer (b).


Either way, I'll be offline for several days starting this afternoon, so 
don't misinterpret my lack of responses.

-Corey