RH Image to Video

Image-to-video is the "make my still image move" job, and on a local machine it's the job that will max out your VRAM and test your patience with a stack of dependencies. RH Image to Video skips all of that: you feed it an IMAGE tensor from your graph, it uploads that image to RunningHub, runs an image-to-video workflow in the cloud, and hands you back a video_url plus a task_id.

This is one of the more genuinely useful nodes in the pack, because image-to-video is exactly the kind of heavy, occasional task where renting a GPU for a couple of minutes beats owning one for it. You keep all your local finishing - the image you made with your own models, your own upscaler - and only the expensive animation step leaves the machine.

The fields that matter

Required:

• image - an IMAGE tensor. This gets uploaded to RunningHub's /task/openapi/upload endpoint and passed to the workflow as its image input.
• api_key, base_url, workflow_id - credentials plus the image-to-video workflow to run. .cn base URL by default, .ai for international.

Optional:

• prompt - a motion prompt ("camera pans left, waves gently"). Leave empty if the workflow has its own default.
• timeout (600s default) - the wait budget for the cloud render. Video takes a while; this is the knob to raise if your job keeps timing out.

Outputs:

• video_url (STRING) - the remote URL of the finished clip.
• task_id (STRING) - for tracking or canceling later.

The gotchas

The output is a URL, not frames. Like RH Text to Video, this node never downloads the video - it just reports where it lives. Wire video_url into RH Download Video to fetch it and optionally extract frames, or open the URL directly.

Only the first image in a batch gets uploaded (image[0]). Feed it a batch and the rest are silently ignored - keep it to a single image per run.

The hardcoded node IDs make a return appearance. The source bakes in nodeId "10" for the image and "6" for the prompt. This assumes your image-to-video workflow's image input is node 10 and its text node is 6. Stock RunningHub i2v templates usually match; hand-built ones may not, and a mismatch means your image silently never reaches the model. When in doubt, RH Node Info + RH Execute Workflow gives you control over the IDs.

Upload errors are reported, not silent. Unlike the image model nodes, a failed upload returns a string like Upload error: ... in video_url rather than a black tensor - slightly friendlier. But a failed render still comes back as an error string in video_url, and the platform's content filter is strict on video, so keep prompts above the line.

Where it fits

The classic pattern: generate a still with your local setup, upscale or inpaint it, then hand it to this node for the expensive animation step. The community's RunningHub take - cheap per-task, easy to try, occasionally slow on the shared pool - applies fully here. It's metered, so watch timeout and don't queue a dozen clips on a whim.

Install

cd ComfyUI/custom_nodes/
git clone https://github.com/liangzheng1128/ComfyUI-RunningHub
cd ComfyUI-RunningHub
pip install -r requirements.txt

or ComfyUI Manager → search "RunningHub", restart. Light deps - requests, websocket-client, Pillow, numpy.