Giacomo Comes wrote:
I have been working on extending the patches submitted some time ago by Alexander in order to support in the correct order 4/5/6 channels sound stream. 6 channels is easy because you can only have 3f+2r+lfe. With 5 channels there are more combinations: 3f+2r, 2f+2r+lfe, 3f+1r+lfe and with 4 channels: 2f+2r, 3f+1r, 3f+lfe, 2f+1r+lfe
Currently there is no way in mplayer/mencoder (and in libavcodec) to specify the number of front/rear/lfe channels, you can only specify the sum of them with the option -channels. For this reason the patches currently assume the following configurations: 6ch 3f+2r+lfe 5ch 3f+2r 4ch 2f+2r because this is what you get with libavcodec ac3 encoder.
I agree. Those seem to be the most common configurations, and for now I don't think it's worth supporting others. It's definitely possible to remix odd configurations into the closest common configuration, but, without an abundance of samples or demand, I think it would complicate the current effort. Perhaps in the future.
The changes to ad_faad.c, ad_pcm.c, ae_lavc.c, ae_pcm.c and ao_pcm.c are just extension of the previous patches. Assuming that the original patches were correct, they should also be. The changes to ae_faac.c instead are completly new, check them carefully.
Thanks. I'll take a look.
I was planning to submit the patch before rc1 was released, but I didn't have the time. Also as Corey has noticed, channel reordering introduces some overhead.
Yes, but not a lot.
May be we can add an option like -nochanreorder the tell mplayer/mencoder to not do channels reordering (keeping maximum speed in case it is required).
Perhaps.
Corey, can you integrate the ideas of this patch in yours?
Yes, one way or another. If I can see how, I want to compare the efficiency of doing the reordering within each ae_*.c vs. adding af_channels to the end of the filter chain just like I'm currently doing at the beginning. ...but not until I get home from work today. Thanks again, Corey