MiniMax H3 Trim Source AV to 17k+5

MiniMax H3 is picky about how many frames it will accept, and not in a "nice round number" way. H3's temporal layout expects video lengths of the form 17k + 5 - 5, 22, 39, 56, 73 frames and so on - and your phone footage or downloaded clip is almost certainly some other count. Feed it the wrong length and you'll get either an encode error or, worse, a silent mismatch between the frames you masked and the frames the model actually saw. MiniMaxH3TrimSourceAV is the boring, essential fix: it drops your source down to the largest valid H3 length and keeps everything downstream on the same temporal range.

What it does

Connect your source frame batch to frames and, optionally, its synchronized audio. The node floors the count to the largest 17k+5 value that doesn't exceed your source - it never pads, never resizes, never changes frame rate. When audio is connected, it's trimmed to match the returned frame duration at H3's fixed 24 fps.

Two behaviors worth knowing before they surprise you. First, this is a floor, not a compromise: if your clip is 100 frames it drops to 90 (17×5+5), and those trailing frames are gone - which is fine, because the whole point is that every branch of your workflow now operates on the identical valid range. Second, if your source audio is shorter than the trimmed video, the node leaves it short and reports the mismatch in its status text. It won't invent silence to fill the gap.

Inputs and outputs

• frames (required IMAGE) - source video frame batch, [frames, H, W, C].
• audio (optional AUDIO) - synchronized source audio, trimmed to the video duration at 24 fps.

Outputs:

• trimmed_frames - the floored frame batch.
• trimmed_audio - audio trimmed to match (null when no audio was connected).
• h3_length - the exact frame count as an INT. Handy to wire anywhere a workflow wants the number explicitly.
• trim_info - a STRING with a human-readable report: how many frames dropped, the resulting duration, and how the audio fared against its target sample count.

Why it has to go first

The trap this node exists to prevent is a pipeline that branches before trimming. In a typical H3 source-video inpaint graph you split the frames three ways - toward SAM3 for masking, toward the grid preview, and toward the H3 video VAE encode. If those branches see different frame counts, the mask and the latent silently disagree and your "inpaint" comes back wrong. Put MiniMaxH3TrimSourceAV at the very front, before the split, and every branch inherits the same trimmed range. The pack's example workflow does exactly this, so if you're following it, this node sits first by design.

It expects a 24 fps source with an audio track, per the example. If you're feeding it an SD-style batch that isn't video-shaped at all, it errors out with a message telling you it wants [T,H,W,C] frames.

Installing

It's part of the ethanfel/ComfyUI-MiniMaxH3-PerRowMasking pack alongside the per-row patch, set-generation-mask, and grid-preview nodes - you'll want all of them for the workflow this feeds. Install via ComfyUI Manager (search ComfyUI-MiniMaxH3-PerRowMasking) or:

cd ComfyUI/custom_nodes
git clone https://github.com/ethanfel/ComfyUI-MiniMaxH3-PerRowMasking.git

Restart ComfyUI. No additional Python packages beyond what ComfyUI already ships.