H3 MCtx Load Video (obvpm)

This is the general-purpose loader of the pack: a core-style video loader that browses your output folder - where takes land, rather than your input folder - and, when a verified sidecar is sitting next to the file, additionally hands you the clip's stored latents and lineage.

The practical upshot: one node gets you the pixels for a preview and the exact continuation material, instead of you needing to know in advance which one you want.

Inputs and outputs

clip is a dropdown of the output folder, same enum the rest of the loaders use. create_pins and pin_window behave exactly as on H3 MCtx Load: set extend (pin tail) or prepend (pin head) and you get a ready-made pin_specs output for the pins pipeline; pin_window picks 39 (the everyday window), 90 for more motion, or one of the shorter ladder rungs.

The outputs:

• video - the clip as a core-compatible VIDEO object, so it drops into anything that takes one.
• images and audio - decoded frames and the decoded track, for previewing or for a pixel-route pin.
• mctx - the latents plus header bundle, None when no verified sidecar pairs with the file.
• pin_specs - the ready-made pin spec, empty when create_pins is none.

mctx being None is not an error. It's the honest answer: this file can't be continued at latent grade, so route its images through H3 MCtx From Frames if you want to extend it anyway.

When the sidecar doesn't pair

The verification is a content hash of the video. Re-encode the clip, swap it for a different take under the same name, or run it through another saver, and the pairing fails - even when the picture looks identical to you. That's the intended behaviour: a false match would silently seed an extension from latents that belong to different pixels, and you'd be debugging a "why does the join look weird" mystery forever.

What you get instead is the pixel route: the images decode normally and the packs' own comment on it is worth repeating - continuity across a join like that is pixel-grade, not latent-grade, because the VAE round trip is lossy.

Install

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

Restart ComfyUI. No pip dependencies (the pyproject deliberately declares none, since torch, safetensors and av already come with ComfyUI). Requires ComfyUI 2026-08-13 or later, which is when the MiniMax H3 nodes landed in core. In ComfyUI Manager, search the pack title comfyui-obvpm-timeline; the (obvpm) suffix on every node also makes obvpm a one-word node-menu search for the whole set.

Before you blame the node for missing clips: it browses the output folder. If you're generating into output/h3/, put h3 in the folder the widget browses via the clip dropdown, and remember base_folder on the save nodes is what decides where takes land.

Troubleshooting

• Some clips load with no mctx. Downstream, a Save node fed from a None mctx will record the new take as a root, not a continuation. That's correct bookkeeping, but it means the take can never be crossfaded against its "parent".
• Everything loads with no mctx. You're probably loading clips that didn't come from this pack. The sidecar format (mctx_v1) is an open convention, but only clips saved by these save nodes have one.
• Off-grid cuts. With a continuation clip, the convenience pin shifts an off-grid edge to the nearest latent-grade cut and logs the frame it chose. If the log says a different frame than your cut, that's why.
• Mismatched resolution. Every clip in a continuation chain must share one resolution - latents can't be resized. Mismatches are refused loudly rather than fudged.

Reach for this one when you're building a graph by hand and want one node to give you both the preview and the continuation. If you know you only want the latents, H3 MCtx Load is faster because it never decodes the video at all.