H3 Latent Info
The lazy way to know your H3 video's real size — without decoding it
- latent
- width
- height
- length
- fps
MiniMax H3 latents are lying to you, in a friendly way. The numbers you see on a latent are in latent pixels and latent frames, not the video you're actually going to get out. H3 Latent Info (TuringUtilsH3LatentInfo) is the one-node way to know the truth: it tells you the decoded pixel width, height, frame count, and the model's 24 FPS rate, straight from the latent tensor - no VAE decode, no guessing.
You reach for it the moment a workflow hands you an H3 latent and you need to know what it actually is. Decoding just to read dimensions is a waste of VRAM and seconds. This node is free. That's its whole job, and it does it in about three lines of tensor math.
What it reads
Feed it one thing:
latent(LATENT, required) - any H3 video latent, or a nested AV latent (the kindH3 Concat AV Latentproduces). It peels the video stream out automatically, so you don't need to separate it first.
You get four outputs:
widthandheight(INT) - the decoded pixel dimensions.length(INT) - the frame count you'll actually get after VAE decode.fps(FLOAT) - always24.0for H3.
Wire those INTs into whatever needs them: a text display node, resolution math, or a node that has to match the target canvas. That last one is the real use - see below.
Where the numbers come from
H3's VAE downsamples space by 16x, so width = latent_w * 16 and height = latent_h * 16. The temporal side is the sneaky part. H3 doesn't do arbitrary frame counts; it lives on a 17*n + 5 frame grid, and the latent encodes that as T = 5n + 2 (a single frame is T=1). So a T=7 latent is really 22 output frames, and T=12 is 39. That's exactly why people get clips back that are two frames short or four frames long - they assumed latent T was linear in real frames. It isn't. This node does the 17*n + 5 math for you so you never have to.
Wiring it in
The one workflow where it earns its keep: H3 Keyframes resizes your keyframe images to match the decoded canvas of whatever latent you connect to it. Plug H3 Latent Info into that latent and into a text/display node, and you'll see exactly what canvas H3 Keyframes is about to target - before you burn a run discovering the mismatch the hard way.
Installing it
This comes from the ComfyUI Turing Utils pack (repo wjie98/comfyui-svdint4; the README still calls it by its old name, comfyui-turing-utils). Easiest path is ComfyUI Manager - search "svdint4" or "Turing Utils". Or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/wjie98/comfyui-svdint4
Then restart ComfyUI. requirements.txt ships only safetensors. The CUDA kernel is a separate, explicit step - and here's the nice part: this node doesn't need it. Latent Info is pure Python tensor shape math. You can use all seven of the H3 reference nodes before you ever compile anything. The kernel (see the pack README: python -m pip install -v --no-build-isolation -e ./kernel) only matters when you actually run the 32B model fast on a Turing card.
The one real gotcha
It will only read H3-shaped latents. Feed it a normal image latent or a Wan latent and it raises Expected H3 video latent [B,24,T,H,W] rather than quietly returning garbage - which is the correct behavior, honestly. If you see that error, the latent isn't H3's, full stop. And if length looks "wrong," run the 17*n+5 check: if your latent isn't on the canonical grid, it's not a valid H3 latent in the first place.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| latent | LATENT | — |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| width | INT | — |
| height | INT | — |
| length | INT | — |
| fps | FLOAT | — |