mono MP3 → E-AC-3 bridge: the first-segment prime scan never gets an encoded audio packet, muxerFailed at every start position including 0.00s

[kskchaitanya1993]

Summary

A plain SD MKV with mono MP3 audio cannot be played on the native route at all. The mp3 → E-AC-3 bridge is selected, the first segment cut is deferred because no audio sample entry can be built, the forward prime scan does not find one, the pump exits muxerFailed, both rebuilds fail identically, the revive cap is reached and the session ends with:

Source audio cannot be muxed (code -22)

Reproduced nine times out of nine, at nine different start positions including 0.00s, on the same file. The software route plays the same file perfectly.

This looks distinct from the three neighbours, and I have tried to rule each out below rather than assume:

• EAC3 first segment with no audio wedges the muxer: cutFragmentForNextSegment lacks the moov guard flushPendingFragment has #222 — its guard is present and doing its job here. The log line is literally AE#222 … cut deferred … scanning forward for a prime frame, i.e. the muxer is correctly declining to write a moov. What fails is the scan that follows.
• muxerFailed / permanent black screen: first-segment audio prime scan gives up when the selected audio track is sparsely interleaved (UHD remux) #366 — there the selected source track was sparsely interleaved and physically far away (Czech AC-3 in a 61.8 GB UHD remux). Here the source audio is 9 ms from the first video packet (audio gate open: actual=9 target=0 … gapMs=0.0), so the source packet is not what is missing. The 6.25.x midpoint-seeking scan is in this build.
• VOD start at resume position with bridged audio (mp3→EAC3) never becomes ready; recovery re-anchor kills the muxer ("Cannot write moov atom before EAC3 packets parsed") with no escalation (#93 residual) #99 — that was bridged mp3→EAC3 at a non-zero startPosition, arriving via the seek/re-anchor path. This reproduces identically from 0.00s with no seek at all.

Environment

• AetherEngine 6.27.1
• iPad mini (6th generation), iOS 26.5 (23F77)
• Host: our Flutter app, own video_player backend; AetherEngine as rung 1, libVLC as rung 2
• Route: native / loopback (canHardwareDecode codec=27 640x272 -> true)

Source media (ffprobe)

Matroska over HTTP from an Xtream-style IPTV origin, 358,378,434 B. Absolute byte ranges are
honoured (206); the origin does not honour suffix ranges, which the engine notices once
and stops asking for — pump tail prefetch rejected after 1676ms: Content-Range: bytes -65536/358378434 does not describe the 65536B asked for; not asking this origin again this session. Mentioning it only to be complete: it is the same on every run, including the ones
where the software route plays the file to the end.

0  h264     video  640x272  High/L2.1  yuv420p  23.976 fps  tel  (default)
1  mp3      audio  mono  44100 Hz   40 kb/s   tel  (default)   <- selected
2  mp3      audio  mono  24000 Hz   32 kb/s   tam
3  mp3      audio  mono  24000 Hz   32 kb/s   hin
4  subrip   sub                               eng  (default)
duration 7070.189s, overall bitrate ~405 kb/s

What the engine does

[AetherEngine] dispatch: codec=27 → native
[HLSVideoEngine] video codecpar: codec=27 640x272 profile=100 level=21 fieldOrder=1 extradata=44B head=01640015ffe1001c
[HLSVideoEngine] segment plan: keyframe-aligned, 2152 IRAPs → 1690 segments [firstKeyframePts=0 (0.000s) videoStream.start_time=0 format.start_time=0us plan[0].startSeconds=0.000]
[HLSVideoEngine] audio: codec=mp3 (bridge required), decoding + EAC3 re-encode
[AudioBridge] init: mode=surroundCompat srcCodec=86017 sampleRate=44100 sourceChannels=1 encoderChannels=1 bitRate=128 kbps (source=container, container=1, decoder=1)
[HLSSegmentProducer] init OK (baseIndex=0, segments=1674, targetDur=4.000s, srcVideoTb=1/1000) audio=bridge inTb=1/44100
[HLSVideoEngine] prepared: codec=avc1.640015,ec-3 resolution=640x272 fps=23.976 range=SDR DV=none segments=1674 duration=7070.2s
[AetherEngine] #321: effective video route = loopback

The failure, from 0.00s

[HLSSegmentProducer] video gate open: actual=0 anchorPts=0 target=-9223372036854775808 desired=0 shift=0 videoPID=0 reconstructed=false
[HLSSegmentProducer] first video pkt: dts=0 pts=0 duration=41 size=1060 (fallback=41 in srcVideoTb)
[HLSSegmentProducer] audio gate open: actual=9 target=0 desired=0 shift=0 gapMs=0.0
[HLSSegmentProducer] #65 ledger seg-0 base=0 itemAxis=0.000s sourceStart=0.000s planSource=0.000s drift=0.000s shift=0.000s
[HLSSegmentProducer] #65 ledger seg-1 base=0 itemAxis=20.771s sourceStart=20.771s planSource=10.427s drift=10.344s shift=0.000s
[HLSSegmentProducer] AE#222 seg-0.m4s cut deferred: audio sample entry needs a parsed packet and none has been muxed; scanning forward for a prime frame
[HLSSegmentProducer] pump finished: reason=muxerFailed packetsRead=1308 packetsWritten=500 lastError=0 elapsed=526ms cacheCount=0
[HLSVideoEngine] #99 VOD pump died with muxerFailed; rebuilding producer + muxer at 0.00s -> seg0 (attempt 1/2)
… identical, elapsed=19ms …
[HLSVideoEngine] #99 VOD pump died with muxerFailed; rebuilding producer + muxer at 0.00s -> seg0 (attempt 2/2)
… identical, elapsed=15ms …
[HLSVideoEngine] #99 VOD muxerFailed revive cap reached (3 failures, cap 2); giving up (source not muxable in this session)

Two things stand out to us, offered as observation rather than diagnosis:

1. The source audio is right there. gapMs=0.0, first audio packet at 9 ms. Whatever is missing is downstream of the demuxer — the bridge's encoded E-AC-3 output, not a source packet.
2. The scan does travel. seg-1 lands at sourceStart=20.771s against planSource=10.427s, a 10.3 s drift, so roughly twenty seconds of media went by without an audio sample entry ever being available.

Every attempt, same file

Nine sessions, nine start positions, nine identical outcomes. packetsWritten/packetsRead is 0.37–0.38 throughout.

startPosition	anchor seg	packetsRead	packetsWritten	first attempt
0.00 s	seg-0	1308	500	526 ms
2214.00 s	seg-545	584	221	400 ms
2483.00 s	seg-611	602	228	763 ms
2932.00 s	seg-720	1025	389	447 ms
3331.00 s	seg-809	811	305	487 ms
5295.00 s	seg-1306	713	270	650 ms
5658.00 s	seg-1398	589	222	496 ms
5867.00 s	seg-1451	414	155	489 ms
5908.00 s	seg-1460	494	185	429 ms

Both rebuilds always read exactly the same packet counts as the first attempt and fail in 12–23 ms, so as in #222 the retry re-enters the same configuration rather than changing the decision that caused the failure.

Two things we checked so you don't have to

• The software route plays this file completely. Same URL, same 6.27.1, on the iOS simulator, which has no VideoToolbox decoder — codec=27 not hardware-decodable by VideoToolbox; routing to the software path so it plays instead of a black screen (#2): 683 frames in 30 s, route=software, all three audio tracks named and selectable, subtitle selection works. So demux and decode of this file are fine; the failure is confined to the loopback muxer path.
• Mono 44.1 kHz E-AC-3 into fragmented MP4 is not inherently impossible. Standalone, ffmpeg -f lavfi -i sine=…:sample_rate=44100 -ac 1 -c:a eac3 -b:a 128k -movflags +empty_moov+default_base_moof+frag_keyframe+delay_moov -f mp4 produces a valid eac3 / 44100 / 1ch track. We are not claiming that is the same code path — only that the encoder configuration AudioBridge reports is one ffmpeg will accept.

Impact for us

Low, and we are not blocked: our ladder demotes to libVLC and the viewer gets a picture. We are reporting it because mono MP3 in MKV is ordinary IPTV catalogue material rather than an exotic shape, and because a source the software route plays end to end is worth having on the native route too.

Happy to run any diagnostic build against this file, or to try a synthetic reproduction if you would like one — a three-track mono-MP3 MKV should be straightforward to generate.

---

🤖 Written and posted by Claude Code on behalf of @ksktech-dev.

[superuser404notfound]

Thanks for this, and for ruling out #222, #366 and #99 before filing. All three checks were the right ones and all three answers hold up, which saved a wrong start.

Reproduced 1:1

Fixture: a mono MP3 44.1 kHz MKV whose audio payloads the decoder cannot make a frame of. The session comes out line for line the same, including the two rebuilds finishing in 2 to 3 ms with identical packet counts and the terminal Source audio cannot be muxed (code -22).

Observation 1 was exactly right, and it is the entire failure

What is missing is the bridge's encoded output, not a source packet. FFmpeg's mp4 muxer can only build an AC-3/E-AC-3 sample entry from a packet it has PARSED, and on a bridged source those packets come from the bridge's encoder. It emitted none for the whole of segment 0. Everything after that follows mechanically: the cut defers (the #222 guard doing its job), the pump exits muxerFailed, the revive cap ends the session, and the sentence that reaches the viewer names the muxer and the source, which are the two subsystems that were fine.

Observation 2 needs one correction, because it points somewhere else

The scan did not travel. scanForAudioMoovPrimeFrame is scoped to single-demuxer stream-copy audio and returns without looking on a bridged session: there is nothing in the source to scan for, since the frames the muxer needs come out of the encoder. The line promising a forward scan was printed unconditionally, so it announced an action that never happened, on the one path where the interesting question had no log line at all. That is fixed.

The seg-1 ledger line is not the scan either. It is the video cutter reaching plan index 1, which is what REQUESTS the segment-0 cut. So the 10.3 s gap between planSource and the actual keyframe is a separate property of that file (the plan's boundaries come from the container index, the cutter waits for a real IRAP) and is unrelated to the audio. What the two lines together do establish is your conclusion: about 20.8 s of media went by with no audio sample entry ever becoming available.

A synthetic reproduction would not help, though thanks for offering

I built the three-track mono-MP3 MKV first. It plays. Mono 44.1 kHz MP3 through the surroundCompat bridge produces a valid ec-3 / 44100 / 1 ch track on the native route, both with a 4 s first segment and with a 20.8 s one. So neither mono, nor 44.1 kHz, nor a long first segment is the trigger. Something specific to that file's audio is, and only that file can say what.

What is on main now (9870892c, PR #397)

The reason neither of us can name the failing step from your log is that there is no step to read. Every stage between a source packet and an encoded frame ends in a return or in a loop that stops on a negative code: a packet avcodec_send_packet rejects, while avcodec_receive_frame(...) >= 0 (which reads as "drain what is there" and behaves as "drop the reason there is nothing"), four early returns in the resampler, avcodec_receive_packet breaking on any negative code. Per packet that is right, one bad frame must not end a session. In aggregate it made a bridge that emitted nothing for a whole segment indistinguishable from one that had simply not been asked yet.

• AudioBridge now counts each of those arms and keeps the decoder's own error code instead of discarding it.
• The deferred cut prints that account instead of announcing a scan it does not run.
• Zero decoded frames ends the session immediately. A restart rebuilds the muxer and re-opens the encoder, both downstream of a failing decoder, which is why your three attempts read identically. Frames decoded with nothing emitted is the encoder side, which a rebuild does heal, and keeps its revive.
• New PlaybackErrorKind.audioBridgeProducedNoOutput for the failure, replacing vodSourceFailed. For a ladder that matters: vodSourceFailed reads as "the source is gone" and is a reason to stop, while here the source is neither gone nor unreadable and a second engine that decodes the track itself plays the file. This one is a demote.

It is on main; say the word if a tagged build is easier to vendor and I will cut one.

One discriminator, and it needs no new build at all

Both routes open the mp3 decoder identically: avcodec_parameters_to_context followed by avcodec_open2(ctx, codec, nil), no options, in AudioDecoder and in AudioBridge alike.

So: on the software route, does that file actually produce sound? The report says the three tracks are named and selectable, which is a demuxer statement rather than a decoder one.

• Audible on software: the same decoder made frames out of the same bytes, so the failing arm sits downstream of the decode inside the bridge, and the counters will say which.
• Silent on software: the audio in that MKV is not decodable by this libavcodec build, which for an Xtream-style remux usually means a mis-declared track, and the engine's remaining job is the one it now does, saying so instead of blaming the muxer.

With the build, one line settles it, either at the deferred cut or as [AudioBridge] ERROR: AE#396 ..., in this shape:

fed=795 decoded=0 enqueued=0 emitted=0 rejected=795 lastDecodeError=Invalid data found when processing input (-1094995529)

decoded=0 is a decoder verdict. decoded>0 emitted=0 is the encoder. Frames decoded with enqueued=0 is the resampler.

Leaving this open: the change makes the failure legible and stops it costing three attempts, it does not yet make that file play. That needs the arm named.

[superuser404notfound]

Tagged: 6.31.0, so this can be vendored as a pin rather than off main.

.package(url: "https://github.com/superuser404notfound/AetherEngine", from: "6.31.0")

Minor rather than patch because of the new PlaybackErrorKind.audioBridgeProducedNoOutput; nothing else in the public API moved, and healthy bridged playback is unchanged.

The cheap question still stands ahead of any run: on the software route, does that file actually produce sound, or do the three tracks only list and select?