Load Visual Chronometer (Pulse of Motion)
It downloads its own model so you don't have to
- model
This is the unglamorous first step of the Pulse of Motion pack: load the Visual Chronometer model once, and the other two nodes (Predict PhyFPS and its batch variant) do the actual work. But the loader has one genuinely nice trick - you don't have to go hunting for weights. The first time you run it, it pulls the checkpoint off HuggingFace automatically and drops it into ComfyUI/models/pulse_of_motion/. No wget, no "download from Google Drive," no digging through a HuggingFace repo. Just click and let it grab ~one file while you make coffee.
What it's loading, briefly: Visual Chronometer is the model behind the Pulse of Motion paper, which tries to measure a video's Physical FPS (PhyFPS) - the true temporal resolution implied by its visual motion, independent of whatever frame rate the file's container claims. That's useful for spotting AI-generated or frame-interpolated footage and for judging how "natural" a clip's speed is. The model itself is a 2+1D video autoencoder whose latent features get pooled through a cross-attention layer with a learned probe token, ending in a tiny MLP that regresses the log-FPS. You don't need to know any of that to use it, but it's why the node feels heavier than a typical loader - it's not just a weights pass-through, it constructs the whole predictor architecture around the checkpoint.
The two inputs
Only two, and you can usually leave both alone:
- model_name - an enum that currently offers exactly one choice,
vc_common_10_60fps.ckpt. If it's not inComfyUI/models/pulse_of_motion/, the node auto-downloads it from HuggingFace. The dropdown is dynamic too: drop your own.ckpt,.pt,.pth, or.safetensorsinto that folder and it appears as an option. - device -
auto(ComfyUI's default device, almost always your main GPU) orcpufor when you're tight on VRAM. On a machine with multiple GPUs you'll also getcuda:0,cuda:1, etc. as options.
One subtlety worth knowing: even on GPU, this model is forced to float32. The source deliberately bumps the dtype up because "the model needs float32 for stable inference." So it'll use more VRAM than a half-precision loader, and cpu mode will be slow - but the weights are small enough that it's rarely a problem.
Output
- model (
VC_MODEL) - feed this into themodelinput of Predict PhyFPS or Predict PhyFPS (Batch). Nothing else uses it.
Installing it
The pack is three nodes in one repo, so installing LoadVisualChronometer means installing ComfyUI-PulseOfMotion. The README suggests ComfyUI-Manager: search for "Pulse of Motion" and hit Install. Heads-up from the community: Manager doesn't always find this one in its registry, so the reliable path is manual:
cd ComfyUI/custom_nodes
git clone https://github.com/akashzeno/ComfyUI-PulseOfMotion.git
cd ComfyUI-PulseOfMotion
pip install -r requirements.txt
Restart ComfyUI. Dependencies are light - just einops and huggingface_hub - no heavy CUDA build.
Gotchas
- If
huggingface_hubis missing, the loader stops with a clear error telling you topip install huggingface_hub. Install the requirements first and you'll never see it. - First load is slow - it's downloading the checkpoint, and it prints progress in your console. Subsequent loads are fast.
- A CPU-only run of the whole pipeline is technically possible but sluggish. If you're just trying the pack, keep
deviceonautoand let the GPU do the heavy lifting.
The one trap: don't expect this node to do anything on its own. It outputs a VC_MODEL and sits there. The payoff is entirely in what you do with Predict PhyFPS next.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| model_name | COMBO | vc_common_10_60fps.ckpt | Visual Chronometer checkpoint file. Auto-downloads from HuggingFace if not found locally. |
| device | COMBO | auto | Device to load the model on. 'auto' uses ComfyUI's default (usually GPU). Use 'cpu' to free up VRAM for other models. |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| model | VC_MODEL | — |