并发提交｜Topaz 视频高清修复

Topaz is the upscaler people benchmark against and resent paying for - 223 threads in the first half of 2026, more mentions than SUPIR and ESRGAN combined, mostly from people looking for the exit. So a node that rents Topaz per job instead of per month is genuinely interesting, and it's also slow: video restoration is not a five-second call. Doing one clip at a time is a waste of an afternoon.

This node is Topaz_Video_Upscale with a future output instead of a video. Same resolution tiers, same restoration-quality knob, same local-file-or-URL choice. The difference is that it enqueues and returns immediately.

The mechanism

The submit wrapper validates the original node's inputs synchronously - wrong resolution value, wrong quality value, a video_url that isn't an HTTP(S) MP4 link - and only then hands the job to the pack's video thread pool. The pool is separate from the image pool, defaults to 10 workers, and is adjustable:

export SEEDANCE_VIDEO_CONCURRENCY=4   # 1..10; restart ComfyUI to apply

Ten is also the receiver's slot count, so the sizing lines up: 并发接收视频（10 路） takes future_1…future_10 and returns video_1…video_10 plus status_json. Results come back in slot order regardless of finish order, and the receiver aggregates progress across the branches into a single bar - which for video jobs is the difference between a node that looks alive and one that looks hung.

Wiring it up

Each submit node needs its own source: either a local MP4 into input_video or a public MP4 URL in video_url, never both. The base node enforces that one-source rule, and the submit wrapper inherits it at preflight, so you find out before the job is queued rather than after.

There's also a hard upload ceiling worth knowing at batch scale: local files must be MP4 (the pack checks for the ftyp header) and must not exceed 50 MB. Feeding it a 200 MB 4K phone clip fails validation even though the file is a perfectly good MP4. Trim, or host it and use video_url.

Give each submit node the api_config connection. Ten branches all pointed at one Seedance API Config node is the normal layout and it works fine.

The receiver is media-type generic, not Topaz-specific. Ten slots can hold a mix of Topaz upscales, Vidu generations, and an Animate motion transfer, as long as they're all video futures. Handy when the same run produces clips and then restores them.

failure_mode, and why you'll care

raise aborts the receiver on the first failure and names the slot. For a ten-clip set that all needs to exist, that's correct. placeholder keeps the successes, substitutes a placeholder video for the dead slot, and writes a redacted status summary into status_json - that's the right call when you've queued ten and need nine of them. Per-branch skip_error still applies underneath: a submit node with it enabled degrades only its own slot.

Interrupt in ComfyUI and the receiver stops polling and cancels anything that hasn't started, rather than leaving ten remote jobs billing quietly in the background.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/ComfyUI_Seedance.git
cd ..
python -m pip install -r custom_nodes/ComfyUI_Seedance/requirements.txt

Or ComfyUI Manager → search ComfyUI Seedance → install → restart. requirements.txt is requests>=2.28; there is no Topaz binary anywhere in this, no license file, no GPU work. The pack also ships examples/并发视频2路最小验证.json and examples/并发视频10路示例.json, which are the fastest way to see the receiver wiring.

Reality checks

Cost is per call and per second of video, so a ten-wide fan-out at 4K with the Ultra quality setting is the single most expensive thing in this pack. Test the pipeline on one clip at 720p/Low, confirm it does what you expect to your footage, then scale.

And Low through Ultra are restoration models, not a resolution ladder - the resolution enum (720p, 1080p, 2K, 4K) sets the output pixel budget and preserves the source aspect ratio, while model sets how hard the restorer works. Defaults are 1080p/Max, which is a sane starting point for archive footage and overkill for a clean modern render that just needs more pixels.

Finally: ten concurrent download jobs all pulling from the same result CDN is exactly the scenario where people hit connection resets. The pack retries, falls back to a direct session, then to system curl, and writes to a .part file before landing it. If a run stalls at 95%, it's usually your network stack, not the node - check for stale HTTP_PROXY variables first.