basicIn_Vedio

Worth saying up front, because it's how most people find this node in the search bar: yes, it's spelled "Vedio," not "Video." That's not a typo on our end - it's the literal class name shipped in the pack, a small tell that the README (and presumably a fair chunk of the pack's internals) started life in Chinese and got translated. If you're hunting for it in ComfyUI's node search, search "vedio" as well as "video," or you'll come up empty.

What it does

Four required fields - width (default 512), height (default 512), length (default 16, the frame count), and frame_rate (default 24) - and four matching outputs, the same values passed straight through as INT. That's it. It doesn't generate a video, load one, or produce a latent; it's a value-holder, the same "set it once, wire it everywhere" primitive pattern as the rest of this pack's IO_Port family, specialized for the four numbers that basically every video generation node in ComfyUI needs.

Why bundle these four together

Because they travel together in practice. A video-generation graph typically needs width, height, frame count, and frame rate fed into several different places - an empty video latent, a video-length calculation, an export/save step - and they need to agree with each other or you get mismatched output. Setting all four once here and fanning them out means changing your target resolution or frame count is a one-node edit instead of a hunt through the graph for every place you typed 512 or 16.

The inputs and outputs that matter

All four inputs matter and none of them has a hidden trick: width/height up to 8192, length up to 9999 frames, frame_rate up to 120. Outputs mirror the inputs one-to-one, same names, same order.

Sensible starting values by use case

The defaults (512×512, 16 frames, 24fps) trace back to AnimateDiff-era conventions rather than anything a current video model expects, so treat them as a starting point to overwrite, not a recommendation. If you're targeting a modern video model, check that model's documented native resolution and frame count first - going well outside a model's trained range tends to produce the same kind of degradation off-resolution image generation does, just harder to spot at a glance across dozens of frames. frame_rate is the field people forget to reconsider most: it only affects playback timing on export, not the generation itself, so getting it "wrong" won't ruin a render, just make the exported clip play back faster or slower than you intended.

Installing it

Search "ComfyUI-Apt_Preset" in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/cardenluo/ComfyUI-Apt_Preset.git

Run install.bat on Windows (pip install -r requirements.txt on Linux/Mac), restart. Nothing to download - it's a value primitive, not a loader.

Common issues

Beyond the naming trap above, the only real thing to watch is length: 16 frames is a fine default for a short AnimateDiff-style clip but nowhere near what most modern video models expect for a usable output, so don't assume the default is meant to be production-ready - treat it as a placeholder to change deliberately, not a recommendation. And because this node produces plain integers, not an actual empty latent, remember it still needs to be paired with whatever your target model's actual latent/video-init node is - this just supplies the numbers that node needs, it doesn't replace it.