MiniMax H3 Finite Output Trim (Internal)

Video diffusion doesn't let you ask for arbitrary lengths. Frames have to land on the model's legal grid, latent time compression quantises what comes back, and so any tool that claims to hit an exact duration ends up generating a bit more than you wanted and cutting the extra off afterwards. Everyone does this - Bernini Infinity's mirrored temporal padding, the 4n+1 arithmetic people curse at on Wan - and this node is the H3 version of the last step.

Its docstring states the use case precisely: "Trim auto-segment padding back to the longest source-media duration." So it's not a general-purpose trimmer you should reach for when you want a shorter clip. It exists for the case where the planner auto-computed segments from a video or audio source and had to over-generate to reach a legal duration.

How it works

Two trims, one number.

Frames: images[:output_frames], cloned. It checks first - if the generated output has fewer frames than the requested count, it raises with both numbers, which is the right call. Silently returning a too-short clip here would look like a successful render right up until you noticed the ending was missing.

Audio: the interesting half. The frame count is converted to samples at the audio's own sample rate (frame_count / 24 * sample_rate) and the waveform is cut to that length. Note the asymmetry with the frames: a short waveform is not an error, just left alone. If the waveform is already shorter than the target, the audio is returned unchanged and the calls it a day. That's deliberate leniency for sources whose soundtrack ends before the picture does - a common shape when you lock an original recording onto a slightly longer timeline.

The frame count arrives as a force-input, meaning it's meant to be wired, not typed - in practice it's the planner's target_output_frames value threaded through by the expansion. If you're using this node by hand, that's the value you have to compute yourself, and it's the longest source-media duration in frames at 24 fps.

Inputs and outputs

Required: images (IMAGE), audio (AUDIO), output_frames (INT, default 5, force-input, min 1 - that tiny default is a hint that it's not meant as a manual setting).

Outputs: Trimmed Frames (IMAGE) and Trimmed Audio (AUDIO). Both are new objects, so the untrimmed inputs stay usable elsewhere if you want a before/after comparison.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Songssx/ComfyUI-MiniMaxH3-TimelineDirector.git

Restart, search MiniMax H3. No pip dependencies - the project declares an empty list and leans on the PyTorch, torchaudio and PyAV already present in ComfyUI. Internal nodes (this one included) need dev mode on in ComfyUI settings to appear in the add-node search. Prerequisites: a recent ComfyUI with native MiniMax H3 nodes, the H3 Ref2VA model, CLIP, video VAE and audio VAE, and Python 3.10+.

Common issues

"Generated output has only N frames; cannot restore an M-frame source duration." You asked for more frames than exist. In the auto-segment path this means the plan's target_output_frames exceeds what the chain produced - typically because the final segment came up short. It's a signal about your timeline, not this node.

The audio doesn't trim with the video. Your audio is already shorter than the target frame count. Working as designed, and usually what you want; if it isn't, your source audio is the thing to look at.

Duration is right but off by a frame or two. Frame-count math at 24 fps against a sample rate that isn't an exact multiple. The frame trim is exact; the audio lands within a sample or two of the boundary. Rounding toward a shorter waveform is the safe direction, which is what happens.

It ran and nothing changed. output_frames came in as zero or as the full length. Check what's wired into it - with nothing connected to a force-input, ComfyUI will use the widget default, and 5 frames is almost certainly not what you meant.