Difforum · Loop

Looping a generated clip is one of those jobs where the community answer has been "just crossfade it" for three years and everyone who has actually shown a loop on a wall knows that's a patch. A dissolve between two frames that were never going to meet is visible on the second cycle, and by the twentieth it's the only thing you can see. If you already read how the Vid2Vid/VACE world handles this in ComfyUI, you'll recognise the complaint: people want a loop that isn't an obvious morph.

Difforum · Loop gives you three methods, and they are three different philosophies rather than three settings.

keep settled lap is the honest one. You render several laps of a looping camera move, and this method throws away everything but the final lap. No blending at all. The idea is that a periodic camera plus a feedback loop settles onto a periodic result after a lap or two, so the last lap is already seamless because it's the point where the system stopped drifting. The node takes cycle_frames - frames per lap, which the pack's Camera node outputs directly - and slices the tail off the batch. If you leave cycle_frames at 0 it treats the whole clip as one cycle, which is only right if you rendered exactly one lap.

flow crossfade is the classic morph, done properly. The last blend_frames frames are faded into the first frames along optical flow, then dropped, so the output is shorter than the input (N minus the overlap, capped internally at a third of the clip) and plays head-to-tail without reversing. It's a patch, but a well-aligned one. Note the dependency: with OpenCV absent the flow estimate is unavailable and the node falls back to a plain crossfade, which is exactly where the ghosting complaints come from.

ping-pong runs forward then backward, endpoints not duplicated, so the clip roughly doubles and the motion reverses at the turn. Great for a turning object, terrible for anything with dialogue or a walking figure.

What comes out

frames is the looped batch. seam_info is a string and it's the reason I'd reach for this node over a generic crossfade: it reports the mean absolute difference between the last frame and the first - the actual seam error, as a number - and when the clip is at least two laps long it also reports lap-to-lap drift. Those two numbers together tell you whether you have a problem at all (seam under ~0.01 reads as clean at playback sizes) and, if you do, whether more laps will fix it or whether the camera path is at fault. If drift is far below the seam error, rendering more laps is wasted time; the residual is coming from the move, not the feedback.

Install

ComfyUI Manager → search Difforum, or clone it into your custom nodes and restart:

cd ComfyUI/custom_nodes
git clone https://github.com/chillithebillis/Difforum.git difforum

The pack's only hard requirement is numpy. For flow crossfade specifically, install OpenCV in the same Python environment ComfyUI runs in (pip install opencv-python) - otherwise you get the blending without the alignment, and the seam numbers will tell you. The authored templates (Templates → Difforum) include a seamless_loop graph that wires a looping Camera, a render and this node together, which is the fastest way to see what "settled" looks like for your model.

Where people get burned

blend_frames at its default of 12 long clips, short loops: on a 24-frame clip the overlap is silently clamped to a third of the batch, so your output is shorter than you planned and the morph is more abrupt than the number suggests. Check the frame count in seam_info before you assume the node did what you asked.

Second: people put this after an Upscale pass. Don't. Loop first, then upscale - otherwise you're flow-warping frames that an ESRGAN model already invented detail into, and the seam gets worse, not better. And the deepest trap is treating flow crossfade as a fix for a bad camera. If the camera drifts on net over the clip, no crossfade will hide it; go back to the camera's loop mode, render three laps, and use keep settled lap.