Adv MiniMax H3 Image to Video (Temporal Fusion)

If you've pushed MiniMax H3 image-to-video on a shot with real motion - a car pulling away, a hand waving, a punch landing - you've probably watched the result smear through the in-between states. H3's encoder is a VLM, and like every video diffusion encoder it doesn't read every frame of your source. It samples a handful, and whatever happens between the samples is where motion gets invented rather than followed. This node is silveroxides' experimental answer: sample more of the video, then fuse all that extra motion back into exactly the same conditioning budget the ordinary encoder would have used. More motion signal, no bigger conditioning, no bigger latent.

What it actually does. The mechanism is temporal density. You set temporal_density on the companion MiniMax H3 Media Configurator (UC_MiniMaxH3MediaConfig) node - leave it at 1 and this node behaves like the plain Advanced MiniMax H3 encoder, which is your baseline to compare against. Turn it up, say to 4, and the encoder also samples "lanes" of offset frames: between each pair of canonically-sampled frames it grabs progressively shifted in-between frames at finer and finer intervals. Every lane is encoded separately by Qwen3-VL, and then only the corresponding video visual-token blocks across lanes get merged - by consensus weighting (default) or spatial fusion - back into the original token slots. That's the trick and the point: the final conditioning occupies the ordinary video token budget, so the sampler sees a sequence no longer than stock H3, but each video block now encodes several moments of motion instead of one.

Where the lanes are fused determines the "Fusion" vs "TokenFusion" naming - this node is the post-encode variant: each lane gets its own full Qwen encode, then blocks are stitched together in the finished conditioning. (Its sibling, Temporal TokenFusion, fuses token features before a single encode, which is the cheaper-on-VRAM path.) Pick the consensus-vs-spatial method and feed the matching config node through media_config; density-1 runs skip the extra encodes entirely.

Inputs that matter. Most of the schema is shared with the stock advanced encoder, and only a few knobs are yours:

• clip - must be the MiniMax H3 text encoder, the Qwen3-VL 32B (qwen3vl_32b), loaded via Core's Load CLIP with type minimax. Feed anything else and the node raises.
• length - frame count at 24 fps, snapped upward to H3's 17k+5 temporal grid.
• media_config - where the whole experiment lives: temporal density, fusion method, Picture timestamp formatting.
• video - a complete 24 fps frame batch. If you want a native reference video rather than frame anchors, this is the input that the temporal sampling runs on.
• text_blend_config - consensus settings for the temporal merge; leave disconnected and it uses a sensible default.

Frames go in either as first_frame/last_frame VAE anchors (also the first two numbered Qwen pictures) or as ordered reference_images - not both. vlm_video_resolution controls how many visual tokens your Video frames consume; higher means more detail but a longer encode.

Outputs. Two: positive CONDITIONING into the sampler's positive input, and LATENT (the joint video latent) into the KSampler. From there it's ordinary H3: sample, decode, save.

Install. ComfyUI Manager → search ComfyUI-UtilsCollection, or:

cd ComfyUI/custom_nodes
git clone https://github.com/silveroxides/ComfyUI-UtilsCollection

then restart ComfyUI. The pack's real Python deps are just opencv-python, typing-extensions, and unifiedefficientloader - the heavy lifting is the model, which the pack does not download for you. You need the MiniMax H3 checkpoint (~42.5 GB), the Qwen3-VL 32B text encoder, and the H3 VAE. And check the licence before you start: the MiniMax H3 Community License excludes the EU, UK, South Korea and the US from its applicable territory, so "open weights" here is a conditional grant, not a free one.

Where people get burned. This is an experiment - the pack flags it experimental, it's aimed at people who've already got stock H3 I2V working, and the whole pack has almost no community footprint yet, so you're the beta tester. Start with density 1 to confirm your baseline reproduces, then step density up and watch both quality and encode time (each lane is a full Qwen pass, so this is not free). Expect the README's own honesty to apply: the results are stochastic and timeline control stays approximate. If you just want ordinary MiniMax H3 image-to-video, Core's native nodes are the stable path - reach for this only when the motion fidelity is actually your bottleneck.