H3 Feasible AV Timeline

Ask for five seconds from a video model and you'll usually get something adjacent: 121 frames, or 4.96 seconds, or a number that only makes sense once you know the model's frame grid. MiniMax H3 clips run 4–15 seconds at 24fps (MiniMax H3 panel), and "the length I asked for" and "the length the model can produce" are two different numbers. This node is where the pack reconciles them into a plan instead of a surprise.

What it does

It builds a deterministic, frame-grid-aligned audiovisual timeline. The planner reads an accepted mode/retention report, caller-owned typed events, the intent graph and the resolved directives, and lays out half-open shots that cover the requested target duration. It doesn't inspect your media and it doesn't ask a model to fill gaps - its docstring says it plainly: "It does not inspect media or ask a model to fill a gap."

The frame grid is a real object in the code, not a rounding afterthought. It's configured as 24fps with an explicit frame-rounding policy, and for the 24fps grid the strict policy rejects durations that don't land on a representable frame boundary rather than silently shaving them. That's why the sidebar shows you "delivered seconds and frame count" next to your requested duration, and why generated segments get marked snapped when H3 returned a marginally different length than you typed. Better to see the snap than to discover it in the edit.

What comes out is a bounded structural hand-off: ordered shots, ordered reference anchors, and explicit statements about exact text and audio continuity. The planner caps its input at 512 events, 128 shots and 128 anchors, and fails closed rather than dropping something to fit.

Inputs and outputs

Six required inputs - no widgets at all, which tells you it's a consumer, not a control surface:

• request - the current H3_CONTEXT_REQUEST.
• reference_registry - the current registry.
• intent_graph and intent_report - the authorized intent and its authority report.
• directive_authority and directive_report - the resolved directives and theirs.

One output: feasible_timeline (H3_FEASIBLE_AV_TIMELINE). It goes into H3 Hierarchical Evidence Reduction, and from there the chain continues to semantic planning and the acceptance gate.

If you're wondering where the reports come from: they're produced by the nodes one stage earlier - H3 Intent Graph Producer and H3 Directive Authority Producer. Each producer emits its value and a report, and the planner wants both because a report is how the planner knows the value it's planning against is current and unmodified.

Install

Not in the Comfy Registry yet, so clone it:

cd ComfyUI/custom_nodes
git clone https://github.com/rookiestar28/ComfyUI-MiniMaxH3-Studio.git
# restart ComfyUI

The package declares no Python dependencies, downloads no models at install, and the sidebar extension is prebuilt. Python 3.10+ and, if you plan to actually generate, the native ComfyUI MiniMax H3 nodes plus official H3 weights. Planning a timeline needs none of that - the whole node is pure deterministic Python, and examples/minimal_core_pipeline.py in the repo runs this stage without ComfyUI at all.

Why you'd reach for it

Most people should meet it through the sidebar, where duration resolution is handled for you: you type 4 to 15 whole seconds, the extension converts it and shows the delivered length, and Start H3 App Mode stays disabled until it resolves. On the canvas, the node is what you reach for when you're building your own graph and want the same guarantee - one duration, resolved once, used everywhere, so there are never two conflicting length settings in the same workflow.

It's also the stage that catches contradictions early. A cut placed inside a line of exact dialogue, or an anchor order that doesn't match the registry, shows up as a timeline status - complete, partial, blocked, conflicting - rather than as a weird-looking render twenty minutes later.

Gotchas

The reason it's strict about the 24fps grid is that H3's own duration normalisation runs at that frame rate, and a plan built on a duration the model can't produce is a plan that lies. So don't fight it: give it whole seconds, let it tell you the frame count, and if your plan really needs a specific millisecond, put that requirement in the hard constraints where it belongs - as something to be honoured and reported, not silently rounded.

One more thing worth knowing: this node plans an audiovisual timeline but doesn't decide how audio gets there. Whether the soundscape comes from your reference clip, from an exact dialogue line, or is explicitly silence is a decision made upstream by the intent graph and the directives. The planner's job is to make sure the plan you ordered is one the model can actually deliver.