Serving Image/Video Output

ServingOutput - displayed as "Serving Image/Video Output" - is where your generation actually leaves the building. Every serving workflow needs at least one of these at the end: you feed it the image from your sampler (or wherever in the graph), and it hands the result to the serving entry point - Discord, Telegram, HTTP, or WebSocket - which then sends it to whoever asked. No ServingOutput, no image. The request's requester just hangs.

The node's one genuinely clever behavior is what happens when the image input is a batch rather than a single frame. Feed it one image and you get a static image back. Feed it a batch - AnimateDiff frames, a multi-frame sample, anything where the tensor has more than one frame - and the toolkit compresses them into a single animated WebP and sends that instead. The README frames this as "if you return more than one image it will create a video," and that's exactly what a Discord/Telegram reply or an HTTP response ends up containing: a looped, lossless WebP.

That's what frame_duration controls. It's the milliseconds each frame stays on screen, and the author's guidance is the useful bit: if you know your FPS, set it to 1000 / FPS. For a 30ms default you get a roughly 33fps animation; want a slower, more cinematic 8fps loop? 125ms. It defaults to 30 and only matters when you're returning more than one frame, but it's the difference between a smooth animation and a frantic flicker.

Inputs:

• image - your IMAGE tensor, straight from the VAE decode or whatever's downstream.
• frame_duration - ms per frame for batch output (use 1000/FPS).
• serving_config - the config from your entry point node.

The optional chained_execution input is a SHOULD_EXECUTE signal you can feed from another output node. That's the toolkit's chaining trick: you can run several outputs in sequence (say, ServingTextOutput for a status message, then this node for the image) and each one's output tells the next to fire.

This node also returns a SHOULD_EXECUTE signal, which is how you chain more work after it. It's technically not marked as an output node in the code, which is why the docs can feel confusing - it does send data back through the serving layer, but the SHOULD_EXECUTE return is what lets the graph keep going afterward.

Install is just the pack install (ComfyUI Manager, or clone + pip install -r requirements.txt) - this node adds no dependencies of its own, everything it needs comes from the shared toolkit. And the one rule that never stops being true: because the node waits for a request to serve, Auto Queue has to be on for the workflow to keep running and actually deliver anything.