KIE • Video Event Analysis
Pixel-change markers, and nothing more
- video
- events_json
- analysis_summary
Read the node description before you get excited: "Detect timecoded visual changes locally. It cannot identify actions or meaning." This node knows when the picture changed. It does not know a door closed, that someone spoke, or that a car arrived. If you want that, you need a vision model - and the pack makes you confirm it by hand, which we'll get to.
What it gives you, cheaply and locally, is a timeline of "something happened at 4.2 seconds." For scoring a video with music or building a sound design brief, that's a genuinely useful first pass. It's free, it runs on the CPU side of ComfyUI, and it never touches your KIE credits.
The mechanism, since it matters here
OpenCV decodes the video and seeks to samples every sample_interval_seconds. Each sample is downscaled to 160×90 and converted to grayscale. The node then takes the mean absolute difference against the previous sample - one number per step - and classifies it:
- difference ≥ 0.30 → a
visual_cut_candidate - difference ≥ 0.07, and at least two seconds since the last activity →
visual_activity - otherwise, nothing worth recording
A start event at 0 seconds is always included, and the event list is capped at 200. Output also reports the true duration_seconds, how many seconds were actually analysed, whether the result is truncated, and a plain-language note that camera movement can resemble a cut.
That last caveat is doing a lot of work, and it's honest. A whip pan or a fast dolly produces the same mean-abs-diff spike as a hard cut, because at 160×90 grayscale it is the same thing. So you get markers, you don't get semantics, and the node says so rather than pretending.
Inputs and outputs
- video - a ComfyUI
VIDEO. Works with KIE generation output, local Wan/LTX renders, or anything loaded through the persistent video loader. - sample_interval_seconds - 0.2 to 5, default 0.5. Halve it for fast-cut material; raise it for slow long takes where you only care about scene boundaries.
- max_seconds - 1 to 3600, default 300. Analysis stops here and sets
truncated, which keeps a one-hour source from turning into a ten-minute wait.
Outputs: events_json - the timeline, ready for KIE • Sound Cue Sheet or KIE • Music Brief from Video - and analysis_summary, a one-line readout like Analyzed 42s of 42s; 6 possible visual changes. Confirm event meaning manually.
The workflow, in order
- Run this node. Get the marker timeline.
- Optionally send the same video through KIE • Sample Video Frames and a vision model, if you want described events rather than pixel changes.
- Watch the video yourself, correct whatever the model said, and pass it through KIE • Review Video Events with
editor_reviewedenabled. - Only those verified events flow into the music and sound-cue nodes.
That gate is the point of the whole subsystem. Pixel changes never become claimed sounds on their own.
Installing it
cd ComfyUI/custom_nodes
git clone https://github.com/felipederosilva/ComfyUI-KIE-Nodes-Next
cd ComfyUI-KIE-Nodes-Next
pip install -r requirements.txt
Here's the one dependency gotcha worth knowing: this node imports OpenCV at runtime, and opencv-python is deliberately not in the pack's requirements.txt (which is just requests, Pillow, numpy, PyYAML). Nearly every ComfyUI install already ships it - it's a core dependency - but if you're on a minimal build and see Video event analysis needs OpenCV in ComfyUI's Python environment, that's your fix:
pip install opencv-python
Restart, then find the node under KIE Next / Studio / Video Analysis. No API key, no credits, no model files.
Where it goes wrong
"Could not decode the connected video for local analysis." The container or codec isn't one OpenCV can open. Remux to MP4/H.264.
"Video frame rate or duration is unavailable." Some webm and streamed files report no frame count. Re-encode with a proper header.
Everything looks like a cut. Lower the sensitivity is not a setting you have - instead raise sample_interval_seconds so you're comparing less similar frames, or accept that a busy handheld shot reads as constant change. Markers are candidates, not conclusions.
No markers on a slow fade. A gradual dissolve may never cross the 0.07 activity threshold between samples. That's a known blind spot of frame differencing, not a bug in your graph.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| video | VIDEO | — | |
| sample_interval_seconds | FLOAT | 0.50.2–5 | — |
| max_seconds | INT | 3001–3600 | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| events_json | STRING | — |
| analysis_summary | STRING | — |