Save as Animated WebP

You made a loop, and now it has to play somewhere that isn't your output folder. An MP4 won't autoplay inline in most of those places. A GIF will, but it's 256 colours, so your gradients and skin tones come back looking like they were faxed. Animated WebP threads that needle: autoplays like a GIF, carries full 24-bit colour, has real alpha.

Save as Animated WebP is this pack's export node: the front half of its sibling Save as GIF (frame-dropping, box scaling, tone curve) with the palette-and-dither block swapped for libwebp's three knobs. No palette to pick, nothing to dither.

Why this and not the stock node

ComfyUI already ships a SaveAnimatedWEBP and it works fine - but it takes an IMAGE batch, not a VIDEO, so the common case means breaking your clip into components and remembering its rate. This one takes the VIDEO directly and reads the rate off it. It's also the pack's return leg: Load GIF as Video reads animated WebP back in as a VIDEO, so a loop can go out and come back as source.

How it works

Resolve the source: a connected video contributes its own frames and frame rate, or an images batch is timed by source_fps. Both is refused - two frame rates is an argument the node can't win.

Then the shared pipeline - drop frames down to fps (same wall-clock duration, fewer frames), scale into the width × height box keeping aspect ratio, apply gamma, round to 8-bit RGB. Only then does libwebp get involved, through Pillow's animated-WebP writer. The encode runs in memory, the bytes land in your output folder as {filename_prefix}_{counter:05}_.webp, and the node then reads that file back to build the images output. Lossless, that's bit-exact; lossy, it's what a viewer sees - which is what you tune quality against. Nothing hits disk until the encode finishes, so a cancel leaves no half-file.

Hard limits before you hit them: 10,000 frames, 8,192 pixels a side, fps capped at 60.

The inputs you'll actually touch

The two optional slots are the decision - video or images, one or the other. Everything else is a required widget with a usable default.

• fps (12) - the rate the WebP is written at. Below the source rate it drops frames: same running time, fewer frames, smaller file. Roughly linear, and it costs nothing in the frames that survive. Above the source rate it does nothing; duplicating frames buys bytes and shows nothing new.
• lossless (on) - every pixel stored exactly. Off gives lossy VP8, dramatically smaller on rendered material. The author's own numbers on a 192×192 twelve-frame clip: GIF at 64 colours 161 KB, lossless 140 KB, lossy at 80 about 5.8 KB.
• quality / method - under lossy, quality is the familiar dial. Under lossless both only change encoder effort; the pixels are exact either way, so don't chase it. The README's own note: quality 100 with method 6 took fifty times as long and came out 4% larger.

Beyond those: width/height, where 0 means keep the source or derive from the other axis, size_mode choosing pad (exactly that canvas, transparent bars) or fit (box as an upper bound, no bars), and resample, where nearest is the specialist that keeps pixel art and hard-edged animation crisp. loop_count 0 loops forever.

Two outputs. images is the frames as written - into Preview Image, or diffed against your input. info is a STRING with filename, real byte size, frame count, canvas, rate and runtime; wire it to Preview as Text (PreviewAny) and tune against that.

Install

ComfyUI Manager → search the pack title Load GIF as Video, or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/id-fa/ComfyUI-LoadGifAsVideo

Restart ComfyUI. There's genuinely nothing to install: the pack's pyproject.toml declares an empty dependency list, and Pillow, NumPy, PyTorch and PyAV already ship with ComfyUI. No requirements file exists here, whatever a guide tells you. You do need a ComfyUI recent enough to have the VIDEO type (comfy_api.input_impl); older builds load the node and raise when it runs.

Common issues

"Video failed to load / Invalid URL" on the node. Not your file. ComfyUI's frontend reads "has a VIDEO input slot" as "preview this node as video", and an unconnected slot counts - so it hands your .webp to a video player and the URL parse throws. The pack ships web/save_as_gif_preview.js to pin the preview back to image; if you see the error, that script didn't load. Update the pack, then hard-refresh the browser (Ctrl+Shift+R).

"Connect either video or images, not both." You wired both. Related: "Connect a video or an images batch to save" when neither is linked.

The images preview doesn't match the file. With pad, the bars are real alpha in the WebP, but images has no alpha channel, so they come back black. The picture itself is always opaque - neither VIDEO nor IMAGE carries alpha in ComfyUI, so composite upstream if you need transparency inside the frame.

Keep the MP4 or PNG sequence as the master, though. Once a clip has been through lossy VP8 there's no way back - let this node make the copy people look at, not the one you archive.