ComfyUI-AICoser Video Info
Stop guessing the numbers — see what your video actually gave you
- video_info
- source_fps
- source_frame_count
- source_duration
- source_width
- source_height
- loaded_fps
- loaded_frame_count
- loaded_duration
- loaded_width
- loaded_height
Every video workflow eventually asks the same question: how many frames do I actually have, and at what size? That number decides your latent dimensions, your frame count for the scheduler, whether your batch fits in VRAM. AICoser_VideoInfo is the node that answers it - it takes the metadata blob from the pack's video loader and unpacks it into ten separate, typed numbers you can wire anywhere.
It exists because a video loader in ComfyUI is a black box. You set frame_load_cap, skip_first_frames, force_rate, and a resize, but the graph doesn't tell you what came out the other end. This node makes the loaded state explicit - and, crucially, it separates source (the file as it exists on disk) from loaded (what you actually got after all your slicing and dicing). That distinction is the whole point.
How it works
Mechanically it's nearly nothing: it reads a AICOSER_VIDEOINFO dict and returns the same keys as individual typed outputs. The logic lives upstream, in AICoser_LoadVideoUpload, which builds that dict after frame extraction - source fps/count/dimensions read straight from the file via OpenCV, loaded values computed after force_rate resampling, skipping, and resizing.
The inputs and outputs
One input, ten outputs:
- video_info - feed it the video_info output of AICoser_LoadVideoUpload (not
vhs_video_info; that socket is typed for VideoHelperSuite nodes, this one is typed for AICOSER_VIDEOINFO).
Outputs split into two families:
- source_fps, source_frame_count, source_duration, source_width, source_height - what the file actually is.
- loaded_fps, loaded_frame_count, loaded_duration, loaded_width, loaded_height - what reached the sampler after your settings.
The loaded family is the one that matters for downstream math. loaded_frame_count after a cap is the number you feed a scheduler or a loop; loaded_width/loaded_height tell you the batch size you're about to pay for in VRAM. And because force_rate resampling is integer-based and therefore approximate, checking loaded_fps is the way to discover your actual rate instead of assuming you got what you typed.
Installing it
Same pack, same one-time install as every node in ComfyUI-AICoser-Tools:
cd ComfyUI/custom_nodes
git clone https://github.com/aicoser-sister/ComfyUI-AICoser-Tools
Restart ComfyUI, or grab it via ComfyUI Manager by searching "ComfyUI-AICoser-Tools". No model files, no requirements.txt - though if you haven't run the video loader yet, note it needs opencv-python (see the LoadVideoUpload page for that).
Common issues
- "Video info not loaded" / no numbers - the input socket only accepts the AICOSER_VIDEOINFO type from the pack's own loader. If you're feeding it the
vhs_video_infooutput, the socket won't connect; use the loader'svideo_infooutput instead. - All zeroes - usually means the upstream node didn't get a valid file handle, or the loader failed before metadata was read. Check the loader's console output; the pack prints clear errors like "video could not be opened".
- Loaded numbers don't match your settings - that's not a bug, that's the integer-sampling behavior of
force_rate. If exactness matters, read the loaded values and adjust.
Honest take: it's a plumbing node, not a glamorous one - but "what did I actually load" is a question you'll ask constantly once you start building video workflows, and this is a tidy way to answer it.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| video_info | AICOSER_VIDEOINFO | — |
Outputs (10)
| Name | Type | Description |
|---|---|---|
| source_fps | FLOAT | — |
| source_frame_count | INT | — |
| source_duration | FLOAT | — |
| source_width | INT | — |
| source_height | INT | — |
| loaded_fps | FLOAT | — |
| loaded_frame_count | INT | — |
| loaded_duration | FLOAT | — |
| loaded_width | INT | — |
| loaded_height | INT | — |