Strange Channel layout on MOV + AAC with 5.1 channel layout (Lb -> Bfl)

[MichalFiglarowicz]

MediaInfo v23.04 reports different Channel layout on MOV file with AAC in 5.1 channel layout then v22.09. In addition the value reported by MediaInfo v23.04 in Channel layout is very different that the value reported in ChannelLayout_Original which seems to be wrong.
MediaInfo v23.04:

Channel layout                           : L R C LFE Bfl Bfr
ChannelLayout_Original                   : C L R Ls Rs LFE

MediaInfo v22.09

Channel layout                           : L R C LFE Lb Rb
ChannelLayout_Original                   : C L R Ls Rs LFE

The change between versions is from Left Rear Surround (Lb) to Bottom Front Left (Bfl), which looks like a bug IMO. The different behaviour is observed since b53aa80

I observe it only on MOV files with AAC which have chan atom/box (Channel Layout Chunk) specified in https://developer.apple.com/library/archive/documentation/MusicAudio/Reference/CAFSpec/CAF_spec/CAF_spec.html#//apple_ref/doc/uid/TP40001862-CH210-BCGBHHHI. In such files the Channel layout is taken from chan atom and ChannelLayout_Original is taken from AAC elementary stream.

Here is how to generated such stream

ffmpeg -i big_buck_bunny_1080p_h264.mov -vn -c:a:0 aac -f mov mov_with_chan_5_1.mov

I looked at the MediaInfoLib code and IMO the problem is that value from chan is renamed with ChannelLayout_2018_Rename function (the most problematic is the part after IsAac flag). It seems that this code should be executed on values parsed from the AAC elementary stream, but not on values form chan atom. Unfortualely I do not know how to properly fix the MediaInfoLib code since the ChannelLayout_2018_Rename is called late and can't see inforamtion where the Audio_ChannelLayout value was taken from.

[JeromeMartinez]

Unfortualely I do not know how to properly fix the MediaInfoLib code since the ChannelLayout_2018_Rename is called late and can't see inforamtion where the Audio_ChannelLayout value was taken from.

This part of the code is definitely messy, and there are conflicts between specs about names, so a mix up when we try to normalize.
I think that we need to know the source of the channel names (AAC or MP4) and this is not an obvious patch due to the super messy code, I'll check.

Here is how to generated such stream

Please share a small sample file, easier for me to deal directly with a file having for sure the issue.

[MichalFiglarowicz]

Here is an example file

mov_with_chan_5_1.mov

Generated with

ffmpeg -i big_buck_bunny_1080p_h264.mov -t 00:00:05.0 -vn -c:a:0 aac -f mov mov_with_chan_5_1.mov