The client's broadcast encoder emits open-GOP I-frames at scene cuts: I-slices that are not IDRs and carry no SPS/PPS, right after an IDR. h264parse flags every I-slice as a keyframe, mp4mux writes it as a sync sample, and the muxl segmenter cut a new signed segment there — one no decoder can start on. Downstream, that one segment a minute took everything with it: the transcoder's orchestrator failed it ("non- existing PPS 0 referenced", "Invalid data found when processing input"), the gateway's session cleanup panicked and left the manifest in "No sessions available" until the manifest rotated; the packetizer found no valid frame in it, so it was never published to the bus and syndicating nodes never received it; and an HLS fragment could start on it. A pad probe after h264parse on both ingest paths (MP4 from Mist, WHIP) now clears the keyframe flag on any access unit without an IDR slice, so such frames stay inside the GoP of the IDR before them (streamplace_ingest_non_idr_keyframes_total counts them). Regression test: x264 open-GOP input, every signed segment must start on an IDR (8 of 9 did not before). And the transcoder push refuses any TS without SPS, PPS and an IDR (ErrNoKeyframe, streamplace_transcode_skipped_no_keyframe_total) so no other source of such a segment can drop the orchestrator session again. Reproduced offline on the client's recording: 41 of 653 pushed segments had no IDR, every one a segment starting right after a one-frame IDR segment Claude-Session: https://claude.ai/code/session_014aPQ5yqG9QFxKnbwQfCYKa (cherry picked from commit f0c4f31356d98c8f527020b806772b01e01e96ec)