MiniMax H3 · Multi-Shot Motion Context + ComfyKitchen

This is the workhorse of the IAMCCS MiniMax H3 motion-context variant - the node that actually renders one chunk of a chained long-video shot. It is a modified form of IAMCCS's standard atomic H3 generation backend with two additions bolted on: it can swap the attention backend to ComfyKitchen's accelerated path, and it takes a trim_frames input so the decoded chunk gets its context tail removed before it's treated as "visible" footage.

The mental model for the whole R37 chain: you generate slightly more than you'll keep (a tail that includes the previous shot's motion context), then this node trims that tail back to exactly the frames the planner promised. If you never trimmed, every chunk would overlap the next one and you'd be stitching footage on top of footage.

How it works

Under the hood it delegates to IAMCCS_MiniMaxH3GenerationBackendV2, IAMCCS's proven atomic generator - this variant deliberately doesn't rewrite sampling. What it adds:

1. If the shot plan's acceleration is comfy_kitchen, it patches the model with ComfyKitchen's INT8 per-model attention backend (ModelAttentionBackend) before sampling. "ComfyKitchen" here is ComfyUI's accelerated attention path - the thing that makes a 33B H3 model more survivable on mid-range cards.
2. It passes the usual batch of sampling widgets (steps, sampler, scheduler, denoise, shift_video, shift_audio, seed, seed_stride) through to the backend.
3. After decode, it trims trim_frames from the front of the frames and audio, matching the tail so the visible segment lines up with the timeline.
4. It verifies the decoded length is at least the planner's visible frame count, trims to exactly that, and re-syncs audio to the visible frames. bridge_last_frame is peeled off as the last visible frame - that becomes the bridge image handed to the next stage.

The "exact trim" isn't optional: if the decoder returns fewer frames than the planner needs, the node raises rather than hand you a truncated shot.

Inputs and outputs

The required inputs mirror a normal H3 sampling graph: model, positive, latent, video_vae, audio_vae, cine_linx, chunk_index, then seed, seed_stride, steps, sampler_name (44 choices - res_multistep, euler, etc.), scheduler, denoise, shift_video (12 default), shift_audio (3), and trim_frames (forceInput - comes from the MotionContext condition node upstream). Optional motion_state if the chunk runs the native AV context path.

Outputs: native_frames, native_audio, bridge_last_frame, sampled_latent, native_fps, report. These feed the delivery/commit stages - notably sampled_latent goes to the state commit node so the next chunk can load it.

Install

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

Beyond that you need MiniMax H3 support in ComfyUI plus the weights (33B - check the H3 community license territory terms first), and for the ComfyKitchen path, the acceleration backend your ComfyUI build ships. If the plan says ComfyKitchen and the attention patch isn't available, expect the node to error instead of silently running slow.

Gotchas

• This node is a generator but it isn't an output node - it doesn't save video. The R38+ delivery/checkpoint stages do that. Wire it into the chain, don't expect a file.
• trim_frames unconnected or zero when motion context is active → overlapping seams. The planner/condition pair feeds it; don't bypass the condition node.
• denoise defaults to 1.0 in this schema (full resample per chunk). For chained context work you usually want that; for a refine pass you'd want lower - that's what the R38 upres sampling nodes are for, not this one.