Nodes/MiniMax H3 Audio T8/MiniMax H3 Native Latent Continuation Concat / 原生续段去重拼接 (Advanced EXP/T8)
ComfyUI Node

MiniMax H3 Native Latent Continuation Concat / 原生续段去重拼接 (Advanced EXP/T8)

Splicing H3 Long Video segments by removing the exact 5/22/39-frame head

By T8mars·Created 20 days ago·Updated a day ago· 807
MiniMax H3 Native Latent Continuation Concat / 原生续段去重拼接 (Advanced EXP/T8)
  • timeline_latent
  • continuation_segment
  • av_latent
  • physical_frame_count
  • visible_frame_count
  • trim_tail_frames_after_decode
  • audio_latent_steps
  • report_json
planner_report_json
conditioning_report_json
output_devicecpu
audio_context_policyrequire_video_and_audio

If you've fought with Long Video in ComfyUI, you know the pain: the model re-renders a chunk of the previous segment as context, and if you don't account for it you end up with doubled frames and audio that drifts. MiniMaxH3NativeLatentContinuationConcatT8Advanced is the node that accounts for it - the Long Video-specific sibling of the pack's plain Timeline Concat, and the one you want when your segments come from the H3 Long Video Conditioning pipeline.

Here's the difference that matters: plain Long Video generation gives every later segment a fresh 5-frame prefix. But the fancier Long Video Conditioning mode re-injects the previous tail as per-token context, and that context comes in three sizes - 5, 22, or 39 frames - depending on how much of the past you asked the model to remember. If you trim 5 frames when the model was actually working with a 22-frame context, your seam is garbage. This node reads the planner's and conditioning's own reports so it knows exactly which context was used.

How it works

The node takes your accumulated timeline latent plus the freshly sampled continuation segment, and it demands the actual report JSON from both the Long Video Segment Planner and the Long Video Conditioning node - wired directly, not pasted as text. That's the only way it can know the true context length, the media bindings, and whether the audio tail actually made it into the conditioning. No sampling, no VAE decode; it operates on the native video (24fps) and audio (40Hz) clocks and builds the combined AV latent on CPU by default.

It's also the node that handles the "hidden tail frame" quirk: a final segment can carry an invisible tail frame that exists so the model can finish cleanly, which means the physical latent has more frames than your visible timeline. The node reports trim_tail_frames_after_decode so you know to crop one frame after the single decode, rather than guessing.

The inputs that matter

  • timeline_latent - segment 0, or this node's own output from the previous continuation.
  • continuation_segment - the sampled latent from the matching Long Video Conditioning.
  • planner_report_json and conditioning_report_json - both required, both wired directly from their nodes. This is not optional; skip them and you're flying blind.
  • audio_context_policy - defaults to require_video_and_audio, because the safe claim is that the audio tail was actually supplied to conditioning. allow_video_only will still remove the overlap duration but drops any claim of audio continuity.

Outputs: av_latent, plus physical_frame_count, visible_frame_count, trim_tail_frames_after_decode, audio_latent_steps, and report_json.

Why it's trustworthy (and why it isn't magic)

The author actually ran this: a real 124+124-frame pair with 22-frame context produced 226 visible frames, with the overlap removed precisely. But the README is refreshingly honest that this fixes the mechanics - duplicate frames and clock drift - and proves nothing about seamless quality, scene continuity, or memory. "不等于NFE断点恢复、无缝质量或省显存证明" - it is not an NFE resume, not a seamlessness guarantee, not a VRAM-saving proof. If you want real NFE checkpointing, that's the separate Dual-Clock NFE Checkpoint + Resume node.

One more trap: the final hidden tail frame must be decoded once and then cropped using trim_tail_frames_after_decode. Decode-then-trim, not trim-then-decode.

Install

It ships in the MiniMax H3 Audio T8 pack - Manager search "MiniMax H3 Audio T8", or:

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

Restart, then load examples/workflows/04-long-video/2026-08-23_H3_Native_Latent_Continuation_Concat_Advanced_EXP.json. No extra pip dependencies; the pack doesn't fetch H3 weights; and Long Video final concat wants ffmpeg on your PATH (most ComfyUI builds already have it). If the node errors about the reports, check that you wired the JSON outputs of the Planner and Conditioning directly instead of running their text through something else first.

CategoryT8/MiniMax H3/Long Video/Experimental

Inputs (6)

NameTypeDefaultDescription
timeline_latentLATENTSegment 0, or the output of this node from the previous continuation.
continuation_segmentLATENTThe sampled latent produced by the matching Long Video Conditioning.
planner_report_jsonSTRINGConnect Long Video Segment Planner report_json for this segment.
conditioning_report_jsonSTRINGConnect Long Video Conditioning report_json used for this segment.
output_deviceCOMBOcpucpu keeps the combined output off GPU, but does not evict ComfyUI's cached input latents or models.
audio_context_policyCOMBOrequire_video_and_audioThe safe default requires the previous audio tail to have been supplied to Long Video Conditioning. allow_video_only still removes the overlap duration but cannot claim audio continuity.

Outputs (6)

NameTypeDescription
av_latentLATENT
physical_frame_countINT
visible_frame_countINT
trim_tail_frames_after_decodeINT
audio_latent_stepsINT
report_jsonSTRING