Cap eac3 encoder sample rate at 48KHz

[DrHurt]

What happened?

Playing TrueHD 96KHz via the audio bridge results in video only due to the eac3 encoder maxing out at 48KHz.

This causes an AudioBridge init failed and video without audio.

Steps to reproduce

Play a movie with a 96KHz TrueHD track and brigde set to default eac3.

AetherEngine version or commit SHA

Unknown - AetherPlayer 0.18.1

Host app

AetherPlayer

Platform

iOS

OS version

27

Device / chip

iPhone 15

Playback path

Native AVPlayer

Source media (for playback bugs)

No response

Error codes / log lines

Anything else

[DrHurt]

Might be worth considering FLAC as default on iOS & macOS as those devices will rarely connect to HDMI audio systems.

[superuser404notfound]

Fixed in 7.4.1 (452c7d6).

Exactly as diagnosed, and the reason it took the whole session down rather than just the encoder: AudioBridge.init copied sample_rate straight out of the source codecpar into the encoder context. E-AC-3 has 32, 44.1 and 48 kHz and nothing else, so avcodec_open2 returned EINVAL with libavcodec printing its own list, the route logged AudioBridge init failed and fell to silent video-only. 192 kHz would have done the same.

The #165 cascade could not rescue it either, which is worth noting because that is the mechanism that exists for exactly this outcome: it retries the other encoder when the resolved one is absent from the build, and stops on any other init failure on the grounds that a re-attempt is pointless. Here the encoder was present and simply refusing the configuration, so it stopped after one attempt.

The rate now comes from the encoder itself via avcodec_get_supported_config, rather than from a table here that no FFmpeg bump would update: exact match kept, above the list the highest supported rate wins (96 and 192 land on 48), below it the lowest so an 8 kHz oddity still plays, and an encoder that advertises no list at all keeps the source rate untouched. That last part is what matters for .lossless: FLAC advertises no restriction, so 96 kHz stays 96 kHz and stays bit-perfect. swr was already sitting between decoder and encoder on every bridged packet and already configured from the encoder's rate, so the conversion costs nothing that was not already being paid, and the init line now names the source rate whenever the two differ.

On FLAC as the default for iOS and macOS: that one is a host decision rather than an engine one (LoadOptions.audioBridgeMode), and the argument for it is real, since a phone or a Mac is usually driving headphones or built-in speakers where the E-AC-3 bitstream is decoded locally anyway and FLAC would be lossless instead of 128 kbps per channel. Two things pulling the other way: both of those platforms do reach HDMI and AVRs through adapters, docks and AirPlay, which is the install base .surroundCompat exists for, and on a route that can only pass a Dolby bitstream through rather than decode it, multichannel LPCM is what gets downmixed. Worth noting that Spatial Audio is not a factor either way: AirPods spatialise the decoded multichannel PCM, so FLAC 5.1 gets the same treatment as bridged E-AC-3 5.1, and real Atmos objects survive neither mode regardless (they only live on the stream-copy path). Still thinking about where the default should land.

[DrHurt]

That was very quick!

I’m sure AetherPlayer will eventually get a settings section to control everything including bridge mode.

FLAC vs eac3 makes very little difference to be fair so I’m personally not bothered either way. As always I’m just thinking out loud.

Feel free to close this now if you want.

[DrHurt]

Additional data point for documentation:

On tvOS 26 (later builds I think) with the new enabled-by-default “continuous audio connection” setting, the Apple TV defaults to Dolby MAT instead of LPCM. This bypasses the LPCM channel limit on many devices.

Both the Philips and Samsung I have support multichannel Dolby MAT (verified in EDID).

Ironically, I disable that setting because it causes audio sync issues (lots of people online having same issue). eac3 bridge works better for me on the Apple TV (for now at least)