Frame Slicer (WepeNerd)

Why you'd reach for this

Video generation hands you an IMAGE batch: 81 frames of Wan, 121 of LTX, whatever your model's grid allows. Nothing downstream cares about the count - until it does. The loop you're building stutters on one frame at the seam. The tail is two frames of drift you'd rather not encode. You want frames 40–100 for a second pass because the first second is the model warming up.

That's the whole job: take a contiguous run out of a batch and pass it on. No model, no resampling. It's the cheapest node in the graph and one you'll keep, because "the clip is right except for a bit at one end" is the normal state of video generation.

How it works

It's Python slice syntax with a UI: frames[start:stop]. Frames count from 0, start is the first frame kept, stop is the first frame left out. Start 2, stop 5 gives you frames 2, 3 and 4 - three frames, not four. Everyone trips on that once, usually while staring at a result one frame short of what they wanted.

The author names RES4LYF's Frames Slice in the description and means it literally: same inputs, same defaults, same numbers give the same frames. Port a workflow built on RES4LYF's samplers and this swaps one for one - which is the real reason to pick it over some random alternative.

The one deliberate difference is failure behavior. A range that keeps nothing - start at or past the batch length, or stop not greater than start - raises with a message about the real batch size, instead of passing an empty batch downstream to blow up in an upscaler three nodes later. That message is worth more than it sounds: "start is 121 but the batch only has 121 frame(s) (indices 0-120)" tells you exactly which of your two numbers is wrong.

The kept frames are copied, not viewed, so the output is contiguous memory and safe to hand around. The cost is small and you pay it for the slice, not the whole batch: 121 frames of 1280×704 fp32 is about 1.3 GB.

The inputs that matter

Only three, and you'll set two:

• frames - the IMAGE batch, usually straight from VAE Decode or Load Video.
• start - first frame kept, 0-indexed.
• stop - first frame dropped. Past the end is fine; you get the rest of the batch, which is how you say "from 40 to the end" without counting.

The single output is image, the cropped batch - wire it into Save Video, a batch upscaler, a second-pass sampler, whatever expected frames. Note the defaults: start 0, stop 1. Drop the node in fresh and it hands you one single frame. Reasonable for a preview, nasty if you queue without looking.

Installing it

ComfyUI Manager - search ComfyUI-WepeNerd by pack title - or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/WepeNerd/ComfyUI-WepeNerd
python -m pip install -r ComfyUI-WepeNerd/requirements.txt

Restart and hard-refresh the browser tab. The real dependency list is Pillow, numpy, SciPy and av>=17.0.0 - PyAV, because other nodes in the pack decode and encode video. No GPU wheels, no model downloads, nothing for models/. MIT.

Common issues

The whole pack is missing from the node menu. It's one Python package: __init__.py imports every node module in a single go, including the video ones that need PyAV. If av or SciPy isn't installed the import dies and none of the WepeNerd nodes register - Frame Slicer included, though it never touches a codec. Check the startup traceback, then rerun the pip line with the Python that actually runs ComfyUI.

You're off by one. stop is exclusive. A 121-frame clip kept entirely is start 0, stop 121 - not 120.

Your audio no longer matches. This node only touches frames. Slice 60 frames off the head, then save with audio from Load Video, and the sound still starts at the top of the file - the saver trims audio to the video's length, it doesn't shift it. Trim the head with Load Video's skip_first_frames instead, which selects the clip's audio along with its frames, and keep Frame Slicer for tails and mid-graph cuts.

You expected it to fix your frame count. If a model wants 4n+1 frames, slicing to an off-grid number just moves the problem; pick a legal count with the pack's Duration Selector and slice what came out. Related, and the reason clips sometimes come back short of what you asked for: the Wan VAE compresses time roughly 4x, so N frames become ((N-1)//4)+1 latents and decode back to (T-1)*4+1 frames. Knowing that arithmetic exists is usually enough to stop blaming the slicer.

It won't do scattered picks. Contiguous ranges only; for every-nth selection, use select_every_nth on Load Video.