MiniMax H3 DLSS 视频插帧 2x (T8 EXP)

If the only thing wrong with your H3 clip is that it reads as 24fps - a bit of judder on pans, a slightly steppy feel that screams "video model" - this is the node for it. It takes a finished video and hands it back at 48 or 60fps by synthesising the frames in between with NVIDIA's DLSS Frame Generation runtime, rather than with an optical-flow interpolator like RIFE or GIMM. Duration, resolution and the original audio track come out unchanged.

Two things it is not, because the name will make you assume them: it is not upscaling, and it does not make H3 generate any faster. It runs strictly after everything else, on a file. It's the last node in the graph, not a shortcut through the middle of it.

How it actually works

The node is a file-level wrapper around an external binary - the author never pretends otherwise. You point it at a runtime directory containing dlssg-worker.exe and nvngx_dlssg.dll, and the node spawns that worker inside an isolated Windows job object (kill-on-close, so cancelling ComfyUI's queue kills the whole process tree instead of orphaning a stuck encoder). Before it runs anything, it hashes the worker and the DLL against pinned values and refuses to proceed on a mismatch rather than quietly producing garbage.

The other thing worth knowing: hard cuts are not detected. The only thing that stops the interpolator from inventing a hybrid frame across a scene change is the cut_frames string you type in yourself. And since it needs the whole file, the node opens it by path - if you trimmed or cropped upstream in the graph without saving to disk, those edits are silently ignored.

The finished file lands in ComfyUI's output root, prefixed H3_DLSS_FI_2x_, H.264 CRF18 - so it's a delivery encode, not a pixel-exact master. Intermediate state and the failure log live in .dlss-fi-tasks, which grows; delete those task folders once you're happy.

The inputs that matter

source_video is a native VIDEO input, ideally straight from a Load Video node on a real file. runtime_directory blank means ComfyUI/models/DLSS-FI/310.7.0. cut_frames takes zero-based indices like 24,48 - one entry per hard cut, first frame of the new shot. timeout_seconds defaults to 600 and only bounds this node's own subprocess; it does not retry.

Four outputs: interpolated_video (the new clip), source_video (passed straight through, handy for A/B in the same graph), saved_path, and report_json. The report is where the honest numbers live - real generated frames versus frames passed through at a cut, and how the audio was carried over.

Install

Grab the pack first, the usual way - ComfyUI Manager, search MiniMax H3 Audio T8, then a full restart:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8

The pack's requirements.txt deliberately installs nothing, so nothing can clobber ComfyUI's Torch/CUDA stack - but that means this node's Python-side dependencies have to already exist in your ComfyUI environment: PyAV, NumPy, OpenCV (the DIS path), psutil and pynvml. The runtime files are yours to supply too. Take the full video2dlssnr-style release from the upstream ComfyUI-NVIDIA-DLSS-Frame-Interpolation project and drop the worker plus DLL into ComfyUI/models/DLSS-FI/310.7.0/. The pack doesn't download or redistribute NVIDIA binaries and you install the upstream node pack itself - you only need its runtime files.

Where people get burned

The runtime directory is not the models/DLSS-NR folder. That's the separate super-resolution runtime from the same pack, and mixing them is the most common mistake. A hash-mismatch error means you have a different build of the worker than the pinned upstream commit (c755e274…) - download it properly instead of forcing the folder.

Then there's the input contract, which is strict by design: Windows, a single NVIDIA RTX card, constant frame rate, 8-bit SDR, square pixels, even width and height, no rotation, source under 60fps. HDR, 10-bit and VFR are refused rather than silently converted. Startup also wants roughly 12GB free VRAM and 16GB of RAM before it will begin, and it will not unload your models for you.

Two subtler refusals to expect: it rejects ranges where the source barely changes but the computed intermediate frames come out identical to both endpoints, instead of falling back to duplicating source frames, and fast motion, occlusion, on-screen text or HUD elements can produce visible artefacts. Expect to check your own footage - there's no independent community verdict on this node to lean on, so the author's clips are the whole evidence base.