Predict PhyFPS (Batch Details)

Predict PhyFPS (Batch Details) is the sibling of the plain Predict PhyFPS node, and it answers the question the average hides: is the whole clip one consistent speed, or is motion all over the place? Same inputs, same sliding-window math, same model - the only real difference is what comes out. Instead of just a single average and a formatted table, you also get the per-segment FPS values as an actual list you can do something with.

That's worth having when you're analyzing a video rather than just eyeballing one number. Say you're checking whether footage is AI-generated or interpolated: real footage might dip and rise in apparent motion across scenes, while a synthetic clip tends to sit at a fairly flat value. Or you're evaluating a frame-interpolation pass - a segment that collapses to near-zero PhyFPS is a strong hint that segment lost its motion. For those, a single average is a lie in one number; the list shows you where the lie lives.

How it works

Identical engine to Predict PhyFPS: overlapping clips slide across your frame batch, each clip is resized to 216×216, normalized to [-1, 1], encoded by the Visual Chronometer's video VAE, attention-pooled, and regressed to a log-FPS that gets exponentiated back. The difference is in the return. The non-batch node builds a formatted ASCII table and discards the raw per-segment values; this one keeps them, rounds each to one decimal, and hands them over as a list.

Inputs (same as the regular node)

• model (VC_MODEL) - from Load Visual Chronometer.
• images (IMAGE) - sequential video frames, e.g. the IMAGE output of Load Video (Upload) from VideoHelperSuite. Auto-resized internally.
• clip_length (default 30) - frames per clip; the model trained on 30. Lower = faster but less accurate. Range 2–120.
• stride (default 4) - step between clips. Lower = more overlapping clips = smoother average, slower run. Range 1–30.

The only setting that really changes behavior here is clip_length and stride, and they change how many segments you get back - more segments means a finer picture of FPS variation but a longer queue time.

Outputs

• avg_phyfps (FLOAT) - the mean across segments, identical to what the plain node calls phyfps.
• segment_fps_list (FLOAT, list) - one predicted FPS per clip, in order. This is the new toy. Wire it to anything that consumes a FLOAT list, or just read the report.
• report (STRING) - a compact summary: the per-segment values, the average, and segment count with the clip/stride settings. Slap it on a Preview as Text / PreviewAny node and you've got your readout.

Install

Same pack, one install for all three nodes:

cd ComfyUI/custom_nodes
git clone https://github.com/akashzeno/ComfyUI-PulseOfMotion.git
cd ComfyUI-PulseOfMotion
pip install -r requirements.txt

ComfyUI-Manager search for "Pulse of Motion" may or may not find it (a known quirk - community members have hit "node manager can't find the nodes" and had to install from GitHub). Restart after installing; the checkpoint auto-downloads to ComfyUI/models/pulse_of_motion/ on first run.

Gotchas

• The overestimate caveat applies here too - the community consensus is that this model tends to predict PhyFPS high, so a video played back at the suggested speed can look comically fast. The list output actually helps here: if every segment is inflated uniformly, scale it down; if it's one segment spiking, you've found your problem child.
• If you only want a single number, you don't need the list output - use the plain Predict PhyFPS node. Reach for this one when you care about variation, which is the entire point of it.
• Same "not enough frames" guard: the batch needs at least clip_length frames in the images batch, or it raises.

In short: plain Predict PhyFPS for the headline number, Batch Details when you want to know whether that number is actually true everywhere in the clip. For a beginner, run the plain one first - and come back here when a result looks suspicious.