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

[Frank Aurich]

Corey Hickey wrote:
> 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

There you go: http://thread.gmane.org/gmane.comp.video.mplayer.devel/36195/



Frank