沐阳 H3 · 粗剪时长拟合（内部）

Every long-video pipeline eventually grows a timeline. You generate clips, you decide where the cut goes, and suddenly there are two sources of truth for how long things are: the generation plan, and the edit. They disagree. Something has to bend.

H3DirectorPlanLimit bends the plan. It takes the storyboard JSON the Director built and squeezes it into a target length, defined in frames, so the generated content lands inside the in/out points you set on the rough-cut timeline.

The arithmetic that makes it non-trivial

If this were just "divide total frames by segment count" it wouldn't be a node. It isn't, because in this pipeline the delivered portion of a segment isn't the whole segment. Each segment from the second one onward carries overlap_frames of pinned context at its head, and that context gets trimmed away after sampling. So a segment that samples 125 frames might deliver 103.

The node does that accounting explicitly, per segment: visible frames, head trim, tail start, tail trim, conditioned frames, resolved through H3's own frame-length rules so the numbers come out on the grid H3 actually accepts. target_frames is therefore visible frames on the timeline, not raw sampled frames - which is what you want, but it's a distinction worth knowing before you assume a 120-frame target produces three 40-frame segments.

Inputs and output

• plan_json (STRING, forced input) - the storyboard plan. Must be valid JSON; if it isn't, you get a clear error saying so rather than a mystery crash.
• target_frames (INT, default 120, up to 1,000,000) - your rough-cut I/O length in frames.
• overlap_frames (INT, default 22, range 0-56) - the context window you're using. Keep this equal to what the rest of the graph uses, i.e. the same value as H3LongVideo.context_length and H3ScriptSplitter.overlap_frames. Mismatch it and the fit is computed against a duration that doesn't exist.

Output: plan_json, the fitted plan, as a string. It goes into whatever expands the seed into segments next.

Why you'd reach for it

The concrete case: you have a 30-second slot in a rough cut for a shot, you've written a plan for five segments, and the plan delivers 34 seconds. Rather than re-writing the plan by hand you drop this in, point target_frames at the slot, and let it redistribute. The same path handles a generated plan that has to fit the boundary constraints either side - the Director's rough-cut flow reads first/last frame constraints from the timeline and then needs a plan that fits between them.

Category is 沐阳 H3/导演台/内部, so it's not a node you'd normally drop on the canvas. It exists in the pack's dynamic subgraph, appears in exported graphs, and is documented so that when you open one of those graphs and can't work out why your segment durations are what they are, you have somewhere to look.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/civilcoco/ComfyUI-MiniMaxH3-Myang

Restart, hard-refresh, category 沐阳 H3/导演台/内部. No extra Python packages - the pack's pyproject.toml declares none, and this node is pure arithmetic over dicts.

You do need the rest of the H3 stack to do anything useful: an H3 diffusion model, a Qwen text encoder, video and audio VAEs. The pack ships the workflow, not the weights.

Honest limits

Two things it won't do. It won't tell you what to cut - no content judgement happens, it re-fits durations. If your plan has five story beats and the slot only fits three, the fit is applied to the durations, not to the story.

And the fit is against the plan's own structure, not against what the model will actually deliver. H3 snaps to a 17k+5 frame grid; the pack handles that, but a fitted plan is still a plan. Validate it with a two-segment render before committing a long job - the same advice the pack gives about everything else, and the reason the long-video field is full of people who discovered drift on hour three.