Trim Video Continuation Prefix

You prepended 22 frames of the previous segment so the model had something to continue from. The sampler did its job and gave you 146 frames back. 124 of them are the clip you wanted; 22 of them are the scaffolding you put there ten minutes ago.

This node removes the scaffolding, from the images and from the audio, using the metadata that recorded where the boundary went.

What it does, exactly

trim_info comes from Video Continuation Concat and carries the composition mode, the prefix length, the number of frames to trim, and the frame rate as an exact numerator/denominator pair. The node drops the first trim_frames images and, if you gave it audio, the matching leading samples computed as ceil(trim_frames * sample_rate / frame_rate) - rational arithmetic, not a float duration / 24.0, because 22/24 is not a float you want rounded twice in a chain that runs thirty times.

It handles both composition modes without you telling it which one you used. In concat mode the prefix is real extra frames at the front. In replace mode the prefix was swapped into leading slots that the body timeline already contained - and those get trimmed too, so the output of a replace-mode chain is the length you asked for, not the length plus context.

Works on IMAGE batches and on audio. If audio isn't connected you just get trimmed images back; the audio output is then empty, which is fine when H3's audio is going somewhere else.

Input wiring

images is required - the whole generated batch, context included. audio is optional. trim_info is technically optional in the schema and effectively mandatory, because without it the node has no boundary to work from and raises rather than guessing. Wire it, and wire the same token to H3 Set Audio Prefix Noise Mask in the branch that produces the audio latent. One token, two consumers, identical boundary: that's the design.

The output images is what you save with Save Indexed Video Segment, or hand to Merge Indexed Video Segments' source folder. audio goes with it. If your chain loops, this is the last node before the save on both wires - the loop closes when the saver writes segment n+1 and the loader reads it next run.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/wjie98/comfyui-svdint4.git
# restart ComfyUI

GitHub and Manager list it as comfyui-svdint4; the README titles the project "ComfyUI Turing Utils" and clones comfyui-turing-utils. Rename history, same pack. No model files, no extra dependencies - the pack's requirements.txt is just safetensors and video handling uses PyAV, which ComfyUI installs anyway. The kernel build in the README's install section is for the quantisation and attention nodes and has nothing to do with this one.

There's no community thread to check either - I searched the reddit corpus for the pack, the author, and both repo names and got zero hits. The README is your documentation, and for this node it's accurate.

Where it bites

Trim before you save, not after. Merge Indexed Video Segments stream-copies stored bytes, so an untrimmed folder merges into a film with 22 duplicated frames at every seam. The failure is visible and annoying and completely avoidable - this node goes upstream of the saver, always.

Double-trimming is the other one. If you trim twice you lose the first 44 frames and the audio stays consistent with the images (so it doesn't look broken, it just starts late). If your chain mysteriously drops the opening beat of every segment, count your trim nodes.

And a trim request larger than the batch is an error, not a clamp. That usually means the sampler returned fewer frames than the timeline you built - check the H3 frame grid (17*n+5) and any padding node in the chain before you go hunting in this one.