H3 MCtx Load (obvpm)
Skip the decode and extend straight from the latents
- mctx
- pin_specs
- latent
An extend in H3 doesn't need to look at your clip. It needs the clip's latents. H3 MCtx Load is the fast path: it reads only the motion-context bundle out of a take's .mctx.safetensors sidecar and never decodes the video at all.
That's a meaningful difference from the usual continuation dance, where you decode a clip to frames, re-encode the tail to latents, sample, and then act surprised when the join changes grade. A VAE round trip is lossy, and every extra one you pay is quality you can't get back. This node hands the stored latent to the sampler untouched.
What you get out of it
Wire latent into an upscaler or straight back into a sampler when you want the clip's own material without a decode. It's the clip's stored AV latent (video + audio) exactly as the sampler produced it; when you only want the picture stream, split it with Separate AV Latent. That's the path the bundled workflow uses to keep the audio and video streams apart for a latent upscale.
mctx is the latents-plus-header bundle the pins pipeline consumes - feed it to H3 MCtx Pin Spec. pin_specs is the convenience output described below.
The three widgets
clip is a dropdown of videos in the output folder - the place takes land. It's an enum, so it only lists files that exist; if your take isn't in the list, you haven't saved it there or you're pointed at a different output folder.
create_pins is the whole reason this node is pleasant instead of fiddly. Set it to extend (pin tail) and the node emits a ready-made pin spec for this clip's tail, so the next generation continues after it. prepend (pin head) pins its head, so the next generation leads into it. Off-grid edges of continuation clips get auto-shifted to the nearest latent-grade cut and the log tells you the seam frame. Wire pin_specs straight to H3 MCtx Apply Pins and skip H3 MCtx Pin Spec entirely.
pin_window picks how much context the pin carries: 39 is the everyday choice and the shortest masked-legal window; 90 pins more motion at the cost of more of your new clip. The other options on the ladder are 22, 5, 56 and 1. Five frames is barely fluid; 22 is nearly seamless.
What it refuses to do
There's no pixel fallback here, deliberately. If no sidecar pairs with the file - the clip was imported, re-encoded, re-muxed, or its sidecar was deleted - the node refuses rather than quietly degrading. The pairing is hash-verified: identity is the SHA-256 of the MP4, so touching the file in any way breaks it.
That's the trade. This is the fast, exact route and it has a hard requirement. For clips without a sidecar, use H3 MCtx Load Video (which decodes and can fall back to pixels), or H3 MCtx From Frames for imports.
Install
cd ComfyUI/custom_nodes
git clone https://github.com/chanon/comfyui-obvpm-timeline
Restart ComfyUI. No extra Python dependencies - the pack declares none because torch, safetensors and av are already in ComfyUI's requirements. You need ComfyUI from 2026-08-13 or later. In Manager, search comfyui-obvpm-timeline; every node in the pack ends in (obvpm), so typing obvpm into the node menu lists all of them.
Troubleshooting
- "Refuses when no sidecar pairs" is the one you'll hit, and it's usually a re-encode. Saving the same clip through a different tool, trimming it in a player, or running it through a muxer all change the file hash even if the picture is identical. The sidecar becomes an orphan.
- Clips from other workflows. They load fine with a sidecar, and continuity is applied automatically where it can be - but a clip with no sidecar at all has no latents to hand you, and no amount of wishing changes that.
- Pin doesn't land where you cut. Latent-grade cuts sit on H3's 17-frame grid, and a convenience pin auto-shifts to the nearest legal frame rather than failing. The log states where the seam actually landed - read it before blaming your prompt.
- Disk. A sidecar stores the full unsliced latents plus optional blob JSON, so it's not small. If you're deleting sidecars to save space, be aware you're deleting the extendability of those takes, not just a cache.
Where it earns its place: iteration. In a session where you're extending the same clip twenty times to hunt for the right continuation, this node is the difference between a fast reload and a decode you didn't need.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| clip | COMBO | A video in the output folder with an mctx sidecar (saved by the H3 MCtx save nodes). | |
| create_pins | COMBO | none | Also emit a ready-made pin spec for this clip: 'extend' pins its tail so the next generation continues after it; 'prepend' pins its head so the next generation leads into it. Off-grid edges of continuation clips are auto-shifted to the nearest latent-grade cut (the log states the seam frame). Wire pin_specs straight to H3MCtxApplyPins. Use H3MCtxPinSpec instead for explicit at_frame cuts, audio windows or multi-pin stacks. |
| pin_window | COMBO | 39 | Context window for create_pins. 39 is the everyday choice (and the shortest masked-legal window); 90 pins more motion at the cost of more of the new clip. |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| mctx | OBVPM_H3_MCTX | The clip's latents + header for the pins pipeline. |
| pin_specs | OBVPM_H3_PINSPECS | Ready-made pin spec per create_pins; empty when none. |
| latent | LATENT | The clip's stored AV latent (video + audio), exactly as the sampler produced it. Split it with Separate AV Latent to reach the video stream on its own. |