H3 Context Windowing (obvpm)

Sliding-window sampling is old news - AnimateDiff-Evolved was doing it for SD 1.5 back in 2023 to break the 16-frame wall, and every long-video pack since has had some version of it. H3 Context Windowing is that idea applied to H3's joint video+audio latent, and it's the one node in the refine branch you'll actually tune.

The model patch samples a long AV latent in windows of window_seconds that overlap by overlap_seconds, blending the model's predictions across the overlap every step - MultiDiffusion along time. Run it before the sampler, model in, model out.

The two numbers

window_seconds defaults to 5, and it's the memory dial. It's rounded to whole latent steps (about 3.4 frames each, and the log tells you what it became), and tokens per window are what attention and memory pay for. From the node's own documentation: at 1920x1088, a 5-second window needs about 7 GB of activations; 13 seconds - a clip and a bit - needs more than 17 GB. Any length is valid. The work per step is the same at any window size; the memory is not. One model call per window per step is what you're buying.

So the tuning rule for a joint refine is blunt: use the longest window your card holds. Bigger windows mean fewer blending seams and fewer passes over the overlaps; smaller windows mean it fits.

overlap_seconds defaults to 1.25, about a quarter of the window, and it's the region where two neighbouring windows share the same seconds of picture and sound. That's where the blend happens. Shrink it and you save a little compute; starve it and the blend has less to work with.

Why the overlap is the whole trick

Each window samples under the conditioning of the clip that owns most of it when H3 Joint Conditioning is on the sampler. That's how a five-prompt timeline stays five prompts while still being one denoising run. The overlap is where the model's opinion of the same moment - formed under two neighbouring contexts - gets reconciled per step rather than being decided by whichever window happens to own the frame. Texture decisions end up shared across every join, which is the entire reason the sequence is sampled as one latent.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/chanon/comfyui-obvpm-timeline

Restart ComfyUI. No extra Python dependencies: the pack's pyproject is deliberately empty, since torch, torchaudio, numpy, safetensors and av all come with ComfyUI. You need ComfyUI 2026-08-13 or later for the core MiniMax H3 nodes. In ComfyUI Manager, search the pack title comfyui-obvpm-timeline; every node in the pack carries an (obvpm) suffix, so obvpm is also a one-word node-menu search.

The bundled refine workflow places this node on the model path between the Set/Get plumbing (from KJNodes) and the sampler. Unless you're hand-wiring, start from that workflow rather than assembling the branch yourself.

Troubleshooting

• Out of memory on the first step. Drop window_seconds. The tempting instinct is to raise the headroom or lower resolution; changing the window is the direct lever, and it's exact - the node rounds to latent steps and tells you.
• Visible banding at regular intervals along the sequence. Your overlap is doing too little work, usually because it's very small relative to the window, or because neighbouring windows are conditioned very differently (a hard cut inside a window). Try a larger overlap before assuming the refine is broken.
• The window size you typed isn't what ran. It got snapped to whole latent steps. Read the log line rather than assuming.
• Very long timeline, limited card. Smaller windows plus H3 VRAM Headroom on the model path is the combination that keeps you out of system memory. The headroom node adds room for the run's keyframe rows and references, which core's own estimate leaves out.
• Frames at the very start or end look different from the rest. A window at the sequence edge has neighbours on one side only; that's structural, not a bug.

One thing worth saying plainly: this node is not an accelerator. It costs you a pass over the length plus the overlaps, and saves you memory. If your whole sequence fits in VRAM as a single window, you don't need it at all - you need the longer window.