Live MPEG-TS: DTS-HD audio mislabeled as mp3 → bridge never produces audio, playback stalls after first frame

[Simpendaal]

What happened?

I load a live MPEG-TS channel whose audio PID arrives with an unknown codec at open time; the probe then settles on mp3. The payload is actually DTS-HD (core sync 7F FE 80 01 + extension substream 64 58 20 25). Every packet fails in mp3float with Header missing, the AudioBridge never emits a packet (fed=64 decoded=0 rejected=64), and the session sits in waitingToPlay / stalls after the first frame. The sample rate / channel count the bridge is initialised with changes per run (16000, 32000, 44100 Hz mono, once 48000 stereo), which also points at misdetection. Other players (and KSPlayer after I added byte sniffing on my side) play the same channel with sound. I expected the engine to recognise the real codec, or at least fall back to video-only instead of stalling.

Steps to reproduce

engine.load(url:) on the live .ts stream of this channel (IPTV provider, channel "24/7: Breaking Bad"; I can share the URL privately)
Observe [Demuxer] stream[1] type=audio codec=mp3 0x0 and continuous [mp3float] Header missing
AudioBridge logs AE#396 (no encoded audio), native host stalls

AetherEngine version or commit SHA

7.15.1

Host app

Custom / my own integration

Platform

tvOS

OS version

27

Device / chip

ATV 4K Gen3

Playback path

Native AVPlayer

Source media (for playback bugs)

Source media (for playback bugs) Live MPEG-TS, H.264 High 4.1 1920x1080 23.976, audio PID signalled/probed as mp3 but carrying DTS-HD: core frame 2012 B (48 kHz, 5 ch, 512 samples) + extension 1728 B = 3740 B per frame. First audio bytes: 7f fe 80 01 fc 3c 7d b2 77 00 0d 3b 80 09 ef 7b.

Error codes / log lines

[Demuxer]   stream[1] type=audio codec=mp3 0x0
[HLSVideoEngine] audio: codec=mp3 (bridge required), decoding + FLAC re-encode
[AudioBridge] init: mode=surroundCompat encoder=flac srcCodec=86017 sampleRate=32000 sourceChannels=1 encoderChannels=1 bitRate=VBR (source=container, container=1, decoder=1)
Last message repeated 2178 times: [mp3float @ 0x133880340] [error] Header missing
[AudioBridge] ERROR: AE#396 the bridge has produced no encoded audio at all (mode=surroundCompat, encoder=flac, frame=2304): fed=64 decoded=0 enqueued=0 emitted=0 rejected=64 lastDecodeError=Invalid data found when processing input (-1094995529).
[NativeAVPlayerHost] #1 playbackStalled

Anything else

On the KSPlayer side I fixed this by collecting ~24 KB of the rejected audio payload, looking for a chain of ≥3 valid frames per candidate codec (ADTS, LATM, AC3, E-AC3, MP2, MP3, DTS/DTS-HD where the frame length is the distance to the next core sync), and reopening the decoder with the detected codec plus its parser. Timestamps of the parser-split frames then needed smoothing (±24 ms jitter otherwise). Happy to share the code or a raw audio sample.

[superuser404notfound]

Thanks for the detailed report, the first audio bytes and the frame sizes made this reproducible without the channel.

Reproduced with a DTS 5.1 transport stream whose PMT label was rewritten, played through the engine's live path. Your log lines came back exactly (codec=mp3 0x0, AE#396 with fed=64 decoded=0 rejected=64, first picture then a frozen clock). Two causes, both fixed:

1. The codec probe could not recognise DTS at all (FFmpegBuild 3.6.0, released). When a PID's stream type does not name its codec, libavformat identifies the payload by running the raw demuxers' probes over it. The FFmpeg build this engine ships had the DTS, TrueHD and LATM decoders but not their raw demuxers, so none of the three could ever be confirmed and the lenient mp3 probe named the track instead. That covers an unknown stream type as well as 0x04 and 0x0f. Separately, a PID labelled 0x03 (MPEG-1 audio) is taken at its word upstream with no probe at all, so a DTS PID labelled that way opens as mp3 even on a full FFmpeg; 3.6.0 carries a patch that probes it like 0x04. With 3.6.0 the fixture opens as dts 5.1 in 0.13 s (it took 21 s before) and plays with sound through the E-AC-3 bridge, for 0x03, 0x04 and an unknown type alike.

2. A live stream whose audio decodes to nothing now falls back to video-only. On live, the bridge's FLAC sample entry is built without any decoded audio, so the session kept serving segments with an audio track that never received a sample, and AVPlayer waited on it indefinitely. No error, no reopen. The engine now detects that the bridge decoded nothing, rebuilds the session without that track, and reports audioDelivery == .droppedNoPipeline, so a host can tell the viewer or switch to a server-side transcode. Verified with a stream whose audio payload is undecodable noise: the picture plays on instead of freezing.

Both are merged to main (#643, d681eb26) and not in a release yet; this issue will get a note with the version when it ships. If the channel still misbehaves on that release, the [Demuxer] stream[1] line and the stream type (ffprobe -loglevel debug <url> 2>&1 | grep stream_type) would be the most useful two things to send.

[superuser404notfound]

Released in 7.17.1 (7d2d1f2): FFmpegBuild 3.6.0 for the DTS probe, the live video-only fallback (#643), and the VOD counterpart (#644), where a FLAC-bridged track that decodes nothing now surfaces .audioBridgeProducedNoOutput instead of playing silently. A run against the channel on that release would confirm it.