H3 Super: TAEHV Decode / TAEHV解码 (Advanced/T8)
The fast decode that ends H3 Super — TAEHV wide, not the full LTX VAE
- latent
- taehv
- frames
- report_json
At the end of the H3 Super Acceleration pipeline sits a small but essential step: turning the refined LTX latent back into pixels. If you've used SD's TAESD, you know the pattern - a tiny autoencoder that trades a little fidelity for a massive speedup, good enough for previews and, in this pipeline, for final output. TAEHV is madebyollin's equivalent for video, and the "wide" variant (taeltx2_3_wide.pth) is the one built for the LTX-2.5 latent space that the refiner works in. This node is the fast decode step.
Why use a fast codec at all instead of the full LTX-2.5 video VAE? Two reasons, both explicit in the pipeline's design. First, decoding with the full VAE is expensive and the TAEHV wide path is the published NVIDIA-companion choice for this exact stage - it's what the official Stage 2 uses for the final decode. Second - and this is the part that trips people up - the fast codec is only for the final decode. It is not the encoder. The refiner upstream was trained on the full LTX VAE's latent distribution, so encoding with TAEHV and feeding the result to the refiner would be wrong; the pack has a separate legacy encode node, and its description warns you directly not to connect its output to the refiner. Encode full, decode fast.
The inputs that matter
latent- the refined, normalized LTX video latent from your refiner stage.taehv- the loaded codec object, fromMiniMaxH3SolEngineTAEHVLoaderT8Advanced. You must load it first; this node won't load anything itself.execution_mode-auto_official(default) picks the sensible path;sequential_low_vramruns the decode in a more memory-frugal order for smaller cards;parallel_high_vram_expis the experimental fast path for cards with headroom. If your VRAM is tight, the name of the middle option is your hint.precision-bf16_official(default) orfp32_referenceif you want to check that bf16 isn't costing you anything.
Outputs: frames (the decoded images, ready for video assembly) and report_json.
Where it sits and what else you need
The decode slot is the tail of the 22-sol-engine-h3-super workflow: H3 draft → Draft-to-LTX prep → full LTX VAE encode → x2 latent upscale → LTX refiner → this node → remux with the bypassed H3 audio. Use the pack's example workflow; it's the only sane way to wire a two-model pipeline like this. And the model is your responsibility: place taeltx2_3_wide.pth in ComfyUI/models/taehv (or models/vae - the loader scans both), from the t8star HuggingFace bundle. If the loader's dropdown is empty, that's the missing piece.
Install
Same pack, same routine:
cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8
or ComfyUI Manager → "MiniMax H3 Audio T8" → restart. Update ComfyUI itself first (comfy_api.latest, native H3 support). One honest note: fast decoders exist to be fast, and TAEHV is no exception - if you're chasing every last bit of fidelity and you have the VRAM, the full VAE decode is still the reference. This node is the speed play, and in this pipeline it's the official one.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| latent | LATENT | — | |
| taehv | T8_SOL_ENGINE_TAEHV | — | |
| execution_mode | COMBO | auto_official | 3 options: auto_official, sequential_low_vram, parallel_high_vram_exp |
| precision | COMBO | bf16_official | 2 options: bf16_official, fp32_reference |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| frames | IMAGE | — |
| report_json | STRING | — |