ML retiming inserts frame from previous file when batch processing (FCP, Compressor)

Question

efortis Author

Level 1

12 points

ML retiming inserts frame from previous file when batch processing (FCP, Compressor)

Problem

Previous file’s 4.1s frame gets injected into next file at 4.1s

When

Given a batch of small clips (001.mov, 002.mov, …), either:

in Final Cut by sharing to a destination of a compressor preset
or by manually starting a batch of individual files in Compressor

Reproducible

When retiming with "Best (Machine Learning)"
Regardless of encoder: ProRes to ProRes or ProRes to H.264.
Regardless of "Enabling additional compressor instances"

Not Reproducible when

Retiming with "Fast (Nearest frame)"
No batch processing (singular file with ML retiming works well)

Steps

Create three .mov files of 10 secs, 4K, 30fps, ProRes 422 HQ

I used three solid colors with a timecode overlay.

vid-001.mov // Red

vid-002.mov // Green

vid-003.mov // Blue

Create a droplet

QuickTime
60fps
ProRes 422
Retiming Quality: Best (ML)

Drop the three .mov files to the droplet

Problem

vid-002.mov (green) has a red frame at 4.1s. That frame came from the previously processed, vid-001.mov, and it corresponds to 4.1s there as well.

---

Final Cut Pro 11.1.1

Compressor 4.10.1

M4 Pro

macOS 15.5

MacBook Pro 14″

Posted on Jul 10, 2025 6:50 PM

Reply

Answer 1

Top-ranking reply

efortis Author

Level 1

12 points

Jul 13, 2025 11:58 AM in response to joema

Thank you joema. I was able to reproduce it on an M1 Pro (with the same macOS, Compressor, and FCP versions).

---

If it helps, I wrote this little tool for detecting the stray frames and printing their timestamps.

brew tap ericfortis/fcpscene
brew install fcpscene


cd ~/Movies/video_foo
for f in *.mov; do
  cuts=$(fcpscene --quiet --min-scene-seconds 0 --mode list "$f")
  if [[ $cuts ]]; then
    echo "$f" "$cuts"
  fi
done

video_foo_018.mov 0.0166667
video_foo_064.mov 0.866667 2.066667
video_foo_073.mov 0.866667 2.066667

Those `video_foo*` above are 25fps 1080p.

On the other hand, 30fps 4K videos seem to have the issue at 4.10000 and 8.20000 (not always but highly consistent). Can't confirm, but I think the issue is not reproducible in videos under 4seconds long.

---

My current workaround is using this AppleScript below, which schedules one video at a time, and waits for "TranscodeService" not to exist before starting each job.

This way I don’t see the stray frames. Although I had to add a two-seconds delay after "TranscoderService" ends.

https://github.com/ericfortis/final-cut-pro-automation/blob/main/batch-compressor-droplet.applescript

Reply

Answer 2

joema

Level 4

1,077 points

Jul 13, 2025 10:05 AM in response to efortis

OK I can reproduce it on M1 Ultra Mac Studio and M4 Pro Mac Mini. Using your scenario, it's not intermittent but happens every time. By clicking on the timecode display in Quicktime Player controls, you can select frame readout. Each file retimed from 30 fps to 60 fps will have 602 frames. The failure places a frame from file 1 in frame 246 of file 2. It's the same each time.

Due to the serious nature of this problem, I need to do a lot more testing to narrow it down. That will include testing more machines, more FCP and Compressor versions, retiming scenarios besides 30 to 60, etc. Hopefully, by the end of today, I'll file a bug and discuss with Apple. Until the boundaries of this problem are understood, I would discontinue all use of machine learning retiming on batch exports.

Reply

Answer 3

joema

Level 4

1,077 points

Jul 13, 2025 4:34 PM in response to efortis

It happens in these cases:

30 -> 60

23.98 -> 29.97

23.98 -> 59.94

It does not happen in these cases:

23.98 -> 60

59.94 -> 29.97

59.94 -> 23.98

59.94 -> 24.0

29.97 -> 59.94

29.97 -> 60.0

Some cases are worse than others. With 23.98 -> 59.94, there are many "cross-contaminated" frames from vid1 improperly written to vid2.

ML retiming has been in FCP for some time, but was only added to Compressor in 4.10.0, the previous version. While FCP can do batch exports, it cannot do batch exports with ML retiming, which requires Compressor or a droplet. This may explain why it's only now being seen.

The failure happens when ML retiming is used in a multi-item batch. There's a function called FRCFrameSynthesizer (FRC = Frame Rate Change), which apparently fails to clear its cached source-frame data in some cases. In a multi-job batch, if the next job needs a real (non-interpolated) frame at the same presentation time-stamp, one frame from the previous clip may erroneously be used.

I have some more testing to do, so I'll probably file the bug tomorrow.

Reply

Answer 4

joema

Level 4

1,077 points

Jul 15, 2025 8:04 PM in response to efortis

Thus far, these are the failure cases, which are all up-conversions. None of the down-conversions failed.

30 -> 60

23.98 -> 29.97

23.98 -> 59.94

24 -> 50

25 -> 60

25 -> 59.94

50 -> 60

These cases seem OK:

23.98 -> 25

23.98 -> 50

23.98 -> 60

24 -> 25

24 -> 29.97

24 -> 30

24 -> 60

24 -> 59.94

25 -> 24

25 -> 23.98

25 -> 29.97

25 -> 50

29.97 -> 59.94

29.97 -> 60

50 -> 23.98

50 -> 24

50 -> 25

50 -> 59.94

59.94 -> 23.98

59.94 -> 24

59.94 -> 29.97

60 -> 23.98

60 -> 24

60 -> 30

I need to create an automated test framework, because when they fix this, I don't want to run all the verification tests by hand. I'll look at the app you wrote (thanks!). These scenarios will also need regression testing in the future.

Reply

Answer 5

BenB

Level 6

13,142 points

Jul 11, 2025 5:43 AM in response to efortis

First, turn off background rendering in the Settings.

Second, in the Browser, select the Library, then File > Delete Generated Project Files, and delete all render files. Quit, relaunch, try again.

Reply

Answer 6

efortis Author

Level 1

12 points

Jul 11, 2025 8:37 PM in response to BenB

Hey BenB,

Thank you for your answer. I tried that but no luck.

Also, tried without Final Cut, just Compressor:

Manual Batch

Droplet

Watch Folder

Also tried exporting from Final Cut individual files to a watched folder, but the stray frame is present as well.

I wonder if there’s a workaround, currently the only thing that works is manually processing videos one-by-one after the previous one is completed.

Or if there’s a workaround to avoid batch processing in the first place. My goal is to increase the frame rate (with ML retiming) without having a transition at the scene changes, which is why I'm splitting into scene files before retiming.

Thanks

Reply

Answer 7

joema

Level 4

1,077 points

Jul 12, 2025 11:52 AM in response to efortis

Excellent job on the replication scenario! I tried it on my M1 Ultra, and so far, I don't see it. However, You are on M4 Pro. The M4 series has upgraded media engines, so for anything implying an encode or encode acceleration issue, it's important to test on the same series. Also the NLE engine is very different on the M4 vs the M1 series. I'll test that tomorrow. My wife has an M4 Pro Mac Mini I can use.

I haven't heard of this before, but I do not doubt the possibility of a problem matching your description. I've worked on several vaguely similar issues over the years.

Reply

Answer 8

joema

Level 4

1,077 points

Jul 15, 2025 8:14 AM in response to efortis

It's worse than I thought and is requiring a lot more testing. E.g, 25 -> 60 produced these results:

vid2 frame 492 shows vid1 frame 205

vid2 frame 513 shows vid1 frame 213

vid2 frame 520 shows vid1 frame 217

vid2 frame 552 shows vid1 frame 230

vid2 frame 573 shows vid1 frame 238

vid2 frame 590 shows vid1 frame 246

vid2 frame 599 shows vid1 frame 250

vid2 frame 609 shows vid1 frame 253

vid2 frame 612 shows vid1 frame 255

vid2 frame 626 shows vid1 frame 261

vid2 frame 645 shows vid1 frame 269

vid3 frame 492 shows vid2 frame 205

vid3 frame 513 shows vid2 frame 213

vid3 frame 518 shows vid2 frame 216

vid3 frame 520 shows vid2 frame 217

vid3 frame 525 shows vid2 frame 219

vid3 frame 552 shows vid2 frame 230

vid3 frame 573 shows vid2 frame 238

vid3 frame 590 shows vid2 frame 246

vid3 frame 599 shows vid2 frame 250

vid3 frame 609 shows vid2 frame 253

vid3 frame 612 shows vid2 frame 255

vid3 frame 626 shows vid2 frame 261

vid3 frame 645 shows vid2 frame 245

Reply

Answer 9

joema

Level 4

1,077 points

Jul 18, 2025 12:44 PM in response to efortis

Still working on this, have automated batch detection running that gives failing frame numbers and average vs actual RGB values for each file in a batch. The scenario also fails on Long GOP, so I only need to provide 720p HEVC, which is a lot smaller.

I'm now integrating command-line batch operation of Compressor, so that they can repetitively re-run all transcoding permutations with automated checks to ensure it's fixed and the working transcode paths don't get accidentally broken. I will probably finish it tonight or tomorrow and file the bug then.

BTW various ML rate conversions to 120 fps also fail with the same "frame cross-contamination" behavior.

23.98 -> 120

24 -> 120

25 -> 120

50 -> 120

59.94 -> 120

60 -> 120

Reply

Answer 10

efortis Author

Level 1

12 points

Jul 11, 2025 10:33 PM in response to BenB

I have old pre-rendered videos. When I retime them with ML, a few frames before and after scene changes get an undesired glitchy transition. That’s regardless of being bladed at the scene changes (normal clips, or compound clips).

I avoid those glitches by retiming each scene in its own file. But now I have another kind of glitch, in which some frames of the previously processed video get injected into the next one.

---

Here's a zip, with three 10s 4K 30fps solid color videos.

https://drive.google.com/file/d/15WX6wkLZF0Z9tourCyIabQl_7D4YlFeP/view?usp=sharing

In Compressor, the present I'm using only has:

quicktime movie
frame rate: 60fps
Remiting Quality: Best (Machine Learning)

When Batch processing those three videos, the second video (green) has a red frame at 4.1s. The third video (blue) is fine.

Reply

Answer 11

joema

Level 4

1,077 points

Jul 19, 2025 6:23 PM in response to efortis

The automated transcoding framework and the automated file testing framework are running OK in manual tests. However, wrapping them into a complete shell script uncovered some problems I'm still debugging. I have to fix this because the statistical nature of this problem requires a massive amount of repetitive testing -- far more than a person could do by hand.

That may explain why this problem evaded detection and shipped. However IMO this test and automated check (when completed) should probably become part of their normal release testing. It will probably catch other types of problems detectable on a frame level in monocolor test files. E.g, black frame, white frame, damaged frame, etc. The same methods that efortis devised can be scaled up and automated to check for these cases.

Reply

Answer 12

joema

Level 4

1,077 points

Jul 25, 2025 12:00 PM in response to efortis

Update: further testing shows the problem is not restricted to "same frame rate" input batches. It can happen with different symptoms on mixed-frame-rate input batches. E.g, a Compressor batch consisting of these three jobs...

23.98 -> 60

25 -> 60

50 -> 60

...Will exhibit different failure modes than input batches with homogeneous frame rates. This, in turn, causes combinatorial explosion of the testing space. I therefore intend to just add a few more mixed frame rate input cases I determine by hand, then finish the automation and file the bug.

I'm working on multiple cases, in addition to my own "real" work, so I'm doing the best I can. But this bug is very important, and my goal is file it within the next 48 hrs.

Reply