Concurrent Submit | zhenzhen-VOSR2-2K-video-upscale-lowprice

Video upscales are the worst case for serial ComfyUI graphs. Each one is a multi-minute cloud job, and if you have a folder of clips to push to 2K, one-at-a-time means a graph that occupies your queue all afternoon. So the pack gives the video path its own pool - ten workers, separate from the image pool, because a video job holds its slot for minutes and you don't want it starving your image nodes.

This is the submit half of the VOSR2 video pair. It runs the same call as zhenzhen-VOSR2-2K-video-upscale-lowprice and returns a task handle of type COMFLY_VIDEO_FUTURE instead of the clip.

The shape

Inputs are copied from the standalone node, validator included: video_url (required string, a public http(s) link), input_video (optional VIDEO socket for a local file), api_config, skip_error, and the cache-only seed. The one-source rule still holds per node - both connected is an error, neither connected is an error - so a ten-clip batch means ten submit nodes, each with exactly one source wired.

The collector for these is Concurrent Collect Videos (10), class ComflyConcurrent_Video_Await. Ten task sockets, a failure_mode dropdown, ten video_* outputs and a status string. Results land in slot order, not arrival order, so submit node three is always video_3 no matter which clip finishes first. That's the whole point of the pairing: batch the long jobs without a filename-matching step afterwards.

failure_mode behaves as on the image side. fail_fast throws and cancels the stragglers, placeholder drops an empty video adapter into the dead slot and flags it in status. For a ten-clip overnight run, use placeholder; while you're testing one clip, use fail_fast because the error message is worth more than the slot.

The collector is marked always-run - the pack uses the float("NaN") IS_CHANGED idiom, the standard ComfyUI way of telling the engine "never cache me". So the waiting happens once, at the collector, rather than serially inside each submit node.

Pool sizing, and why video is capped lower

export COMFLY_VIDEO_CONCURRENCY=4     # workers, default 10
export COMFLY_VIDEO_PENDING=4         # queued slots beyond that

Read at load time, clamped to 1–128, defaults of ten and ten. Ten concurrent video uploads is already a lot of outbound bandwidth, and it's also a lot of simultaneous billing on a shared reseller endpoint - this is the number to drop first if you're seeing 429s or uploads timing out. The image pool's variables are separate; changing one doesn't touch the other.

The bits that bite

Wire api_config into every submit node from the one Settings node. A missing config fails inside the worker thread, not at submission, so it shows up as a dead slot and an entry in the collector's status rather than a red node you can click on.

Long jobs plus a patient-timeout mismatch is the other one. Video tasks can outlive the node's patience, and the job may well have completed on the server after ComfyUI declares the wait over. Every clip in this pool still returns its own task_id inside the parent's result - check the site's async task list with it before re-rendering and paying twice. This is the single most useful habit with any cloud video node, and the pack's README is emphatic about it too.

And seed is still only a cache key. On fixed with nothing changed, ComfyUI serves the cached result and never re-submits - which is exactly what you want when you tweak one prompt in a ten-clip graph and don't want to fund nine re-renders.

Install

cd ComfyUI/custom_nodes && git clone https://github.com/T8mars/Comfyui-zhenzhen

Manager route: search Comfyui-zhenzhen, install, restart. Nothing to download beyond the pack's ordinary Python dependencies - no weights, no model folder, no GPU requirement, since the upscale happens on the vendor's hardware. You need an account, a key in the Settings node, and the api_config wire.