MiniMax H3 V2V Exact Delivery Trim (R22)
The trim node that makes MiniMax H3 V2V segments come back the exact right length
- images
- audio
- cine_linx
- images
- audio
- delivery_frames
- trimmed_tail_frames
- checkpoint_trim_head_frames
- report
Video models never return exactly the frame count you ask for. MiniMax H3 aligns segments to its internal frame constraints and hands back a few frames more (or fewer) than the shot needs, and in a multi-segment V2V render those strays pile up until the timeline drifts off the source video. IAMCCS_MiniMaxH3V2VExactDeliveryR22 is the small, unglamorous node that fixes it: it trims the decoded H3 output back to the exact frames the segment requested, and slices the audio to match.
What it actually does
You feed it the decoded images and audio, plus the cine_linx shotplan and segment_index. It looks up what that segment requested, checks the decoded batch is at least that long (it raises if the model under-delivered - better to fail loudly than silently ship a short clip), trims the tail, and cuts the audio to the same frame count at H3's native fps. Its outputs spell out the whole deal:
images/audio- the trimmed, sync-aligned delivery.delivery_frames- the number you actually get.trimmed_tail_frames- how many were shaved off the decode tail.checkpoint_trim_head_frames- always 0 here, on purpose.report- a one-line summary of the math.
That checkpoint_trim_head_frames of 0 is the interesting design note. In the regular (non-V2V) H3 path, the native checkpoint save removes an extra head frame to compensate for H3's alignment padding. V2V segments are independent REF2VA renders whose edit is a hard cut, so removing a head frame would desync them - this node explicitly reports "no head trim" so the checkpoint logic downstream doesn't steal one.
Why you'd wire it
This is the delivery end of the pair that starts with IAMCCS_MiniMaxH3V2VConditioningR22. The conditioning node aligns your request up to H3's constraints (that's the aligned_frames output you saw there); this node trims the decode back down to the real requested_frames. Use the pair together and every segment in a multi-shot object-swap render lands on the source timeline at the right length, which is the difference between a V2V edit that holds sync across segments and one that slowly slips.
The one failure to expect
If it raises with "decode returned N frames, below requested delivery," that's the model genuinely under-producing for that segment - usually a VRAM-constrained run or an over-ambitious requested length. Don't paper over it by trimming less; the fix is upstream (smaller requested frames, more memory, or a different performance profile in the Shotboard). The node's strictness is the feature.
Ships with IAMCCS-nodes: ComfyUI Manager → search "IAMCCS", or git clone https://github.com/IAMCCS/IAMCCS-nodes.git into custom_nodes, restart. No extra model files.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | — | |
| audio | AUDIO | — | |
| cine_linx | IAMCCS_SUPERNODE_LINX | — | |
| segment_index | INT | 00–1000000 | — |
Outputs (6)
| Name | Type | Description |
|---|---|---|
| images | IMAGE | — |
| audio | AUDIO | — |
| delivery_frames | INT | — |
| trimmed_tail_frames | INT | — |
| checkpoint_trim_head_frames | INT | — |
| report | STRING | — |