VRGDG Blend Overlap Output
Stitch the processed chunks back into one continuous clip
- 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 lastoverlapprocessed 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.
cosinegives the smoothest S-curve transition,smoothstepa similar but slightly different profile,linearthe 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 exactlywindowframes. 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 VHSBatchManagerobject, 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.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | — | |
| overlap_info | VRGDG_OVERLAP_INFO | — | |
| meta_batch | VHS_BatchManager | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| assembled_images | IMAGE | — |
| emitted_frame_count | INT | — |