Sweet Tea Preview Video From Images
Watch your frame batch move, without dropping a file in output/
- images
- audio
A ComfyUI IMAGE batch is just frames in a tensor - there's no timing in it. Nothing says whether those 81 frames are three seconds or eight, which is why this node makes you state a frame rate and refuses to guess one.
SweetTeaPreviewVideoFromImages takes an image sequence, encodes it once into a video, and hands it back as a preview stored in ComfyUI's temp directory. Nothing lands in output/. No prefix, no counter, no duplicate - run it ten times while dialing in motion and you have zero files to go delete afterward.
Where it comes from, and who it's for
One of four nodes in tea-time-labs/sweet-tea-nodes, a pack whose headline acts are a tiled upscaler and a pair of Wan VACE nodes - so a plain video-preview node looks like an odd duck until you know the context. The author (tea_time_labs, publisher id jkotieno) built Sweet Tea Studio, a producer-style front end that drives your local ComfyUI with exported workflows and keeps its own gallery and metadata database. If Studio persists the media, an output node that also writes a permanent file into output/ saves everything twice. Hence the pack's media_output module: transports that publish media to the client without a duplicate save. Not a Studio user? It's still a tidy no-clutter preview for AnimateDiff, LTX, Wan, or anything ending in an image batch.
How it works
Three code paths, and which one you hit is decided by codec, pixel_format, and bitrate_mbps.
If codec is auto, h264, or av1 and pixel_format is auto and bitrate_mbps is 0, it uses ComfyUI's own native video encoder: it builds a Types.VideoComponents from your frames, optional audio and a fractional frame rate, wraps it via InputImpl.VideoFromComponents, and lets core write the file. That's the well-behaved path - and why this node wants a reasonably current ComfyUI build. Pick anything else (h265, nvenc_h264, vp9, an explicit pixel format, a real bitrate) and it falls back to a direct PyAV encode. GIF is its own third path through Pillow.
Either way the file lands in ComfyUI/temp/sweet_tea_preview_<random>.<ext> and comes back as a UI descriptor tagged type: "temp" with animated set, which the front end renders as a playing preview. The node has no outputs - it's marked as an output node, so ComfyUI always executes it when you queue the graph.
The inputs worth setting
images and frame_rate are the two that matter. frame_rate defaults to 24 and takes 1 to 120; it only sets playback timing, so 81 frames at 24fps gives you a 3.4-second clip out of a generation possibly sampled at 16fps. Get that wrong and your motion looks sped up or syrupy - it isn't the model, it's the number.
format and codec have to agree: WebM accepts av1, vp9, or auto; the GIF container accepts the GIF codec or auto. auto resolves by codec - GIF means GIF, AV1/VP9 mean WebM, everything else MP4.
crf defaults to -1, meaning "use the encoder's default," not "best quality." Drop it to 18-23 for H.264 and you'll see a difference. Raising bitrate_mbps above 0 forces a constant bitrate instead of CRF, so leave it unless you want a target size.
bit_depth and color_space are paired: on auto, 10-bit is chosen only when color_space is HDR or HDR PQ, otherwise you get 8. The 10-bit path converts to a 16-bit tensor and feeds rgb48le - more faithful on gradients, but it wants H.265 or NVENC to carry it, and those reject any color space but sRGB.
The optional audio input takes a ComfyUI AUDIO and muxes it in - AAC normally, Opus for WebM, mono/stereo/5.1 by channel count - trimmed to the video's exact length instead of trailing off past your last frame. GIF plus audio is a hard error, which is fair.
Install
ComfyUI Manager, search for Sweet Tea Nodes, install, restart. Or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/tea-time-labs/sweet-tea-nodes.git
The only declared dependency is tqdm. PyAV, NumPy and Pillow aren't installed by this pack - the code uses the ones ComfyUI already ships, so there's no separate environment step. No models, no weights, no licenses. One real requirement: your ComfyUI has to be new enough to expose comfy_api.latest with native video support.
Where people get burned
The commonest one is a hard stop, not a bug:
SweetTeaPreviewVideoFromImages requires a ComfyUI build with native VIDEO support
That import happens before any branch runs, so an old ComfyUI fails on the GIF path too. Update ComfyUI; installing this pack won't fix it.
Second: "the video vanished." It didn't. It's in ComfyUI/temp/, named sweet_tea_preview_*, and temp/ is scratch space by design - the same directory PreviewImage writes to. If something cleaned the folder, it's gone, and that's the trade you accepted by mounting a preview node instead of a save node. When you want the file kept, wire SaveVideo (or VHS's combine node) in alongside this one.
Then the combination errors, all of which are the node telling you off politely: GIF output requires GIF or Auto codec, WebM output requires AV1, VP9, or Auto codec, GIF output does not support audio, and Custom H.265/NVENC/VP9 output currently supports sRGB only. Every one is a real mismatch, not a quirk.
And if a 10-bit HDR preview won't play in your browser, that's the file doing exactly what you asked for in software that can't handle it - set bit_depth to 8 and color_space back to sRGB and it's universally playable.
Inputs (10)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | — | |
| frame_rate | FLOAT | 241–120 | — |
| format | COMBO | mp4 | 5 options: auto, mp4, mkv, webm, gif |
| codec | COMBO | auto | 7 options: auto, h264, h265, nvenc_h264, av1, vp9, +1 |
| crf | FLOAT | -1-1–100 | — |
| bitrate_mbps | FLOAT | 0.00–10000 | — |
| pixel_format | COMBO | auto | 5 options: auto, yuv420p, yuv420p10le, yuv444p, yuv444p10le |
| bit_depth | COMBO | auto | 3 options: auto, 8, 10 |
| color_space | COMBO | sRGB | 3 options: sRGB, HDR, HDR PQ |
| audioopt | AUDIO | — |
Outputs (0)
No outputs