[MPlayer-users] H264/AAC in MKV: Wrong channel mapping [Was: Quicktime sound atom v2: Wrong audio channel mapping]

[Corey Hickey]

Frank Aurich wrote:
>>>> Hi,
>>>>
>>>> with the recent fix by Corey Hickey, new Apple Quicktime videos 
>>>> which use the sound atom 2 (e.g. HD trailers) play fine in MPlayer.
>>>> The audio channel mapping, however is wrong on 5.1 sound systems.
>>>>
>>>> The speech channel, which should come from the center speaker, is 
>>>> mapped to front left. I dont know about the others, mainly because 
>>>> it's difficult to determine ;)
>>>>
>>>> Tested with latest mplayer-cvs and the following trailers:
>>>>
>>>> http://movies.apple.com/movies/universal/king_kong/king_kong-tlr_h720p.mov 
>>>>
>>>> http://movies.apple.com/movies/wb/superman_returns/superman_returns-tlr1_h720p.mov 
>>>>
>>>>
>>>>
>>>> Frank Aurich
>>>
>>> Can anybody confirm the described behaviour on their system or is it 
>>> a problem on my side?
>>>
>>> I figured I could simply remap the channels by using the -channels 
>>> option, but for that I'd first need to know the wrong mapping.
>>> I was wondering therefore if anyone has a AAC audio or MP4 video file 
>>> which uses Quicktimes sound atom 2, that clearly advertises each of 
>>> the 5 (or 6) channels (i.e. some test signal that simply puts a 
>>> singular sound to each of the speakers).
>>
>> The channel mapping is documented on Apple's website. I always have a
>> hard time finding it:
>>
>> http://developer.apple.com/documentation/MusicAudio/Reference/CACoreAudioReference/CoreAudioTypes/Enums/Enums.html 
>>
>>
>> The corresponding line is, I think:
>>
>> kAudioChannelLayoutTag_AAC_5_1 = kAudioChannelLayoutTag_MPEG_5_1_D, // C
>> L R Ls Rs Lfe
>>
>> ...which means:
>>
>> 0 - center front
>> 1 - front left
>> 2 - front right
>> 3 - rear left
>> 4 - rear right
>> 5 - lfe
>>
>> As far as I know, mplayer always assumes the channel mapping is like the
>> AC3 5.1 stored in DVDs:
>>
>> 0 - front left
>> 1 - front right
>> 2 - rear left
>> 3 - rear right
>> 4 - center front
>> 5 - lfe
>>
>> So, the remapping would be like this:
>> -af channels=6:5:0:4:1:0:2:1:3:2:4:3
>>
>> ...and manually downmixing to 2 channels would be like this:
>>  -af pan=2:0.4:0.4:0.4:0:0:0.4:0.2:0:0:0.2:0.5:0.5
>>
>> Note that the relative mixing levels in the above line are mostly
>> arbitrary, and I can't practically test either of them because I don't
>> have a surround setup. Starting from here, though, you ought to be able
>> to correct any mistakes I made.
>>
>> One of these days I'll probably get around to figuring out how to fix
>> mplayer so it understands the correct channel mapping. Of course, if
>> anybody else wants to do it, feel free.
>>
>> -Corey
> 
> I ran into the very same problem as described above again, this time 
> with a MKV file. Video is H.264, audio 6ch AAC. Here also, the channel 
> mapping is wrong.
> I tried the remapping you advised above, and it sounds correct (although 
>  I'm not too sure about the rear channels, they are hardly used).
> 
> Is it possible that the mapping issue of my initial posting is rather a 
> problem with AAC and not with Quicktime?

Yes, you are right. When I dug deeper, I found that the channel mapping 
was coming from the AAC decoder rather than from the MOV demuxer.

The problem isn't really a problem like a bug; it is evidence of a lack 
of foresight on the part of whoever designed the audio formats. There 
are many, many different types of multichannel audio and no standard for 
how to order the channels. Consequently, AAC is different from AC3 and 
other formats are probably different still.

Since MPlayer's channel ordering is designed around AC3, it doesn't 
handle AAC correctly. I wrote a proof of concept patch quite a while ago:

http://mplayerhq.hu/pipermail/mplayer-dev-eng/2006-February/040764.html

Please test it. I'll try to find some time later to re-do the patch 
properly and commit something. Don't hold your breath, though; I'm very 
busy these days.

-Corey