MiniMax H3 DLSS-NR Video Frames / 帧序列超分 (T8 Advanced)

Here's the DLSS-NR node you want when the video is already sitting in your graph as an ordered IMAGE batch - the classic case being frames straight out of an H3 VAE decode. The image version of this node processes each frame in isolation, which is fine for stills and wrong for video: denoise a clip frame-by-frame and the noise-reduction "decisions" flicker between frames, which reads as crawling shimmer. The trick this node pulls is that it streams the whole batch through one persistent external process, so DLSS's temporal denoising state carries over from frame to frame the way it's supposed to.

It does not interpolate, it does not reorder, and it doesn't touch your audio. Feed it an ordered batch and you get back the same number of frames in the same order, just cleaned and optionally upscaled.

How it works

The mechanism is the "persistent process" bit, and it's why this is its own node rather than a mode on the image one. Spawning video2dlssnr per frame throws away the temporal history that makes the NR good; keeping one process alive across the batch is what lets DLSS track motion and reuse information between neighbors. Partial pipes, crashes mid-stream and cancels all fail loudly rather than returning a half-processed batch - you don't get a silently truncated clip.

The inputs that matter

Same family as the image node, so skim past the familiar ones: mode = sr_nr, scale = 2.0, quality_profile = standard, plus the full NR manual controls if you drop to custom. The ones that are new:

• frames - the ordered IMAGE batch. Order is your contract; the node trusts it.
• fps - default 24. Tells the motion engine what "one frame of motion" means.
• motion_engine - auto is fine; nvof forces NVIDIA's optical flow, lk is the lighter Lucas-Kanade path.
• audio (optional) - if you pass an AUDIO object it comes out the other end bit-identical on the audio output. The node doesn't decode or re-encode it; it just babysits it through the pipeline so you don't have to reattach it afterwards.

Outputs are candidate_frames, source_frames, audio, and report_json.

Installing and running it

It's the same story as every DLSS-NR node in this pack - this one is not standalone:

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"), then restart. The frame route adds no new pip packages - no extra PyTorch, no safetensors - but it does require the external Windows runtime under ComfyUI/models/DLSS-NR/1.3/ and a READY from the Runtime Audit node first. Driver 616.56+, full v1.3 release (not light), and only the images route uses your existing ComfyUI Torch/NumPy/PyAV environment.

Where people get tripped up

• Don't run this on a batch that isn't ordered. Shuffled or re-spliced frames make temporal NR chase motion that isn't there, and you'll swear the node is broken when it's your frame order.
• It's Windows/RTX-only. Same as the rest of DLSS-NR; on other platforms the audit upstream never goes green.
• Audio out is the same object, not a copy. If you're used to nodes that return re-encoded audio, the identical-byte pass-through here is deliberate - the pack's own encoding is handled elsewhere.
• Red nodes after install usually mean your ComfyUI is too old for the pack's native H3 support. Update ComfyUI + front-end + Manager and fully restart before touching anything else.