FastH3 V2 · Accepted Remainder Delivery Port (T8 EXP)

Here is the arithmetic that ruins a good continuation. You render a window of 124 frames to get 68 new ones, because 22 of those frames are context you already had. Decode the whole thing and you have duplicated two thirds of a second of video at the front of your segment. Decode from the wrong offset and you have dropped real frames. Get it right by hand once and you will get it wrong the next time you change the window length.

This node hands you the numbers instead: parent identity and exact trim coordinates, computed from the authenticated accepted window.

What it gives you

Inputs are contexts - the accepted-window object - plus total_accepted_frames (default 192) and render_policy, which is either compact_remainder (default) or old_fixed_124.

Outputs are a delivery report in the form of wiring-friendly scalars: chain_id, segment_index, parent_candidate_id, parent_manifest_revision, timeline_start_seconds, trim_start_seconds, final_duration_seconds, save_context, and report_json.

The typical 8-second case is 124 + 22 + 68. trim_start_seconds tells you to drop the decoded 22-frame context prefix; final_duration_seconds tells you the fresh material's length; timeline_start_seconds tells you where this segment sits in the film. save_context comes back false - this node is not a save, and it does not want to be mistaken for one.

The two policies, and why one of them will refuse

compact_remainder computes the frame count you actually need, and it will only return if the remainder lands on H3's native 17n+5 grid. Ask for a remainder that does not, and the node raises instead of rounding - the honest behaviour, since a window off that grid does not exist.

old_fixed_124 is for reproducing the historic V2 second window exactly. It requires the concrete 8-second contract: accepted start at frame 124, 22 context frames, 192 total frames, 68 new. Anything else and it refuses. That is not pedantry; the fixed window discards a suffix relative to the compact calculation, and the pack wants that difference to be a decision, not a surprise.

What it is not allowed to claim

Three things, all stated by the author. It does not trim - it reports coordinates, and you perform the trim in your decode or save path. It does not save a candidate or accept it. And it does not certify the current edited job contract: the parent identity is authenticated, but today's model, LoRA and prompt recipe is not proven to be the one that produced the parent. If you edited the workflow since the parent was rendered, the coordinates are still correct and the equivalence claim is not.

That last point is the one to keep in mind if you are building anything automated on top of this. The numbers are trustworthy about geometry. They are not a reproducibility guarantee.

Wiring

Where this earns its keep is any graph that saves a segment: feed trim_start_seconds into your trim/decode step, final_duration_seconds into duration or filename handling, and chain_id / segment_index / parent_candidate_id / parent_manifest_revision into whatever records which segment you just wrote. Those four identity fields are what let the next segment find this one as its accepted parent.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8

Then fully quit and restart ComfyUI - registration is at import. ComfyUI Manager install works too, searching "MiniMax H3 Audio T8". The pack deliberately installs zero pip packages, so an install cannot replace ComfyUI's Torch/CUDA stack; the FastH3 V2 checkpoint does not need FastVideo's distributed runtime either. You do need a recent Core with native H3 support, the V2 student in models/diffusion_models, plus the Qwen encoder and video and audio VAEs.

Things that will bite you

The node will happily report a window that has no valid remainder if you point it at an accepted parent whose timeline is shorter than total_accepted_frames - check the report's numbers against your own expectations before trusting them into a save node.

Then there is the audio side of trimming. Cutting a 22-frame context prefix out of the video leaves you deciding what happens to the corresponding slice of audio, and the pack's answer is consistent throughout: deliver the audio path you actually want, explicitly, because the model's sampled track and your source track are not the same object. If the seam hums or a syllable gets clipped, this is the first place to look - and it is also where the pack's own known limitation about slight colour change at continuation seams lives, so give the boundary a proper listen and look rather than a glance.