Write to Video

Most video-from-frames nodes want the whole batch first, then encode at the end. Write to Video does the opposite: per the README, it writes "a frame as you generate to a video (best used with FFV1 for lossless images)." Each run of the node appends one more frame to a video file that's already being built, instead of collecting a batch of images in memory and encoding once at the finish line. It's the video-container cousin of WAS's Write to GIF node, and a sibling of Create Video from Path, which encodes from an already-saved folder instead of appending live.

Where this actually helps

Anywhere you're generating a long sequence and don't want to hold every frame in VRAM/RAM to hand off to a batch encoder afterward. Loop a generation, write each frame as it lands, and the video grows on disk incrementally. For short sequences, a normal batch-to-video approach is simpler; this one earns its keep on longer runs where memory is the constraint.

The part that actually catches people out

Straight from the README, not a guess: if you use anything other than a lossless codec, each write recompresses the frames already in the file, and the README's own words are that this "will start exponentially ruining the starting frames run to run." That's not a minor artifact - it's the file visibly degrading the longer you keep appending to it. Use FFV1. The node's own name in the README literally comes with that recommendation attached, which tells you how central it is to using this node correctly.

Two more things worth knowing before you wire this up:

Windows-only, by the author's own admission. The README states plainly: "for now I am only supporting Windows installations for video nodes... I do not have access to Mac or a standalone linux distro." Linux and Mac are unsupported territory - it may work, it may not, and there's no guaranteed upstream fix if it breaks on your platform, since the pack has been unmaintained since December 2023.
FFV1 throws a cosmetic warning. The README calls out that FFV1 will "complain about invalid container," even though the resulting MKV plays back fine - the author never tracked down the cause but confirms it's not a real failure. Don't let that warning make you second-guess the one codec setting you actually want here.

How it works

You feed it frames as your generation produces them, and it appends each one to a video file via FFMPEG under the hood - WAS shells out to FFMPEG binaries rather than reimplementing a codec itself, which is why FFMPEG needs to be installed and configured separately, not just the pack's Python requirements.

The inputs and outputs that matter

I don't have a formal schema for this node's exact fields, so take this as the shape of the job rather than literal widget names: an image frame goes in on each call, along with settings for where the video file lives and which codec to use. Given the README's own emphasis, expect a codec choice to matter more here than on almost any other node in the pack - pick FFV1 unless you have a specific reason not to.

How to install it

Comes with WAS Node Suite, but needs one extra piece beyond the usual pack install.

ComfyUI Manager: search "WAS Node Suite," install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/WASasquatch/was-node-suite-comfyui

then install requirements.txt against your ComfyUI Python and restart. That gets you the node - but video encoding itself needs FFMPEG installed on the system separately, with its path set in was_suite_config.json. For H264 output specifically, the README also calls for the OpenH264 1.8.0 library dropped into your ComfyUI root folder; without it, H264 won't encode even with FFMPEG present.

Common issues & troubleshooting

Frames look progressively worse the longer the video runs. This is the exact failure the README warns about - you're using a non-lossless codec and each write is recompressing the whole file. Switch to FFV1.

Nothing happens, or an error mentions a missing binary. Start with FFMPEG - it's the single most common cause and it isn't bundled or installed automatically by ComfyUI Manager. Confirm was_suite_config.json points at real FFMPEG binaries.

"Invalid container" message on FFV1 output. Per the README, this is a known, cosmetic quirk - the resulting MKV plays fine despite the warning.

Whole pack fails to import. The general WAS gotcha, unrelated to video specifically: unmaintained since December 2023, and a ComfyUI core update can desync its pinned dependencies, throwing "Import Failed" for every WAS node at once. Reinstall requirements.txt against the correct, activated Python environment and restart.