Wan Trim Frames ✂️
Cropping off the padding Wan's 4n+1 rule leaves behind
- images
- images
- frames_kept
If you've ever asked Wan for a clip of a specific length and gotten back a video with a handful of extra frames tacked on the end, this tiny node is the fix. It does exactly one thing: keep the first total_frames frames of a batch and throw away the rest. No blending, no interpolation, no cleverness - a straight crop, frame 0 through total_frames - 1.
Why this is even a problem
Wan's VAE compresses time by a factor of about 4, and it only works in whole latent frames. That means your requested frame count has to satisfy Wan's 4n+1 rule - 33, 81, 121, and so on - and if it doesn't, the sampler rounds up to the nearest valid length before generating. Decode that back out and you get more frames than you actually wanted. One Wan user doing frame-accurate audio-reactive video described the annoyance well: their beat segments needed exact frame counts, but Wan would only hand back 4n+1 lengths, so their pipeline had to compute the padding, generate the padded clip, and then manually strip the extra frames off the end before stitching. That's the exact workflow this node automates.
It shows up even more directly when you're chunking a long clip through WanAnimate-style motion transfer. This pack's own WanFrameWindowSize node computes a window size and tells you output_frames - the total length the windowing will actually produce, which is always greater than or equal to your source clip's real length, plus a frame_diff telling you exactly how much padding to expect. Wan Trim Frames is the node you feed that padded, decoded output into afterward to get back down to your real clip length. The node's own description says it outright: use it after WanVideo Decode, paired with WanFrameWindowSize.
Inputs and outputs
Only two inputs, both required:
images(IMAGE) - the decoded frame batch straight out ofWanVideo Decode, shape[F, H, W, C].total_frames(INT, default 81) - how many frames from the start to keep. The tooltip is explicit that this can be eitherWanFrameWindowSize'soutput_frames(if you want to keep the padded, windowed length for some reason) or your original source clip's true frame count (the normal case - trim the padding off entirely).
Two outputs: the trimmed images batch, ready to hand to a video-save node, and frames_kept (INT) - a sanity-check count of how many frames actually made it through, so you can confirm the crop landed where you expected before you burn time re-encoding.
Installing it
This is a tiny personal pack, not something you'll reliably find by browsing ComfyUI Manager's featured list - search Manager for the repo name (comfyui-sortlist) or the pack's registered title (comfyui-huyl2-nodes) first, and if it's not indexed, install manually:
cd ComfyUI/custom_nodes
git clone https://github.com/huyl3-cpu/comfyui-sortlist.git
Restart ComfyUI afterward. There's nothing to download - no model weights, no extra Python dependencies for this node specifically. Worth flagging: the pack's own README doesn't mention WanTrimFrames (or its sibling WanFrameWindowSize) at all - it only documents an unrelated video-segment-cutting node. These Wan utility nodes ship in the code but aren't written up anywhere, so this article and the node's own tooltips are your only documentation.
Common issues and troubleshooting
It's a crop, not a fix. This node doesn't know or care why your batch has extra frames - it just lops off everything past total_frames. If your actual problem is that Wan generated the wrong content (not just the wrong length), this node can't help; it's strictly a post-decode cleanup step.
Get total_frames from the right place. The tooltip's "either/or" phrasing is there for a reason - plug in WanFrameWindowSize's output_frames and you keep the padding; plug in your real source length and you strip it. Mixing these up is the most likely way to end up with a clip that's a few frames longer or shorter than you meant.
Order matters. Run this after decode, not before - trimming latents instead of decoded frames will just get you a differently-shaped mess, since the whole point is to operate on the final [F, H, W, C] image batch.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | Batch ảnh từ WanVideo decode (shape: [F, H, W, C]) | |
| total_frames | INT | 811–99999 | Số frame gốc cần giữ lại (từ WanFrameWindowSize → output_frames hoặc total_frames gốc) |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| images | IMAGE | — |
| frames_kept | INT | — |