JR H3 → LTX Finish Media (Experimental)

What it's for

You've run the whole H3 → LTX bridge: draft in H3, latent upscale, adapter, three LTX refinement steps, Conv VAE decode. Your frames are sitting there looking good - and there are two extra ones at the end that don't belong to your video, an audio track that's LTX's take on your audio rather than your audio, and a duration that's nearly right.

This is the last node before the mux. It trims the internal LTX padding back to your original H3 timeline, and it hands you back the exact PCM that H3 generated in Stage 1.

It's a small node doing an unglamorous job, and skipping it is how you end up with a video that's 83 ms too long and audio that is nearly right.

How it works

H3 and LTX don't share a timeline grid. H3 works in 17-frame clips at 24 fps; LTX wants frame counts of the form 8k+1. So a 175-frame H3 draft has to be padded internally to 177 frames before the adapter will convert it, and 124 frames becomes 129. Those padding frames are load-bearing during refinement and garbage afterwards.

bridge_latent is where that bookkeeping lives. The adapter stamps timeline metadata into the latent it hands out - source frame count, padded frame count, fps, height, width, whether the tensor shape still matches. This node reads it, checks that the decoded images you're feeding it have exactly padded_frames frames at exactly the metadata's height and width, then slices the output back to source_frames. So 177 frames in, your original 175 out, ending exactly where the H3 draft ended.

The audio side is the same idea applied to samples. Your original_h3_audio is validated against the latent's frame count - batch size one, mono or stereo, floating point, finite, and a duration inside one 40 Hz latent tick plus a hair of the source video. That tolerance exists because H3's audio latent rounds at 40 ticks per second, so an exact sample match is impossible; what the check won't accept is a different clip, or seconds of missing audio. If it passes, the waveform is trimmed to round(frames / 24 × sample_rate) samples and passed through untouched. No resample, no time-stretch, no filler.

Out come four things: the trimmed images, the trimmed original_h3_audio, a frame_rate of 24.0 - convenient to wire into a combine node that wants to be told rather than to guess - and a status string that is the metadata JSON, which is the most useful debug output in the whole bridge.

Wiring

LTX Conv VAE decode ────────────→ images ──────┐
original H3 audio (from Refine) → original_h3_audio ─┼→ JR H3 → LTX Finish Media → Enhanced Video Combine
Adapter output latent ──────────→ bridge_latent ┘
                                                       └→ frame_rate

Note that bridge_latent is the adapter's output - the plain video latent - not the AV latent the refine setup produced. The node needs the timeline metadata from the conversion step, and the joint latent doesn't carry it in the form it reads.

Installing it

Same pack, same one-time install: ComfyUI Manager and search ComfyUI JR MiniMax H3 Node, or:

cd ComfyUI/custom_nodes
git clone https://github.com/Goldlionren/ComfyUI_JR_MiniMaxH3Node
<ComfyUI-Python> -m pip install -r ComfyUI_JR_MiniMaxH3Node/requirements.txt

Use ComfyUI's own Python, restart, hard-refresh the browser afterwards. This particular node has no extra model requirements - nothing to download, no checkpoint, no adapter. If you got as far as having frames to trim, you already have everything.

Common issues

"Decoded video geometry/frame count differs from the adapted latent." The check is exact, on purpose, and it's telling you one of two things. Either you decoded a different length than the padded timeline (a sampler that dropped or added frames), or you resized somewhere between the VAE and here. Don't. Any spatial upscaling belongs after this node - the RTX upscaler chain sits downstream of it for exactly this reason.

"H3 audio duration does not match the draft; use audio from the same Stage1 request." You're holding audio from a different generation, or from a different length. The bridge is strict about this because the alternative is a video that looks fine and drifts a second out of sync by the end, which is much harder to diagnose than an error message. Decode the audio from the same Stage 1 request that produced the latent.

Nothing came out of status. It should always be the metadata JSON. If it's empty you're looking at a node that never ran - usually an upstream stop, or the audio/latent validation throwing before the report is written.

One habit worth keeping: wire the images and original_h3_audio outputs into your video combine node and set the frame rate from the frame_rate output rather than the widget on the combine node. Hard-coding 25 or 30 anywhere in this chain is the classic way to make a perfectly good 24 fps render feel slightly wrong for reasons you can't name.