H3 Video Reference

Most video models only let you condition on stills. MiniMax H3 lets you condition on video - motion, camera, pacing, and the audio attached to it. H3 Video Reference (TuringUtilsH3VideoReference) is the node that makes that happen: it takes reference clips, encodes them into the VAE latents H3's DiT reads, and separately prepares a low-frame-rate view for Qwen to "watch" while it builds your prompt's semantics.

Two clever things happen inside. First, the model gets different views at different rates: the DiT gets the full-resolution VAE latent, while Qwen gets a 2 FPS sample of the clip with timestamps - so the language model understands sequence without paying the token cost of every frame. Second, it can pair each clip with a soundtrack through index-matched sockets, because H3 is one of the first local video models that generates native audio, and it'll happily reference the sound of your source clip too.

Inputs that matter

• video_vae (VAE, required) - encodes the frames into H3 video latents.
• megapixels (FLOAT, default 1.0) - source-area budget when no latent is connected. Same semantics as H3 Image Reference: a cap, not a target, and it never upscales.
• audio_vae (VAE, optional) - required only if you connect soundtracks.
• latent (LATENT, optional) - match-area sizing against a target latent.
• videos (autogrow, up to 16) - the clips, each as consecutive frames. The tooltip is the contract: "Consecutive frames already resampled to 24 FPS."
• video_audios (autogrow, up to 16) - soundtracks, paired by index. video_audio_1 belongs to video_1, and so on.

Output: video_reference (TURING_UTILS_H3_VIDEO_REFERENCE) → H3 Semantic Reference and H3 Build Conditioning.

How it actually works

The frames get trimmed to H3's canonical 17*n+5 frame grid (you need at least five frames), resized per the sizing rule, and VAE-encoded. Any index-paired soundtrack is resampled to the audio VAE's native rate and encoded too. Then it builds the 2 FPS Qwen view - every 12th frame at 24 FPS - with timestamps so the model knows where in the clip each sample sits.

Where people get burned

• Not-24-FPS input. This is the big one. The node does not resample for you - the tooltip says so, and it means it. Feed it 30 FPS frames and the timing is wrong in ways that are hard to notice until the output drifts. Resample upstream to 24 FPS.
• Short clips. Under five frames, it refuses with a clear error. H3's temporal grid needs the headroom.
• Soundtrack without an audio_vae. Connect a soundtrack but skip the audio VAE and it errors out loudly: "has a soundtrack but audio_vae is not connected." That's a feature, not a bug - silent conditioning would be worse.
• VRAM. Each reference video is a full VAE latent plus tokens in the Qwen stage. One or two short clips is a lot; sixteen is a memory experiment.

Installing it

Part of the ComfyUI Turing Utils pack (repo wjie98/comfyui-svdint4; the README still says its old name, comfyui-turing-utils). ComfyUI Manager - search "svdint4" or "Turing Utils" - or:

cd ComfyUI/custom_nodes
git clone https://github.com/wjie98/comfyui-svdint4

Restart ComfyUI. requirements.txt ships only safetensors; the CUDA kernel (python -m pip install -v --no-build-isolation -e ./kernel) is a separate step you'll want to actually run H3, but this node is pure VAE encode and works without it.

Where it sits in the graph

Clips and soundtracks in → H3 Video Reference → video_reference → H3 Semantic Reference (Qwen watches the 2 FPS view) and H3 Build Conditioning (the DiT gets the full latents). Same two-wire pattern as the other references - and it's the node that finally makes "reference the vibe of this clip, not just a still from it" a thing you can do locally.