MiniMax H3 AV Decode Safety / 音视频安全解码 (T8 Advanced)
Check the decode's VRAM bill before the VAE ever runs
- av_latent
- video_vae
- audio_vae
- frames
- generated_audio
- video_latent
- audio_latent
- report_json
The OOM usually doesn't happen during sampling. It happens at decode, right at the end, after you've already waited - the VAE unpacks the whole joint latent and the card quietly gives up. MiniMaxH3AVDecodeSafetyT8Advanced is the preflight for exactly that moment: it estimates the decode's output size and checks your current VRAM headroom before the VAE runs, and its default mode, preflight_only, doesn't decode anything at all.
This is the pack's discipline in one node. The stable MiniMaxH3AVDecodeT8 just decodes; this advanced sibling is the "read the manual before you press go" version. It takes the same three inputs (av_latent, video_vae, audio_vae) and adds a contract layer: what latent are we actually decoding, what will the output occupy, and can the card afford it?
The gates
- minimum_current_headroom_mib (512) - the pack's standard floor. The README repeatedly tests to a 512MiB headroom gate, and this node enforces the same number by default. If the report says you're under, you'd rather find out here than mid-decode.
- maximum_estimated_output_mib (8192) - the ceiling for the estimated decode output. This is a sanity bound so a mis-shaped latent (say, a canvas far bigger than you meant) fails early with a readable error instead of a VAE that silently starts eating gigabytes.
- enforcement -
report_onlywarns; the stricter option actually blocks the decode when a gate fails. Start inreport_only, read the report, then decide. - mode -
preflight_only(default) vs the decode mode. The tile controls (video_tile_size,video_tile_overlap,video_tile_temporal) are exposed for explicit tiling, but read the description before trusting them: current H3 regular decode already uses internal 256-pixel spatial tiles on big canvases, so these knobs may be ignored and are explicitly marked experimental. Don't tune them as a VRAM workaround and assume they ran.
Wiring
It mirrors the stable decode node's outputs - frames, generated_audio, video_latent, audio_latent - plus a report_json you should actually read. In preflight_only the image/audio outputs are empty; that's the point, it's a gate. Wire report_json to a text node and glance at the headroom number before every long render, or put the whole thing behind a conditional so an under-headroom result stops the chain.
Where people get burned: treating this as a decode replacement. It's a safety wrapper. If you just want frames and audio out, MiniMaxH3AVDecodeT8 is the everyday node. Use this one in Long Video chains and 16GB setups where decode is the known failure point.
Install
Standard T8mars pack install:
cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8
Restart ComfyUI. It's under T8/MiniMax H3/Audio/Experimental, needs no extra pip packages and no separate model files - the H3 video/audio VAEs are the same ones your conditioning already loaded. It belongs in the 12-system-memory family of preflight nodes, which is where the pack keeps all its "check before you commit VRAM" tooling.
Inputs (10)
| Name | Type | Default | Description |
|---|---|---|---|
| av_latent | LATENT | — | |
| video_vae | VAE | — | |
| audio_vae | VAE | — | |
| mode | COMBO | preflight_only | 3 options: preflight_only, decode_regular, decode_tiled_exp |
| minimum_current_headroom_mib | FLOAT | 5120–65536 | — |
| maximum_estimated_output_mib | FLOAT | 81921–131072 | — |
| enforcement | COMBO | report_only | 2 options: report_only, block_known_unsafe |
| video_tile_size | INT | 322–256 | — |
| video_tile_overlap | INT | 80–128 | — |
| video_tile_temporal | INT | 9992–4096 | — |
Outputs (5)
| Name | Type | Description |
|---|---|---|
| frames | IMAGE | — |
| generated_audio | AUDIO | — |
| video_latent | LATENT | — |
| audio_latent | LATENT | — |
| report_json | STRING | — |