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

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 31 October 2006 at 01:06, 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 channels=4.

> 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.

I can't recall any such thing.

> 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.

Great. I guess nobody was interested because nobody who cared had access
to >2ch speaker setup. Could you also take care of WMA? See the recent
thread on -users for details.

Regards,
R.

-- 
MPlayer developer and RPMs maintainer: http://rpm.greysector.net/mplayer/
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
	-- from "Collected Sayings of Muad'Dib" by the Princess Irulan