H3 Trim Output to Source Length

This is a two-input, one-output utility, and it exists because of one specific quirk plus one inevitable arithmetic problem. It is not exciting. It will save you a render.

Here's the situation. H3's frame grid is 17n+5, so a 6-second source at 24 fps is 144 frames, which is not a legal H3 length. You round up to 158, generate, and now you're holding 14 frames more than the footage you started with - repeated tail padding that will show up as a frozen last half-second if you hand it straight to a video saver. Meanwhile the installed H3 VAE has a known habit of decoding one frame short at an exact window boundary, which is enough to shift your whole audio alignment by 1/24 of a second.

H3 Trim Output to Source Length handles both.

Inputs and outputs

• images - the decoded IMAGE batch.
• source_frames - how many frames you actually want to keep. Default 120, minimum 1, maximum 3592 (the largest 17n+5 value within H3's 3600-frame node limit). Wire this from H3 Prepare Video's source_frames output.

One output: trimmed_frames, an IMAGE batch of exactly that length.

Behaviour, in order. If the batch came back exactly one frame short, it logs a warning and repeats the final frame to preserve the audio/video duration rather than silently shortening your clip. If it's short by more than one frame, it raises - H3 returned N frames; expected at least M. Check the length connections. - because more than one missing frame means something is genuinely wrong upstream, most often a length input that didn't get wired. And if there's padding to spare, it returns the first source_frames frames.

That ordering is the reason to use this rather than a plain image-slice node. It's aware of the H3 decode quirk; a generic slice isn't, and a slice that lands before the hold will lop off your last real frame instead.

Where it goes in the graph

Two sane placements:

• After a single-window decode, when you're running a short clip in one pass and just need the padding gone.
• After the final assembly in a longer chain, as a belt-and-braces trim if your source_count plumbing isn't carrying the exact length.

In the pack's windowed workflows the assembly nodes already trim to the source count internally, so adding this on top is redundant - harmless, but redundant. It earns its place in hand-built or single-window graphs, which is exactly where people hit the padding problem first.

Install

It ships inside H3 Relay, so there's nothing separate:

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/akatz-ai/h3-relay.git

or Manager → search H3 Relay → install → restart. ComfyUI 0.32.0 or newer. Works on CPU, loads no models, and needs no downloads of its own - although the pack around it wants the MiniMax H3 weights from MODELS.md and FFmpeg on PATH before any of the video nodes will be happy.

If you previously installed the standalone labs-video-prep pack, remove it: this node keeps the same class identifier and sockets so saved workflows load unchanged, but the old package can shadow the current one.

Snags

• H3 returned N frames; expected at least M - check the length going into your generation and whether source_frames is connected to the right output. A common cause is passing the padded H3 length where the unpadded source count belongs, which makes the node think frames are missing when they aren't.
• Output ends one frame long. That's the deliberate hold. If a frozen frame at the very end bothers you, check whether the model had padding to spare; when it did, the padding is trimmed and the hold never reaches the output.
• Audio and video length drift apart. source_frames is in frames at 24 fps. If your source was resampled from 30 fps somewhere else in the graph, the arithmetic here is still 24-based - resample upstream with the preparation node and keep the whole chain on one clock.
• Nothing to trim. If your source is already a legal 17n+5 length there's no padding and this node is a no-op pass-through, which is fine. It's cheap insurance, not a step you need to think about.