Summary
AudioCodecCompat.mp3 is classified as fMP4-legal stream-copy at HLSVideoEngine.swift:81 (and emitted as mp4a.40.34 per hlsCodecsString). AVPlayer reads the mp4a sample entry as AAC and fails to decode the MP3 frames, returning:
AVFoundationErrorDomain -11829 'Cannot Open'
underlying: CoreMediaErrorDomain -12848
This mirrors the documented Opus behaviour already handled in requiresBridge (codec is spec-legal in fMP4 but AVPlayer's downstream handling rejects it).
Reproduction
- Load a source whose audio stream is MP3 (e.g. MP3 audio in an
.mov container).
- Engine routes through the native HLS-fMP4 path.
- Log line appears:
[HLSVideoEngine] audio: codec=mp3 → stream-copy as \mp4a.40.34``.
- AVPlayer fails on first segment with
-11829 / -12848 within a few hundred ms.
Fix
Add .mp3 to AudioCodecCompat.requiresBridge, alongside .opus. MP3 then routes through the FLAC bridge (decode → S16 PCM → FLAC re-encode), emitting an fLaC audio track AVPlayer handles cleanly.
Diff and message in this branch (combined with #5):
https://github.com/hp561/AetherEngine/tree/aetherctl-tvos-fix
Specifically:
hp561@fd4e431
Trade-off: MP3 sources lose their stream-copy zero-overhead path, but bridge cost on a lossy mono/stereo source is negligible compared to TrueHD/DTS where the bridge is already engaged.
Verification
Tested on a real MP3-in-mov source via the tvOS 26 simulator (Apple TV 4K 3rd gen runtime). Pre-fix: -11829 within ~200ms. Post-fix: audio: codec=mp3 (bridge required), AVPlayer reaches readyToPlay and timeControlStatus=playing, segments serve cleanly via the local HLS server.
Happy to open a PR.
Summary
AudioCodecCompat.mp3is classified as fMP4-legal stream-copy atHLSVideoEngine.swift:81(and emitted asmp4a.40.34perhlsCodecsString). AVPlayer reads themp4asample entry as AAC and fails to decode the MP3 frames, returning:This mirrors the documented Opus behaviour already handled in
requiresBridge(codec is spec-legal in fMP4 but AVPlayer's downstream handling rejects it).Reproduction
.movcontainer).[HLSVideoEngine] audio: codec=mp3 → stream-copy as \mp4a.40.34``.-11829 / -12848within a few hundred ms.Fix
Add
.mp3toAudioCodecCompat.requiresBridge, alongside.opus. MP3 then routes through the FLAC bridge (decode → S16 PCM → FLAC re-encode), emitting anfLaCaudio track AVPlayer handles cleanly.Diff and message in this branch (combined with #5):
https://github.com/hp561/AetherEngine/tree/aetherctl-tvos-fix
Specifically:
hp561@fd4e431
Trade-off: MP3 sources lose their stream-copy zero-overhead path, but bridge cost on a lossy mono/stereo source is negligible compared to TrueHD/DTS where the bridge is already engaged.
Verification
Tested on a real MP3-in-mov source via the tvOS 26 simulator (Apple TV 4K 3rd gen runtime). Pre-fix:
-11829within ~200ms. Post-fix:audio: codec=mp3 (bridge required), AVPlayer reachesreadyToPlayandtimeControlStatus=playing, segments serve cleanly via the local HLS server.Happy to open a PR.