fix(audio): a silent transcoding bridge names itself instead of dying as a muxer error (#396)

[superuser404notfound]

Closes nothing yet: AE#396 stays open for the reporter's capture. This is the instrumentation and the classification that make their next run answer the question.

What the report is

A plain SD MKV with mono MP3 audio fails on the native route at nine of nine start positions, ending on Source audio cannot be muxed (code -22) after three identical revive attempts of 12 to 23 ms each.

What is actually happening

The muxer is right and innocent. 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, not from the source. The bridge had emitted none, so the first cut deferred (AE#222's guard, doing its job), the pump exited muxerFailed, and the revive cap ended the session.

Reproduced 1:1 on a synthetic fixture (mono MP3 44.1 kHz MKV whose audio payloads were made undecodable): same log lines, same three attempts, same terminal string.

Nothing in the session said any of that. Every step between a source packet and an encoded frame ends in a return or in a loop that stops on a negative code:

• avcodec_send_packet answering invalidData / einval (a deliberate per-packet skip, Blu-ray ISO playback failed, audio bridge.feed failed at pkt #64)
• while avcodec_receive_frame(...) >= 0, which reads "drain what is there" and behaves as "drop the reason there is nothing"
• four early returns in resampleAndPushIntoFIFO
• avcodec_receive_packet breaking on any negative code
• the producer ignoring writePacket's rc on the bridged arm

Per packet all of that is correct: one bad frame must not end a session. In aggregate it made a bridge that emitted nothing for a whole first segment indistinguishable from one that had simply not been asked yet, and the only sentence the session ever produced named the muxer and the source, which are the two subsystems that were fine.

What this changes

• AudioBridge.FeedStats: fed, rejected, decoded, dropped-before-FIFO, enqueued, emitted, decode/encode errors, and the decoder's own last error code instead of discarding it. One loud line the moment enough source has gone in for the silence to be structural rather than start-up latency (64 packets, two orders past the worst-case first output).
• The deferred cut tells the truth on the bridged path. It used to announce "scanning forward for a prime frame" while scanForAudioMoovPrimeFrame returns without looking there (it is scoped to stream-copy audio by design, a bridged session has nothing in the source to scan for). A log line describing an action that never happens, on the one path where the interesting question had no line at all. It now prints the bridge's account.
• Zero decoded frames ends the session at once. A restart rebuilds the muxer and re-opens the encoder, both downstream of a failing decoder, so the revive budget bought the same answer three times. Frames decoded with nothing emitted is the ENCODER side, which a rebuild does heal (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 failure mode B), and keeps its revive.
• PlaybackErrorKind.audioBridgeProducedNoOutput. This used to arrive as .vodSourceFailed, which reads as "the source is gone" and ends a host's fallback ladder. The source is neither gone nor unreadable here, and a second player that decodes the track itself plays the file, so a ladder should DEMOTE on this kind, not stop.

Verification

Fixture A/B with aetherctl play:

• before: three revive attempts, state=error("Source audio cannot be muxed (code -22)"), no mention of audio decoding anywhere in the session
• after: AE#396 seg-0.m4s cut deferred: the audio sample entry is built from a BRIDGED packet and the bridge has muxed none. Bridge: fed=2 decoded=0 enqueued=0 emitted=0 rejected=2 lastDecodeError=Invalid data found when processing input (-1094995529), then state=error("Audio track could not be decoded (code -22)") immediately

Control: the same fixture undamaged plays unchanged (item.audioTrack codec='ec-3' sr=44100 ch=1, no new lines, no early exit). Long-GOP and normal-GOP variants both clean.

Issue396SilentAudioBridgeTests: 4 tests, including a control that a bridge which DID emit keeps the muxer verdict (verified to fail when the branch is made unconditional).

1936 swift-testing + 547 XCTest green, no new warnings.

🤖 Generated with Claude Code

https://claude.ai/code/session_01E5UztmCZtNYPQpzdmSdmWG