H3 Auto Chain Reference Video

If you've run an H3 auto-chain and seen a node called "H3 Auto Chain Reference Video" appear in your execution graph that you never placed there - that's this one, and it's doing a boring job so you don't have to think about it. It takes a reference video (as a batch of frames) and slices it down to the frame window the current clip needs. MiniMax H3's reference-video input is one of the few genuinely "like Kling" motion-transfer tricks in open weights, but a chain generates clip by clip, and you can't feed a 10-second reference video into a 3-second clip and expect the timing to line up. Something has to keep the reference in sync. This is that something.

What it actually does

H3 Auto Chain Reference Video is a dumb, honest slice. You feed it an IMAGE batch (frame 0 to frame N of your reference video), a start_frame, an end_frame, and you get image[start:end] back out as a contiguous tensor. It clamps both bounds to the actual number of frames so you can't slice past the end, and if the window comes out under 5 frames it returns None instead - which the chain treats as "skip the reference for this clip," so a short or misaligned reference quietly degrades rather than killing the render.

That's the whole mechanism. No resizing, no FPS conversion, no magic. When a window needs to be resized to H3's canvas, that happens elsewhere in the pack (the Auto Chain Audio node does it if you route the reference through it). This node is purely "give me frames X through Y."

The inputs that matter

Only two are worth touching:

• image - the reference video's frame batch. Load it with Video Helper Suite at the chain's FPS (24 by default). An IMAGE tensor, not a VIDEO.
• start_frame / end_frame - the window you want, in frame numbers. Defaults are 0 and 120, which is 5 seconds at 24 FPS, a sensible single-clip reference.

One output: the sliced IMAGE, which you wire into the H3 node's reference-video input.

Why you'll rarely add it by hand

Here's the slightly confusing part. This node is mostly auto-injected: if you wire a reference video directly into the H3 "Reference To Video" node's ref_video_0 input, the pack rewrites the graph on the fly and inserts this slicer, updating start_frame/end_frame per clip. That's why you see it appear and disappear between renders.

The recommended path in the README is different: feed the reference video into H3 Auto Chain Audio's optional ref_video input instead, and that node handles windowing, FPS checking, and resizing for you - the tooltip on that input says exactly that. So you'd add this node manually only when you're slicing a frame batch yourself, e.g. testing a single window before committing to a full chain.

Installing it

This pack needs ComfyUI 0.34.0 or newer - it relies on the native H3 anchor and keyframe behavior that version introduced, and unlike older H3 patch packs it doesn't touch ComfyUI internals. Install via ComfyUI Manager (search "H3 Motion Context Auto-Chain") or:

cd ComfyUI/custom_nodes
git clone https://github.com/Ltamann/ComfyUI-H3-Motion-Context-Auto-Chain-addon

Then restart ComfyUI. Dependencies are imageio-ffmpeg, numpy, Pillow, and safetensors - nothing exotic. What you do need is a working MiniMax H3 workflow underneath, and that's the big one: the weights run ~42.5 GB and the H3 Community License geofences the weights out of the US, EU, UK and Korea, so check you're in a licensed territory before you go down this road.

Where people get burned

The usual failure is a reference video whose FPS doesn't match the chain (the pack errors on that rather than silently sliding), or one too short for the window - which just gets skipped, leaving you wondering why clip 4 has no reference. Both show up in the ComfyUI console as h3_motion_context: log lines, so watch the console when a clip comes out with no motion transfer. And remember the chain-wide rules: same resolution across every clip, and never reuse a chain_id for unrelated projects.