MiniMax H3 Shotboard Backend

The name says "Backend" and your first instinct is to assume it calls some MiniMax API. It doesn't. Nothing in this pack touches the cloud - MiniMax H3 runs locally through ComfyUI's native nodes, and this node is the piece that connects your editorial plan to that render. If you've ever wanted to generate a multi-shot film where shot B picks up exactly where shot A left off, this is where that magic gets wired together.

What it actually does

IAMCCS's Shotboard workflow is built around a JSON shot plan - a timeline of segments, each with its own prompt, duration, keyframes, and audio - that travels through the graph as a cine_linx pipe (type IAMCCS_SUPERNODE_LINX). The MiniMax H3 Backend reads that plan, looks at the segment_index you give it, and pulls out everything needed to condition one shot: the prompt, the sliced audio window, the planned first/last frames, and the resolution.

Under the hood it's a thin wrapper around ComfyUI's native MiniMaxH3ImageToVideo and MiniMaxH3ReferenceToVideo nodes. It calls one or the other depending on the segment's mode - t2va, i2va, fl2va (first-and-last frame), or ref2va (reference images/audio). In ref2va mode it tags your frames with instructions like "use this as the subject and opening-state reference" and hands the sliced audio to the model as <Audio 1>. It even frees the Qwen3-VL text encoder from CPU RAM after conditioning when release_text_encoder_memory is on, which matters on 16GB-and-under systems.

The inputs that matter

You feed it the four loaded H3 components - model, clip, video_vae, audio_vae (the GGUF Loader above is a one-stop source for all four) - plus cine_linx and segment_index. The optional ones worth knowing:

• bridge_frame - the previous segment's last frame, used as this segment's first frame when the plan says so. This is how the shotboard keeps continuity without holding a whole movie in VRAM.
• driven_audio - the full audio track; the node slices the segment's window out of it.
• first_frame_override / last_frame_override / prompt_override - quick manual nudges without editing the whole shot plan.

The outputs that matter

Thirteen outputs, but you mainly care about three: positive (the conditioning), latent (the AV latent to sample), and model (passed straight through). Those go into the Render Backend or Generation V2. first_frame / last_frame, driven_audio_slice, and prompt are there for previews and logging. The rest - current_segment, total_segments, trim_head_frames, timeline_start_seconds, upscale_mode, report - keep the graph self-aware and tell downstream nodes what stage it's in.

Installing it

The pack is on ComfyUI Manager - search "IAMCCS". Or, in a terminal:

cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git

Restart ComfyUI. Requirements are ComfyUI ≥ 3.0, Python ≥ 3.12, and a current PyTorch/CUDA build. There are no pip deps - the heavy lifting is done by ComfyUI's native MiniMax H3 support plus optional packs like ComfyUI-GGUF for quantized weights.

Where people get burned

The biggest gotcha is mode mismatch: the node warns when the plan wants ref2va but you loaded an fl2va model (and vice versa). Second is the bridge frame - if a later segment needs one and none is available, it raises a FileNotFoundError; start the queue at segment 0 or connect bridge_frame by hand. One pack-specific trap: never keep a second copy of IAMCCS-nodes in custom_nodes (backups included), or ComfyUI registers stale classes and you get confusing import failures.