Skip to content

HLSVideoEngine: MP3 stream-copy emits mp4a.40.34, AVPlayer fails with -11829 #6

@hp561

Description

@hp561

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

  1. Load a source whose audio stream is MP3 (e.g. MP3 audio in an .mov container).
  2. Engine routes through the native HLS-fMP4 path.
  3. Log line appears: [HLSVideoEngine] audio: codec=mp3 → stream-copy as \mp4a.40.34``.
  4. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions