MiniH3 Magic (Frame Adjuster)
H3 won't accept your frame count — this pads it to the grid for you
- images
- audio
- adjusted_images
- adjusted_audio
- final_frame_count
- frames_added
- duration_seconds
Every open video model has its own frame-count superstition. Wan wants 4×+1. MiniMax H3 wants something weirder: (n*17)+5. If your clip isn't exactly 5, 22, 39, 56, 73 frames and so on, H3 errors out or silently misbehaves. MiniH3 Magic (Frame Adjuster) is the node that saves you from doing that arithmetic: it rounds your frame count up to the next valid H3 number by appending gray frames, so your clip is always legal before it hits the sampler.
Why gray frames? Because H3 pads up to 16 frames (about 0.67 seconds at 24fps) - gray is the neutral filler that keeps the extra frames inert. The README's advice is worth quoting: trim back to your original frame count after generation, because you don't want the padding in the final render.
Inputs
- images - your video frame batch. That's the only required input.
- audio - optional. If you connect an AUDIO track, it gets padded with trailing silence (or trimmed) so its duration matches the adjusted clip length at H3's native 24 fps. Nice touch - it keeps audio and video in lockstep through the padding, which is exactly where sync drifts happen.
Outputs
- adjusted_images - original frames plus the appended gray padding.
- adjusted_audio - the audio, matched to the new length (None if you didn't connect audio).
- final_frame_count - the padded total, always
(n*17)+5. - frames_added - how many gray frames went in. 0 means your input was already valid.
- duration_seconds - adjusted length at 24fps, rounded to the nearest whole second. Handy for a duration-based prompt or a video-combine node.
Install
Part of TrentNodes:
cd ComfyUI/custom_nodes
git clone https://github.com/TrentHunter82/TrentNodes.git
cd TrentNodes
pip install -r requirements.txt
Restart, look under Trent/Utilities. Pure tensor math - no models.
Where people get burned
The classic mistake is feeding the padded frames into your video combiner and shipping the gray tail. The node can't know you're done with them - trim back to your original count after sampling, or let the pack's frame-range utilities cut them. Also remember it only pads up: a 23-frame clip becomes 39, not 22. If you're on a tight VRAM budget, that 16-frame jump to the next valid count is real generation you're paying for; you can trim input to a legal count first if you want the minimum. And the gray fill is 0.5 neutral gray, not black - if you were expecting black bars, adjust downstream. Finally, H3's frame grid only matters for the local weights/API path; if you're calling a hosted H3 endpoint that abstracts the grid, you may not need this at all.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | Video frames to pad. Gray frames are appended until the count hits the next (n*17)+5 value. | |
| audioopt | AUDIO | Optional audio track. Padded with trailing silence (or trimmed) to match the adjusted clip length at 24 fps. |
Outputs (5)
| Name | Type | Description |
|---|---|---|
| adjusted_images | IMAGE | Original frames plus appended gray padding frames. |
| adjusted_audio | AUDIO | Audio padded/trimmed to the adjusted clip length (None if no audio was connected). |
| final_frame_count | INT | Total frame count after padding — always of the form (n*17)+5. |
| frames_added | INT | Number of gray frames that were appended (0 if the input count was already valid). |
| duration_seconds | INT | Adjusted clip duration at 24 fps, rounded to the nearest whole second. |