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

[Giacomo Comes]

On Mon, Oct 30, 2006 at 04:06:07PM -0800, 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.

The patch has not been committed.
Later (if I have time) or tomorrow I will point you to the original
patch and I will post also a new one I made that extend the
original one.

Giacomo

> 
> 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
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

--