Delivery Video Node

The Delivery Video Node is the moving-pictures half of the pixel-socket pack from 0nyx Networks (published as "m10i"). Same philosophy as its image sibling: it's a terminal output node with no sockets coming out, and instead of writing a file to disk it takes your finished video, re-encodes it to MP4, and streams the bytes down a WebSocket to a server. If you've read the Delivery Image Node page, the shape is familiar - request_job_id, secret_token, and a websocket_url that's a placeholder by default (wss://example.foundation0.link/ws/streaming, the example. prefix is not decorative). The receiver is supposed to be a job-queue or web-app backend that handed you a job ID and is waiting for the render to come back over the wire.

This is a niche node for a niche setup: ComfyUI running headless as a render engine, not as a thing you watch. There's no community chatter around it at all - zero Reddit signal for "pixel socket" or "foundation0" - so don't expect tutorials to bail you out. The source is short enough to read, and you probably should.

How it works

The pipeline is nearly identical to the image node, with one meaningful difference at the front. Your video input - a VIDEO-typed value from ComfyUI's newer comfy_api video IO - gets saved out through video.save_to() as an MP4 container with H.264 codec. The bytes then go into the same msgpack envelope: type: "notification-from-pixel-socket" with jobId, blobData, videoLength, fileExtension, mimeType, secretToken, and a millisecond timestamp. That payload is zstd-compressed at level 22 and pushed as a single binary WebSocket frame on a connection that opens, sends, and closes. One shot per run, no retries.

The VIDEO input is the footgun. This node wants the new video-as-object primitive from the comfy_api era, not a file path. Classic video packs hand you a path to an mp4 on disk, and that won't plug into this socket. If you can't get anything to connect to the input, that's why - you need a node that emits a VIDEO-typed value (typically the newer comfy_api-style video nodes) or a converter in the chain.

The inputs that matter

• video - the finished VIDEO value, from whatever generated your frames.
• websocket_url - the wss:// endpoint that should receive the blob.
• secret_token - a shared secret the receiver checks; the default is literally the string generate_random_token, change it.
• request_job_id - which job this render belongs to, supplied by whatever queued the run.
• file_format - has exactly one option, MP4. ComfyUI's way of saying "MP4, no choice." There are no optional inputs at all.

How to install it

Same pack as the Delivery Image Node, so the steps are identical. In ComfyUI Manager, search pixel-socket-extensions-for-comfyui and install, or:

cd ComfyUI/custom_nodes
git clone https://github.com/0nyx-networks/pixel-socket-extensions-for-comfyui

Restart ComfyUI afterwards. Dependencies come from the pack's requirements.txt - msgpack-python, websocket-client, zstd, pyoxipng, plus pillow, numpy, httpx, piexif - and there are no model files to fetch. The one compatibility catch applies here harder than for the image node: the pack is written against ComfyUI's newer backend API (comfy_api.latest, a comfy_entrypoint() instead of NODE_CLASS_MAPPINGS), and the video node additionally leans on the new VIDEO primitive. Old ComfyUI builds won't load it; update ComfyUI first if the nodes don't appear.

Common issues

Silent failure, again. Every send is wrapped in try/except in the source - a failed connection prints WebSocket error: ... to the console and the node still completes. Wrong URL, dead server, bad token: green checkmark, nothing delivered. Check the terminal, every time.

Placeholder defaults. Queue it unconfigured and it connects to a domain that isn't your server. Nothing tells you it failed.

No local copy. It replaces the save step rather than adding to it, so a failed send means the video exists nowhere. Keep a save node in parallel until the pipe is proven.

The encode is real work. Before anything is sent, the whole clip gets re-encoded to H.264, which costs CPU time on top of generation. And zstd level 22 on already-compressed video bytes rarely buys much - you're paying for compression you mostly don't need, but the node's author chose it, so it's the price of admission.