Control Crossfade (Iteration Fix)

If you've ever run an iterative video workflow, you know the "flash": a visible brightness pop at the exact moment one generated segment hands over to the next. It happens because the control frames - the ones steering the generation - jump from one segment's tail straight into the next segment's head, and the model reacts to the discontinuity. ControlCrossfadeIterationFix removes the jump by cross-fading the start frames into the control frames, so the control signal changes smoothly instead of snapping.

The source's framing is honest about the target: it was built for the flash in iterative Wan 2.1 SkyReels-style workflows, but the fix is generic to any iteration-boundary flash.

How it works

Required inputs:

• start_frames - the overlapping tail from the previous iteration.
• control_frames - the control video for the current iteration.

Then the blending controls, which read like a real compositor's toolkit:

• num_start_frames - the frame index where control fully takes over (the blend target). Default 14.
• blend_length - how many frames the fade spans, ending right before num_start_frames. Default 8.
• blend_curve - linear, ease_in_out, ease_in, or ease_out, for the fade shape. ease_in_out is usually the least noticeable.
• color_match - matches the control frames' brightness/color to the start frames at the transition, which handles the "brighter control footage than generated footage" case that pure alpha blending can't.

Optional: mask - if you only want the fade to apply to part of the frame (say, keep the background solid), pass a mask. The node also outputs a blended_mask that follows the same zones: black where start frames are pure, the mask where control takes over, and a fade in between.

The zone layout (0-indexed) is worth knowing because it's the whole design: frames before the blend are pure start_frames, the blend spans the cross-fade, and from num_start_frames onward it's pure control. On iteration 0, with no previous chunk to fade from, start frames are injected directly with no fade.

Where it fits

Between your start-frame source and the ControlNet / control input of the current iteration. Put it in the control path, not the image path - it's smoothing the steering, and the sampler still generates. Pair with the pack's FrameAccumulator and the Boundary Frame nodes for a full seam-free iterative pipeline.

Installing it

Part of Mickmumpitz-Nodes:

cd ComfyUI/custom_nodes
git clone https://github.com/mickmumpitz/ComfyUI-Mickmumpitz-Nodes.git

or ComfyUI Manager → search "Mickmumpitz" → install → restart. No downloads; the pack's dependencies are just numpy, Pillow and opencv-python.

Troubleshooting

• Still flashing - check num_start_frames and blend_length against your actual overlap. If your workflow carries 4 start frames but the node fades over 8, the math never matches the footage.
• Fade too short to see - blend_length spans frames before num_start_frames; if it's larger than the number of start frames you actually have, you'll get a partial fade. Keep it ≤ your start-frame count.
• Color shift at the seam - toggle color_match off and on. When it helps, leave it on; when the control and start footage have genuinely different content in the overlap, it can fight you.
• "Why did iteration 0 look different?" - no previous chunk to fade from, so iteration 0 is injected directly. That's by design.