MiniMax H3 Motion Retiming Prepare / 动作扩时二采准备 (Advanced)

Here's the counterintuitive core of the Motion Recovery system: to fix fast, overloaded H3 motion, you don't just rerun the same frames - you stretch the problem in time first. MiniMaxH3MotionRetimingPrepareT8Advanced takes the frames the analyzer flagged, expands them (each problem frame becomes a hold group of several frames), and encodes that longer video into a fresh H3 video latent. Fast motion that was crammed into too few frames now has breathing room for the re-sample to resolve cleanly.

That's the "retiming" in the name, and the reason the whole chain works. If you think about it, H3 botches fast motion partly because the movement happens too quickly relative to its temporal resolution; giving it extra frames to work with is the standard trick, done at the latent level so the V2V pass can use it. It's not optical-flow frame interpolation and it's not face repair - it's re-timing the source so the model gets a second, fairer shot.

Inputs

• frames - the pass-1 decoded frames.
• motion_plan - the signed plan from the analyzer; only the frames it selected get expanded, which keeps the VRAM and cost bounded.
• video_vae - the H3 video VAE, for encoding the expanded frames into latent.
• audio_vae (optional) and source_audio (optional) - the audio side. When provided, the node can seed the shared AV transformer with a phase-vocoder guide built from pass-1 audio.
• audio_seed_mode - follow_original_0p5 by default.

Outputs

av_latent - the longer H3 joint AV latent that the recovery composer will partially denoise. smeared_frames - a preview of the expanded/hold frames. smeared_audio_seed - the phase-vocoder audio seed (diagnostic). motion_plan and report_json pass through/report.

Install and honest expectations

Pack install once: ComfyUI Manager → search MiniMax H3 Audio T8, or git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8 into ComfyUI/custom_nodes/, restart. No pip extras, no model downloads - bring your own H3 VAEs.

The author's guidance is worth heeding: keep the final audio on pass1_original unless you've explicitly reviewed the recovered audio. The README documents a real case where the full pass-2 recovered track suddenly sounded distant mid-window before returning to normal - downgraded to diagnostic use. The audio seeding here is a guide, not a guarantee. And this is where the chain starts spending real compute: expanding frames + a joint AV forward pass on a longer latent. If you're on 16GB, respect the pack's standing advice to validate on small clips first, and don't stack EAV/STG/Restart/BlockCache on top of a first repair pass.