[MPlayer-dev-eng] [RFC] 6-channel AAC and channel reordering

[Corey Hickey]

Dominik 'Rathann' Mierzejewski wrote:
> Reviving an old, forgotten patch...

Yeah, I have a bad habit of leaving old patches alone...

> I've tested it on my 4.0 setup and I didn't hear the front center and lfe
> channels until I downmixed it to 4ch:
> mplayer -af pan=4:1:0:0:0:0:1:0:0:0:0:1:0:0:0:0:1:0.25:0.25:0:0:0.25:0.25:0:0 \
> return,_the_h720p.mov

That makes sense, since mplayer is outputting 6 channels, and on your 
system the last two aren't hooked up to anything. One thing, though: do 
you have channels=6 in your config file, or did you specify -channels 6 
on your command line? If not, then I'm confused, since as far as I know 
mplayer tells libfaad to downmix to 2 channels be default.

I have one or two ideas of ways to implement reasonably user-friendly 
upmixing and downmixing configurations (that can be specified in the 
config file). When I wrote the original patch, I was thinking it would 
be nice to use pan (instead of channels) to do the remapping and 
remixing at the same time, but now I think it would be better to remix 
as a second step in order to conserve programming sanity.

Like this:
decoder  [1]--->   channel-remap   [2]--->   remixing   [3]--->   output
where:
[1] is arbitrary channel order
[2] is consistent channel order
[3] is remixed the way the user wants

> With that, it seems to be working fine (certainly the trailer sounds better
> than without it). Attached a version updated to current SVN, although the
> old patch still applies.
> 
> OK to apply?

For some reason I have a nagging feeling that somebody else proposed a 
different approach and that it might have been committed, but I can't 
dig up the patch. Maybe I'm imagining things.

In any case, the patch I posted was mostly a proof-of-concept, but I 
guess it works. Looking back, I see two things I might do differently.

(a) The chan_map array could just be a string, with creation of *int 
pointers for af->control happening right before they're needed. This 
would obviate the need for a separate af_set_channel_map() funcion.

(b) If (a) is done, then it would be easy to make sure the length of the 
array is as expected and prevent reading beyond the end.

I'll go ahead and make those changes and see if it works.

-Corey