Nodes/VRGameDevGirl Video Enhancement Nodes/VRGDG Blend Overlap Output
ComfyUI Node

VRGDG Blend Overlap Output

Stitch the processed chunks back into one continuous clip

By vrgamegirl19·Created about a year ago·Updated about 7 hours ago· 718
VRGDG Blend Overlap Output
  • images
  • overlap_info
  • meta_batch
  • assembled_images
  • emitted_frame_count

The whole overlap rig exists so that a long video can be processed by a model with a fixed frame window without seams - and VRGDG Blend Overlap Output is the node that actually removes them. It takes the model's processed window, crossfades the duplicated region where this window meets the previous one, trims the synthetic padding, and hands back a stream where every source frame appears exactly once, in order. If you've done long-video enhancement by hand, this is the step you've reimplemented badly at least once.

It's the last node in the chain: VHS Batch Manager → VRGDG Build Overlap Window → your enhancement model → this node → save.

How the blend works

Because each window overlaps its neighbor by overlap frames, that region of video gets processed twice - once as the tail of window N, once as the head of window N+1 - and the two versions rarely match perfectly (denoising is not deterministic across different context). The node's job is to decide who wins and how.

The recipe, batch by batch:

  • Batch 0 - the node knows the head of the window is synthetic (repeated frames created by Overlap Window for context), so it just drops that padding. Real output starts at frame overlap. It saves the last overlap processed frames as a tail for the next round.
  • Later batches - it takes the previous processed tail and the current batch's head, and crossfades them using a weight ramp over the overlap region. cosine gives the smoothest S-curve transition, smoothstep a similar but slightly different profile, linear the cheapest straight ramp. The freshly-generated middle frames then append unchanged.
  • Final batch - no tail is carried forward; everything is emitted, including the frames that were padded at the very end (those get trimmed by the count logic, not blended).

The result: a continuous processed clip with the overlap regions gradually morphing from one window's output into the next, so nothing pops, and no frame is emitted twice or dropped.

Inputs and outputs

  • images - the model's processed output for this window. It must be exactly window frames. The node checks and errors if your enhancement pass changed the frame count.
  • overlap_info - from VRGDG Build Overlap Window. Carries the batch index, window/overlap/stride, whether this is the final batch, and the blend mode.
  • meta_batch - the same VHS BatchManager object, so the node can track which batch it's on and verify nothing was skipped (same "queue again to reset" contract as the Window node).

Outputs:

  • assembled_images - the continuous output for this batch: blended overlap frames plus the new unique frames, every source frame accounted for exactly once.
  • emitted_frame_count - INT. Handy for sanity-checking that you're getting the expected number of frames out per batch (should equal the stride except on the final batch).

The traps

  • Frame count drift kills it. Any node between Overlap Window and this one that resizes, drops or interpolates frames (a temporal upscaler, a "remove duplicate frames" utility) will produce the "processed output must preserve the window" error. Keep that segment pure.
  • Don't bypass the state checks. These nodes carry tail frames in memory across the VHS requeue; cancelling mid-run and resuming out of order is exactly what produces a "state skipped" error. Re-queue the whole workflow to reset.
  • Blend mode is set upstream in VRGDG Overlap Preset, not here. If you want cosine instead of linear, change it at the preset node; this node just honors it.

Install

Same pack as its siblings:

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

or ComfyUI Manager → "VRGameDevGirl" → restart → hard-refresh. Requires VideoHelperSuite for the VHS_BatchManager input type. And yes, the whole pack's heavy requirements.txt rides along - voxcpm and llama-cpp-python are the ones that need Cython/scikit-build-core (and ideally a compiler) installed first on Windows.

If you're wondering whether you need this node at all: if your video fits in one model window, you don't. If it doesn't, this is the difference between a stitched-together mess and footage that looks like it was processed in one piece.

CategoryVRGDG/Video/Meta Batch

Inputs (3)

NameTypeDefaultDescription
imagesIMAGE
overlap_infoVRGDG_OVERLAP_INFO
meta_batchVHS_BatchManager

Outputs (2)

NameTypeDescription
assembled_imagesIMAGE
emitted_frame_countINT