1st movie clip!
Hmm… I can’t recommend YouTube for anything other than “learning cases where a model answer exists” or entertainment… What you do in ComfyUI is essentially no different from programming—except you don’t write code. It’s a process of selecting components and assembling a workflow. That means “looking for a model answer is a waste of time unless it’s a very basic sample.” There’s probably no model answer out there that covers every possible combination. At least, it’s unlikely to be available for free…
So, let’s look for “building blocks” in a conceptual sense from the very beginning. When improving your ComfyUI workflow, you’ll often have no choice but to use search engines or generative AI, borrow good parts from someone else’s workflow, or think for yourself and proceed through trial and error… That’s why I don’t think dealing with issues that arise in ComfyUI is easy for beginners…”
Best path for this case: frame-safe repair, not direct video-in/video-out
Short answer
For this specific case, I would not keep trying to fix the current direct video workflow by adding random batch nodes.
The safer path is:
Wan output video
-> extract numbered frames
-> run ReActor on image frames
-> save repaired frames
-> keep original frames where ReActor fails
-> rebuild video from a complete frame folder
-> only later add RIFE/interpolation if needed
The main reason: your symptom sounds like a frame-continuity problem , not just an FPS problem.
A jerk around one random point — often near the start, around frame 8 — can mean:
- one frame is actually missing,
- one frame is duplicated,
- one frame is out of order,
- one frame exists but ReActor visually failed on the face,
- the video loader selected a different frame than expected,
- the video export/recombine step changed timing,
- or interpolation/batching created a boundary problem.
So the immediate goal should not be “make the final video nicer.” The immediate goal should be:
Find out exactly what happened to frame_00008.
That is why the best workflow is a numbered-frame workflow.
Why I think this is the best path
There is a very close ReActor case where video face swap works while the subject faces the camera, but starts skipping/cutting frames when the subject turns their head. The practical recommendation there is to split the video into frames/images, do face swap as a batch process, then reconstruct the video from frames: ReActor discussion: frame skipping/cutting on head turns.
There is also a ReActor issue where even one or two frames without a detectable face can break video processing: ReActor issue: frames without detectable face.
That matters because in AI-generated video, “no detectable face” does not necessarily mean the face is absent to a human viewer. It can mean the detector temporarily struggles because the face is:
- too small,
- too blurred,
- too turned away,
- partly hidden,
- too distorted by generation artifacts,
- near the image edge,
- low contrast,
- confused with another face-like object,
- or changing too quickly.
ReActor also has a documented failure mode where it says it cannot detect the target face and skips swapping: ReActor FaceSwapOpt docs: “Cannot detect any Target, skipping swapping…”.
So the safest design is:
If ReActor succeeds:
use the ReActor frame.
If ReActor fails:
keep the original frame.
Never let a failed ReActor frame disappear from the final timeline.
This preserves motion continuity.
A one-frame face flicker is usually less damaging than a missing motion frame.
What is probably happening
Your tests all show a jerk, and the jerk appears somewhat random. That suggests the problem is probably in a shared part of the workflow:
Load Video / Load Frames
-> ReActor
-> Save / Combine
not only in:
24 frames vs 36 frames vs 48 frames
The 24/36/48-frame tests were useful because they asked:
Does the failure only happen when the clip section is too long?
Your result seems to say:
No. The jerk appears in all tests.
So I would stop thinking “maybe I need the right batch node” and start thinking:
Which stage breaks the frame sequence?
Frame sequence means:
input frame_00001 -> output frame_00001
input frame_00002 -> output frame_00002
input frame_00003 -> output frame_00003
...
input frame_00072 -> output frame_00072
If one frame is missing, duplicated, bad, or out of order, the video will jerk.
A “jerk” is not always a missing frame
This distinction is important.
When you watch the output, it may look like a missing frame. But it could be several different technical problems.
| What you see | What may actually be happening |
|---|---|
| Sudden jump forward | A frame was dropped |
| Tiny freeze, then jump | A frame was duplicated |
| Wobble / backward-forward twitch | Frames are out of order |
| Face pops for one instant | ReActor failed visually on that frame |
| Preview looks okay but final output jerks | Loader/output mismatch |
| Only happens after interpolation | RIFE/VFI or batch-boundary issue |
| Already present before ReActor | Source generation issue |
So the key diagnostic question is not:
Why does the video jerk?
The better question is:
What exactly happened to frame_00008?
Why I would not start with MetaBatch
MetaBatch is useful later, but it is not the first tool I would introduce.
A Meta Batch Manager is intended to break large video jobs into smaller sections, often to make long videos more manageable: VHS Batch Manager docs.
But MetaBatch adds another hidden layer. If something goes wrong, you now have to ask:
Was it the loader?
Was it ReActor?
Was it MetaBatch?
Was it Video Combine?
Was it RIFE?
Was it a batch boundary?
Was it the final video encode?
There is also a VideoHelperSuite issue where a user got MetaBatch processing working, but Video Combine produced broken 0-byte videos; the workaround was to save frames and stitch/rebuild afterward: VideoHelperSuite issue: MetaBatch + Video Combine 0-byte output.
So my recommendation is:
Manual image-frame batching first.
MetaBatch later.
Manual batching means:
Run frames 1–24.
Then run frames 25–48.
Then run frames 49–72.
It is less elegant, but much easier to understand and debug.
Why I would not add RIFE yet
RIFE / VFI should be a polish step , not a repair step.
There is a VideoHelperSuite issue where RIFE VFI + VHS MetaBatch causes the output to become shorter because one frame is lost per batch when the last frame of one batch is not passed into the next batch: VideoHelperSuite issue: RIFE + MetaBatch drops one frame per batch.
So if you add RIFE now, you could accidentally stack two problems:
ReActor may fail on a difficult face frame.
RIFE/MetaBatch may also create a boundary-frame problem.
That makes debugging much harder.
The safe order is:
1. Prove the raw source frames are stable.
2. Prove ReActor output frames are complete.
3. Prove the rebuilt video is smooth.
4. Only then add RIFE.
Not:
Load Video -> ReActor -> RIFE -> MetaBatch -> Video Combine
That all-in-one graph is too hard to debug for this problem.
Why I would avoid direct video-in/video-out ReActor for now
The tempting workflow is:
Load Video
-> ReActor
-> Video Combine
It is simple, but it hides the evidence.
If the result jerks, you do not know whether the failure happened in:
Load Video,- ReActor,
Video Combine,- output encoding,
- the video player,
- or an interpolation/batch stage.
VideoHelperSuite’s Load Video settings can directly alter the frame sequence. Public docs describe controls such as frame_load_cap, skip_first_frames, and select_every_nth: VHS Load Video docs.
VideoHelperSuite’s repository also explains that frame_load_cap is the maximum returned frame count, skip_first_frames skips frames, and select_every_nth skips between returned frames: ComfyUI-VideoHelperSuite repository.
There is also a reported preview/output mismatch involving select_every_nth and skip_first_frames: VideoHelperSuite issue: preview/output mismatch with skip/select.
So while debugging, the safest approach is:
Avoid clever video-loader settings.
Avoid direct video-to-video repair.
Use numbered frames instead.
Best workflow for this case
Use three or four small workflows , not one giant graph.
Workflow 1: extract frames
Workflow 2: repair frames
Workflow 3: assemble final frames with fallback
Workflow 4: rebuild video
This is much easier to understand and much safer.
Workflow 1 — Extract video to numbered frames
Purpose
Turn the source video into visible, countable image frames.
You want a folder like:
01_raw_frames/
frame_00001.png
frame_00002.png
frame_00003.png
...
frame_00072.png
For example, if the clip is 6 seconds at 12 FPS:
6 seconds × 12 FPS = 72 frames
So you should expect:
frame_00001.png
...
frame_00072.png
Beginner-safe ComfyUI graph
[VHS Load Video]
|
v
[Save Image]
Suggested settings
force_rate = 0 or 12
frame_load_cap = 0 or 72
skip_first_frames = 0
select_every_nth = 1
Meaning:
| Setting | Plain meaning |
|---|---|
force_rate = 0 or 12 |
Do not unexpectedly retime the clip |
frame_load_cap = 0 or 72 |
Load all frames, or exactly the expected count |
skip_first_frames = 0 |
Do not start later |
select_every_nth = 1 |
Use every frame |
Avoid during debugging:
select_every_nth = 2
select_every_nth = 3
skip_first_frames > 0
random force_rate values
small frame_load_cap values
RIFE
MetaBatch
Those are not “bad” forever, but they are bad while trying to diagnose a missing/jerky frame.
Workflow 1 check
After saving raw frames, inspect around the problem area:
frame_00006.png
frame_00007.png
frame_00008.png
frame_00009.png
frame_00010.png
frame_00011.png
frame_00012.png
Ask:
Does the original clip already jerk here?
If yes
Then ReActor is not the cause. The source generation already contains the motion problem.
Best fix:
- regenerate the shot,
- shorten the shot,
- reduce motion,
- keep the face more visible,
- avoid sudden head turns,
- avoid strong motion blur,
- use a steadier camera prompt,
- or split the moment into two shots.
Face swap can fix identity. It cannot reliably fix broken body/camera motion.
If no
Continue to Workflow 2.
Workflow 2 — Run ReActor on frames, not direct video
Purpose
Use ReActor only to create replacement frames.
Do not let ReActor directly control the final video timeline.
Beginner-safe graph
[Load Reference Face Image]
|
v
[ReActor Face Swap]
^
|
[VHS Load Images / Load Image Sequence]
|
v
[Save Image]
Output folder:
02_reactor_frames/
frame_00001.png
frame_00002.png
frame_00003.png
...
Look for a node such as:
VHS Load Images
VHS Load Images Path
VHS Load Image Sequence
Load Images Path
Load Image Sequence
The exact name can vary depending on the installed nodes.
VideoHelperSuite supports loading image sequences and has controls such as image_load_cap, skip_first_images, and select_every_nth: VideoHelperSuite Load Image Sequence docs in repo, RunComfy VideoHelperSuite guide, VHS Load Images docs.
Suggested settings
image_load_cap = 0
skip_first_images = 0
select_every_nth = 1
Meaning:
| Setting | Plain meaning |
|---|---|
image_load_cap = 0 |
Load all images |
skip_first_images = 0 |
Do not skip starting images |
select_every_nth = 1 |
Use every image |
Do not connect to Video Combine yet.
First save the repaired frames as images.
Workflow 2 check
Compare the raw folder and ReActor folder.
You want:
01_raw_frames/frame_00001.png
02_reactor_frames/frame_00001.png
01_raw_frames/frame_00002.png
02_reactor_frames/frame_00002.png
...
01_raw_frames/frame_00072.png
02_reactor_frames/frame_00072.png
Now inspect the suspected area:
02_reactor_frames/frame_00006.png
02_reactor_frames/frame_00007.png
02_reactor_frames/frame_00008.png
02_reactor_frames/frame_00009.png
02_reactor_frames/frame_00010.png
Ask:
Is frame_00008 missing?
Is frame_00008 duplicated?
Is frame_00008 present but visually wrong?
Is the face smeared or blurred?
Did ReActor swap the wrong face?
Did ReActor skip the swap and leave it unchanged?
If ReActor logs show something like “Cannot detect any Target, skipping swapping…”, that points to a face-detection failure: ReActor FaceSwapOpt error explanation.
Workflow 3 — Assemble final frames with fallback
This is the most important part.
Purpose
Prevent ReActor failures from becoming missing timeline frames.
Create a third folder:
03_final_frames/
First copy all original frames into it:
01_raw_frames/* -> 03_final_frames/
Now 03_final_frames already has every frame.
Then copy only good ReActor frames over the matching originals:
02_reactor_frames/good frames -> 03_final_frames/
So if ReActor produced a good frame_00008.png, use it.
If ReActor failed on frame_00008.png, keep the original raw frame_00008.png.
Why this works
Bad final sequence:
frame_00007
frame_00009
Frame 8 is missing. Motion jumps.
Good final sequence:
frame_00007
frame_00008 original fallback
frame_00009
Motion stays continuous.
The face may briefly be less perfect, but the timeline does not break.
The rule is:
Every final video frame number must exist.
If ReActor fails, use the original frame.
This is the best practical protection against ReActor skipping/failing on difficult face frames.
Workflow 4 — Rebuild the video
Once 03_final_frames is complete, rebuild the video.
Beginner-safe graph
[VHS Load Images / Load Image Sequence]
|
v
[Video Combine]
Suggested settings
Use the original FPS:
frame_rate = 12
if your source clip is 12 FPS.
Do not use output FPS as a repair knob.
Changing Video Combine.frame_rate changes how quickly the existing frames are played. It does not restore a missing upstream frame. The frame folder must already be correct before this step.
Complete workflow overview
[Workflow 1: Extract]
Source video
-> VHS Load Video
-> Save Image
-> 01_raw_frames
[Workflow 2: Repair]
01_raw_frames
-> VHS Load Images / Load Image Sequence
-> ReActor
-> Save Image
-> 02_reactor_frames
[Workflow 3: Fallback assembly]
Copy 01_raw_frames to 03_final_frames.
Copy only good ReActor frames over matching originals.
Leave failed/missing ReActor frames as original frames.
[Workflow 4: Rebuild]
03_final_frames
-> VHS Load Images / Load Image Sequence
-> Video Combine at original FPS
-> final video
This is the best path because it directly protects against the actual problem: one failed frame breaking the timeline.
How to introduce batching safely
There are many “batch” nodes in ComfyUI. For this problem, ignore most of them at first.
You do not need to start with:
MetaBatch
Batch Manager
Image Batch to List
Image List to Batch
Repeat Image Batch
Rebatch Images
Latent batch nodes
Queue batch
At this stage, the only batching you need is:
Load a limited number of image frames.
Run ReActor.
Save those repaired frames.
Then load the next group.
That is manual batching.
Manual batching for a 72-frame clip
If your clip has 72 frames, split it into three chunks:
Batch 1: frames 1–24
Batch 2: frames 25–48
Batch 3: frames 49–72
Use the same Workflow 2 graph each time:
[VHS Load Images / Load Image Sequence]
|
v
[ReActor]
|
v
[Save Image]
Only change the image-loader settings.
Batch 1
image_load_cap = 24
skip_first_images = 0
select_every_nth = 1
Expected:
frames 1–24
Batch 2
image_load_cap = 24
skip_first_images = 24
select_every_nth = 1
Expected:
frames 25–48
Batch 3
image_load_cap = 24
skip_first_images = 48
select_every_nth = 1
Expected:
frames 49–72
VideoHelperSuite’s image sequence docs explicitly support this idea: image_load_cap limits returned images, and incrementing skip_first_images by image_load_cap divides a long sequence into batches: ComfyUI-VideoHelperSuite Load Image Sequence.
Why manual batching is better than advanced batch nodes right now
Manual batching gives clear control:
I know which frames entered ReActor.
I know which frames came out.
I can inspect the output folder.
I can keep originals where ReActor failed.
Advanced batching hides these details.
Right now the problem is not:
How do I automate everything?
The problem is:
How do I stop one bad frame from breaking the timeline?
Manual batching plus fallback solves that.
What to do if ReActor fails on frame 8
Suppose you inspect:
02_reactor_frames/frame_00008.png
and it is missing or visually bad.
Do this:
Use 01_raw_frames/frame_00008.png in 03_final_frames.
Do not drop frame 8.
Do not duplicate frame 7 unless there is no better option.
Use this fallback order:
1. Good ReActor frame
2. Manually repaired frame
3. Original raw frame
4. Duplicate previous/next frame only as last resort
Why original frame is usually better than duplicating:
| Fallback | Result |
|---|---|
| Original frame | Motion stays correct; face may flicker briefly |
| Duplicate previous frame | Motion freezes briefly |
| Dropped frame | Motion jumps |
| Bad ReActor frame | Face pops/smears |
For your symptom, preserving motion continuity is the top priority.
What to do if frame 8 is bad before ReActor
If the raw frames already show the jerk, then the best path is not ReActor repair.
Use one of these:
Regenerate the shot.
Shorten the shot.
Reduce motion.
Cut before the bad motion.
Use a second shot instead of one continuous shot.
This is often the better creative solution.
In film terms, a cut is normal. You do not need to force one continuous shot if the video model or repair pass cannot maintain it.
What to do if ReActor output has all frames but the face pops
This means ReActor did not skip the frame; it produced a visually unstable face result.
Likely causes:
face turned too much
face too small
motion blur
face partly hidden
face detection changed
wrong face index
source/reference image not strong enough
background face-like object confused the detector
Fixes:
Use a clearer reference face.
Use a more frontal reference.
Use a few clean reference angles if your setup supports that.
Make the generated shot easier: face visible, slow movement, no strong blur.
Repair fewer frames.
Leave impossible frames as original.
ReActor’s options/docs also matter when multiple faces or face-like objects appear. It can use face indexes, and target/source face detection can fail or select the wrong face if the frame is ambiguous: ReActor FaceSwapOpt docs.
Beginner-safe rule:
Use one clear target face in the shot while debugging.
Avoid background faces, posters, reflections, and face-like artifacts.
What to do if the rebuilt video jerks but frames look fine
If this is true:
03_final_frames looks smooth.
The final video still jerks.
Then the problem is probably in the rebuild/export stage.
Try:
Load final frames again.
Use original FPS.
Try a different Video Combine format.
Avoid audio for now.
Do not use RIFE yet.
Extract the final video back to frames and compare.
If the final video extracted back to frames differs from 03_final_frames, the combine/export stage changed something.
When to add RIFE
Only add RIFE after this is true:
03_final_frames is complete.
No frame numbers are missing.
The rebuilt video is smooth without RIFE.
Then RIFE can be used for smoothing.
If you later use RIFE with batching, be careful with overlap because public reports show RIFE + MetaBatch can lose a boundary frame per batch: RIFE + MetaBatch drops one frame per batch.
Safe order:
final_frames
-> rebuild stable 12 FPS video
-> optional RIFE
-> final polished video
Not:
ReActor
-> RIFE
-> then try to debug missing frame
When to add MetaBatch
Add MetaBatch only when:
manual batching works
you understand which frames are in each batch
you can rebuild video from saved frames
you need automation for longer clips
Do not use it as the first batching solution.
For now:
manual 24-frame batches
are safer.
Recommended folder structure
Use clear folder names:
movie_test_001/
01_source_video/
source.mp4
02_raw_frames/
frame_00001.png
frame_00002.png
...
03_reactor_frames/
frame_00001.png
frame_00002.png
...
04_final_frames/
frame_00001.png
frame_00002.png
...
05_final_video/
final_12fps.mp4
If using manual batches:
movie_test_001/
03_reactor_batch_001/
frame_00001.png
...
frame_00024.png
03_reactor_batch_002/
frame_00025.png
...
frame_00048.png
03_reactor_batch_003/
frame_00049.png
...
frame_00072.png
Avoid vague names:
test
test2
fixed
fixed_final
new_fixed
Frame debugging needs boring, exact folder names.
Recommended settings
During diagnosis
Use:
force_rate = 0 or source FPS
frame_load_cap = 0 or full expected count
skip_first_frames = 0
select_every_nth = 1
image_load_cap = 0 or intended batch size
skip_first_images = 0, 24, 48, etc.
select_every_nth = 1
Video Combine.frame_rate = source FPS
RIFE = off
MetaBatch = off
Avoid during diagnosis
Avoid:
select_every_nth > 1
random force_rate values
skip_first_frames > 0 unless deliberately extracting a known range
RIFE
MetaBatch
direct ReActor video-in/video-out
changing final FPS to hide the jerk
Best path summary
Best path now
video -> numbered frames -> ReActor image repair -> save frames -> fallback originals -> rebuild video
Best batching now
manual 24-frame image batches
Best fallback
if ReActor fails on a frame, keep the original frame
Best thing to avoid
direct Load Video -> ReActor -> RIFE -> Video Combine
Best thing to inspect
frame_00008 before ReActor
frame_00008 after ReActor
frame_00008 in final_frames
frame_00008 after final video extraction
Final recommendation
Build this:
Workflow A:
VHS Load Video
-> Save Image
Then:
Workflow B:
VHS Load Images / Load Image Sequence
-> ReActor
-> Save Image
Then manually assemble:
Workflow C:
Copy raw frames into final_frames.
Overwrite only with good ReActor frames.
Leave failed ReActor frames as original frames.
Then:
Workflow D:
VHS Load Images / Load Image Sequence
-> Video Combine at 12 FPS
Only after that works, try:
optional RIFE
optional MetaBatch
optional automation
This is the best path because it directly protects against the actual problem: a single failed frame creating a timeline jerk.
Useful references
- ReActor discussion: frame skipping/cutting on head turns
- ReActor issue: one or two frames without detectable face can break video processing
- ReActor FaceSwapOpt docs: target detection failure / “skipping swapping”
- ComfyUI-ReActor repository
- ComfyUI-VideoHelperSuite repository
- VHS Load Video docs
- VHS Load Images docs
- RunComfy VideoHelperSuite guide
- VideoHelperSuite issue: preview/output mismatch with skip/select
- VideoHelperSuite issue: MetaBatch + Video Combine 0-byte output
- VideoHelperSuite issue: RIFE + MetaBatch drops one frame per batch
Discussion in the ATmosphere