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

[Frank Aurich]

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

Thanks Corey,

with the mentioned patch (the link seems to be wrong but I found it 
anyway) it works fine with the matroska files.
I discovered though that for Quicktime files the patch for demux_mov.c 
has to be applied as well, otherwise the mapping is incorrect.


Frank