👺 Media Stream Input (URL)

MediaStreamInput is the inbound half of the same streaming pair as 👺 Media Stream Output (URL): where the output node uploads renders and pings a queue, this one pulls media in from a URL and turns it into an image tensor for your graph. Read that "from a URL" carefully - the presigned_download_url input defaults to the literal string <auto-filled by system>. This node is designed for a host system to hand it a pre-signed object-storage URL; it is not a general-purpose "browse the internet for an image" tool.

What it does

Three inputs: input_name (a label, default default_input), format, and presigned_download_url. The format dropdown picks how the bytes get interpreted:

• image - downloads the URL, decodes it with PIL, converts to RGB, and returns a single-image tensor.
• image_batch - treats the URL as a manifest: it fetches the JSON, which lists a set of image files (each with its own pre-signed URL and a sequence number), sorts them by that sequence, downloads them all, and stacks them into a batched tensor in order. That's the mechanism behind "here are 40 frames, process them in order."
• video - downloads the file and decodes it with imageio into a stack of frames, again as one batched tensor, in playback order.

Everything comes back as a single IMAGE output (a batch tensor when the source had more than one frame), so downstream nodes see a normal image batch regardless of which format you chose.

The error handling is notable in a good way: on any request failure it logs a 🛑 error and returns None rather than crashing the whole run. In practice that means a dead URL gives you a silent-ish null downstream, so check the console if a workflow "works" but produces nothing.

Who actually uses this

Real talk: this is farm infrastructure. It pairs with MediaStreamOutput inside a pipeline where a scheduler pre-signs object-storage URLs for inputs and outputs, workers pull inputs from those URLs, render, and push results back. If you're a normal local user, about the only way this becomes useful is if you have a pre-signed GET URL to some object store - any S3-compatible one, since it's plain requests.get - and you want to drop that media into ComfyUI. For general image loading from disk, use ComfyUI's built-in Load Image; for web fetching, use a purpose-built HTTP/network node pack instead. This node wants the whole orchestration system around it.

Install and dependencies

ComfyUI Manager (search "Nilor Nodes") or:

cd ComfyUI/custom_nodes
git clone https://github.com/nilor-corp/nilor-nodes
cd nilor-nodes && pip install -r requirements.txt

Restart ComfyUI. Its real dependencies are requests, PIL, and imageio (+ the imageio-ffmpeg backend for mp4 decoding) - all covered by the pack's requirements.txt. No config or .env needed just to run this node, unlike its output sibling, since it doesn't touch SQS or S3 credentials itself.

Bottom line

A clean, well-behaved media fetcher - for the one scenario where the URL is handed to you by the system that owns the media. If that's your scenario, this is genuinely convenient: one node, three formats, batched output, graceful failure. If it isn't, treat it as infrastructure you're unlikely to reach for, and don't let the format: video promise trick you into skipping a proper video-loading setup.