MiniMax H3 Video Timing

MiniMax H3 generates picture and sound in one pass. That's its selling point - a 33B omni-modal model that emits a 4–15 second clip with native stereo audio instead of bolting a foley pass onto a silent generator. The annoyance is what comes out the other end: an IMAGE batch of frames and an AUDIO tensor, with no shared length guarantee, and the frame count sitting on H3's 17k+5 latent grid rather than on the round number of seconds you asked for.

HenjiccH3VideoOutput - MiniMax H3 Video Timing, category Henjicc/Video - is the last twenty centimetres of that pipeline. Three inputs, one VIDEO output, and all it does is make the two streams agree.

The mechanism, which is short

duration is quantised in 1/24-second steps (the widget's step is the frame duration). The node computes count = round(duration * 24), then checks two things: your images batch has at least count frames, and your audio has at least round(count / 24 * sample_rate) samples. If either comes up short you get "Not enough generated frames" / "Not enough generated audio" pointing at your duration wiring.

Passes both, it slices frames to count, slices the waveform to the exact sample count, and hands both to comfy_api.latest's VideoFromComponents with frame_rate=Fraction(24). The output is a proper VIDEO object - not an IMAGE batch, not a file - so it feeds native video preview/save nodes or anything else on the V3 video API.

Notably it does not pad short inputs, does not loop the last frame, and does not stretch audio. It trims. That's the correct instinct: H3's padding frames are the tail of the stack, and stretching audio to cover them would put your dialogue out of sync with your mouth.

What you set

Just duration (0.0417 to 15 seconds - one frame minimum, 24 frames per second of step). Everything else is wired: images from the VAE decode of your H3 sample, audio from the audio VAE decode.

The trap is that duration should be the duration the conditioning node actually produced, not the number you typed there. If you're driving H3 through HenjiccH3RoleInputs or HenjiccMiniMaxMedia, those nodes emit an authoritative duration - the role-input node in particular reports the real measured length in seconds, which may not equal your requested integer. Wire that into this node and the trim lands correctly. Type 5 by hand against a 4.71-second generation and you'll spend ten minutes wondering why the run fails.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/henjicc/ComfyUI-Henjicc.git ComfyUI-Henjicc
python -m pip install aiohttp av numpy Pillow

Or Manager → search comfyui-henjicc. Restart and refresh. The pack ships no models; H3 weights, text encoder, video VAE and audio VAE all come from your existing H3 setup, and the VIDEO output path relies on comfy_api.latest, so you need a current ComfyUI rather than a museum build.

Where it goes wrong

Duration mismatches are the whole failure list. Both errors this node raises are length errors, and both mean the same thing: the number in the box isn't the number that got generated. Fix it upstream, not here.

24 fps is not a setting. It's baked in - H3 is a 24 fps model and the node sets Fraction(24) explicitly. If you were hoping to reinterpret a 30 fps generation, this isn't the node for it.

It doesn't master your audio. No loudness normalisation, no fade in or out, no channel mixing. If the H3 audio comes out quiet or the tail is abrupt, that's a separate pass - the pack's HenjiccAudioMix if you're combining tracks, something else if you need a real loudness target.

Silent video isn't handled. audio is a required input, not optional. A workflow that conditionally produces no audio track can't just leave this socket empty.