Write to Video
Stream frames to a video file as you generate them
- image
- IMAGE_PASS
- filepath_text
- filename_text
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.
Inputs (8)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | The images to append. A batch is appended one image at a time, in batch order, each faded in from the one before it. | |
| transition_frames | INT | 300–120 | How many blended frames are drawn between the last frame in the file and the incoming image. 0 cuts straight to it; anything above 60 is treated as 60. Ignored the first time, when there is nothing to fade from. |
| image_delay_sec | FLOAT | 2.50.1–60000 | How long each appended image is held once the fade into it has finished, in seconds. The fraction is dropped, so 2.5 holds for 2 seconds and anything under 1 second is held for a single frame. |
| fps | INT | 301–60 | Frames per second of a newly created video, which also decides how many frames a held image lasts. Appending to a video that already exists keeps that file's own rate instead. |
| max_size | INT | 512128–1920 | Longest edge, in pixels, each image is scaled to before it is encoded. 512 turns a 1024x768 image into 512x384. Frame size is fixed by the first image, so later images are fitted to it. |
| root | COMBO | Which folder the file lands in: ComfyUI's own 'output' or 'temp', or any folder added under paths.allow_write in config.yaml, listed by its own name. filename names the part below it, so '[time(%Y-%m-%d)]/clip' files each day's under a dated folder. | |
| filename | STRING | comfy_writer | Name of the video, without an extension, the codec picks one, such as '.mp4' or '.mkv'. Every prompt using the same name appends to the same file, so change the name, or put a token such as [time(%Y-%m-%d)] in it, to start a new clip. |
| codec | COMBO | How the video is compressed, which also picks the file extension. A codec this machine cannot encode is reported before anything is written. |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| IMAGE_PASS | IMAGE | The images exactly as they arrived, so this node can sit mid-chain. |
| filepath_text | STRING | Full path of the video that was written, extension included. |
| filename_text | STRING | The filename widget as it was typed, with no folder and no extension, for feeding a caption or a log. |