TranscodingMaxAudioChannels=2 ignored when audio codec matches — 5.1 AAC stream-copied instead of downmixed

[GreatSandstone 0]

Summary

When the Emby Web client requests transcoding with TranscodingMaxAudioChannels=2 (stereo), Emby ignores this constraint if the source audio codec already matches the target codec (AAC→AAC). Instead of downmixing the 5.1 source to stereo, Emby uses -c:a:0 copy in the FFmpeg command, passing the full 5.1 audio stream through to the client unchanged. This results in clients receiving 5.1 channel audio when they requested stereo, which causes audio/video desync on browsers (Firefox/macOS confirmed) with limited bandwidth connections.

Environment

Emby Server: 4.9.5.0
Client: Emby Web 4.9.5.0, Firefox 149 on macOS 10.15
Transcoding: Hardware (NVDEC/NVENC, GTX 1060)
Source file: MKV container, HEVC video, AAC 5.1 audio

Steps to Reproduce

Have a media file with AAC 5.1 audio (6 channels).
Play it from the Emby Web client (browser) on a connection slow enough to require transcoding. Transcoding is triggered here due to ContainerBitrateExceedsLimit.
The client sends the HLS manifest request with AudioCodec=aac&AudioBitrate=320000&TranscodingMaxAudioChannels=2.
Observe that the FFmpeg transcoding command generated by Emby uses -c:a:0 copy for the audio stream, despite the TranscodingMaxAudioChannels=2 constraint.
Result: The output HLS segments contain 5.1 AAC audio. The browser receives and attempts to play 6-channel audio when it requested 2 channels, causing desync.

Expected Behaviour

When TranscodingMaxAudioChannels=2 is included in the client request, and the source audio has more than 2 channels, Emby should transcode the audio to stereo (e.g. -c:a:0 aac -ac 2) regardless of whether the source codec matches the target codec.

Actual Behaviour

Emby generates the following FFmpeg command (relevant portion):
-c:a:0 copy -metadata:s:a:0 language=eng -disposition:a:0 default
The source stream is AAC 5.1 at 447 Kbps. The client requested AAC at 320 Kbps, max 2 channels. Because the codec (AAC) matches, Emby skips audio transcoding entirely, ignoring both the channel limit and the bitrate limit.

There is also a related issue: Emby's media detection reports the audio stream bitrate as 320,000 bps, but ffprobe reads the actual bitrate from the file metadata as 447,245 bps. Because Emby believes the source bitrate equals the requested budget (320,000 = 320,000), it concludes no transcoding is needed. This may be contributing to the decision to stream-copy.

From the FFmpeg log, the source stream is detected as:
Stream #0:1(eng): Audio: aac (LC), 48000 Hz, 5.1, fltp, Start-Time 0.020s (default)
  BPS: 447245

But Emby's own media info JSON for the same stream reports:
"Codec": "aac",
"BitRate": 320000,
"Channels": 6

Disclaimer: 
Claude was used to help identify the issue and sort through the logs. It has written the summary with a great deal of authority, although it is definitely possible there is a configuration oversight we are both missing. 

ffmpeg-transcode-4adf667c-6450-4842-aa79-63d6aeca9f87_1.txt embyserver-63918795788.txt

[Abobader 3504]

Hello GreatSandstone,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team