Nvidia driver update - reactor node
In my previous reply, I mainly talked about the general recommended flow, but if I narrow it down specifically to improving the video side, I think it would look something like this:
Short version
For your current stage and an 8GB VRAM setup, I would not jump sideways into a larger “perfect identity / perfect audio / perfect control” workflow yet.
I would first stabilize the smallest video route:
no F2F for now
→ very short I2V / TI2V
→ static camera
→ one small action
→ stronger preservation prompt
→ several seeds
→ pick the best face-stable result
→ repair only the bad parts later
The main change is this:
I would stop treating F2F as a face-consistency tool. I would treat it as an endpoint-transition tool.
Your own test is probably the most useful evidence here: when you removed the F2F / last-frame part, the lighting bump disappeared. So I would not put F2F back into the main route until the simpler video path is stable.
Why I would avoid F2F as the main fix for now
The way I understand your result is:
| Setup | What you wanted | What likely happened |
|---|---|---|
| First frame = image A | preserve the character | |
| Last frame = same image A | force the clip to return to the same identity | |
| Short action prompt | “char1 looks at char2” | |
| Actual result | Wan generated an intermediate path, then returned to A | |
| Visible symptom | lighting / color / exposure changed in the middle |
So the model may not be interpreting this as:
keep the same face and lighting for the whole clip
It may be closer to:
start here, invent a middle, and return to the endpoint
That is useful for transitions, but not always useful for “same person, same lighting, tiny motion.”
This also matches how the ComfyUI FLF docs describe the workflow: first/last frames define the video boundaries, and the model fills the intermediate transition/dynamic change: ComfyUI Wan FLF2V example
So I would classify the tools like this:
| Goal | Better first tool |
|---|---|
| Make one image slightly alive | normal I2V / TI2V |
| Make a clear A-to-B transition | F2F / FLF |
| Make a loop | generate a good short clip first, then loop/edit later |
| Repair one bad area/frame | I2I / inpaint / frame repair |
| Stronger video repair/control | VACE or control workflow later |
| Strong identity-specific workflow | Stand-In / LoRA / identity workflow later |
So, for now, I would keep F2F out of the main path.
8GB VRAM: what seems realistic
On 8GB, I would think about the options like this:
| Route | 8GB practicality | My opinion for your current stage |
|---|---|---|
| Very short I2V / TI2V | Good | Best next step |
| Wan2.2 5B with ComfyUI native offloading | Good candidate | Main route to test |
| Wan2.1 1.3B / 480P route | Useful fallback | Good diagnostic route |
| F2F / FLF | Possible, but risky here | Do not use as face lock |
| ReActor | Useful in clean cases | Targeted repair only |
| VACE 1.3B | Possible later | Useful, but workflow-heavy |
| Fun Control / pose-control routes | Later | More about structure/motion than face identity |
| Stand-In / identity-preserving workflows | Interesting later | Probably too early as the next fix |
| 14B / S2V / all-in-one AV workflows | Heavy | Not the next local 8GB step |
The ComfyUI Wan2.2 docs say the Wan2.2 5B version should fit well on 8GB VRAM with ComfyUI native offloading, so that is the most natural first candidate if you want to stay local.
If that is still too slow or unstable, a smaller/480P test route is not a failure. The Wan2.1 repo describes the 1.3B model as requiring about 8.19GB VRAM and being aimed at 480P. That makes it useful as a diagnostic route, even if the final quality is lower.
The key rule is:
On 8GB, the best workflow is often not the most powerful workflow. It is the smallest workflow that fails in a predictable way.
Recommended video-only route
For now, I would try to make one clean baseline:
source image
→ short I2V / TI2V
→ no F2F
→ static camera
→ one small action
→ preservation-heavy positive prompt
→ several seeds
→ choose the best face-stable result
→ repair isolated defects only if needed
For the first stable test, I would keep it boring:
| Setting area | Recommendation |
|---|---|
| Clip length | 2–3 seconds |
| Motion | one small action only |
| Camera | static |
| Prompt | explicitly preserve face / lighting / background |
| Resolution | low enough to iterate |
| F2F | off |
| Seed | test several |
| Judging priority | face first, prompt obedience second |
The first goal is not to make the whole final scene.
The first goal is only:
Can I get one short clip where the face, lighting, and background stay mostly stable?
If yes, then build from there.
Detailed test plan (click for more details)
Prompt strategy: do not rely on the end frame anymore
Since F2F is no longer doing the “return to the reference” job, I would not use only an ultra-short prompt like this:
char1 looks at char2
That prompt gives the action, but leaves too much open:
- lighting
- skin tone
- background
- camera movement
- color balance
- expression intensity
- face permanence
- amount of motion
Instead, I would put the preservation rules into the positive prompt.
Example:
same person, same face, same identity, same hairstyle, same clothing,
same room, same background, same camera angle, static camera,
same soft lighting, same skin tone, same color balance,
only subtle natural motion, small eye movement, slight breathing,
char1 slowly looks toward char2,
no zoom, no pan, no scene change
A short negative prompt is still fine, but I would not depend on the negative prompt as the main control. Especially in low-step / distilled / low-CFG workflows, negative prompts often do less than people expect.
Practical rule:
Put the important “do not change this” information into the positive prompt, not only into the negative prompt.
Where ReActor fits
I would still keep ReActor in the toolbox, but I would narrow its job.
ReActor is useful when the face is:
- visible
- clean
- not heavily occluded
- not in complex physical interaction
- not changing too much across frames
The ReActor repo describes it as a face-swap extension and also labels it SFW-friendly. So if interaction shots are triggering sensitivity, black output, or blocked results, I would not fight that as the main path right now.
I would use ReActor more like this:
| Use case | ReActor fit |
|---|---|
| clean portrait repair | good |
| simple visible face | possible |
| simple talking-head style shot | possible |
| two characters interacting closely | fragile |
| hands/arms crossing faces | fragile |
| solving all identity drift | not ideal |
So I would not make ReActor responsible for the whole video. I would use it only where it is naturally strong.
Where I2I / frame repair fits
I2I or frame repair is good for isolated defects:
| Problem | Better approach |
|---|---|
| one frame has bad jewelry | I2I / inpaint |
| one hand is wrong | I2I / inpaint / regenerate shot |
| one face frame is slightly off | targeted repair |
| face slowly morphs across the whole clip | shorter clip / better source / better prompt / seed search |
| lighting changes mid-clip | remove F2F, shorten clip, preserve lighting in prompt |
| interaction shot breaks | simplify blocking, split into shorter shots |
For interaction scenes, sometimes the best fix is not a stronger node. It is simpler shot design.
Example:
Hard version:
one long shot where two people interact, turn, touch, speak, and move
Easier version:
shot A: char1 reacts
shot B: char2 reacts
shot C: simple wider interaction
shot D: close-up repair if needed
Less glamorous, but much easier to control on 8GB.
Later branches: VACE, Fun Control, Stand-In, LoRA, 14B (click for more details)
Should you move to another workflow just because it has sound nodes?
For the video side, I would say no — not yet.
A workflow having sound nodes does not automatically solve:
- face consistency
- F2F lighting bump
- interaction scenes
- ReActor sensitivity
- hands/jewelry/nails
- color drift
- video repair
It may only move you into a larger workflow with more things to debug.
I would separate the branches:
video quality branch
= face, lighting, hands, motion, shot design
audio branch
= TTS, audio mux, lip-sync, Foley, sound effects
Since you already diagnosed a real video-side issue, I would stabilize that branch first.
Then add audio as a separate branch later.
Practical roadmap
| Step | Action | Success condition |
|---|---|---|
| 1 | Duplicate the current working workflow | old version remains safe |
| 2 | Disable F2F / last-frame path | lighting bump does not return |
| 3 | Make a 2–3 sec I2V/TI2V test | face mostly holds |
| 4 | Use static camera + one tiny action | less drift |
| 5 | Add preservation-heavy positive prompt | lighting/background/face hold better |
| 6 | Try several seeds | at least one acceptable seed |
| 7 | Repair only isolated defects | avoid rebuilding whole workflow |
| 8 | Only then test VACE/ReActor/control tools | targeted use, not main path |
| 9 | Only after video baseline works, return to audio | fewer variables |
Main rule:
Keep the main branch boring. Put risky experiments in copies.
Very compact version
If I compress all of this into one practical recommendation:
For the video side, I would not switch to a larger workflow yet. On 8GB VRAM, I would first stabilize a small no-F2F I2V/TI2V route: Wan2.2 5B with native offloading if possible, or a smaller/480P diagnostic route if needed. Keep clips very short, use static camera, ask for only one small action, put identity/lighting/background preservation into the positive prompt, and choose the best seed by face permanence first. Use ReActor, I2I repair, VACE, Fun Control, or Stand-In later as targeted repair/control branches — not as the first main solution.
That seems like the safest next direction from where you are now.
Discussion in the ATmosphere