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