zhenzhen-VOSR2-2K-video-upscale-lowprice

Video upscaling is the least settled job in the field, and the reason is structural rather than a matter of picking a better model: every frame has to agree with its neighbours or fine repeating texture boils. SeedVR2 is genuinely good at it and needs something close to datacenter hardware - one well-known test put 720p→4K at twelve minutes on a rented L40S. FlashVSR is the fast local alternative, and its own community numbers show the trade: tiling off means a 24GB card, tiling on means "far slower".

So there's a real gap for "I have a 480p-ish clip and a laptop, just make it 2K". That's the pitch here. It uploads your video, the vendor's VOSR2 service does the rest, and you get a VIDEO back - no weights, no VRAM, no overnight queue you're hosting.

The inputs, which is a two-slot puzzle

video_url is the required one and it's a plain string: a public http(s) link to the clip. Leave it empty when you're connecting input_video instead.

input_video is the optional VIDEO socket for a local file - from a Load Video node, a Video Combine output, or the output of a generation node earlier in the graph.

The rule is exactly one source. Connect both and it refuses with "accepts exactly one source: input_video or video_url"; connect neither and it refuses the other way. That's more discipline than most nodes show, and it's welcome - a local file can't be silently ignored in favour of a URL you left in the widget three sessions ago.

Feeding it a local file means the node reads the bytes, works out the container and uploads it with a matching MIME type. Supported containers are the obvious ones - mp4, mov, avi, mkv - so anything else you transcode first. The URL path skips the upload entirely, which is faster and cheaper if the clip is already public.

Then api_config for the Settings node, skip_error, and seed - cache control only, tooltip-confirmed, not sent upstream. Note how little else there is. No target resolution, no prompt, no strength, no duration field. The schema says 2K and that's the deal.

Mechanism

Under the hood it's one VIDEO in, one VIDEO out, and a job in the middle. The payload is minimal: the model ID vosr2-video-upscale and a metadata.video_url pointing at the source. The node submits that as a video task, polls, downloads the result MP4 and wraps it in the pack's video adapter so it behaves like any other VIDEO in ComfyUI - which means you can wire it straight into Save Video or a Video Combine node. There's a working example in the repo's workflow/ folder doing Load Video → this node → Save Video.

Because it's task-based, you get task_id as an output, and on video jobs that's the output to remember. Video takes minutes; ComfyUI giving up on the wait is common; the job finishing on the server anyway is also common. The site's async task list plus that ID is how you recover a clip your graph declared dead.

video_url on the output is the result link - useful when a large download fails and you'd rather grab it than pay for another render. response holds the submit and poll JSON.

Install

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

Manager route: search Comfyui-zhenzhen, install, restart. Nothing heavy comes with it - this pack's whole trick is that the compute lives on the vendor's side. The README's dependency list is ordinary Python, there are no checkpoints to place in models/, and your GPU stays idle while this node works. What you need instead is a funded account and a key wired into the Settings node's api_config.

Keep your expectations straight

Two honest caveats. The output ceiling is 2K, so this is not the tool for a 4K delivery, and there's no knob to ask for more.

More importantly: you can't inspect how VOSR2 handles temporal consistency, and that's the specific thing that ruins video upscales. Run a short clip with patterned wallpaper or fabric as your test before you send it anything you care about. If the pattern crawls, the model isn't preserving frames across time, and no amount of re-prompting fixes it - that's architecture, not a setting.

Also worth knowing where you are in the ecosystem: this model name returns exactly zero hits in the community discussion corpus, and neither does the pack or the author in English. That's not a warning about the node, it's just the reality that this particular vendor's toolchain lives on Chinese-language YouTube and a Discord. You're an early tester, not a late adopter. Use the task_id and the site's task log whenever the node and reality disagree about what happened.