```
ComfyUI custom-node dependency docs:
- [ComfyUI Custom Nodes](https://docs.comfy.org/development/core-concepts/custom-nodes)
- [Installing custom nodes](https://docs.comfy.org/installation/install_custom_node)
- [ComfyUI Dependencies](https://docs.comfy.org/development/core-concepts/dependencies)
## Success checklist
I would consider the updated environment repaired only after these are true:
```plaintext
nvidia-smi works
driver version is suitable for the ComfyUI CUDA stack
fresh ComfyUI portable starts
basic image generation works
torch.cuda.is_available() is True
ReActor imports without error
onnxruntime.get_available_providers() includes CUDAExecutionProvider
minimal still-image ReActor workflow works
old workflow works after replacing the ReActor node
short video workflow works without ReActor
short video workflow works with ReActor
full video workflow works
```
## Short version
I would not try to keep repairing the current folder in-place.
I would:
```plaintext
1. rename the broken install and keep it as backup
2. install a fresh current ComfyUI portable
3. confirm basic ComfyUI + PyTorch CUDA first
4. move models only
5. install only official ReActor
6. verify ONNX Runtime providers
7. test one still image
8. replace old ReActor nodes in workflows
9. bring video workflows back last
```
That gives you the best chance of ending up with a properly updated environment instead of a half-rolled-back, half-updated one.
---
**Author:**  [@kdalts3759](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fkdalts3759)%5C
**Post date:** [May 26, 2026, 9:56am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-driver-update-reactor-node%2F176221%2F3 "2026-05-26T09:56:00Z")
wow… very comprehensive… I take the point about a mixed up environment… makes sense
I did exactly as suggested, new install, all the tests and cmd commands appeared to work correctly with no errors and the basic reactor faceswap on a simple image also worked! However, I noticed the is the command window when using reactor
“2026-05-26 10:52:37.6787763 [E:onnxruntime:Default, provider\_bridge\_ort.cc:2369 onnxruntime::TryGetProviderInfo\_CUDA] E:\_work\1\s\onnxruntime\core\session\provider\_bridge\_ort.cc:1962 onnxruntime::ProviderLibrary::Get [ONNXRuntimeError] : 1 : FAIL : Error loading “D:\ComfyUI\_windows\_portable\python\_embeded\Lib\site-packages\onnxruntime\capi\onnxruntime\_providers\_cuda.dll” which depends on “cublasLt64\_12.dll” which is missing. (Error 126: “The specified module could not be found.”)”
absolutely no idea how to fix this and chatgpt is hopeless at this stuff
---
**Author:**  [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C
**Post date:** [May 26, 2026, 5:11pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-driver-update-reactor-node%2F176221%2F4 "2026-05-26T17:11:27Z")
Yeah, ONNX Runtime breaks quite easily after environment changes… switching it to CPU temporarily may be a good move. Maybe something like this?
* * *
That error is very informative. It means the clean reinstall probably helped, but **ONNX Runtime’s CUDA provider is still not loading correctly**.
This line is the key:
```plaintext
Error loading:
D:\ComfyUI_windows_portable\python_embeded\Lib\site-packages\onnxruntime\capi\onnxruntime_providers_cuda.dll
which depends on:
cublasLt64_12.dll
which is missing.
```
So I would read the current state like this:
```plaintext
Clean ComfyUI install: probably OK
Basic PyTorch CUDA test: probably OK, if your earlier torch command passed
Basic ReActor still-image swap: works
ONNX Runtime CUDAExecutionProvider: broken or drifting
ONNX Runtime CPUExecutionProvider: probably being used as fallback
```
So this is **not the same problem as before**. You made progress.
Before, the whole environment was probably mixed. Now the problem looks narrower:
> ReActor can run, but ONNX Runtime GPU acceleration cannot load the CUDA 12 DLLs it expects.
That missing `cublasLt64_12.dll` is a CUDA 12 cuBLAS runtime DLL. ONNX Runtime’s CUDA provider is trying to load it, and Windows cannot find it.
Similar ReActor reports:
- [ComfyUI-ReActor issue #201 - `cublasLt64_12.dll` missing](https://github.com/Gourieff/ComfyUI-ReActor/issues/201)
- [ComfyUI-ReActor issue #188 - CUDA provider / CPU tensor / `cublasLt64_12.dll`](https://github.com/Gourieff/ComfyUI-ReActor/issues/188)
- [ComfyUI-ReActor issue #195 - Python 3.13 + GPEN-BFR + `cublasLt64_12.dll`](https://github.com/Gourieff/ComfyUI-ReActor/issues/195)
Relevant ONNX Runtime docs:
- [ONNX Runtime CUDA Execution Provider](https://onnxruntime.ai/docs/execution-providers/CUDA-ExecutionProvider.html)
- [ONNX Runtime Install docs](https://onnxruntime.ai/docs/install/)
## Important caveat: this may be real GPU/runtime drift
I would **not** assume this is only a harmless warning.
It might be harmless if ReActor falls back to CPU and the output looks correct. But it might also mean the GPU execution layer genuinely drifted.
In other words, this could be real drift in the execution substrate:
```plaintext
GPU model / architecture
NVIDIA driver
PyTorch CUDA build
onnxruntime-gpu version
CUDA runtime DLLs
cuDNN runtime DLLs
Windows DLL search path
ComfyUI embedded Python environment
```
That matters because ONNX Runtime GPU support is sensitive to the exact combination of CUDA, cuDNN, Python, PyTorch, and GPU architecture.
So CPU mode is not “the final answer.” It is a **stabilization and isolation step** :
```plaintext
First: make ReActor work reliably on CPU.
Then: treat ONNX Runtime GPU as a separate optimization / migration problem.
```
This keeps you from breaking the clean install again while trying to fix GPU acceleration.
## Why the face swap still worked
Because ONNX Runtime can often fall back to CPU.
So this can happen:
```plaintext
ONNX Runtime tries CUDAExecutionProvider
CUDA provider fails because a CUDA DLL is missing
ONNX Runtime continues with CPUExecutionProvider
ReActor still produces an image
console prints scary CUDA errors
```
That would explain:
```plaintext
simple ReActor image test works
but console shows cublasLt64_12.dll errors
```
The main downside may be speed.
But if later video or face-restore paths become unstable, then the broken CUDA provider may matter more.
## First: capture the exact GPU/runtime state
Before changing packages again, I would record this:
```bat
cd D:\ComfyUI_windows_portable
nvidia-smi
.\python_embeded\python.exe -c "import sys; print('python=', sys.version)"
.\python_embeded\python.exe -c "import torch; print('torch=', torch. __version__ ); print('torch cuda=', torch.version.cuda); print('cuda available=', torch.cuda.is_available()); print('gpu=', torch.cuda.get_device_name(0) if torch.cuda.is_available() else 'no gpu'); print('capability=', torch.cuda.get_device_capability(0) if torch.cuda.is_available() else 'no gpu')"
.\python_embeded\python.exe -c "import onnxruntime as ort; print('onnxruntime=', ort. __version__ ); print('providers=', ort.get_available_providers())"
.\python_embeded\python.exe -m pip list | findstr /i "onnxruntime torch nvidia cuda cudnn"
```
The GPU name and compute capability matter. For example, if someone is on a very new GPU architecture, old CUDA wheels or runtime packages can genuinely be wrong even if the code did not change.
So I would save this output somewhere before fixing anything.
## Interpret the provider result
Run:
```bat
cd D:\ComfyUI_windows_portable
.\python_embeded\python.exe -c "import onnxruntime as ort; print('onnxruntime=', ort. __version__ ); print('providers=', ort.get_available_providers())"
```
### Case A
```plaintext
providers= ['CUDAExecutionProvider', 'CPUExecutionProvider']
```
This means ONNX Runtime package-level CUDA support is present, but loading the actual CUDA DLLs may still fail at runtime.
### Case B
```plaintext
providers= ['CPUExecutionProvider']
```
or:
```plaintext
providers= ['AzureExecutionProvider', 'CPUExecutionProvider']
```
This means ONNX Runtime is effectively CPU-only.
### Case C
```plaintext
Error loading onnxruntime_providers_cuda.dll
missing cublasLt64_12.dll
```
This means `onnxruntime-gpu` is installed, but the CUDA 12 runtime DLL it expects is not findable.
## Check for mixed ONNX Runtime packages
This is worth checking:
```bat
.\python_embeded\python.exe -m pip list | findstr /i "onnxruntime"
```
A confusing state would be:
```plaintext
onnxruntime
onnxruntime-gpu
```
Ideally, for a clean CPU-only temporary state, you want only:
```plaintext
onnxruntime
```
For a clean GPU state, you want only:
```plaintext
onnxruntime-gpu
```
Mixed CPU/GPU ONNX packages can make debugging harder.
## Safest short-term workaround: make ONNX Runtime CPU-only
Because the simple ReActor swap already works, I would probably stabilize first.
The idea is:
```plaintext
Remove broken ONNX Runtime GPU provider
Use CPU ONNX Runtime
Verify ReActor still works
Verify the cublasLt64_12.dll warning disappears
Then decide whether GPU acceleration is worth fixing
```
Commands:
```bat
cd D:\ComfyUI_windows_portable
.\python_embeded\python.exe -m pip uninstall -y onnxruntime-gpu
.\python_embeded\python.exe -m pip install --upgrade --force-reinstall onnxruntime
```
Then verify:
```bat
.\python_embeded\python.exe -c "import onnxruntime as ort; print('onnxruntime=', ort. __version__ ); print('providers=', ort.get_available_providers())"
```
A good temporary result is:
```plaintext
providers= ['CPUExecutionProvider']
```
or sometimes:
```plaintext
providers= ['AzureExecutionProvider', 'CPUExecutionProvider']
```
Then restart ComfyUI and test the same simple ReActor face swap again.
If the warning disappears and the image still works, then you have a stable baseline:
```plaintext
ComfyUI works
ReActor works
ONNX Runtime uses CPU
no missing cublasLt64_12.dll warning
```
That is a good recovery state.
Not necessarily the final fastest state, but a good stable state.
## Why CPU-only may be the right next move
Because you have already proven something important:
```plaintext
fresh install worked
basic commands worked
basic ReActor image swap worked
```
So the remaining issue is narrower:
```plaintext
ONNX Runtime GPU acceleration is not loading
```
That should be treated separately.
If you try to fix ONNX GPU immediately, you may end up changing:
```plaintext
onnxruntime-gpu
CUDA runtime packages
cuDNN packages
PyTorch
Windows PATH
NVIDIA driver
ReActor dependencies
```
all at once again.
That is exactly how the original mixed environment probably happened.
So I would first get a clean CPU baseline, then handle GPU acceleration as a second phase.
## If you later want to fix ONNX Runtime GPU
Only do this after CPU ReActor is stable.
The goal would be:
```plaintext
Make onnxruntime-gpu able to find the CUDA 12 / cuDNN DLLs it expects.
```
There are several possible paths.
### Option A: Try ONNX Runtime GPU with CUDA/cuDNN extras
ONNX Runtime documents installation forms that can bring CUDA/cuDNN runtime dependencies into the Python environment.
In ComfyUI portable, use embedded Python:
```bat
cd D:\ComfyUI_windows_portable
.\python_embeded\python.exe -m pip uninstall -y onnxruntime onnxruntime-gpu
.\python_embeded\python.exe -m pip install --upgrade "onnxruntime-gpu[cuda,cudnn]"
```
Then test:
```bat
.\python_embeded\python.exe -c "import onnxruntime as ort; ort.preload_dlls(); print('onnxruntime=', ort. __version__ ); print('providers=', ort.get_available_providers()); ort.print_debug_info()"
```
Relevant docs:
- [ONNX Runtime CUDA Execution Provider - preload DLLs](https://onnxruntime.ai/docs/execution-providers/CUDA-ExecutionProvider.html#preload-dlls)
- [ONNX Runtime Install](https://onnxruntime.ai/docs/install/)
But I would treat this as a second-phase experiment, not the immediate recovery step.
### Option B: Preload PyTorch / NVIDIA DLLs before ONNX Runtime
ONNX Runtime documents that preloading DLLs can help it use CUDA/cuDNN DLLs from PyTorch or NVIDIA Python packages.
The basic idea is:
```python
import torch
import onnxruntime
```
or:
```python
import onnxruntime
onnxruntime.preload_dlls()
```
But whether this helps inside ComfyUI depends on when ReActor creates its ONNX Runtime sessions. If the custom node creates sessions before the preload happens, the preload test may work in a standalone command but not fix the node.
So this is useful for diagnosis, but not always a clean user-level fix.
### Option C: Install CUDA runtime globally
You could install CUDA 12 runtime/toolkit so Windows can find `cublasLt64_12.dll`.
But I would not start there.
Global CUDA and PATH edits can make things harder to reason about. For ComfyUI portable, I would prefer keeping dependencies inside the portable Python environment where possible.
## Do not confuse these two questions
There are now two separate questions:
```plaintext
Question 1:
Can ReActor work reliably at all?
Question 2:
Can ReActor use ONNX Runtime GPU acceleration?
```
You have probably answered Question 1: yes, at least for a simple still image.
Question 2 is still unresolved.
That means the practical recovery route is:
```plaintext
First stabilize ReActor CPU.
Then decide whether ONNX GPU is worth fixing.
```
## What I would do next
My exact next steps would be:
```plaintext
1. Save the current command outputs
2. Confirm the simple ReActor still-image test works
3. Check ONNX Runtime providers
4. Remove onnxruntime-gpu
5. Install CPU onnxruntime
6. Restart ComfyUI
7. Confirm the cublasLt64_12.dll warning is gone
8. Test simple ReActor still image again
9. Test your real still-image workflow
10. Test short video
11. Only later try ONNX Runtime GPU again
```
Commands:
```bat
cd D:\ComfyUI_windows_portable
.\python_embeded\python.exe -m pip list | findstr /i "onnxruntime"
.\python_embeded\python.exe -m pip uninstall -y onnxruntime-gpu
.\python_embeded\python.exe -m pip install --upgrade --force-reinstall onnxruntime
.\python_embeded\python.exe -c "import onnxruntime as ort; print('onnxruntime=', ort. __version__ ); print('providers=', ort.get_available_providers())"
```
Then restart ComfyUI.
## How to interpret the result
### Good temporary result
```plaintext
providers= ['CPUExecutionProvider']
ReActor still works
no cublasLt64_12.dll warning
```
Meaning:
```plaintext
You now have a stable CPU ReActor setup.
It may be slower, but it is clean.
```
### Still noisy
```plaintext
cublasLt64_12.dll warning still appears
```
Then `onnxruntime-gpu` is probably still installed somewhere in the ComfyUI embedded Python environment, or another package is still importing the GPU provider.
Check again:
```bat
.\python_embeded\python.exe -m pip list | findstr /i "onnxruntime"
```
### ReActor stops working after CPU-only install
Then reinstall official ReActor using its installer:
```bat
cd D:\ComfyUI_windows_portable\ComfyUI\custom_nodes\ComfyUI-ReActor
install.bat
```
But make sure it uses:
```plaintext
D:\ComfyUI_windows_portable\python_embeded\python.exe
```
not system Python.
## Short version
Your new install probably worked.
The remaining error is probably:
```plaintext
ONNX Runtime GPU provider is broken or drifting
but ReActor can still run through CPU provider
```
So I would not reinstall everything again.
I would first stabilize ONNX Runtime as CPU-only:
```bat
cd D:\ComfyUI_windows_portable
.\python_embeded\python.exe -m pip uninstall -y onnxruntime-gpu
.\python_embeded\python.exe -m pip install --upgrade --force-reinstall onnxruntime
```
Then test ReActor again.
If that works and the warning disappears, you have a usable recovery state.
After that, GPU acceleration can be treated as a separate ONNX Runtime / CUDA / cuDNN / GPU-architecture migration problem, not as the main ReActor recovery problem.
---
**Author:**  [@kdalts3759](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fkdalts3759)%5C
**Post date:** [May 26, 2026, 6:41pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-driver-update-reactor-node%2F176221%2F5 "2026-05-26T18:41:43Z")
Again… very comprehensive…
Here’s where we are now..
Basic reactor (single image to image) works
More advance (image to video (81 frames) - runs but always seem to hit the NSFW detected and produces a black square - even though there is no nsfw, literally someone just walking - other than a bare leg!
onnxruntime 1.26.0
There are no error or warning messages in the command screen (cublasLt64\_12.dll warning still appears) no message about this
So I guess this is progress
I notice there is a NSFW reactor node - should I try it?
---
**Author:**  [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C
**Post date:** [May 27, 2026, 2:57am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-driver-update-reactor-node%2F176221%2F6 "2026-05-27T02:57:21Z")
> should I try it?
Yeah. I think trying that direction is probably faster. For ONNX, **if the current speed feels too slow** , you can sort out the GPU side later:
* * *
At this point I would probably stop treating the `cublasLt64_12.dll` warning as the main blocker.
It is still a real issue, but it now looks like a **performance / ONNX CUDA provider issue** , not the thing preventing ReActor from working.
The current situation looks more like this:
```plaintext
Clean ComfyUI install: working
Basic ReActor still-image face swap: working
Video workflow: runs
ONNX Runtime CUDA provider: still not healthy
ONNX Runtime CPU fallback: probably working
Current visible blocker: black output / SFW checker / NSFW detector
```
So if the current speed is acceptable, I would leave ONNX alone for now.
Do **not** keep chasing CUDA DLLs yet. That path can easily re-break the clean install.
Relevant ONNX docs, for later:
- [ONNX Runtime CUDA Execution Provider](https://onnxruntime.ai/docs/execution-providers/CUDA-ExecutionProvider.html)
- [ONNX Runtime Install docs](https://onnxruntime.ai/docs/install/)
The `cublasLt64_12.dll` warning basically means:
```plaintext
onnxruntime-gpu tried to load CUDAExecutionProvider
↓
onnxruntime_providers_cuda.dll needed cublasLt64_12.dll
↓
Windows could not find that CUDA 12 DLL
↓
CUDAExecutionProvider failed
↓
ReActor likely continued through CPUExecutionProvider
```
That is not ideal, but if ReActor runs and speed is tolerable, I would postpone it.
## The more important problem now is probably the SFW checker
The current GitHub ReActor build is intentionally SFW-oriented. The README says it has a nudity detector to avoid use with 18+ content:
- [ComfyUI-ReActor README](https://github.com/Gourieff/ComfyUI-ReActor)
There are also reports where ReActor outputs black images because the SFW checker is too sensitive:
- [ComfyUI-ReActor issue #57 - all output images pure black](https://github.com/Gourieff/ComfyUI-ReActor/issues/57)
- [ComfyUI-ReActor issue #62 - black screen](https://github.com/Gourieff/ComfyUI-ReActor/issues/62)
- [ComfyUI-ReActor issue #15 - preview image is black / NSFW detector](https://github.com/Gourieff/ComfyUI-ReActor/issues/15)
So if your workflow is now running but the result becomes black squares, that sounds less like “ReActor is broken” and more like:
```plaintext
ReActor works
but the SFW / NSFW checker is blocking the output
```
If the checker is the real blocker, then trying to fix ONNX GPU first probably will not solve the black output.
## I would not modify the now-working install directly
The current install is valuable because it works.
I would back it up before doing anything else.
For example:
```plaintext
ComfyUI_windows_portable
->
ComfyUI_windows_portable_sfw_working_backup
```
Then create a second copy for experiments:
```plaintext
ComfyUI_windows_portable_reactor_experiment
```
Use one as the stable backup, and one as the test install:
```plaintext
ComfyUI_windows_portable_sfw_working_backup
= known working clean/SFW install
ComfyUI_windows_portable_reactor_experiment
= experimental ReActor install
```
Do not test alternative ReActor builds inside the only working install.
That is how the environment can get mixed again.
## Why I would separate the installs
ReActor-related installs can modify or depend on packages such as:
```plaintext
onnxruntime
onnxruntime-gpu
opencv
numpy
protobuf
insightface
transformers
timm
face restore packages
```
If multiple ReActor variants are installed together, it becomes hard to know which one is loading and which dependency changed.
So I would avoid this:
```plaintext
official ComfyUI-ReActor
+ old reactor node
+ forked reactor node
+ Manager-installed reactor
+ manual clone reactor
```
Instead, in the experiment copy, keep **one ReActor variant at a time**.
That is the main rule.
## Share models instead of copying everything
If disk space is an issue, you do not have to duplicate all models.
ComfyUI supports `extra_model_paths.yaml` for sharing model folders between ComfyUI installs:
- [ComfyUI Models / extra\_model\_paths.yaml](https://docs.comfy.org/development/core-concepts/models)
So the structure can be:
```plaintext
D:\AI\Models\
checkpoints\
vae\
loras\
controlnet\
insightface\
reactor\
D:\ComfyUI_windows_portable_sfw_working_backup\
D:\ComfyUI_windows_portable_reactor_experiment\
```
Then point both ComfyUI installs to the shared model directory.
This keeps the program environments separate while avoiding huge duplicate model folders.
## Suggested practical path
I would do this:
```plaintext
1. Keep the current install as a backup.
2. Do not fix ONNX GPU right now.
3. Do not run Manager Update All.
4. Make a second ComfyUI copy for ReActor experiments.
5. In the experiment copy, remove/disable other ReActor variants.
6. Install/test only one ReActor variant at a time.
7. Test one still image first.
8. Test one extracted video frame.
9. Test a tiny 5–10 frame video.
10. Only then test the full 81-frame workflow.
```
The test order matters.
Do not start with the full video workflow.
Use this order:
```plaintext
still image
↓
one problematic extracted frame
↓
several extracted frames
↓
very short video
↓
full video
```
## How to interpret the result
### If the experimental ReActor build works on still images
Good. Then the base face swap path is healthy.
### If it works on extracted frames
Then the SFW checker was probably the main blocker.
### If extracted frames work but video fails
Then the issue is probably video pipeline integration, batch handling, frame order, or memory pressure.
### If it fails even on a still image
Then the experimental install itself is not healthy yet.
## Keep ONNX GPU as a later task
I would treat the ONNX warning like this:
```plaintext
Known issue:
ONNX Runtime CUDAExecutionProvider cannot load cublasLt64_12.dll.
Current workaround:
Let ReActor run through CPU fallback if speed is acceptable.
Later optimization:
Fix onnxruntime-gpu / CUDA / cuDNN only if CPU speed is too slow.
```
Do not combine these two projects:
```plaintext
Project A:
get a ReActor build that does not black out the output
Project B:
restore ONNX Runtime GPU acceleration
```
Do Project A first.
Only do Project B later if needed.
## One more caution
I would avoid manually patching random files inside the working install.
It is cleaner to preserve the working state and test a separate build/branch in a separate ComfyUI copy.
Also, obviously, this should only be used for content where you have the rights and consent to use the faces/images involved. Face-swap tooling can easily cross legal and ethical lines, so I would keep the test environment private and controlled.
## Short version
I would do this:
```plaintext
Back up the current working install.
Leave ONNX GPU alone for now.
Use CPU fallback if the speed is acceptable.
Create a separate ComfyUI experiment copy.
Test a different ReActor build/branch there, not in the stable install.
Keep only one ReActor variant in that copy.
Test still image → extracted frame → short video → full workflow.
```
If that solves the black output, then the SFW checker was probably the real blocker.
If it does not, then the next target is the video pipeline, not ONNX CUDA.
---
**Author:**  [@kdalts3759](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fkdalts3759)%5C
**Post date:** [June 7, 2026, 11:33am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-driver-update-reactor-node%2F176221%2F7 "2026-06-07T11:33:19Z")
so its been a tough learning curve and I still have a very long way to go but, thanks to the advice in this post (and No Thanks to copilot ) I finally have a complete workflows and a method to create a video scene - woohooo. It’s not perfect but it’s good enough and I’ve thoroughly enjoyed the challenges from fabricated rings on hands, spots appearing from nowhere, facial inconsistency, clothing suddenly changing style .. well you all know the challenges)
Now for my next challenge and it’s one I wish I had combined with this project… audio
My main workflow is a native Wan2.2 - not even sure its a bit of a hybrid SDXL I think… not figured this bit out yet… anyway, there is no audio. The save video node audio icon is not active…
I’ve tried to add a node but I’m not sure that’s the answer as this looks like simply adding a prerecorded audio track, I just need to prompt speech through the video…
any help always appreciated although I have a horrible suspicion that my home made workflow may now have reached it’s limits so happy to create a new one (I still only have a 8GB VRAM setup)
many thanks in advance
---
**Author:**  [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C
**Post date:** [June 8, 2026, 4:05am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-driver-update-reactor-node%2F176221%2F8 "2026-06-08T04:05:06Z")
Hmm… if you are trying to do audio too on 8GB VRAM, maybe something like this:
* * *
I would separate the “audio problem” into three different problems:
| Layer | What it means | 8GB VRAM practicality |
| --- | --- | --- |
| **1. Attach audio to a video** | Add an existing `.wav` / `.mp3` track to the generated video | Very realistic |
| **2. Generate speech** | Create the dialogue audio from text or a recording | Realistic, especially if done outside the video workflow |
| **3. Lip-sync / audio-driven motion** | Make the mouth, face, head, or body follow the audio | Possible, but should be treated as a separate later workflow |
So I would **not** try to solve all of this in one giant ComfyUI graph at first.
For 8GB VRAM, the practical order is probably:
```plaintext
1. Generate or record the voice separately
2. Generate the silent video with your current working workflow
3. Mux the audio into the video
4. If the mismatch is too obvious, try a simple lip-sync post-process
5. Only then look at heavier audio-driven video systems
```
The most important point is this:
> An audio input on a video node usually means “I can attach an existing audio stream,” not “I can generate speech from the prompt.”
So if the save/combine video node has an audio socket or audio icon, that does not necessarily mean Wan/ReActor is generating audio. It usually means you can pass in an existing audio object and have it combined into the final file.
## Recommended path for 8GB VRAM
I would start with the boring, common, well-documented path:
```plaintext
TTS or recorded voice
↓
silent generated video
↓
mux audio into the video
↓
optional Wav2Lip / LatentSync pass if lip-sync is needed
```
This is less magical than a full audio-driven video model, but it is much more realistic on 8GB VRAM.
## Why I would not start with Wan2.2-S2V locally
Wan2.2-S2V is closer to the ideal solution: image/video + audio → speech-driven video.
But I would not start there on 8GB VRAM.
Wan2.2-S2V-14B exists and is the more “native” speech-to-video direction:
- [Wan2.2 GitHub](https://github.com/Wan-Video/Wan2.2)
- [Wan-AI/Wan2.2-S2V-14B on Hugging Face](https://huggingface.co/Wan-AI/Wan2.2-S2V-14B)
However, the official model card / README examples are much heavier than an 8GB local setup. The S2V route is more like:
```plaintext
high-VRAM GPU / cloud / hosted workflow
```
not:
```plaintext
easy local 8GB ComfyUI workflow
```
So I would treat Wan2.2-S2V as the “ideal future path,” not the first recovery path.
## Step 1: audio attachment / muxing
For simply putting audio into a generated video, the common ComfyUI path is usually something like:
```plaintext
LoadAudio
+
Video Combine
```
Useful links:
- [ComfyUI LoadAudio node](https://docs.comfy.org/ja/built-in-nodes/LoadAudio)
- [ComfyUI SaveAudio node](https://docs.comfy.org/ja/built-in-nodes/SaveAudio)
- [ComfyUI-VideoHelperSuite](https://github.com/kosinkadink/ComfyUI-VideoHelperSuite)
- [RunComfy Video Combine node guide](https://www.runcomfy.com/comfyui-nodes/ComfyUI-VideoHelperSuite/VHS_VideoCombine)
VideoHelperSuite’s `Video Combine` node is useful because it combines image frames into a video, and if an optional audio input is provided, it can combine that audio into the output video.
So the first test should be very simple:
```plaintext
short generated silent video
+
short audio file
↓
Video Combine
↓
video with audio
```
Do not start with a full long clip. Start with 5–10 seconds.
### Good first test settings
```plaintext
Duration: 5–10 seconds
One speaker
One face
Front-facing if possible
No scene cuts
No camera chaos
Audio length roughly equals video length
```
This first step answers only one question:
> Can I attach audio to the video at all?
It does not solve lip-sync yet.
## Step 2: generate the speech separately
For speech, I would initially use a separate TTS or recorded voice path.
Possible options:
| Option | Why use it | Caveat |
| --- | --- | --- |
| **Recorded voice** | Simplest and most predictable | Requires recording |
| **External TTS** | Often easiest | May require API/account |
| **ComfyUI TTS node** | Keeps more inside ComfyUI | Adds more dependencies |
| **Voice cloning TTS** | Better character voice control | More setup and ethical/legal care |
ComfyUI TTS/audio nodes exist, but I would keep them separate from the main video workflow at first.
Some useful entry points:
- [TTS-Audio-Suite for ComfyUI](https://github.com/diodiogod/TTS-Audio-Suite)
- [TTS-Audio-Suite releases](https://github.com/diodiogod/TTS-Audio-Suite/releases)
- [F5-TTS paper](https://arxiv.org/abs/2410.06885)
- [ComfyUI ElevenLabs integration announcement](https://blog.comfy.org/p/elevenlabs-is-now-available-in-comfyui)
For the first working version, I would not care too much where the voice comes from. The important thing is to get a clean `.wav` or `.mp3` that you can attach to the video.
## Step 3: if lip-sync is needed, start with common tools
You probably will eventually want lip-sync. But I would not start with the newest full audio-driven video system.
For beginner-friendly debugging, I would try the older/common lip-sync route first:
```plaintext
generated video
+
speech audio
↓
Wav2Lip or LatentSync
↓
lip-synced video
```
This is a post-processing step. It is different from asking Wan to generate the whole video from the audio.
## Beginner-friendly first lip-sync option: Wav2Lip
Wav2Lip is older, but that is actually a benefit for debugging. There are many examples, tutorials, and failure reports around it.
Useful links:
- [ComfyUI\_wav2lip](https://github.com/ShmuelRonen/ComfyUI_wav2lip)
- [Wav2Lip paper](https://arxiv.org/abs/2008.10010)
- [Wav2Lip original GitHub repo](https://github.com/Rudrabha/Wav2Lip)
- [Example YouTube tutorial: LipSync in ComfyUI with ReActor and Wav2Lip](https://www.youtube.com/watch?v=UPBjx5SuJeA)
Why Wav2Lip first?
```plaintext
older
common
more tutorials
more known failure cases
simpler mental model
```
The mental model is straightforward:
```plaintext
input video + input audio → output video with adjusted mouth movement
```
It may not be the best quality, but it is often a good first proof of concept.
### Expected Wav2Lip problems
Wav2Lip can struggle with:
```plaintext
small faces
side views
covered mouths
fast head movement
multiple faces
low-resolution faces
strong stylization
large camera motion
long clips
```
So the first test should be intentionally easy:
```plaintext
one person
face visible
mouth visible
short clip
audio length close to video length
```
## Better-quality next option: LatentSync
If Wav2Lip works but the quality is not good enough, I would try LatentSync next.
Useful links:
- [ComfyUI-LatentSyncWrapper](https://github.com/ShmuelRonen/ComfyUI-LatentSyncWrapper)
- [LatentSync paper](https://arxiv.org/abs/2412.09262)
- [LatentSync GitHub issue #99: video/audio length mismatch behavior](https://github.com/bytedance/LatentSync/issues/99)
- [ThinkDiffusion LatentSync guide](https://learn.thinkdiffusion.com/seamless-lip-sync-create-stunning-videos-with-latentsync/)
LatentSync is newer and likely to give better results in some cases, but it also has more moving parts.
The main practical issues to expect are:
```plaintext
video length vs audio length mismatch
fps mismatch
audio sample-rate expectations
face detection failure
small/side faces
long clip instability
VRAM pressure
dependency issues
```
A very common beginner mistake is trying:
```plaintext
5-second video + 30-second audio
```
and expecting a full 30-second lip-synced output. Tools often behave according to the video length, the audio length, or internal chunking assumptions. So keep the first test very short and matched:
```plaintext
5-second video
+
5-second audio
```
## What I would not do first
I would not start with these on 8GB VRAM:
| Tool / direction | Why not first |
| --- | --- |
| **Wan2.2-S2V-14B** | Much closer to ideal, but too heavy for 8GB local first attempt |
| **InfiniteTalk** | More powerful audio-driven video/dubbing direction, but more complex |
| **FantasyTalking / WanVideo adapter workflows** | Potentially strong, but heavier and more fragile |
| **HunyuanVideo-Avatar** | High-end audio-driven human animation; not a simple 8GB beginner route |
| **Long multi-scene lip-sync** | Too many failure points at once |
These are worth knowing about, but I would keep them as later options.
Useful links for later exploration:
- [InfiniteTalk GitHub](https://github.com/MeiGen-AI/InfiniteTalk)
- [InfiniteTalk on Hugging Face](https://huggingface.co/MeiGen-AI/InfiniteTalk)
- [Comfy workflow: Wan2.1 InfiniteTalk audio-driven character lip sync](https://www.comfy.org/workflows/templates-wan2_1_infinitetalk_music-1eab7aa23f6a/)
- [HunyuanVideo-Avatar paper](https://arxiv.org/abs/2505.20156)
- [MMAudio GitHub](https://github.com/hkchengrex/MMAudio)
- [ComfyUI-MMAudio wrapper](https://github.com/kijai/ComfyUI-MMAudio)
InfiniteTalk is interesting because it does not only try to modify the lips. It aims to align lip sync, head movement, body posture, and facial expression from an input video and audio track. That is more ambitious than Wav2Lip-style mouth replacement. But that also means it is not where I would start on a small local setup.
## Recommended practical workflow
I would use this staged approach.
### Phase 1 — prove audio muxing
Goal:
```plaintext
Can I attach audio to my generated video?
```
Test:
```plaintext
1. Generate a 5-second silent video
2. Create or record a 5-second audio file
3. Load the audio
4. Combine video + audio
5. Export
```
Use:
- [LoadAudio](https://docs.comfy.org/ja/built-in-nodes/LoadAudio)
- [VideoHelperSuite Video Combine](https://github.com/kosinkadink/ComfyUI-VideoHelperSuite)
Do not care about lip-sync yet.
### Phase 2 — create better speech
Goal:
```plaintext
Can I make the voice track I actually want?
```
Options:
```plaintext
recorded voice
external TTS
ComfyUI TTS node
voice-cloning TTS
```
Output:
```plaintext
clean wav/mp3
same approximate duration as the video
```
### Phase 3 — basic lip-sync attempt
Goal:
```plaintext
Can I make the mouth roughly match the audio?
```
First try:
```plaintext
Wav2Lip
```
Then, if needed:
```plaintext
LatentSync
```
Test conditions:
```plaintext
5–10 seconds
single person
front-facing
no cuts
mouth visible
audio length ~= video length
```
### Phase 4 — scale up carefully
Only after the short test works:
```plaintext
longer clip
higher resolution
more motion
more camera movement
more stylized faces
multiple scenes
```
If it breaks, go back to a shorter clip.
### Phase 5 — advanced audio-driven video
Only later consider:
```plaintext
InfiniteTalk
Wan2.2-S2V
HunyuanVideo-Avatar
FantasyTalking
MMAudio for sound effects/background audio
```
This is where you explore more modern full audio-driven motion systems, but it is not the first 8GB route.
## Suggested decision table
| Goal | First thing to try | If not enough | Avoid at first |
| --- | --- | --- | --- |
| Just add sound | VideoHelperSuite Video Combine | ffmpeg/editor mux | S2V |
| Generate dialogue | external TTS or simple ComfyUI TTS | better TTS / voice cloning | full audio-driven video |
| Basic lip-sync | Wav2Lip | LatentSync | InfiniteTalk first |
| Better lip-sync quality | LatentSync | short-clip advanced tools | long full-scene test |
| Body/head/audio-driven performance | InfiniteTalk-like workflows | cloud/high-VRAM workflows | 8GB local full setup |
| Sound effects/background audio | MMAudio-like V2A tools | manual SFX editing | treating it as dialogue TTS |
## Practical advice for 8GB VRAM
For 8GB VRAM, I would think in terms of short, separate stages:
```plaintext
video generation
audio generation
audio muxing
lip-sync pass
final edit
```
not one huge all-in-one workflow.
A good first target:
```plaintext
5-second talking clip
one face
one voice
audio attached
rough lip-sync
```
A bad first target:
```plaintext
81-frame or longer full workflow
multiple cuts
stylized face
moving camera
ReActor
Wan video
TTS
lip-sync
audio mux
all in one graph
```
The second version has too many things that can fail at once.
## The simple recommendation
If I had to pick a practical beginner route, I would do:
```plaintext
1. Keep your current working video workflow.
2. Generate or record the voice separately.
3. Use VideoHelperSuite / Video Combine to attach the audio.
4. If lip-sync is necessary, try Wav2Lip on a 5–10 second clip.
5. If Wav2Lip is too low-quality, try LatentSync.
6. Treat Wan2.2-S2V / InfiniteTalk / HunyuanVideo-Avatar as later high-end options.
```
That path is not the fanciest, but it is probably the most debuggable.
And with 8GB VRAM, “debuggable” matters more than “most advanced.”
---
**Author:**  [@kdalts3759](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fkdalts3759)%5C
**Post date:** [June 13, 2026, 8:39am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-driver-update-reactor-node%2F176221%2F9 "2026-06-13T08:39:00Z")
Still figuring out how to prevent my wan2.1 w/f from inventing things into a clip that mess up the integrity of the scene
for example, when hands disappear for what ever reason out of shot, then, in a later shot they back in the scene but covered with rings and hideous nail colours… problem is, earlier clips show no rings or nail colour so this looks off
Tried all sorts of prompts like ((nude nails : 1.4)) and negative prompts to avoid like nail colour, rings on fingers, bracelets etc but nothing seem to work… I even tried taking the last generated frame with the accessories and removed them in I2I.. then reran the I2V using 1st frame last frame.. very time consuming and then new rings and nail colours appear in the next clip
This is a bit of a show stopper really… cant have this inconsistency - its tough enough maintaining facial consistency… just get close enough then a ring appears in the scene… really frustrating… sometime taking me an hour to just produce a 6 second clip with consistency
Any advice is always welcome
---
**Author:**  [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C
**Post date:** [June 13, 2026, 9:03am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-driver-update-reactor-node%2F176221%2F10 "2026-06-13T09:03:41Z")
Hmm, this is not really a Wan-only thing, but there is a pretty hard ceiling on what prompt changes alone can fix in the model output:
* * *
I think this is probably **not just a prompt problem**.
What you are describing sounds like a mix of:
```plaintext
image-to-video continuity drift
+
occlusion / out-of-frame re-entry
+
small-detail resampling
+
clip-to-clip artifact accumulation
```
In simpler terms:
```plaintext
hand is visible with no rings / nude nails / no bracelet
↓
hand leaves the frame, becomes hidden, or crosses a clip boundary
↓
model no longer has a strong visual anchor for the exact hand details
↓
hand re-enters the frame
↓
model re-invents plausible "pretty hand" details
↓
rings, nail polish, bracelets, manicured nails, etc. appear
```
That is frustrating, but it is also a very normal kind of failure in AI video workflows.
I would not interpret it as:
```plaintext
The negative prompt is wrong.
```
I would interpret it more like:
```plaintext
The model is not being visually constrained strongly enough after the hand disappears.
```
So I would treat the hands, nails, rings, and bracelets as **continuity props** , not just prompt words.
If the hands matter to the scene, manage them the same way you would manage a face, outfit, tattoo, logo, or important object.
## Direct answer
For this case, I would not try to solve it only with:
```plaintext
no rings
no nail polish
((nude nails:1.4))
```
That can help, but it is not a hard constraint.
A better practical stack is:
| Layer | What it does | 8GB VRAM suitability | How much I would rely on it |
| --- | --- | --- | --- |
| **Positive continuity prompt** | Tells Wan what must remain stable | Safe | Medium |
| **Negative prompt** | Reduces unwanted concepts | Safe | Low/medium |
| **Shot design** | Avoids giving the model a chance to re-invent the hand | Safe | High |
| **Short clips** | Reduces drift and error accumulation | Safe | High |
| **Clean first frames** | Gives each new clip a corrected visual anchor | Safe | Very high |
| **Still-image I2I / inpaint** | Fixes bad keyframes before continuing | Usually realistic | Very high |
| **Video inpaint / VACE** | Repairs a region across frames | Later/experimental on 8GB | Medium, but not first |
| **Fun Control / pose/depth/canny** | Controls motion/structure more than accessories | Later/experimental | Medium |
| **Reference / LoRA / identity workflows** | Helps character/object consistency | Later | Case-dependent |
The short version:
```plaintext
Prompt can bias the model.
Clean frames and shot planning constrain the model.
```
For your particular artifact, I would start with:
```plaintext
structured positive prompt
+
shorter shots
+
avoid hand leaving frame
+
clean keyframe before each new clip
+
still-image inpaint if the hand becomes wrong
```
Only after that would I try heavier video-editing workflows.
## Why this is not only a Wan issue
This is a broader image-to-video problem.
Image-to-video generation starts from an image and tries to extend it into a temporally coherent video. But maintaining visual consistency across the subject, background, style, and details is still a known hard problem.
Useful background:
- [ConsistI2V: Enhancing Visual Consistency for Image-to-Video Generation](https://arxiv.org/abs/2402.04324)
- [AIGCBench: Comprehensive Evaluation of Image-to-Video Generation](https://arxiv.org/abs/2401.01651)
- [ConsID-Gen: View-Consistent and Identity-Preserving Image-to-Video Generation](https://arxiv.org/abs/2602.10113)
The exact research papers are not necessary for your workflow, but they are useful context: even research systems treat consistency as a central problem. So if Wan invents a ring after the hand disappears, that is not surprising. It is a practical version of the same general issue.
## Why hands, nails, and jewelry are especially fragile
Some details are much harder to preserve than others.
| Detail type | Usually easier/harder | Why |
| --- | --- | --- |
| Character gender/body outline | Easier | Large global feature |
| Hair color | Medium | Visible but can drift |
| Clothing color | Medium | Large but texture can change |
| Face identity | Hard | Needs identity preservation |
| Hands/fingers | Hard | Complex anatomy, small shapes |
| Nails | Very hard | Tiny detail, easily stylized |
| Rings/bracelets | Very hard | Small accessories, often “beautified” by model |
| Logos/text | Very hard | Fine detail and exact symbols |
The model can preserve:
```plaintext
same woman
same room
same general outfit
same cinematic look
```
while still changing:
```plaintext
nails
rings
bracelets
finger details
small clothing trim
```
That is why prompt changes may improve the probability but not guarantee continuity.
## Wan-specific prompt advice
For Wan, I would use a more structured prompt rather than only short tokens.
A useful Wan prompting discussion:
- [How to get the most out of prompts for WAN Models](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fhow-to-get-the-most-out-of-prompts-for-wan-models%2F170354)
The practical idea is to describe:
```plaintext
subject
scene
camera
motion
style
continuity constraints
```
not only a list of forbidden objects.
For example, instead of only:
```plaintext
no rings, nude nails
```
I would include a positive continuity block:
```plaintext
Her hands remain plain and bare throughout the entire shot.
Her fingernails are short, natural, nude, and unpainted.
She wears no rings, no bracelets, no bangles, no gemstones, and no hand jewelry.
When her hand moves or re-enters the frame, it remains the same plain bare hand as in the first frame.
The hand details remain visually consistent from the first frame to the last frame.
```
Then use a supporting negative prompt:
```plaintext
rings, ring, bracelet, bracelets, bangle, bangles, hand jewelry, gemstones, nail polish, painted nails, colorful nails, red nails, pink nails, black nails, long nails, fake nails, acrylic nails, decorated nails, manicure, inconsistent hands, changing jewelry
```
But I would still think of this as only **Layer 1**.
## Prompt template to try
Positive prompt:
```plaintext
A cinematic realistic shot of the same woman in the same outfit and the same environment. Her hands remain plain and bare throughout the entire shot. Her fingernails are short, natural, nude, and unpainted. She wears no rings, no bracelets, no bangles, no gemstones, and no hand jewelry. When her hand moves, partially leaves view, or re-enters the frame, it remains the same plain bare hand as in the first frame. The hands, fingernails, sleeves, and skin texture remain visually consistent from the first frame to the last frame. Natural realistic fingers, no added accessories, no cosmetic nail styling.
```
Negative prompt:
```plaintext
rings, ring, bracelet, bracelets, bangle, bangles, hand jewelry, gemstones, jewel, jewels, nail polish, painted nails, colorful nails, red nails, pink nails, black nails, glossy nails, long nails, fake nails, acrylic nails, decorated nails, manicure, jeweled hands, inconsistent hands, changing jewelry, extra fingers, deformed fingers, distorted hands
```
This is worth trying.
But again:
```plaintext
This can reduce the issue.
It probably cannot fully guarantee the issue disappears.
```
## Why negative prompts are weak here
Negative prompts are not the same as a hard mask or a hard rule.
They can reduce probability, but they do not force exact pixel-level continuity.
This is especially true when the artifact is a small plausible detail. In cinematic/fashion/beauty-like imagery, the model may have a learned tendency to add things like:
```plaintext
manicured nails
glossy nails
rings
bracelets
jewelry
```
because those are visually common in similar training contexts.
There are also practical discussions around Wan negative-prompt behavior:
- [ComfyUI-WanVideoWrapper issue: Weighted Negative Prompting Feels Chaotic](https://github.com/kijai/ComfyUI-WanVideoWrapper/issues/1834)
I would still use negatives, but I would not make them the main fix.
## The main failure trigger: hand leaves frame
The most important practical observation in your case is probably this:
```plaintext
The hand leaves the frame, then returns changed.
```
That suggests the problem is not simply:
```plaintext
Wan cannot draw plain hands.
```
It is more likely:
```plaintext
Wan can draw the current hand, but does not preserve the exact small details after occlusion/out-of-frame/re-entry.
```
So the easiest practical fix is to avoid the failure trigger.
If hands/nails/jewelry continuity matters, avoid shots where:
```plaintext
the hand exits the frame
the hand goes behind the body
the hand is hidden by hair/clothing/object
the hand becomes tiny
the hand crosses the edge of the frame
the hand returns after several seconds
the clip boundary happens while the hand is missing or distorted
```
Better shot planning:
```plaintext
keep the hands visible
keep the hands relaxed
cut before the hand disappears
start a new clip from a clean hand frame
avoid long hand re-entry movements
do not make the hand the focus unless necessary
```
This is less exciting than a technical fix, but often more reliable.
A useful practical rule:
> If the model keeps re-inventing something after it disappears, avoid making it disappear.
## Shot design table
| If you want… | Avoid… | Prefer… |
| --- | --- | --- |
| No rings / no bracelets | Hand leaving frame and returning | Hand stays visible |
| Nude natural nails | Close-up beauty hand gestures | Relaxed hands, less emphasis |
| Stable sleeve/hand relation | Hand crossing body/face/hair | Simpler arm motion |
| Stable hands across clips | Last frame with bad hand | Clean corrected first frame |
| Long scene continuity | One long uncontrolled generation | Several short controlled clips |
| Fewer hand artifacts | Tiny/blurred hands | Larger, clearer, simpler hands |
## First/last frame is useful, but not magic
First/last frame workflows are useful, but they are not a total continuity solution.
Relevant links:
- [ComfyUI Wan2.2 tutorial](https://docs.comfy.org/tutorials/video/wan/wan2_2)
- [Wan 2.2 14B First-Last Frame to Video - ComfyUI Workflow](https://www.comfy.org/workflows/video_wan2_2_14B_flf2v-7016f027bcf1/)
- [ComfyUI-WanVideoWrapper issue #1342 - First and Last Frame Pingponging Wan 2.2](https://github.com/kijai/ComfyUI-WanVideoWrapper/issues/1342)
The issue is that first/last frames give boundary guidance, but they do not guarantee that every tiny detail will remain stable inside the generated video.
Also, if your last frame already contains a bad ring/nail/bracelet artifact, and you feed it into the next clip, you may accidentally tell the next generation:
```plaintext
This ring is now part of the scene.
```
So I would not do this blindly:
```plaintext
clip A last frame
↓
clip B first frame
```
I would do this:
```plaintext
clip A last frame candidate
↓
inspect it
↓
fix hands/nails/jewelry as a still image if needed
↓
use the corrected clean image as clip B first frame
```
That gives the model a cleaner anchor.
## Clean keyframe strategy
This is probably the most important workflow change.
A practical clip-chaining workflow:
```plaintext
1. Generate clip A.
2. Pick the best final frame or near-final frame.
3. Inspect hands, nails, jewelry, sleeves, face, clothing.
4. If anything is wrong, fix the frame as a still image.
5. Use the corrected frame as clip B's first frame.
6. Generate clip B.
7. Repeat.
```
This is slower, but it avoids artifact accumulation.
Bad pipeline:
```plaintext
generate video
↓
use last frame automatically
↓
artifact enters next clip
↓
artifact becomes stronger
↓
continuity gets worse
```
Better pipeline:
```plaintext
generate short video
↓
select clean boundary frame
↓
repair boundary frame
↓
continue from repaired frame
```
## Still-image inpainting before video inpainting
Since you are on 8GB VRAM, I would start with still-image repair before video repair.
ComfyUI has basic inpainting workflows:
- [ComfyUI Inpaint Examples](https://docs.comfy.org/tutorials/basic/inpaint)
The simple idea:
```plaintext
bad hand frame
↓
mask rings / nails / bracelet area
↓
inpaint as plain bare hand
↓
use repaired image as next first frame
```
Still-image inpainting is not perfect, but it is usually easier to debug than video inpainting.
For your case, I would try:
```plaintext
I2I / inpaint keyframes first
VACE / video inpaint later
```
## What to do when the bad detail appears inside the clip
If a bad ring/bracelet/nail appears inside an otherwise good clip, you have several options.
| Option | Best when | 8GB friendliness | Notes |
| --- | --- | --- | --- |
| Regenerate the short clip | Clip is short | High | Often easiest |
| Change seed | Artifact is seed-dependent | High | Quick test |
| Change shot | Hand re-entry is causing it | High | Best structural fix |
| Cut around the bad frames | Artifact is brief | High | Normal editing approach |
| Repair a keyframe and regenerate | You need continuity | Medium/high | Good compromise |
| Still-image inpaint frames | Few frames matter | Medium | Manual but controllable |
| Video inpaint / VACE | Good clip except local hand issue | Lower | More advanced |
For a first pass, I would not attempt to perfectly repair a long clip. I would make the clip shorter and regenerate.
## 8GB VRAM reality check
This matters because some solutions are technically relevant but may not be the best first move for your setup.
Wan2.1 has a 1.3B model that is described as consumer-grade and around 8.19GB VRAM:
- [Wan-AI/Wan2.1-T2V-1.3B](https://huggingface.co/Wan-AI/Wan2.1-T2V-1.3B)
- [Wan paper](https://arxiv.org/abs/2503.20314)
But that does **not** automatically mean every Wan editing workflow, VACE workflow, 14B workflow, or video-inpainting setup will be comfortable on an 8GB card.
So I would keep the first-line plan lightweight:
```plaintext
prompt
shot design
short clips
clean first frames
still-image inpaint
```
and treat heavier tools as experiments.
## VACE / video inpainting
VACE is relevant, but I would not put it first for an 8GB setup.
Relevant links:
- [ComfyUI Wan VACE tutorial](https://docs.comfy.org/tutorials/video/wan/vace)
- [Wan2.1-VACE native support announcement](https://blog.comfy.org/p/wan21-vace-native-support-and-ace)
- [Wan2.1 VACE Inpainting - ComfyUI Workflow](https://www.comfy.org/workflows/video_wan_vace_inpainting-a1bb55d904c9/)
- [VACE GitHub](https://github.com/ali-vilab/VACE)
The concept is exactly relevant:
```plaintext
mask the bad hand/nail/jewelry area
↓
inpaint the local region
↓
keep the rest of the video
```
For your case:
```plaintext
mask the hand area
remove ring / nail polish / bracelet
restore plain bare hand
```
However, video inpainting can be harder than it sounds. There are practical reports of VACE/video inpainting damaging areas outside the mask or creating texture issues:
- [Reddit: Wan 2.2 VACE inpainting corrupting outside mask](https://www.reddit.com/r/comfyui/comments/1tezktt/wan_22vace_inpainting_corrupting_outside_mask_and/)
So I would phrase VACE like this:
```plaintext
Very relevant idea.
Worth testing later on a short clip.
Not my first recommendation on 8GB VRAM.
```
If you do try it:
```plaintext
test 2–3 seconds
low resolution first
small mask
one problem area
compare before/after carefully
do not start with a full scene
```
## Fun Control / control workflows
Wan Fun Control workflows may be useful if the problem is hand movement, pose, or structure.
Relevant links:
- [ComfyUI Wan2.1 Fun Control tutorial](https://docs.comfy.org/tutorials/video/wan/fun-control)
- [ComfyUI Wan2.2 Fun Control tutorial](https://docs.comfy.org/tutorials/video/wan/wan2-2-fun-control)
These workflows can use control signals like:
```plaintext
Canny
Depth
OpenPose
MLSD
trajectory
```
This can help with:
```plaintext
hand position
body movement
camera structure
silhouette
motion path
```
But it probably does not directly solve:
```plaintext
no rings
no nail polish
no bracelet
```
So I would put Fun Control in this category:
```plaintext
Useful for motion/shape control.
Not a direct jewelry/nail continuity fix.
Try later if hand motion itself is unstable.
```
## Reference / subject consistency workflows
Reference-based workflows may help with general character and clothing consistency.
Relevant links:
- [Phantom GitHub](https://github.com/Phantom-video/Phantom)
- [Phantom paper](https://arxiv.org/abs/2502.11079)
- [RunComfy: Wan2.1 Stand-In character-consistent video workflow](https://www.runcomfy.com/comfyui-workflows/wan2-1-stand-in-in-comfyui-character-consistent-video-workflow)
These are interesting for:
```plaintext
same character
same outfit
same subject
same visual identity
```
But I would be cautious about expecting them to guarantee:
```plaintext
exact nail color
no tiny ring
same bracelet absence
```
They may help the whole image stay more consistent, but tiny hand accessories are still a very hard target.
## LoRA / training route
A LoRA or character-specific workflow may help if you need repeated scenes with the same character and outfit.
But for your immediate problem, I would not go there first.
Training or reference workflows are more useful when the problem is:
```plaintext
the character keeps changing
the outfit keeps changing
the face keeps changing
```
Your current issue is narrower:
```plaintext
hands/nails/accessories are being invented after motion/occlusion
```
So I would first solve it with:
```plaintext
shot design
keyframes
still repair
short clips
```
not training.
## Suggested practical order
If this were my workflow, I would test in this order:
| Order | Test | Why |
| --- | --- | --- |
| 1 | Add positive hand-continuity wording | Easy and free |
| 2 | Keep negative prompt, but simplify expectations | It may help but not guarantee |
| 3 | Generate a shot where the hands never leave frame | Tests whether re-entry is the trigger |
| 4 | Shorten the clip | Reduces drift |
| 5 | Change seed | Checks if artifact is seed-specific |
| 6 | Use a manually cleaned first frame | Stronger continuity anchor |
| 7 | Fix bad boundary frames with still inpaint | Prevents artifact accumulation |
| 8 | Regenerate only the short bad clip | Cheaper than fixing a long clip |
| 9 | Try VACE/video inpaint on 2–3 seconds | Later experiment |
| 10 | Try Fun Control/reference workflows | Later experiment |
## Tiny test matrix
Before investing in the full scene, I would run a tiny experiment.
| Test | Setup | What it tells you |
| --- | --- | --- |
| A | Original prompt | Baseline |
| B | Add positive hand continuity prompt | Prompt sensitivity |
| C | Same prompt, hand never leaves frame | Whether re-entry causes the artifact |
| D | Same shot, shorter clip | Whether duration causes drift |
| E | Clean corrected first frame | Whether visual anchor helps |
| F | Different seed | Whether it is random seed dependent |
| G | Still-inpainted first frame + shorter clip | Best lightweight solution |
| H | VACE/inpaint short test | Whether local video repair is worth the complexity |
If test C is much better than A, then your main enemy is:
```plaintext
hand disappears → model re-invents details
```
If test E/G is much better, then your best tool is:
```plaintext
clean keyframes
```
If none of them helps, then the prompt/model combination may simply be biased toward styled hands/jewelry and you may need a different shot or workflow.
## A concrete “safe” 8GB workflow
```plaintext
1. Keep the current working Wan workflow.
2. Do not add several new heavy systems at once.
3. Generate only a short clip.
4. Avoid hand leaving frame.
5. Use positive hand continuity wording.
6. Inspect final frames.
7. If hands/nails/jewelry are wrong, fix the still frame.
8. Use the fixed still frame as the next clip's first frame.
9. Only after this works, test VACE/Fun Control/reference workflows separately.
```
That keeps your current setup from getting unstable again.
## What I would avoid for now
I would avoid:
```plaintext
long clips
multiple chained clips without inspection
automatically feeding bad last frames into the next clip
trying VACE on a full scene first
installing several new video custom nodes at once
treating "no rings" as a hard rule
forcing everything through one giant workflow
```
Especially after your earlier ReActor/ONNX/environment trouble, I would keep each new experiment isolated.
## My practical expectation
I would expect roughly this:
| Method | Expected effect |
| --- | --- |
| Negative prompt only | Small improvement, not reliable |
| Better positive continuity prompt | Useful, but not enough |
| Keeping hands visible | Very useful |
| Shorter clips | Very useful |
| Clean first frames | Very useful |
| Still-image inpaint on boundary frames | Very useful |
| VACE/video inpaint | Potentially useful, but more complex |
| Fun Control | Useful for motion/pose, not directly jewelry |
| Reference workflows | Useful for character consistency, uncertain for nails/rings |
So my best guess is:
```plaintext
Do not fight this only at the prompt level.
Make the continuity visible and explicit.
Then repair/anchor the frames where continuity matters.
```
## Final mental model
I would think of it like film continuity:
```plaintext
hands = continuity prop
nails = continuity prop
rings/bracelets = forbidden props
clean first frame = continuity anchor
short clip = safer shot
inpainted keyframe = reset point
```
Once a bad ring appears, do not let it become part of the next generation.
Go back to the last clean frame, repair it if needed, and continue from there.
---
**Author:**  [@kdalts3759](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fkdalts3759)%5C
**Post date:** [June 13, 2026, 11:37am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-driver-update-reactor-node%2F176221%2F11 "2026-06-13T11:37:43Z")
Thanks again for the tips… I had to laugh though… I used the posi and neg prompts you advised… first gen I got 3 rings on one hand, a chunky bracelet and sleeves from nowhere
so clearly prompts are not the solution but thanks anyway
---
**Author:**  [@kdalts3759](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fkdalts3759)%5C
**Post date:** [June 16, 2026, 1:10am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-driver-update-reactor-node%2F176221%2F12 "2026-06-16T01:10:02Z")
I am determined to crack this…
I also tied first frame \> last frame using the exact same frame for both to see if this would tighten up the facial consistency. Then pick a new end frame for the start of the next clip (say fame 50 from 80)… this ensures I have a different start frame for each new clip and don’t just keep going back to the same end frame which would look unnatural
Even this is a battle.. I notice that frames 1\>80 I can see a very gradual light increase (very very slight) and hardly noticeable. Accept, after 4 or 5 clips this light increase becomes very noticeable.. looks like the characters have been on a sun bed by the end of clip 4 and it’s clearly not the same scene anymore
Tried tweaking the diffusions (high and low) but makes no difference, I have a 2 pass ksampler with cfg =1 and KS1 steps 0-2 and KS2 2-4… any higher and the time to gen a 7 sec clip becomes too long on an 8GB gpu
As always, look forward to any advice
---
**Author:**  [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C
**Post date:** [June 16, 2026, 2:38am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-driver-update-reactor-node%2F176221%2F13 "2026-06-16T02:38:09Z")
Hmm, probably:
* * *
I think you have found a **second, separate problem** now.
The earlier rings / nails / bracelets issue was mostly:
```plaintext
object / detail continuity drift
```
This new issue sounds more like:
```plaintext
color / exposure / skin-tone drift
```
They are related because both are continuity problems, but they need slightly different fixes.
Your description is very specific:
```plaintext
frames 1 → 80:
very slight gradual light increase
after 4–5 chained clips:
the small increase has accumulated
the character looks much brighter / more tanned
the scene no longer feels like the same scene
```
That sounds less like a bad prompt and more like **cumulative clip-chain drift**.
## Direct answer
I would not try to solve this only by increasing steps or tweaking the prompt.
On an 8GB GPU, I would first test a **pipeline fix** :
```plaintext
shorter clip
+
do not pass the raw last frame forward
+
create a corrected "clean continuity frame"
+
color/exposure match that frame to a stable reference
+
use the corrected frame as the next clip's first frame
```
In other words, I would stop thinking of the last frame as automatically “safe.”
I would treat the last frame as:
```plaintext
a candidate frame that needs inspection and correction before it becomes the next first frame
```
## Why this seems like a real Wan/I2V behavior
There are a few reports that look close to what you are seeing.
Wan2GP has a very similar issue report:
- [Wan2GP issue #511 - Progressive Light Increase When Using “Continue Video”](https://github.com/deepbeepmeep/Wan2GP/issues/511)
The description there is basically:
```plaintext
every time the video is extended
brightness/light increases
the video becomes progressively more overexposed
```
That is extremely close to your “after 4 or 5 clips” observation.
There is also this one:
- [Wan2GP issue #579 - Wan 2.1 i2v generated videos progressively increased brightness and end up seriously overexposed](https://github.com/deepbeepmeep/Wan2GP/issues/579)
That report describes 5–6 second Wan2.1 I2V generations where brightness increases progressively toward the end of the video.
Wan2.1 itself also has a long-frame color-shift/flicker issue report:
- [Wan2.1 issue #369 - long videos have color shifts and flickering](https://github.com/Wan-Video/Wan2.1/issues/369)
That issue specifically mentions long generations such as 121 frames and says the problem appears when going beyond 81 frames.
So your 80-frame / 7-second setup is right near the area where I would be suspicious of frame-length instability.
There was also an older Wan2.1 I2V frame-count discussion:
- [Wan2.1 issue #73 - Image2Video hardcoded at 81 frames](https://github.com/Wan-Video/Wan2.1/issues/73)
I would not over-interpret that as “81 is always the magic number,” because workflows and implementations differ. But it does suggest that Wan2.1 I2V has historically been very sensitive around that frame-count region.
## The likely mechanism
I would describe the mechanism like this:
```plaintext
clip 1 starts from a good frame
↓
within clip 1, exposure/skin tone drifts slightly brighter
↓
clip 1 last frame is now a little brighter than the original
↓
clip 2 uses that brighter frame as its new starting point
↓
clip 2 drifts a little brighter again
↓
repeat 4–5 times
↓
the accumulated change becomes obvious
```
So the problem is not necessarily that any single clip is terrible.
The problem is that a very small change becomes the new baseline each time.
This is why it can be “hardly noticeable” in one 80-frame clip, but obvious after several clips.
## Two different continuity problems
I would separate the current issues like this:
| Problem | What changes | Likely cause | Best first response |
| --- | --- | --- | --- |
| **Object/detail drift** | rings, nails, bracelets, sleeves | model re-invents small details after motion/occlusion | shot design, clean keyframes, still inpaint |
| **Color/exposure drift** | skin tone, brightness, contrast, warmth | small exposure/color shift accumulates through chained clips | shorter clips, color reset, reference matching |
| **Identity drift** | face changes | weak identity constraint over time | better reference frames, face restore/swap, shorter clips |
| **Motion drift** | pose/action becomes different | long generation / weak control | shorter clips, control workflows |
| **Scene drift** | room/background changes | insufficient visual anchor | stronger first frames, fewer chained assumptions |
Right now, #12 is mostly the second one:
```plaintext
color/exposure drift
```
## This is not mainly a prompt problem
You can try adding phrases like:
```plaintext
consistent lighting
constant exposure
same skin tone
no exposure change
no brightness shift
same color grading
```
but I would not expect that to fully solve it.
The issue is happening inside the generated image sequence and then getting inherited by the next clip.
A prompt can bias the model, but it cannot reliably enforce:
```plaintext
frame 80 must have exactly the same exposure distribution as frame 1
```
So I would put prompt tweaks low on the priority list.
## Why increasing steps may not be the best first fix
You said:
```plaintext
2-pass KSampler
cfg = 1
KS1 steps 0–2
KS2 steps 2–4
higher steps make a 7 sec clip too slow on 8GB GPU
```
That is important.
On an 8GB card, trying to fix this by simply raising steps may not be practical. It may help a little, or it may not, but it makes every experiment expensive.
I would first test cheaper variables:
```plaintext
frame count
clip length
raw last frame vs corrected first frame
color match on continuity frame
seed sensitivity
reference-frame color matching
```
Those tests may teach you more than just increasing steps.
## First test: shorten the clip
Because there are Wan reports around color shift / flicker at longer frame counts, I would first test shorter clips.
For example:
| Test | Frames | Goal |
| --- | --- | --- |
| A | 80 frames | current baseline |
| B | 48 frames | test whether drift reduces |
| C | 40 frames | stronger short-clip test |
| D | 32 frames | extreme stability test |
Keep everything else as similar as possible:
```plaintext
same source image
same prompt style
same sampler style
same resolution
same approximate scene
```
Then compare:
```plaintext
frame 1 vs final frame
```
If the brightness drift is much smaller at 40–48 frames, then the problem is probably strongly related to clip length / frame count.
That would be useful information.
## Second test: do not chain raw last frames
I would test this difference:
```plaintext
Test A:
clip A raw last frame → clip B first frame
Test B:
clip A last frame
→ color/exposure corrected against original reference
→ clip B first frame
```
If Test B reduces the “sun bed” effect, then the main fix is not prompt or steps.
The main fix is:
```plaintext
color reset before chaining
```
## Build a reference frame
Pick one frame as the color reference.
Usually one of these:
```plaintext
original input image
clip 1 frame 1
best-looking frame from clip 1
a manually corrected still frame
```
This becomes your “visual truth” for:
```plaintext
skin tone
exposure
contrast
warmth
color balance
scene brightness
```
Then every time you create a new continuity frame, compare it against that reference.
The mental model:
```plaintext
reference frame = color anchor
last frame = motion anchor
corrected continuity frame = next first frame
```
## Suggested chaining pipeline
Instead of:
```plaintext
generate clip 1
↓
use raw last frame as clip 2 first frame
↓
generate clip 2
↓
use raw last frame as clip 3 first frame
```
try:
```plaintext
generate clip 1
↓
pick a good near-final frame
↓
compare it to the reference frame
↓
correct exposure/color/skin tone
↓
save this as clean continuity frame 1
↓
use clean continuity frame 1 as clip 2 first frame
↓
generate clip 2
↓
repeat
```
This turns clip chaining into a controlled pipeline instead of an automatic drift amplifier.
## Practical “color reset” methods
There are several levels of correction.
| Method | Where | Good for | Notes |
| --- | --- | --- | --- |
| Manual correction | editor / image tool | one boundary frame | very controllable |
| ColorMatch | ComfyUI | matching one frame/image to reference | quick test |
| Histogram match | ComfyUI | approximate color distribution match | can help with exposure/color drift |
| LUT / grade | DaVinci / ffmpeg / editor | final clip consistency | good for final polish |
| Full-frame batch correction | ComfyUI / editor | all frames in a clip | more work, but useful |
| Video inpainting | ComfyUI | local objects/details | not the first fix for exposure drift |
ComfyUI-related nodes/resources worth looking at:
- [ComfyUI-KJNodes ColorMatch](https://www.runcomfy.com/comfyui-nodes/ComfyUI-KJNodes/ColorMatch)
- [KJNodes source / ColorMatch implementation](https://github.com/kijai/ComfyUI-KJNodes/blob/main/nodes/image_nodes.py)
- [ComfyUI Essentials ImageColorMatch+](https://www.runcomfy.com/comfyui-nodes/ComfyUI_essentials/ImageColorMatch-)
- [ComfyUI-EasyColorCorrector](https://github.com/regiellis/ComfyUI-EasyColorCorrector)
External tools:
- [FFmpeg documentation](https://ffmpeg.org/ffmpeg.html)
- [FFmpeg filters documentation](https://ffmpeg.org/ffmpeg-filters.html)
- [Using FFmpeg to apply LUT / color correction](https://gabor.heja.hu/blog/2024/12/10/using-ffmpeg-to-color-correct-color-grade-a-video-lut-hald-clut/)
- DaVinci Resolve or any normal video editor
I would not assume a ComfyUI color-match node will be perfect. It may be enough for boundary frames, though.
## Important caution about ColorMatch
Color matching is useful, but it can also fail.
There is a KJNodes issue where Color Match caused problems when later frames were very white:
- [ComfyUI-KJNodes issue #349 - Color Match issue with white frames](https://github.com/kijai/ComfyUI-KJNodes/issues/349)
Also, if the camera angle or content changes too much, a pure color-match operation can produce weird results.
So I would test gently:
```plaintext
use 50% strength first if available
test on one frame
do not apply blindly to a whole long clip
compare before/after
```
For boundary-frame chaining, I would start with:
```plaintext
correct only the frame that becomes the next first frame
```
not:
```plaintext
color-match every frame aggressively
```
## Boundary frame correction vs full clip correction
There are two different uses of color correction.
### 1. Boundary-frame correction
Goal:
```plaintext
prevent drift from being passed into the next generation
```
This is probably the most important for you.
Pipeline:
```plaintext
clip A final frame
↓
color match to reference
↓
use corrected frame as clip B first frame
```
### 2. Final clip grading
Goal:
```plaintext
make the finished clips look consistent after generation
```
Pipeline:
```plaintext
all clips generated
↓
bring into editor
↓
match exposure/contrast/skin tone across clips
↓
export final movie
```
Both are useful, but they solve different parts of the problem.
Boundary correction prevents the next generation from inheriting the drift.
Final grading makes the already-generated clips look consistent.
## What I would test first
I would run a small matrix.
| Test | Change | What it tells you |
| --- | --- | --- |
| 1 | Current 80-frame generation | baseline |
| 2 | 48-frame generation | whether shorter clips reduce drift |
| 3 | 40-frame generation | stronger short-clip check |
| 4 | 80-frame generation, different seed | whether seed matters |
| 5 | 80-frame generation, same source but lower motion | whether motion drives drift |
| 6 | raw last-frame chaining | baseline chaining drift |
| 7 | color-corrected continuity-frame chaining | whether color reset helps |
| 8 | final editor grade only | whether post grade is enough |
The highest-value test is probably:
```plaintext
80 frames vs 40–48 frames
```
and then:
```plaintext
raw last frame vs corrected continuity frame
```
## Why 7 seconds may be too ambitious for stable chaining
A 7-second clip may be fine if you only need one clip.
But if you plan to chain:
```plaintext
clip 1
clip 2
clip 3
clip 4
clip 5
```
then each clip must not only look good by itself. It must also end in a good state for the next clip.
That is much harder.
A 7-second clip with a tiny internal exposure drift may look acceptable alone, but it becomes a bad building block for chaining.
So for chained scenes, shorter clips can be more stable:
```plaintext
3–4 seconds
or
40–48 frames
```
Then use editing to assemble the scene.
This may feel slower creatively, but it gives you more control.
## The “do not pass drift forward” rule
This is probably the key rule.
Do not pass this forward:
```plaintext
slightly brighter last frame
```
Pass this forward:
```plaintext
motion-continuity frame corrected back to reference exposure/color
```
Once a frame becomes brighter and you use it as the next input, the model may treat the brighter skin/scene as the new normal.
That is the same idea as the earlier rings/nails issue:
```plaintext
if a bad ring becomes part of the next first frame,
the next clip may preserve or amplify the ring
```
For color:
```plaintext
if a brighter skin tone becomes part of the next first frame,
the next clip may preserve or amplify the brighter skin tone
```
## Relationship to long-video research
This is not just a “you configured something wrong” issue.
Long/chained video generation has a general problem called things like:
```plaintext
drift
error accumulation
exposure bias
temporal degradation
memory bottleneck
```
FramePack discusses this problem directly:
- [FramePack project page](https://lllyasviel.github.io/frame_pack_gitpage/)
- [FramePack paper](https://arxiv.org/html/2504.12626v3)
- [LearnOpenCV FramePack article](https://learnopencv.com/framepack-video-diffusion/)
Another related long-video paper:
- [Rolling Forcing: Training-Free Long Video Generation](https://openreview.net/forum?id=IAyzXjbfwo)
I am not saying you should switch to those immediately. With 8GB VRAM, that may not be the practical next step.
But these links are useful because they show that the problem category is real:
```plaintext
long video generation tends to accumulate errors over time
```
Your case is a practical Wan I2V version of that.
## What I would not do first
I would not start with:
```plaintext
raising steps a lot
trying to fix it with "no overexposure" in the negative prompt
building a giant new workflow
installing several new video systems at once
trying full video inpainting first
```
Those may be useful later, but they are not the cheapest diagnostic tests.
Given your 8GB GPU, I would first test:
```plaintext
shorter clips
color reset between clips
boundary-frame correction
final grading
```
## A possible safe workflow for your setup
Something like:
```plaintext
1. Pick one reference frame.
Usually original image or clip 1 frame 1.
2. Generate clip 1, but test shorter length first.
Try 40–48 frames.
3. Inspect frame 1 vs final frame.
Look at exposure, skin tone, warmth, contrast.
4. Pick a near-final frame for continuity.
Do not automatically use frame 80 if frame 80 is already drifting.
5. Color-correct that frame against the reference.
Use ColorMatch / histogram match / manual editor correction.
6. Use the corrected frame as clip 2 first frame.
7. Repeat.
8. After all clips are generated, do final color grading across the finished clips.
```
If you must keep 80 frames, then I would be stricter about step 5.
## Tiny diagnostic checklist
For each generated clip, check:
```plaintext
frame 1
frame 20
frame 40
frame 60
frame 80
```
Ask:
```plaintext
Is the face brighter?
Is the skin warmer?
Is contrast lower?
Are highlights clipping?
Is the background changing?
Is the whole frame brighter or only the character?
```
If the whole frame is drifting:
```plaintext
global exposure/color drift
```
If only the face/skin is drifting:
```plaintext
subject/skin-tone drift
```
If only highlights are growing:
```plaintext
overexposure/highlight clipping
```
Different drift types may need different correction.
## Suggested language for your notes
I would name the two current problems like this:
```plaintext
Problem 1:
object/detail continuity drift
rings, nails, bracelets, sleeves
Problem 2:
cumulative color/exposure drift
brightness, skin tone, contrast over chained clips
```
Then your workflow goal becomes:
```plaintext
Do not let either kind of drift become the next clip's starting condition.
```
## My practical expectation
I would expect the best improvement from:
```plaintext
shorter clips
+
not using raw last frames
+
color-correcting continuity frames
```
I would expect smaller or inconsistent improvement from:
```plaintext
negative prompt
slightly more steps
minor diffusion tweaks
```
And I would treat model/workflow changes as later experiments.
## Short version
You are probably no longer just fighting prompt adherence.
You are now fighting **clip-chain drift**.
Each clip slightly changes the visual state. If the next clip starts from that changed state, the change accumulates.
For your 8GB setup, the most practical first fix is probably:
```plaintext
try 40–48 frames
use a stable reference frame
correct the boundary frame before chaining
then do final color grading after all clips are assembled
```
That may not be a perfect in-model fix, but it is a realistic production-style workaround.
---
**Author:**  [@kdalts3759](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fkdalts3759)%5C
**Post date:** [June 16, 2026, 4:15pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-driver-update-reactor-node%2F176221%2F14 "2026-06-16T16:15:32Z")
I probably didn’t explain it well
frame 1 and frame 80 are exactly the same frame.
I am using a 1st frame \> last frame w/f. I find this helps tighten the facial constituency - as it drifts mid clip it starts to return because it needs to land on the last frame which is exactly the same frame as the first frame.
If I look at all the frames (80) in all side by side I can see the around frame 20 ish there is a def increase in brightness through to about frame 50 ish. Then, as it targets the end frame is starts to go dark again
Interestingly, I tried using one of the lighter frames as 1st and last and it did the opposite… went from light to dark then back to light again
Seems every time it find a workaround for 1 challenge then another one comes along - lol
---
**Author:**  [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C
**Post date:** [June 16, 2026, 11:17pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-driver-update-reactor-node%2F176221%2F15 "2026-06-16T23:17:01Z")
Ah, so, then I think the fix changes too:
* * *
I think I misunderstood one important detail earlier.
If frame 1 and frame 80 are **literally the same image** , then this is probably **not mainly cumulative last-frame chaining drift**.
It sounds more like a **same-frame first/last-frame problem** :
```plaintext
frame 1 = reference image
frames 20-50 = model invents a transition path and exposure/color moves
frame 80 = the same reference image again
```
So the model is not simply drifting forward forever. It is doing something more like:
```plaintext
dark/reference
→ unwanted brighter middle
→ dark/reference again
```
And when you use one of the lighter middle frames as both the first and last frame, it does the opposite:
```plaintext
light/reference
→ unwanted darker middle
→ light/reference again
```
That is a very useful observation, because it changes the diagnosis.
## Direct answer
I would stop treating identical first/last-frame FLF as the main tool for this specific goal.
A simple rule:
```plaintext
FLF is good for “A becomes B.”
FLF is not always good for “A stays A.”
```
Your goal seems closer to:
```plaintext
A
→ small motion / facial micro-movement / slight acting
→ A
```
But FLF may interpret identical first/last frames as:
```plaintext
A
→ generate some kind of transition path anyway
→ A
```
That generated middle path can show up as:
```plaintext
brightness hump
contrast shift
skin tone change
gray flicker
unwanted exposure movement
unwanted visual excursion
```
So yes, if frame 1 and frame 80 are exactly the same image, the fix changes.
## Why identical first/last frames can be unstable
Wan FLF is not simply:
```plaintext
keep this image stable for 80 frames
```
It is more like:
```plaintext
given a starting frame and an ending frame,
generate the missing motion between them
```
The ComfyUI Wan FLF documentation describes FLF as using a start frame and an end frame, with the model filling in the intermediate dynamic change:
[ComfyUI Wan2.1 FLF2V Native Example](https://docs.comfy.org/tutorials/video/wan/wan-flf)
That distinction matters.
FLF is naturally a **transition tool** :
```plaintext
first image
→ intermediate motion / transformation
→ last image
```
So if you give it:
```plaintext
first image = A
last image = A
```
the model may still try to create a meaningful middle. It may not understand that you want:
```plaintext
A, but almost static, with constant exposure and only tiny motion
```
It may instead produce:
```plaintext
A
→ some invented motion/lighting/color path
→ A
```
Your light/dark/light experiment fits that explanation very well.
## Similar reports / clues
There are a few reports that point in the same direction.
### Same image as first/last causing loop/color problems
This issue is very relevant:
[ComfyUI-WanVideoWrapper issue #1541 — Wan 2.2 I2V Looping same image Start-End step - Color contrast increase over time](https://github.com/kijai/ComfyUI-WanVideoWrapper/issues/1541)
That report involves using the same image as first/last for a loop and getting problems such as:
```plaintext
color / contrast increase
gray flicker
gray ending
```
It is not exactly the same workflow as yours, but it is close enough to be useful: identical first/last conditioning can create unwanted color/exposure behavior.
### First/last frame ping-pong behavior
Another related issue:
[ComfyUI-WanVideoWrapper issue #1342 — First and Last Frame Pingponging Wan 2.2](https://github.com/kijai/ComfyUI-WanVideoWrapper/issues/1342)
This is useful because it shows that FLF can behave less like “hold this image steady” and more like a temporal path that may move toward one endpoint and then back.
### Practical comment: identical frames may be bad
There is also a practical Reddit discussion where users mention that identical first/last frames can give worse results, and that slightly changing the last frame may help:
[Reddit: PSA — WAN 2.2 does First Frame Last Frame out of the box](https://www.reddit.com/r/StableDiffusion/comments/1me4306/psa_wan_22_does_first_frame_last_frame_out_of_the/)
The practical takeaway is:
```plaintext
Do not always use identical first/last frames.
If you use FLF, make the last frame slightly different.
```
That turns the task into:
```plaintext
A → A'
```
instead of:
```plaintext
A → A
```
The model may handle that more naturally.
## Updated tool map
I would map the tools like this.
| Goal | Better first tool | Why |
| --- | --- | --- |
| **A clearly changes into B** | FLF | This is what first/last-frame generation is good at |
| **A stays mostly A with slight motion** | short normal I2V | Less likely to create an artificial transition arc |
| **A loops back to A** | normal I2V + editing loop | Often more stable than identical first/last FLF |
| **A loops back to A using FLF anyway** | FLF with a slightly modified last frame | Avoids the exact duplicate endpoint problem |
| **The middle of FLF changes too much** | shorter clip / middle anchor / FMLF | First+last alone may not constrain the middle |
| **Color/brightness hump appears mid-clip** | avoid same-frame FLF first; then post-correct if needed | The hump may be part of the generated FLF path |
| **8GB VRAM stability** | short clips and editing | More iterations, fewer heavy experiments |
The main thing:
```plaintext
Use FLF when you want a transition.
Use normal I2V when you want a short living-still / micro-motion shot.
Use editing when you want a clean loop.
```
## Broader map for your current project
Based on the whole thread, I would separate the tasks like this:
| Task | Practical path on 8GB VRAM | Avoid as first step |
| --- | --- | --- |
| ReActor face swap | Keep it simple, test stills/short clips first | full complex video workflow immediately |
| Basic Wan video | short normal I2V | long chained clips before stability testing |
| Add audio | TTS or recorded audio + mux | full speech-to-video model locally |
| Lip-sync | Wav2Lip / LatentSync as post-process | Wan2.2-S2V 14B on 8GB |
| Keep hands/nails/jewelry stable | shot planning + clean keyframes + still inpaint | negative prompt only |
| A→B visual change | FLF | normal I2V only |
| A→tiny motion→A | short normal I2V | identical first/last FLF |
| Loop-like result | generate a good short clip, then loop in editing | forcing exact duplicate FLF loop |
| More control over the middle | FMLF / middle anchor later | hoping first/last alone controls everything |
| Heavy local video editing | test only after the simple path works | installing many new systems at once |
This is why I would not put FLF in the “bad” category. It is not bad. It may just be the wrong tool for this exact task.
## What I would test next
I would run a small test matrix.
### Test 1 — normal I2V, no FLF
```plaintext
Use the same source image.
Do not set the same image as both first and last.
Generate a short normal I2V clip.
Try 40–48 frames first.
```
Goal:
```plaintext
Does the brightness hump still appear?
```
If the brightness hump mostly disappears, then same-frame FLF was probably the trigger.
### Test 2 — FLF, but last frame slightly different
Instead of:
```plaintext
first = A
last = A
```
try:
```plaintext
first = A
last = A'
```
Where `A'` is almost the same image, but with a tiny real change:
```plaintext
slightly different expression
slightly different head angle
slightly different hand position
slightly different eye direction
slightly different camera crop
```
Goal:
```plaintext
Give the model a real A→A' path,
instead of forcing it to invent an A→A loop path.
```
### Test 3 — shorter FLF
Try the same setup at:
```plaintext
32 frames
40 frames
48 frames
```
instead of:
```plaintext
80 frames
```
Goal:
```plaintext
Does the middle brightness hump shrink when the model has less time to invent an excursion?
```
### Test 4 — loop in editing, not generation
Generate a normal short I2V clip that looks good.
Then loop it afterward using editing techniques:
```plaintext
cut off bad ending frames
crossfade end to start
reverse a copy and ping-pong it
use interpolation between end/start
```
For interpolation, RIFE is one common frame interpolation family:
[RIFE paper](https://arxiv.org/abs/2011.06294)
This is not necessarily “better AI generation,” but it may be a more stable production trick.
## About FMLF / middle anchors
If first/last alone gives too much freedom to the middle, then a middle anchor is the logical next idea.
There are Wan first-middle-last / multi-keyframe workflows and nodes, for example:
[RunComfy: WanFirstMiddleLastFrameToVideo](https://www.runcomfy.com/comfyui-nodes/ComfyUI-Wan22FMLF/wan-first-middle-last-frame-to-video)
The idea is:
```plaintext
first frame = A
middle frame = controlled middle state
last frame = A or A'
```
This can reduce the model’s freedom in the middle.
But I would treat FMLF as a later experiment, not the first fix, because:
```plaintext
more keyframes = more complexity
more nodes = more installation/debugging
8GB VRAM = test carefully
middle-frame workflows can have their own artifacts
```
There are also practical reports of middle-frame workflows having artifacts such as flash-like problems, so it is not guaranteed to be magic:
[Reddit: Wan 2.2 First Frame Middle Frame Last Frame FMLF middle-frame flash issue](https://www.reddit.com/r/comfyui/comments/1otbw01/wan_22_first_frame_middle_frame_last_frame_fmlm/)
So the order I would use is:
```plaintext
normal I2V short clip first
then slightly different FLF endpoint
then FMLF/middle anchor only if needed
```
## If the goal is a loop
If the goal is a clean loop, I would not force a perfect AI-generated loop first.
I would first generate a good short clip.
Then make it loop in editing.
Possible approaches:
| Loop method | When useful | Notes |
| --- | --- | --- |
| **Cut before the bad ending** | The clip looks good until the final frames | simplest |
| **Crossfade end→start** | Slight mismatch | easy in any editor |
| **Ping-pong / reverse** | Motion can naturally reverse | can look artificial, but stable |
| **Frame interpolation** | Need smoother transition | RIFE/other interpolation tools |
| **Slightly different FLF endpoint** | You still want FLF | avoid identical A→A |
| **FMLF / middle anchor** | Middle needs control | later experiment |
For 8GB VRAM, editing tricks are not a compromise. They are often the practical route.
## My suggested order for your setup
Given your constraints, I would try:
```plaintext
1. Stop using identical first/last frame for this test.
2. Try short normal I2V at 40–48 frames.
3. If you need FLF, make the last frame slightly different.
4. If you need a loop, create a good non-loop clip first, then loop in editing.
5. If the middle still needs control, try FMLF / middle anchor later.
6. If color still bumps in the middle, correct it after generation.
```
I would avoid doing this first:
```plaintext
80-frame identical first/last FLF
```
because your own test suggests that it creates:
```plaintext
reference → brightness/color excursion → reference
```
which is exactly the pattern you are trying to avoid.
## Short version
I would now think of it like this:
```plaintext
Your previous setup:
identical first frame + identical last frame
= asks FLF to generate an A→A path
The problem:
the model fills the middle with an unwanted exposure/color path
The fix:
do not ask FLF for A→A unless you really need that.
use short normal I2V for subtle motion,
or use A→A' with a slightly changed last frame,
or make the loop later in editing.
```
So the practical rule is:
```plaintext
FLF for transitions.
Normal I2V for living-still motion.
Editing/interpolation for loops.
FMLF only if the middle needs extra control.
```
---
**Author:**  [@kdalts3759](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fkdalts3759)%5C
**Post date:** [June 23, 2026, 7:00am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-driver-update-reactor-node%2F176221%2F16 "2026-06-23T07:00:36Z")
Ok… great diag… thanks
The F2F is def the issue.. ran without a last clip and the lighting bump (tango’d as I call it) disappeared… so that is clearly what is going wrong and would explain why it felt random because my entire video is a mix of F2F and I2V clips. I though I was being clever with F2F to tighten the facial consistency effectively stopping wan from drifting too far from the reference image.
This has resulted in very short 1 liner prompt like ’ char1 looks at char2’ given that the end frame will always contain all the detail ie: no need for a prompt to keep describing the background, camera or lighting given that the only possible outcome is the end frame if that makes sense. So the ‘filler’ now makes sense.. I give a 1 line action prompt, wan makes up the rest then around halfway through the clip it starts to ‘undo’ any lighting changes (tango) to get back to the 1st image (now the last image too)
Sorry, needed to type this out so I could validate this in my own head
So now I’m back to facial consistency.. and the best route to solve this..
Editing I2I frames works best for actions and removal of unwanted jewelry, painted nails etc… but not for facial consistency. Reactor only works where there is no interaction between the chars as it is appears NSFW sensitive even though there is nothing ‘adult’ happening.
but I’m making progress so thanks for the diag.. given up on the speech for now
I’m beginning to wonder if I should stray outside my comfort zone of my current w/f because I understand it… maybe I should consider looking at something that already has the sound nodes…
---
**Author:**  [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C
**Post date:** [June 23, 2026, 8:14am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-driver-update-reactor-node%2F176221%2F17 "2026-06-23T08:14:01Z")
Hmm… then maybe something like this?
* * *
I think this is a good point to separate two very different goals:
1. **finish a minimum end-to-end pipeline**
2. **make the pipeline good**
Those are not the same task.
From your latest test, if the lighting bump disappears when you remove the F2F / last-frame part, I would treat that as a useful diagnosis. F2F was probably acting more like an endpoint-transition constraint, not like a face/identity lock.
So I would not try to solve face consistency, lighting, audio, lip-sync, and final export all in one workflow right now.
I would first make one very simple complete pipeline.
| Route | Do now? | Why |
| --- | --- | --- |
| Short normal I2V/T2V clip | yes | you already have this roughly working |
| Simple audio mux | yes | fastest way to complete the pipeline |
| Simple TTS if you have no audio | yes | gives you a test WAV/MP3 |
| Face / hand / jewelry / lighting repair | later | separate video-quality problem |
| Lip-sync | later | separate audio-to-mouth problem |
| V2A / Foley sound effects | later | separate sound-design problem |
| VACE / advanced video repair | later | useful, but workflow-heavy |
| S2V / all-in-one speech-to-video | not now | interesting, but not the next 8GB step |
My short answer would be:
> Yes, moving to a minimum audio/video pipeline now is reasonable.
> Just keep it minimal: short video, simple audio, mux, export.
> Then come back to face consistency, lip-sync, SFX, and visual repair as separate branches.
> **1. Minimum pipeline I would test first**
>
> For a first complete test, I would keep it almost boring:
>
> ```plaintext
> short generated video
> → simple audio file
> → mux audio into the video
> → export MP4
>
> ```
>
> If you already have audio:
>
> ```plaintext
> video frames / video clip
> + WAV/MP3 audio
> → Video Combine / ffmpeg / editor
> → MP4 with sound
>
> ```
>
> If you do not have audio yet:
>
> ```plaintext
> text
> → simple TTS WAV/MP3
> → LoadAudio
> → Video Combine
> → MP4
>
> ```
>
> Useful references:
>
> - [LoadAudio - ComfyUI docs](https://docs.comfy.org/built-in-nodes/LoadAudio)
> - [ComfyUI-VideoHelperSuite](https://github.com/kosinkadink/ComfyUI-VideoHelperSuite)
> - [VideoHelperSuite / Video Combine overview](https://www.runcomfy.com/comfyui-nodes/ComfyUI-VideoHelperSuite)
>
> The important thing is that this is mainly **audio muxing**.
>
> That means:
>
> ```plaintext
> existing video + existing audio → video file with audio
>
> ```
>
> It does **not** mean:
>
> ```plaintext
> prompt → perfect speech
> → perfect mouth movement
> → perfect acting
> → perfect edited video
>
> ```
>
> Those are later problems.
>
> For the first test, I would only check:
>
> - does the MP4 play?
> - is audio present?
> - is the duration correct?
> - is the audio roughly in sync?
>
> If yes, the minimum pipeline works.
> **2. If you do not have audio yet: simple TTS**
>
> If you do not already have a voice/audio file, I would add a very simple TTS step first.
>
> I would not assume English only. Even if someone posts in English, the final voice might need another language, accent, or voice style.
>
> Possible TTS routes:
>
> | TTS route | Use case | Notes |
> | --- | --- | --- |
> | External TTS site/app | fastest first test | least ComfyUI dependency risk |
> | EdgeTTS-style node | simple TTS inside/near ComfyUI | good enough for testing |
> | Qwen3-TTS-style model | multilingual / more flexible voice direction | more advanced |
> | F5-TTS / voice cloning | better voice control | more workflow risk |
>
> Examples:
>
> - [ComfyUI-EdgeTTS](https://github.com/1038lab/ComfyUI-EdgeTTS)
> - [Qwen3-TTS](https://github.com/QwenLM/Qwen3-TTS)
> - [Qwen3-TTS 0.6B model card](https://huggingface.co/Qwen/Qwen3-TTS-12Hz-0.6B-Base)
> - [TTS-Audio-Suite](https://github.com/diodiogod/TTS-Audio-Suite)
> - [ComfyUI-F5-TTS](https://github.com/niknah/ComfyUI-F5-TTS)
>
> For the first complete pipeline, I would not start with voice cloning or complex acting control.
>
> I would just make one short WAV/MP3 line and treat it as normal audio.
> **3. What is easy vs hard**
>
> A lot of these tasks sound related, but they are different problems.
>
> | Task | What it does | Difficulty |
> | --- | --- | --- |
> | Audio mux | puts existing audio into video | low |
> | Simple TTS | creates a voice file from text | low-medium |
> | Lip-sync | changes mouth motion to match speech | high |
> | V2A / Foley | generates SFX/ambience from video | high |
> | I2V/T2V | generates the visual clip | medium |
> | V2V / inpaint / repair | fixes or modifies video | high |
> | S2V | uses speech/audio to generate video | very high |
> | One perfect AV workflow | tries to do everything at once | very high |
>
> So I would separate it like this:
>
> ```plaintext
> minimum pipeline
> = video + audio + export
>
> quality pipeline
> = face + hands + lighting + lip-sync + SFX + editing
>
> ```
>
> Those are not the same thing.
>
> This is especially important on 8GB VRAM.
> Low VRAM makes the “one perfect workflow” route much harder, so small repairable stages are easier to debug.
> **4. Advanced audio branches for later**
>
> After the minimum audio path works, there are several later branches.
>
> ### Lip-sync
>
> Lip-sync is for:
>
> ```plaintext
> video + speech audio
> → video with mouth motion adjusted to speech
>
> ```
>
> Examples:
>
> - [LatentSync](https://github.com/bytedance/LatentSync)
> - [ComfyUI-LatentSyncWrapper](https://github.com/ShmuelRonen/ComfyUI-LatentSyncWrapper)
> - [LatentSync paper](https://arxiv.org/abs/2412.09262)
>
> This is not the same as simply adding audio to a video.
>
> ### V2A / Foley
>
> V2A / Foley is for:
>
> ```plaintext
> silent video
> → matching sound effects / ambience
>
> ```
>
> Examples:
>
> - [MMAudio](https://github.com/hkchengrex/MMAudio)
> - [MMAudio paper](https://arxiv.org/abs/2412.15322)
> - [ComfyUI-MMAudio](https://github.com/kijai/ComfyUI-MMAudio)
> - [FoleyCrafter](https://github.com/open-mmlab/foleycrafter)
>
> This can help later with footsteps, movement sounds, background ambience, object sounds, etc.
>
> But I would not start here if the basic MP4-with-audio pipeline is not working yet.
> **5. Advanced video branches for later**
>
> For the video side, there are also advanced repair/control routes.
>
> Examples:
>
> - [Wan2.2 ComfyUI tutorial](https://docs.comfy.org/tutorials/video/wan/wan2_2)
> - [Wan FLF tutorial](https://docs.comfy.org/tutorials/video/wan/wan-flf)
> - [Wan VACE tutorial](https://docs.comfy.org/tutorials/video/wan/vace)
> - [Wan2.1 paper](https://arxiv.org/abs/2503.20314)
> - [VACE paper](https://arxiv.org/abs/2503.07598)
>
> One important detail:
>
> > a small model does not always mean a simple workflow.
>
> For example, VACE has a 1.3B route and a 14B route, so the smaller route may be more possible on low VRAM. But VACE is still an editing/control/inpaint-style workflow. It may be lighter than 14B in model size, but it is not necessarily beginner-simple.
>
> So I would classify VACE 1.3B as:
>
> ```plaintext
> possible later experiment
> not the first minimum pipeline step
>
> ```
>
> For the current stage, I would keep the first complete pipeline much simpler.
> **6. 8GB VRAM reality**
>
> On 8GB VRAM, I would think roughly like this:
>
> | Task | 8GB reality |
> | --- | --- |
> | Short T2V/I2V | realistic |
> | Short I2V + simple audio mux | realistic |
> | Wan 1.3B-class workflows | realistic-ish |
> | Wan2.2 5B with offloading/optimized workflow | possible, slower, more fragile |
> | VACE 1.3B | possible experiment, but workflow-heavy |
> | 14B video workflows | much harder |
> | S2V-14B / all-in-one speech-to-video | not the next local 8GB step |
>
> Wan2.1 1.3B is documented as a consumer-grade model around the 8GB VRAM class:
>
> - [Wan2.1 paper](https://arxiv.org/abs/2503.20314)
> - [Wan2.1 GitHub](https://github.com/Wan-Video/Wan2.1)
>
> Wan2.2-S2V-14B is a very different class of thing:
>
> - [Wan2.2-S2V-14B](https://huggingface.co/Wan-AI/Wan2.2-S2V-14B)
>
> So I would not treat S2V as the next local 8GB step.
>
> It is more like:
>
> ```plaintext
> future / high-resource / cloud-GPU direction
>
> ```
>
> not:
>
> ```plaintext
> beginner next step after I2V
>
> ```
> **7. Even with more VRAM, editing still matters**
>
> Even with more VRAM, I would still not assume that the normal route is one perfect long generation.
>
> A more realistic pattern is:
>
> ```plaintext
> generate short shots
> → repair weak shots
> → add or generate audio
> → edit clips together
> → final export
>
> ```
>
> This is not only an AI limitation. Normal video editing has its own traps too:
>
> - FPS
> - frame count
> - duration
> - MP4 export settings
> - audio sync
> - variable frame rate vs constant frame rate
> - concat/mux issues
>
> So the minimum pipeline is not:
>
> ```plaintext
> make one perfect long video
>
> ```
>
> It is more like:
>
> ```plaintext
> make one short clip with sound successfully
>
> ```
>
> Then build from there.
>
> If ComfyUI export becomes annoying, it is also reasonable to use a normal video editor or ffmpeg for the final mux/export step:
>
> - [FFmpeg documentation](https://ffmpeg.org/ffmpeg.html)
## My suggested next step
I would do the simplest possible complete test:
1. make a very short video clip
2. create or choose one short audio file
3. load the audio
4. combine video + audio
5. export MP4
6. check whether it plays correctly
Only after that, I would return to:
- face consistency
- lighting stability
- hand/accessory fixes
- lip-sync
- V2A/Foley
- VACE or other advanced repair workflows
So my practical answer is:
> Finish the rough pipeline first.
> Keep it minimal: short video, simple audio, mux, export.
> Then treat visual quality, lip-sync, sound effects, and final editing as separate later branches.
---
**Author:**  [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C
**Post date:** [June 23, 2026, 8:56pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fnvidia-driver-update-reactor-node%2F176221%2F18 "2026-06-23T20:56:26Z")
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:
```plaintext
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:
```plaintext
keep the same face and lighting for the whole clip
```
It may be closer to:
```plaintext
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](https://docs.comfy.org/tutorials/video/wan/wan-flf)
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](https://docs.comfy.org/tutorials/video/wan/wan2_2) 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](https://github.com/Wan-Video/Wan2.1) 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:
```plaintext
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**
>
> ## Test 0 — keep the broken/control case
>
> Keep one copy of the old F2F result as a reference.
>
> That tells you what failure you are trying to avoid:
>
> ```plaintext
> F2F on
> → lighting bump appears
>
> ```
>
> Then create the new branch:
>
> ```plaintext
> F2F off
> → same/similar source
> → same rough action
> → short clip
>
> ```
>
> ## Test 1 — normal short I2V / TI2V
>
> Goal:
>
> > Does the lighting bump stay gone?
>
> If yes, that is already useful. It means the new route is healthier than the old F2F route.
>
> ## Test 2 — clip length
>
> Try very short clips first:
>
> | Clip length | Why |
> | --- | --- |
> | 2 seconds | fastest sanity check |
> | 3 seconds | good working range |
> | 5+ seconds | only after the short clip is stable |
>
> Longer clips give the model more time to drift. So for face consistency, short clips are not just faster; they are safer.
>
> ## Test 3 — prompt preservation
>
> Run the same seed twice:
>
> | Run | Prompt |
> | --- | --- |
> | A | short action prompt only |
> | B | action + face/lighting/background preservation prompt |
>
> Judge in this order:
>
> 1. same face
> 2. same lighting
> 3. same background
> 4. no morphing
> 5. natural motion
> 6. prompt obedience
>
> Prompt obedience should not be first. For this case, a clip that obeys the action perfectly but changes the face is still a failed clip.
>
> ## Test 4 — seed search
>
> Once the settings look acceptable, run several seeds:
>
> ```plaintext
> same image
> same prompt
> same settings
> 8–16 seeds if time allows
> short preview first
>
> ```
>
> Choose by face stability first.
>
> For this project:
>
> > A seed that preserves the face and obeys 70% of the prompt is better than a seed that obeys 100% but changes the face.
* * *
## 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:
```plaintext
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:
```plaintext
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](https://github.com/Gourieff/ComfyUI-ReActor) 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:
```plaintext
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**
>
> ## VACE
>
> [VACE](https://docs.comfy.org/tutorials/video/wan/vace) is relevant because it supports video editing/control-style workflows: text, image, video, masks, control signals, local replacement, motion transfer, etc.
>
> So yes, it is conceptually close to video repair.
>
> But I would not make it the next step before the simple video route is stable.
>
> Why?
>
> Because VACE adds more things to debug:
>
> - model choice
> - masks
> - video inputs
> - control inputs
> - node bypasses
> - edited regions
> - temporal consistency
> - more VRAM pressure
> - more workflow complexity
>
> So I would classify it as:
>
> ```plaintext
> possible later experiment
> not first recovery path
>
> ```
>
> ## Fun Control
>
> Wan Fun Control / control-style workflows may help with motion, pose, depth, or structure.
>
> But I would not treat them as a face-consistency tool first.
>
> They are more like:
>
> ```plaintext
> control body / pose / motion / structure
>
> ```
>
> not:
>
> ```plaintext
> guarantee same face in every frame
>
> ```
>
> So again: later.
>
> ## Stand-In
>
> [Stand-In](https://github.com/WeChatCV/Stand-In) is interesting because it is specifically about identity-preserving video generation.
>
> So the direction is relevant.
>
> But I would still not make it the next step for your current situation.
>
> Reasons:
>
> - it is more research/workflow-like than a simple recovery step
> - it brings another stack of dependencies
> - its README notes that some ComfyUI integrations differ from the official version
> - some routes depend on heavier Wan bases
> - it is a better “future identity branch” than an immediate fix
>
> So I would put it in the “keep an eye on this” category, not the “switch today” category.
>
> ## Character LoRA / identity training
>
> This may become useful if you want to make the same character again and again.
>
> But as a next step, it is too much:
>
> - dataset preparation
> - captions
> - training settings
> - overfitting risk
> - model/version compatibility
> - more storage
> - more VRAM/time
> - harder debugging
>
> So I would not use training as the immediate fix for this specific problem.
>
> ## 14B / GGUF / heavy routes
>
> Quantized 14B routes can be interesting, but I would not make them the first recovery route on 8GB.
>
> They may run, but running is not the same as being practical:
>
> - slower iteration
> - more configuration sensitivity
> - more memory edge cases
> - harder troubleshooting
> - longer feedback loop
>
> For learning what is causing face drift, short 5B or 1.3B tests are usually more useful.
* * *
## 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:
```plaintext
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.