Save Video Lossless (Ultrafast)

Despite living in an attention-kernel pack, this node has nothing to do with attention, MiniMax, or GPUs. It takes a VIDEO and writes an H.264 MP4 at CRF 0 with the ultrafast preset. That combination is either exactly right for you or completely wrong, and it's worth knowing which before you point it at a 345-frame render.

If you're benchmarking, it's right. A codec that decides for itself what counts as "visually lossless" is a variable you don't want in a quality comparison, and the pack's own harness uses this node to archive every clip it measures. If you're posting to a forum or dropping a clip into Discord, keep scrolling - use core SaveVideo or SaveWEBM and save yourself several gigabytes and a CPU encode.

What it actually does

The whole node is a handful of lines. It resolves output_path, creates the parent directory, encodes to a temporary dotted filename, then renames it into place so an interrupted run never leaves a truncated MP4:

video.save_to(str(temporary), format=VideoContainer.MP4,
              codec=VideoCodec.H264, crf=0, preset="ultrafast")

That call goes through ComfyUI's comfy_api VideoCodec/VideoContainer utilities, so you need a ComfyUI new enough to have that API surface - the pack targets 0.38.x and 0.39.x, which do. The resolved path is published back to the UI, and there are no outputs at all: it's a terminal node, wired at the end of the graph like any other saver.

About the name. CRF 0 is the rate-control setting that tells x264 to spend whatever bitrate it takes to reproduce the input, and ultrafast is the preset that tells it not to be clever about finding redundancy. So you get frames that match your render, in a file that is much larger than the same clip at CRF 18, from an encode that still takes real CPU time. Calling it "lossless" is the author's shorthand; it's a benchmark-archive setting, and it's honest about its priorities.

Inputs

• video - a VIDEO. Core CreateVideo emits this, as do the video loaders. If your VIDEO carries an audio track, the MP4 gets audio; if it doesn't, you'll get a silent file and blame the encoder. Check where the audio went before you file a bug.
• output_path - a string, default /tmp/comfyui_lossless.mp4. This is an absolute filesystem path, not a filename_prefix - the node completely ignores ComfyUI's output directory and its naming conventions. Tildes expand. Keep the .mp4 extension, since the container is hardcoded to MP4.

Put it after your CreateVideo:

VAEDecode ─┐
           ├─> CreateVideo ─> Save Video Lossless (Ultrafast)
VAEDecodeAudio ─┘

Installing

ComfyUI Manager, searching the pack title, is the easy path - it's on the registry under publisher zechengtang, node ID comfyui-spark-h3. Manual install:

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/zechengtang/Spark-H3
# then restart ComfyUI

The release ZIP route is the officially supported one for the pack, because the Spark attention nodes need an architecture-specific comfy-kitchen wheel built for SM86, SM89 or SM120:

cd /path/to/ComfyUI/custom_nodes
unzip /path/to/ComfyUI-Spark-H3-<version>-linux-x86_64-sm120-cu130.zip
/path/to/ComfyUI/.venv/bin/python ComfyUI-Spark-H3/install.py

This particular node needs none of that - no CUDA kernel, no comfy-kitchen, no extra Python packages. It leans entirely on ComfyUI's own video save path, so whatever encoder support your ComfyUI install already has is what you get; if core video saving works for you, so does this.

When it breaks

A tiny file, or a file that won't open. Almost always a path problem: the node creates the parent directory, but it can't write to a path it has no permission for, and a network share that disconnects mid-encode gives you a truncated temp file that never gets renamed. Encode locally, copy after.

The file is comically large. That's not a bug, that's CRF 0. If your workflow runs at 1344×768 for several hundred frames, expect hundreds of megabytes at least - and if you're looping over a benchmark grid, budget the disk before you start.

You want to share it. Re-encode. Nothing stops you from keeping the CRF 0 master and making a small copy for posting, and that's the sane split: the archive stays faithful, the upload stays small.