FL_MiniMaxH3MotionShot

FL MiniMax H3 Motion Shot is the internal node that turns a list of rendered shots into one shot you can refine. Give FL MiniMax H3 Motion Refine a shot_plan and it builds one of these per planned render, each feeding its own prepare and sample stages. Dev-only, so you won't see it in the menu unless ComfyUI's dev mode is on - and if you ever do place one by hand, you're debugging, not working.

Why it exists

A beat-planned H3 workflow doesn't produce one latent. It produces a latent per planned render, each with its own authored length, its own conditioning, and possibly a hidden motion-context prefix carrying the tail of the previous render as invisible conditioning. Refining that as a single blob would smear one shot's prompt across the next. So this node slices: shot N's latent, shot N's conditioning, shot N's authored/trim frame accounting, plus the pieces of the baseline it needs for comparison decoding.

Inputs and output

Required: latents (the only input that accepts a list - everything else must be a single value and errors if you hand it a list), shot_plan, index (which shot, zero-based), and vae. Optional: audio_vae, baseline_images, baseline_audio.

The single output is an FL_H3_MOTION_SHOT bundle: the shot's latent, its positive conditioning, the shot record, the total timeline length, the previous shot's latent and record, the sliced baseline images and audio, and the trim/authored counts. That bundle is what the prepare and sample stages consume.

The validation is the point

This node is where a plan and a set of latents get checked against each other, and it is strict on purpose. The plan has to be a version 1 H3 beat shot plan at 24 fps, not a temporal reshoot. Every shot must be contiguous - shot N's start_frame must equal the running cursor - with a positive authored length, render_frames at least 5 and on H3's 17k+5 grid, a motion-context trim that's a valid H3 context window and no longer than the render, real conditioning, and no reshoot flag. A shot with motion context must reference the immediately previous shot. The ranges have to add up to the plan's total.

Then it checks the latents themselves. Each one carries fl_h3_shot metadata, and every field - index, start and end frame, authored and render frames, motion context, total frames, fps - has to match the plan exactly. Durations get checked against H3's latent arithmetic, and all shots have to share a source resolution.

That's heavy, and it's why the errors here are useful rather than mysterious:

• latent N does not match shot_plan. Connect the exact plan used by Beat KSampler, including Shot Motion Context. - you re-planned (added or changed motion context, changed a beat) and sampled from an older latent list, or connected a plan with Shot Motion Context to latents that came from a graph without it.
• expected N rendered latents, received M - the plan says one number and your sampler list has another. Usually a render group changed after the fact.
• all shots must have the same source resolution - mixed resolutions in one assembled timeline.
• temporal reshot plans are not supported - Motion Refine doesn't handle the reshot path. Sample a reshoot with the beat sampler and assemble it with the reshot assembler.

Install

It ships with the pack, so there's nothing extra: ComfyUI Manager → search FL MiniMax H3, or

cd ComfyUI/custom_nodes
git clone https://github.com/filliptm/ComfyUI-FL-MiniMaxH3.git

Restart afterwards. The pack needs a current ComfyUI with native H3 support and - for anything that goes through Motion Refine - ComfyUI-MAINodes. You'll also need the standard H3 model set: ref2va diffusion model, MiniMax-compatible Qwen3-VL encoder, fp16 video VAE, fp32 audio VAE.

The practical takeaway: if you're seeing shot-mismatch errors, don't fight the node. Re-run the sampler with the plan you actually intend to refine, then refine. The node's job is to refuse to guess which shot you meant.