H3 MCtx From Frames (obvpm)

Everything in this pack wants a sidecar. A sidecar holds latents. Clips you shot, downloaded, or exported from another tool have no sidecar and no latents - so how do you extend those?

You encode them, and this is the node that does it. H3 MCtx From Frames is the pack's only pixels-to-latents crossing, and the author made it an explicit graph node rather than a hidden fallback on purpose. Crossing into pixel space costs fidelity and loses identity, and both facts should be visible in your graph instead of quietly changing what a pin means.

What it's not

Two things worth stating before the wiring, straight from the node's own documentation:

It is not verified. There's no file to hash - frames arrive on a wire and may have been graded, upscaled, cropped or composed on the way. self_id stays empty, so a take saved from a pin on this bundle records itself as a ROOT rather than claiming a lineage it can't prove. You get a real clip; you don't get a claim about where it came from.

It is not exact. A VAE round trip is lossy, so continuity across the join is pixel-grade, not latent-grade. Apply says so in the log whenever a pin's origin is encoded.

Neither of those is a bug. They're the honest description of "I only have pixels".

The inputs

images takes the decoded footage - and only the kept window gets encoded, so decode as little as you need. latent is the target clip's empty AV latent, exactly as wired to Apply and the sampler: only its resolution is read, and your frames are resized to it, so a pin can't mismatch the canvas.

fps is where people get burned. It declares the footage's own frame rate, default 24, and it has to be declared because an IMAGE wire carries no timebase - nothing here can measure it. Anything other than 24 is resampled by floor-indexed CFR. A wrong value pins at the wrong speed, and "wrong speed" looks like a motion problem, not an fps problem.

keep handles footage that doesn't fit H3's 17k+5 clip grid or exceeds max_frames: tail if you're extending (the pin comes from the end), head if you're prepending. max_frames caps how many frames to encode from that end - 0 means all of them, and the VAE cost is per frame, so a 22-frame pin wants about 22 frames and not your whole clip. fit decides how different aspect ratios meet the target canvas: cover crops, stretch distorts, and cover is the right call for a continuation because the pinned content has to line up geometrically with what follows.

Both VAEs are required: video_vae and audio_vae. Yes, even for silent footage - a pin's audio has to be encoded silence, not an empty latent.

Optional audio is the footage's soundtrack, aligned with frame 0 of images. Absent, the pin carries silence. Output is a single mctx bundle with the same shape as a loaded one, so Pin Spec, Apply, Trim and Save need no idea this path exists.

Install

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

Restart ComfyUI. No Python deps - the pack declares none because ComfyUI already ships torch, safetensors and av. ComfyUI 2026-08-13 or later. In Manager, search comfyui-obvpm-timeline; every node ends in (obvpm), so obvpm finds them all in the node menu.

You'll need the H3 video VAE and audio VAE on disk for this one to do anything.

Troubleshooting

• The join looks soft compared to a normal extend. Expected. You're pinning encoded pixels, not the generation's own latents, so the model re-renders a window it only approximately has.
• Motion plays at the wrong speed. Check fps against the actual footage. This is the single most common mistake with this node, and nothing will warn you.
• Resolution complaints. The target latent's resolution wins and your frames get resized to it. If the aspect is wildly different, choose cover and expect a crop.
• Clips that DO have a sidecar. Don't route them here. Load those with H3 MCtx Load (or the video loader) and pin from the sidecar - that path is exact, hash-checked, and never touches a VAE. The pack's own wording: clips that have a sidecar must keep using it.
• The take saved as a root. That's the design, not a failure. An IMAGE wire carries nothing to hash, so there's no lineage edge to record.

Being able to continue footage H3 didn't make is the neat part. Just don't expect the first generation off an imported clip to look like a native extend - it's a slightly softer starting point by construction.