VRGDG_PadVideoWithLastFrame
Freezing the last frame so your video doesn't jitter
- images
- images
The name is the whole manual: VRGDG_PadVideoWithLastFrame takes your frames and tacks a copy of the final frame onto the end. That sounds trivial until you've fought LTX for an hour and realize half of what you're fighting is the model inventing a fake "ending" for every clip it renders.
This node comes from VRGameDevGirl's AI music video pack, and it's one of the small glue nodes that make the big workflow work. The pack's "unlimited length" music video workflow renders a bunch of short clips and chains them. Video models are notorious for start/end jitter - the community reports in this very pack's threads that the pre/post frames that get rendered and dropped are exactly what kills the usual LTX-2 start and end jitters. What this node does is the holding-pattern version of that trick: instead of rendering fake frames and throwing them away, it holds a real frame still for as long as you ask.
How it works
It's a pure frame-manipulation node. Feed it a images batch (the IMAGE tensor that comes out of any video sampler or upscale step), tell it how many frames to pad, and it duplicates the last frame that many times, appending them to the end of the batch. Nothing fancy, no model involved, effectively free.
Three inputs, and honestly you mostly care about one:
images- your frame tensor.pad_frames- how many duplicate frames to append. Default 1, up to 1000. For a hold at the end of a clip, 4–8 frames is usually plenty; going to 1000 gives you a multi-second freeze frame at 24fps.pad_front- flip this on and the copies go at the front instead, using the first frame. Handy for an intro hold.
The single images output wires straight back into your next video node, so you can slot this in the middle of a chain without changing anything downstream.
Where it fits
Two classic uses. First, the end-of-clip hold: render your clip, pad it, and the model's sloppy final frames get covered by a stable hold, which also gives you a clean splice point for the next clip. Second, a deliberate freeze-frame for an outro card or a beat-synced drop - pad 24–48 frames and your video just stops, cinematically, instead of decaying into mush.
Installing it
This ships inside the vrgamegirl19/comfyui-vrgamedevgirl pack, so install the pack, not the node:
cd ComfyUI/custom_nodes
git clone https://github.com/vrgamegirl19/comfyui-vrgamedevgirl
Then restart ComfyUI. Easier route: ComfyUI Manager → Install Custom Nodes → search vrgamedev. The pack pulls in kornia, librosa, and imageio via its requirements.txt; on a Windows portable install run python.exe -m pip install -r ..\custom_nodes\comfyui-vrgamedevgirl\requirements.txt from inside python_embeded.
Gotchas
The one thing that trips people up is expecting it to interpolate. It doesn't - it's a hard cut to a frozen frame, and on a slow scene that's seamless, on a fast one it reads as a stutter. If you want a smooth slow-down instead of a freeze, look at a frame-interpolation pass rather than this node. And remember pad_frames counts frames, not seconds - at 24fps, a one-second hold is 24.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | — | |
| pad_frames | INT | 10–1000 | — |
| pad_front | BOOLEAN | false | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| images | IMAGE | — |