On 6/2/2026 12:06 AM, Michael Niedermayer via ffmpeg-devel wrote:
Hi

On Sun, May 31, 2026 at 03:52:41PM -0300, James Almer via ffmpeg-devel wrote:
On 5/31/2026 3:51 PM, Michael Niedermayer wrote:
Hi

This breaks the following (channels are very wrong afterwards)

-i Nero%20032%20kbps%20CBR-HE.mp4 -t 5 -bitexact -y test513.wav

file shoukld be here: 
https://trac.ffmpeg.org/attachment/ticket/513/Nero%20032%20kbps%20CBR-HE.mp4

Huh? How does a change to the aac encoder affect decoding to pcm? Are you
sure this is the right commit?

right commit wrong testcase

ffmpeg -i 51.flac -strict experimental -ab 512k -aac_coder 0 -acodec aac 
-bitexact -y test5.mp4

https://samples.ffmpeg.org/flac/51.flac

ffplay plays the channels in the correct speakers, but i see that other players don't like the PCE layout. The reason would be that for side channels we're using the very much not expected SIDE aac position.

AAC has FRONT, SIDE, BACK and LFE channel positions. For 5 channels (three front, two surround) + LFE and for 7 channels (three front, four surround) + LFE, and really, for any other layout with up to 8 channels, pre-defined PCE channel_conf values use BACK position for all surround channels. SIDE is never used outside of 22.2 If BACK has two channels, then it's assumed to be Ls/Rs (We map those to back). If it has four, then it's assumed to be Ls/Rs/Lrs/Rrs (we map to side and back respectively). Given we wanted to differentiate 5.1 and 5.1(side), we use the SIDE position for the latter, but evidently, parsers don't like anything being in SIDE. See https://github.com/mstorsjo/fdk-aac/blob/d8e6b1a3aa606c450241632b64b703f21ea31ce3/libAACenc/include/aacenc_lib.h#L573 for a list of pre-defined config values.

As for why it worked before that commit, the PCE layout we were writing was completely broken, so everything ignored it (the native aac decoder would export unspec layout and the CLI would guess 5.1).

So the solution would be to not write SIDE position elements at all, which will result in 5.1(side) and 5.1 sources write the same PCE layout, which coincidentally will make encodings that had the former source be detected as the latter, like it was before the aforementioned commit.

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to