VRGDG_TrimImageBatch

Long videos blow up VRAM. That's the blunt fact every video workflow runs into, and VRGDG_TrimImageBatch is a small but real part of the answer: instead of feeding a whole multi-scene video through your sampler as one giant tensor batch, you cut it into per-scene chunks and process them one at a time. This node does the cutting.

It's aimed squarely at VRGameDevGirl's music video pipeline, where the reference-image-plus-audio workflow splits the song into scenes, renders each scene's frames as its own batch, and later stitches them. Between those two stages you need exactly this: "give me only the frames that belong to scene N."

How it works

Four inputs, one output:

• images - the full frame batch for the video (or the segment you're slicing from).
• frames_per_scene - how many frames each scene chunk contains. Get this right and the math is trivial; get it wrong and every scene boundary shifts.
• preroll_frames - frames to keep before the scene's chunk. In a music video pipeline this is how scenes get a little lead-in context so the video model has something to build on instead of starting cold.
• chunk_index - which scene you're extracting right now (0-based, matching how frame batches are indexed).
• images (output) - the trimmed batch for just that scene, ready to feed a sampler or a video-combine node.

The workflow loop this enables: for each chunk_index, run this node, render that chunk, save it, move to the next. Your GPU never has to hold the entire video at once, which is what keeps a 5-10 minute music video build from OOM-ing on a 12GB card. It also lets you re-render a single bad scene without regenerating the whole thing - worth a lot when scene 7 keeps coming out cursed.

Installing it

Ships in the VRGameDevGirl Video Enhancement Nodes pack. ComfyUI Manager → search vrgamedev → install, or:

cd ComfyUI/custom_nodes
git clone https://github.com/vrgamegirl19/comfyui-vrgamedevgirl

Restart ComfyUI. No models to download; this node is pure tensor slicing.

Common issues

Scenes are the wrong length or shifted. frames_per_scene must match how your upstream workflow split the video. If your chunks were defined by SRT timing rather than fixed frame counts, this node's fixed-count math will misalign - that's what the _SRTOnly sibling is for.

Out-of-range chunk_index. If the index points past the end of the batch, you'll get an error or an empty result. The math here is "chunk index covers frames index * frames_per_scene to (index+1) * frames_per_scene", with preroll_frames added before it - sanity-check that against your total frame count.

It's a plumbing node, not a showpiece. But if you've ever watched a long generation die at 95% with a CUDA out-of-memory error, you'll understand why chunking like this is quietly the most important habit in multi-scene video work.