H3 MCtx Trim Pinned (obvpm)

Small node, real job. When you extend or prepend with H3, the raw output contains more than the clip you asked for: the model was handed context as pinned material, re-rendered it, and continued past it. The extra frames are scaffolding. If you decode them and preview them, your take opens on the tail of the previous clip. If you save them, your delivery has duplicated frames at the join.

H3 MCtx Trim Pinned removes exactly that scaffolding - picture and sound together - and fixes the audio length while it's in there.

What it does, precisely

Two inputs that matter: images (the decoded clip, untrimmed) and pins, the resolved pins wire from H3 MCtx Apply Pins. The trim amounts are derived from what was actually pinned during the run, not from a number you type: before pins come off the head, after pins off the tail. Wire the same pins output that fed Apply and the two nodes can't disagree about where the delivered clip starts.

With audio wired, it trims by the same durations so sound stays locked to picture, then truncates the audio tail to exactly frames/fps.

That truncation is the part people don't expect. H3 rounds its audio grid up, so each clip ships roughly 8 ms more sound than it has video for. One clip: irrelevant. A ten-clip chain: 80 ms of accumulated drift, which is exactly the sort of thing you notice as "why are the later lines slightly out" long after you've forgotten this node exists.

Outputs are the delivered images and audio, ready for H3 MCtx Save Video - or for a preview node, if you want to eyeball the join before saving it.

When you'd use it instead of the one-node save

H3 MCtx Trim and Save Video does the trim and the save in one step, and the pack recommends it as the default. This node is for when you want the pieces separate:

• You're saving through something else (VHS, or your own pipeline) and only need the trim handled here.
• You want to run the delivered frames through another node before saving.
• You're debugging a join and want to see what came off.

Worth knowing: with no pins wired, it has nothing to trim and passes the clip through as-is. That's the root-clip case, and it's not an error.

Install

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

Restart ComfyUI. No Python dependencies - the pack's pyproject declares an empty list on purpose, since torch, safetensors and av already ship with ComfyUI. ComfyUI from 2026-08-13 or later brings the core MiniMax H3 nodes this depends on. In Manager, search the pack title comfyui-obvpm-timeline; and remember every node in this pack ends in (obvpm), which makes obvpm a one-word search for the whole set.

Troubleshooting

• Nothing got trimmed. pins is unconnected. It's required, but an empty resolved-pins wire means "root clip, nothing pinned" rather than an error - so it fails silent by design. Check the Apply node actually had specs fed into it.
• Trimmed by the wrong amount. The trim follows the resolved pins, so if a window snapped down to the nearest available rung, or an off-grid cut was auto-shifted, the delivered length follows that. The log states which seam frames were used.
• Audio and picture disagree. Only possible when audio isn't wired (silent clips are a legitimate case), or when a second audio path in your graph escaped the trim. There's one trim site for a reason.
• Prepending and the clip starts too late. Same pins story, opposite end: after pins come off the tail, and if you fed Apply a hand-built spec rather than the loader's convenience pin, double-check which end you pinned.

One node, one job: deliver the clip the way it was meant to play, and keep the audio honest for the clips that come after it.