did we have more people in this project?

[Floribela]

is a dumb question, but the only one that keep this is @adrientoupet ?
how can i starting help here in code? (yeah i dont know sh*t but maybe i can help some how in vibe code)
if someone here knows how to code, wanna help this repo?

[urixl]

I'm sure https://github.com/naxci1 works in it too.

[Floribela]

Thanks for sharing the branch! I just pulled it and ran some initial tests.

I noticed that the temporal consistency is struggling a bit—the frames look a bit weird/flickery in motion, and the overall result isn't quite as impressive as the base model.

Maybe I'm using the wrong settings for this GGUF version? Did you get better temporal stability in your own tests, or is this exactly why you held off on merging it to the main branch?

[adrientoupet]

To be honest, I doubt there will be a SeedVR3 coming up anytime soon with @IceClear now wroking at Apple.
I'm trying to see if @numz has any bandwidth to get back into the project in terms of implementation support. If not, I'll do my best to support it further, acknowledging that there is only so much that can be done without changing the base model. I know there are still some issues/optimisation tickets open so worth looking into them.

Sorry team, I keep being pulled into other things and it's been challenging to allocate time this year for this.

[naxci1]

Hi @adrientoupet

It's great to see you back, like many SeedVR2 fans, this makes me very happy. @IceClear made a statement after joining Apple, saying they'll release a new model and version as soon as possible, we're not waiting. @numz seems very busy, I haven't seen any comments from him since I joined. Companies like Topaz, despite their efforts, still can't reach the quality of SeedVR2. If the VAE decode bottleneck in SeedVR2 is resolved, nobody will be able to stop it.

We trust all three of you on this matter, and we are ready to do whatever we can to help.

Sincerely,

[naxci1]

Hi @Floribela

I had no problems; I tried it 3 months ago, and it worked very well. A smaller model was created, and there were no issues. When I have time, I'll fix the bugs and send it to the main branch, and I'll let you know. To be honest, I didn't pay much attention to it since it didn't work in the old videos. All my work was based on broken videos, and only SeedVR2 can do this in the world. I tried many other models, and none of them even came close to SeedVR2. Topaz SLM came a little closer, but its quality is not good at all, and it's very slow. That's why we need to take SeedVR2 further; it's the project of the future.

[Floribela]

(this was translated from gemini, and using the vibe code that i try)

Hi @adrientoupet and @naxci1,

Thank you for keeping this amazing project alive! I completely agree with @naxci1 — SeedVR2's quality is unmatched, and if we solve the decoding and memory bottlenecks, it will be unstoppable.

I’ve been doing some deep profiling and stress-testing on the pipeline (pushing 5,000+ frames on an RTX 4090), and I found the exact root cause of the crashes on long videos, as well as a huge opportunity for a speedup.

1. The RAM Bottleneck (The Crash at the Finish Line)
   Currently, the pipeline attempts to hold all decoded and post-processed frames in system RAM (as a giant tensor) before passing them to ComfyUI's Video Combine node. For a 5000-frame video, holding raw FP32/FP16 frames easily exceeds 70GB+ of system RAM. The OS simply kills the process (OOM) right at the end of Phase 3 / Phase 4, even if the GPU VRAM is perfectly fine.

Gemini gerated this solution:
The Solution (Direct-to-Disk Streaming): Instead of concatenating chunks in RAM (torch.cat), we need to fuse Phase 3 (VAE Decode) and Phase 4 (Color Correction). As soon as the GPU decodes and color-corrects a batch, we should stream it directly to an .mp4 file on the SSD (using cv2.VideoWriter or FFmpeg) and immediately clear the RAM. We then return a dummy 1-frame tensor to ComfyUI just to satisfy the node output requirement. This caps system RAM usage at ~3GB regardless of whether the video is 500 or 50,000 frames.

2. DiT Inference Speed Hack (The "Turbo Path")
   While reviewing infer.py, I noticed that the classifier_free_guidance_dispatcher evaluates both positive and negative embeddings even when cfg_scale == 1.0 (which is the default for upscaling).

Gemini gerated this solution:
The Solution: We can implement a simple bypass. If cfg_scale == 1.0, we skip the negative path and dispatcher entirely. This effectively cuts the DiT inference time in half, as the GPU no longer calculates the negative path unnecessarily.

3. The Prepend Frames VRAM/RAM Spike
   In generation_utils.py, pad_video_temporal tries to clone the entire massive video tensor just to prepend 32 reversed frames for stability. For long videos, this causes an instant 15GB+ RAM spike before inference even starts.

Gemini gerated this solution:
The Solution: Add a simple RAM protection check: if total_frames > 1000, automatically set prepend_frames = 0. For videos this long, the first second of artifacts is negligible compared to the massive memory overhead of cloning the tensor.

[naxci1]

Hi @Floribela

Writing to disk will only slow down the VAE bottleneck further; splitting it into smaller files is the most logical approach, which I've been using for a year. I split videos into 2-3 minute files, then combine them all after processing. I've even created a small Python application for this.

[menditsa]

Going back to what the OP asked I think people are now looking as this project as abandonware.

Adrien did great a job but now has other commitments beyond giving their time for free.

[Floribela]

totally true. its kinda sad that i dont know how to programming. but im working on use z ai and kimi agents to get something and keep this project alive

[adrientoupet]

I still need SeedVR2 at this stage so not treating it completely as abandonware until something better comes through - but I'm trying to sort my other commitments out and figure out what @numz 's expectations are for the future before I dive back into it. Thanks