A production stream kept wedging in the MUXL-ize step: video flowed in on the MKV endpoint but segments stopped coming out mid-stream, with no EOS, until the ingest watchdog killed the worker. Root cause: when a push falls behind, MistServer drops delta frames and the video track degrades to keyframe-only (~1s between video frames) while audio continues normally. The fMP4 muxer feeding the signer is a gst aggregator — it consumes nothing until every sink pad has data — so during a video gap the audio branch must buffer the whole gap while matroskademux walks the byte stream to the next video frame. buildMKVIngestPipeline used bare `queue` elements, whose default max-size-time is 1s: a >=1s video gap fills the audio queue, blocks the demux, starves the muxer's video pad, and deadlocks the graph permanently (confirmed with native thread stacks: fmp4mux:src in gst_aggregator_wait_and_check, queue1:src blocked in gst_aggregator_pad_chain_internal, demux parked on the full queue). Fix: use the shared Queue2Big preset (no time/buffer cap, generous byte cap) on both ingest branches — the same fix the transcode pipeline already carries for its double-GoP variant of this deadlock. Also set sync=false on the muxl appsink (every other appsink in the tree sets it); the default sync=true was clock-pacing the entire ingest graph at realtime for no benefit. With the fix, the full 164s production capture (which goes keyframe-only at ~140s) segments to completion: 171/171 GoPs in ~4s, versus 145 then a watchdog kill before. Fallout handled: the 4-audio sample-stream.mkv "wedge fixture" stopped wedging — its wedge was this same queue-cap deadlock all along — so the watchdog/ban containment tests now synthesize an audio-only MKV instead (the muxer's video pad never sees data or EOS: a true wedge no queue sizing can fix). New TestMKVIngestSparseVideoNoWedge synthesizes the sparse-video shape in-test (no binary fixture) and fails on the unfixed pipeline. Known follow-up (pre-existing, out of scope here): with node transcode keys a long full-speed feed progressively slows the transcode completion path until the watchdog fires, and the worker then hangs in the post-cancel drain (transcoder.Feed blocks on its jobs channel under a context.WithoutCancel ctx, so RunMKVIngestWorker never returns). See the skip note on TestMKVIngestMistFullSample. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>