basicIn_Media_Params

Most video-model pain in ComfyUI is one of two numbers. Your resolution isn't a size the model likes, or your frame count isn't a count the 3D VAE can compress. basicIn_Media_Params exists so you compute both once, in one node, instead of nudging sliders on five samplers until something stops erroring.

What it does

You give it a mode - one of Hunyuan-Video, Wan2.x, LTX-2, CogVideoX-1.5, MiniMax-H3, Flux2, SDXL - plus an aspect_ratio from a list of eight (1:1 through 21:9), a megapixels budget (0.6 by default), a size_multiple (32 by default, the tooltip's own words: the divisor your width and height get snapped to), and for video modes a time_s and fps. It hands back four things: width, height, length, fps - as INT, INT, INT, FLOAT.

The arithmetic is simple and it's worth knowing because it explains the numbers you get. Width and height come from sqrt(megapixels × 1024² / (ratio_w × ratio_h)), each side snapped to the nearest multiple of size_multiple and floored at one multiple. So 1:1 at 1.0 MP gives you exactly 1024×1024; 1:1 at the 0.6 MP default gives ~800×800; 2:3 at 0.6 MP gives 640×960.

Then length - and this is the part people are really here for. The frame count starts as round(time_s × fps) and is snapped to a temporal rule per mode:

• Hunyuan-Video and Wan2.x → count ≡ 1 (mod 4)
• LTX-2 and CogVideoX-1.5 → count ≡ 1 (mod 8)
• MiniMax-H3 → count ≡ 5 (mod 17)
• Flux2 and SDXL → no rule; you get the raw frame count

So 5 seconds at 24 fps is 120 frames, and the node hands you 121 for Wan or Hunyuan, 121 for LTX-2, and 124 for MiniMax-H3. That's not a rounding bug, that's the node keeping you inside the counts those VAEs accept. If you were expecting the familiar 81, set time_s to about 3.3 at 24 fps and check the live readout.

Why you'd wire it in

Because width, height, length and fps are the exact four values every loader and sampler in the pack wants, and having them come from one place means an aspect-ratio change is one edit rather than four chances to leave a stale 1024 somewhere. The frontend draws a live W × H length:N readout on the node that updates as you change any widget, so you can see the result before you queue anything - and it hides the time_s and fps widgets entirely in the image modes, where they'd only be noise.

The resolution half is worth taking seriously if you're generating stills. The knowledge base's resolution notes are blunt about this: SDXL was trained on a specific set of ratios, and the classic "why does my character have two heads" complaint traces back to generating at a ratio it never saw. At 0.6 MP a 4:3 gives you 896×672, which is fine; at 1:1 you get 800×800, which is smaller than SDXL wants. For SDXL I'd push megapixels to about 1.0 and size_multiple to 64 - 1024² is 1.05 MP, and 64 is the multiple the later architectures expect (Flux wants divisibility by 64 too, per the troubleshooting tables). The 2026 generation of models is more forgiving and degrades softly rather than duplicating anatomy, but the trained-ratio habit is still the right one on anything SDXL-derived.

Installing it

ComfyUI Manager → ComfyUI-Apt_Preset, or:

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

Restart, then find it under Apt_Preset → IO_Port.

Small traps

The aspect-ratio dropdown arrives labelled in Chinese (1:1（正方形）, 16:9（横屏）). That's cosmetic - the pack ships a zh locale - but if a workflow you downloaded from the author's Bilibili has that value baked in, matching it by eye takes a second.

Second: size_multiple defaults to 32 and that's fine for most video work, but if you're feeding SDXL or Flux stills, 64 is the number you want. And third, length is meaningless for the two image modes - the node happily returns round(time_s × fps) there, so don't wire length into anything if you're just making a picture.