Edit Router
Split a video batch at the cut so frame interpolation stops melting your edits
- images
- before_edit
- after_edit
If you've ever run VFI on a video that contains a cut - a scene change, a camera switch, a hard edit - you've seen it: the interpolator walks the frame before the cut into the frame after it, and you get a couple of frames of smeared morphing mush right where the edit was. Frame interpolation (GIMM-VFI, RIFE, whatever) assumes continuous motion between frames; a cut breaks that assumption. Edit Router exists to fix exactly this: it finds the first edit in your frame batch and hands you two clean batches - everything before the cut and everything after - so you can interpolate each side separately and stitch later.
It's a one-trick pack from clayton-grey, and the trick is a single node: CG_EditRouter, display name "Edit Router", tucked under video/analysis. No model downloads, no dependencies beyond torch, no API calls, Apache-2.0. It's the kind of utility that's invisible when it works and indispensable when you hit the problem - which, in any realistic Wan/LTX workflow that touches real footage, you will.
What it does
Feed it an IMAGE batch ([B,H,W,C], straight out of a video loader) and it returns two IMAGE outputs:
- before_edit - every frame before the detected cut
- after_edit - every frame after it, with fade/dissolve frames trimmed out
No edit detected? Then all frames pass through before_edit and after_edit comes back as an empty batch. That pass-through is deliberate - chain it without worrying that an editless clip wipes your batch.
How it actually works
Peek at the source and the mechanism is plain, all torch:
- Convert to luma and downsample the long edge to 256. Small and brightness-based, so a big slow scene change doesn't accidentally score as an edit.
- Score each frame as the mean absolute difference from the previous frame.
- The first frame whose score beats
thresholdis the cut. - Rewind through the fade ramp, then read forward until the signal returns to "normal motion" for
stable_framesframes, and drop everything in between.
That last bit is the smart part. "Normal motion" is computed from a median + MAD baseline of the frame scores - not your threshold - so a genuine hard cut survives intact while short fades and dissolves get trimmed instead of polluting your after_edit batch.
The inputs that matter
Only three, which is refreshing. images is the batch; the two you'll actually tune:
- threshold (FLOAT, default 0.09) - sensitivity. Misses cuts? Drop it toward 0.04–0.05. Fast motion or camera pans keep tripping it? Raise to 0.08–0.12.
- stable_frames (INT, default 3) - how many consecutive "back to normal" frames confirm the transition is done. Nudge to 4–6 for short fades, down to 1–2 if it's eating real post-cut frames.
Wire before_edit and after_edit into separate interpolation branches, then concat the upscaled/interpolated halves back together.
Installing it
Easiest via ComfyUI Manager - search "Edit Router". Or by hand:
cd ComfyUI/custom_nodes
git clone https://github.com/clayton-grey/ComfyUI-EditRouter
Restart ComfyUI and the node appears in video/analysis. That's the whole install: no requirements.txt, nothing to download. This is one of those rare packs you can install without worrying about dependency hell.
Gotchas
Two things will bite you. First, it only detects the first edit in the batch - a multi-cut clip needs splitting into single-cut segments before this node, or you only get the first transition handled. Second, the detection hardcodes a 16 fps assumption (the Wan default). Fine for Wan video at that rate; if you're interpolating footage at a very different frame rate, expect the fade-trimming to be a bit off. Long, slow transitions can also read as "always transitioning" and misbehave.
One curiosity from the source: there's a much fancier EditRouterAdvanced class in there - MAD auto-thresholding, gate ratios, edit-frame indices, an 8-output signature - but it's commented out of the node mappings. It may land later, it may not. For now the three-knob version does the one job well, and for a scene-cut problem that's genuinely all you need.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | — | |
| threshold | FLOAT | 0.090–1 | — |
| stable_frames | INT | 30–81 | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| before_edit | IMAGE | — |
| after_edit | IMAGE | — |