VRGDG Build Overlap Window

Every batch-chunking pipeline for video has the same structural problem: the model sees each chunk cold, with no memory of what came before, and the chunk boundaries show up as flickers, jumps and style breaks. VRGDG Build Overlap Window is the node that fixes the model's side of that - it assembles each model input so it contains both the new frames you're actually generating and the tail of the previous chunk for context, then pads the last chunk up to the exact frame count the model needs.

It sits in the middle of the VRGameDevGirl overlap rig, between the VideoHelperSuite Batch Manager feeding you source frames and your enhancement model. If you're using the family, this node is where the "overlap" becomes real.

How it works

Each batch that arrives has stride new source frames (that's how the VHS manager was configured - see VRGDG Overlap Preset). The node does three things:

1. Prepends context. On the first batch there's nothing to prepend, so it synthesizes a context by repeating the first frame overlap times (marked as synthetic_prefix in the info, and dropped later during blending). On every later batch it prepends the actual source tail it carried over from the previous window - the real frames that came right before this batch, so the model has true temporal continuity instead of a cold start.
2. Assembles to the fixed window size. Context + new frames are concatenated and, if the result is short of the model's window count (which happens on the final short batch), the last real frame is repeated to pad it out. The model always sees exactly the number of frames it expects.
3. Carries state and reports. It stores the current source tail for the next batch and reports whether this is the final batch (is_final), which lets the Blend node know not to wait for another round.

There's real guard-rail logic here, because meta-batch state is exactly where pipelines corrupt silently: it verifies the VHS manager's frames_per_batch matches your stride, checks batches arrive in order, and raises a "queue the workflow again to reset" error if you cancel mid-run and the state counters get skipped.

Inputs and outputs

• images - the current source batch from the VHS manager (stride frames).
• meta_batch - the standard VHS BatchManager object (output of VideoHelperSuite's VHS Batch Manager).
• overlap_config - from VRGDG Overlap Preset; the node re-validates that window/overlap/stride are consistent, so a mismatched wire fails loudly.

Outputs:

• window_images - the assembled window-frame tensor. This feeds your model's conditioning/image input. Exactly window frames, always.
• overlap_info - a VRGDG_OVERLAP_INFO bundle (batch index, window, overlap, stride, new-frame count, whether the prefix was synthetic, is_final, blend mode). Wire this to VRGDG Blend Overlap Output - it's how the blender knows what to trim and crossfade.
• new_frame_count - INT, how many real new frames are in this window.
• is_final - BOOLEAN, true on the last batch.

Where it sits in the workflow

The source manager (VHS Batch Manager) → this node → your enhancement pass → VRGDG Blend Overlap Output → save. Use the preset node to configure it. The model output must come back exactly window frames or the Blend node will refuse - so don't stick a node that changes frame count between Window and Blend without accounting for it.

Install

With the pack:

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

or ComfyUI Manager → search "VRGameDevGirl" → restart → hard-refresh. VideoHelperSuite must be present for the meta_batch input type to exist. The usual heavy requirements.txt applies (kornia, librosa, transformers, voxcpm, llama-cpp-python, …).

Common trouble

• "The previous overlap carry is missing" - you cancelled or skipped a batch; re-queue the whole workflow to reset the state. That error is the node refusing to silently produce a corrupted stitch.
• "VHS supplied N frames but the stride is M" - the manager isn't configured with this node's stride. This node has to sit directly after the VHS manager feeding your loader; putting another splitting node in between breaks the contract.
• Window looks wrong on batch one - the repeated synthetic prefix is intentional context, not a bug; the Blend node drops it before anything is saved.