Video Split Scenes

An edited clip is several shots glued together, and almost every useful per-shot operation needs to know where the seams are: stabilising an edit, reframing one, colour matching one, or just getting an accurate scene count. Video Split Scenes finds every cut and answers each scene as a clip of its own, with its own stretch of the audio - one per output, all of them as a list, and where each starts.

It is the utility node of this video family. Unglamorous, and you will use it constantly.

How it finds cuts

Not a pixel-difference threshold. It measures motion between neighbouring frames and asks what share of the picture still follows from the frame before; a hard cut is a pair where that share collapses. That is why cut_threshold is expressed as a share of the picture (default 0.4), and why the numbers behave the way the tooltip says: 0.4 default, 0.6 finds softer cuts but will also split fast action, 0.2 only hard cuts.

And it does not measure it twice. motion is an optional input that takes a shared flow measurement from Video Motion of this same clip at any size - if your graph is already measuring flow, wire it and this node costs nothing extra.

Outputs, and the 24-slot thing

scene_count is how many scenes were found (1 or more). starts is the first frame of every scene, counting from 0 - [0, 48, 96] in the author's example. That list is what you feed to a per-scene value node when you want something to change shot to shot.

scenes is every scene as a list, so a node after it runs once per scene. That is the output that changes how you build a graph: instead of looping over hardcoded wires, you put the per-scene work downstream of scenes and let ComfyUI execute it per item.

Then scene_1 through scene_24 - individual outputs, one per scene, each with its audio. Those are for when you need to treat a specific shot differently. The slots below your scene count are blocked, so an eight-scene clip leaves sixteen greyed-out sockets that are not errors, just unrouted.

min_scene_frames (default 6) is the guard against nonsense: a scene must hold at least that many frames, so a one-frame flash does not become its own shot. 1 gives you every cut including flashes, 24 is one second at 24 fps.

The panel shows the first frame of every scene, which is a fast way to confirm the split actually landed on the edits and not on a whip pan.

Install

ComfyUI Manager → search WAS Node Suite v3 → install → restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/WASasquatch/was-node-suite-comfyui.git

ComfyUI 0.14.0+ and Python 3.10+. The pack installs nothing - requirements.txt is a lone comment, pip never runs, and v3 removed the outbound requests the v2 nodes used to make. No model weights are needed for this node. First start (and the first after a pull) takes an extra second while it writes config.yaml and compiles.

Practical notes

Fast action is not a cut. This is the classic false positive: a whip pan, a hard camera snap, or a subject crossing frame fast enough that little "still follows" from the previous frame. Raise min_scene_frames and lower cut_threshold if you are getting too many scenes on a single-shot clip.

Feed it a finished edit, not a raw generation. A 5-second H3 clip is usually one scene and the node will correctly tell you so, which is not useful. Its value is in assembled timelines - several generations joined, or someone else's edit.

Downstream benefit is the point. Once scenes are separate, stabilisation, reframing and temporal consistency all stop having to handle cuts themselves. Those nodes do have cut handling built in, but splitting first is cheaper than re-deriving the same information four times, and it makes the graph much easier to reason about.

Audio is per scene. Each output carries its own stretch of the soundtrack, so a per-scene effect does not desync. If you rejoin them later, rejoin the audio in the same order.