Ares Trim Video

H3's MiniMax H3 Reference to Video node takes a reference clip as IMAGE frames at 24fps, 2–15 seconds - that's 48 to 360 frames, per the input's own tooltip and the author's clamp constants. You do not have IMAGE frames. You have a VIDEO object, freshly decoded from the sampler, and you want the tail of it, because the last frame of clip one is where clip two needs to start.

Ares Trim Video is the node that does both jobs in one hop: VIDEO in, clamped frame batch out.

How the slicing works

It converts your frame numbers into time - dividing by the clip's frame rate, defaulting to 24 if the video doesn't report one - and then calls the same time-based trim machinery core ComfyUI's Video Slice uses. start_frame sets the cut point, frame_count sets the length.

The interesting mode is tail. Flip it on and the arithmetic inverts: instead of starting at start_frame and running forward, it starts at total_frames - frame_count and runs to the end. That's the seamless-continuation move. You generate 5 seconds, take the last 2, and hand those 2 seconds to the next round as its reference video - the model now knows what the motion was doing when the previous clip ended. With tail on and frame_count at 0 you get the last 48 frames, i.e. exactly the model's 2-second floor.

Then the clamp. Whatever comes out of the trim, the images output is forced into H3's reference window: under 48 frames and it pads the batch by repeating the final frame until you hit 48; over 360 and it truncates. That padding is why a 5-frame trim still works as a reference - the model gets a 48-frame clip that holds still at the end.

Inputs and outputs

You set three things in practice. tail (off by default - turn it on for continuation). frame_count, remembering that 0 means "to the end", except under tail where 0 means "the last 48". And strict, which changes failure into an error instead of a silent short read - worth turning on while you're still building the workflow, because the alternative is a confusingly static result three nodes later.

start_frame is ignored whenever tail is on. That's documented in the tooltip, and forgetting it is the usual five minutes of confusion.

Three outputs, and the split matters:

• video - the trimmed clip as a VIDEO. Note this one is not clamped: trim 5 frames and you get a 5-frame video here.
• images - the frame batch, clamped to 48–360. This is the one that goes into H3's ref_video_0. It's an IMAGE output, which is what that port actually wants - a VIDEO won't connect.
• last_frame - a single IMAGE, the final frame of the (clamped) clip. Wire it into ref_image_0 and the next clip is anchored to start from the previous clip's last frame. That pairing - last_frame into ref_image, images into ref_video - is the whole seamless-continuation trick, and it's two wires.

Is it worth using over core nodes?

Core ComfyUI has Video Slice, Get Video Components and an interactive Video Trim, and you can assemble this yourself. What you're buying here is the clamp and the last_frame output in one node - and the clamp is the part people forget until they hand H3 a reference it rejects or silently ignores. If all you need is "video to frames", core's Get Video Components is fine.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/SuperWJ062/ComfyUI-ares_MiniMaxH3_IntelligentPrompt

Restart, and the four Ares nodes appear under the Ares category. No requirements.txt, no extra packages - it's torch and folder_paths, both already in your install. You do need a ComfyUI new enough for the io.ComfyNode authoring API and the newer frontend. The pack itself ships no models; the H3 weights (~42.5GB) are your download, and their licence carves out the US, EU, UK and South Korea, so check that before you plan a project around them.

Things that will confuse you

Your reference is shorter than you trimmed. Handing over 48 frames doesn't guarantee the model uses 48. The official H3 node snaps reference clips down to its own 17k + 5 frame grid, so a 48-frame batch becomes 39 frames once it's inside. Nothing is broken; the model's clip lengths just quantise that way, and it's the reason a "2 second" reference can feel a touch shorter than the 2 seconds you measured.

Chaining a loop, and the trim keeps giving you the same thing. That's usually upstream - if nothing about the loaded video changed, ComfyUI will happily serve a cached result. See Ares Load Last Video's caching note; the two nodes are designed as a pair.

One last thing: this node wants a VIDEO in. If you're holding a loose IMAGE batch, you need core's CreateVideo first.