Video Info (C2C)

What it is

A one-input, ten-output node that turns a loader's metadata blob into plain sockets. You wire video_info from a Load Video (C2C) node - or any VHS-style loader, since it is the same VHS_VIDEOINFO format the VideoHelperSuite established - and you get fps, frame count, duration, width and height as ordinary float/int sockets you can drive other widgets from.

It is the least glamorous node in this pack and one of the most quietly useful, because "how many frames did I actually load?" is the question that ruins an afternoon when you get it wrong.

Why there are two sets of numbers

This is the whole point. You get source_* and loaded_* - fps, frame count, duration, width, height for each.

source_* is the file: what the clip was before you touched it. loaded_* is what is actually on the wire in your graph, after the loader retimed it (force_rate), skipped frames (skip_first_frames), took every Nth frame (select_every_nth), capped the count (frame_load_cap) and resized it to your custom_width / custom_height. The loader's own pipeline order is probe → retime → trim → stride → cap → format → size, and only the last number in that chain is what the sampler sees.

So when a clip "feels off", compare the two. A 30 fps source that reports loaded_fps = 15 tells you the stride or the forced rate is doing something you forgot about. loaded_width/loaded_height differing from source_ means a resize you did not intend is in the graph.

The ten outputs

source_fps (FLOAT), source_frame_count (INT), source_duration (FLOAT), source_width (INT), source_height (INT), then the same five again as loaded_fps, loaded_frame_count, loaded_duration, loaded_width, loaded_height. Durations are frame count over fps, computed by the pack itself.

What you actually wire them into:

• loaded_fps → a video container or combine node's framerate, so the saved file plays at the speed you meant rather than at whatever the node's default was.
• loaded_frame_count → a batch stride, a step count, a loop bound, or a sanity check before you queue something expensive.
• loaded_width / loaded_height → your tiling nodes, a resize target, an aspect decision.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Code2Collapse/ComfyUI-CustomNodePacks.git

Or ComfyUI Manager → "CustomNodePacks". Restart and check for:

[C2C] CustomNodePacks: 142 nodes loaded (...) - 0 failed

The shared dependencies - installed deliberately rather than by running the requirements file over ComfyUI's torch:

pip list | grep -i "opencv\|scipy\|safetensors"
pip install opencv-python>=4.7.0 scipy>=1.10.0 safetensors>=0.4.0

Video decoding itself comes from the loader, not from this node; if your loader has no decoder the failure shows up there, several nodes upstream.

Where people get burned

• It only reads a metadata blob. There is no IMAGE socket here. You cannot ask a decoded frame batch for its fps - the information was in the loader's return, and if you did not keep that wire, it is gone. Wire the info output from the loader when you build the graph, not when you need it.
• A loader that speaks a different dialect. VHS_VIDEOINFO is a duck-typed dict; a loader that names its keys differently will raise here. In practice that means C2C and VideoHelperSuite loaders work and a bespoke pack's home-grown metadata may not.
• loaded_frame_count is not what comes out of a VAE. If you are encoding for a video model, the latent frame rule bites: Wan and friends keep 4n+1 frames, so ten, eleven or twelve frames in can come out as nine. The loader told you the truth; the encoder is allowed to trim.
• The model's own window is the other limit. A video model's native context is around 81 frames - about five seconds at 16fps - and that is a genuine constraint of the field, not a setting you can raise. Comparing loaded_frame_count against that number before you queue is a good habit; longer clips need chunking, and chunk boundaries are where identity drift lives.
• Duration is arithmetic, not a probe. It is frame count divided by fps, so if a weird container reports an odd rate, expect an odd duration.
• Resizing does not change the count. A resize in the loader moves loaded_width/loaded_height and nothing else, which is exactly why looking at the numbers beats eyeballing the preview.