TOPIC:

Update: this has been solved.

Turned out that FCPX couldn't handle retiming a large number of clips that had been grouped into a compound clip. But was able to perform it without errors if the clips were retimed individually.

In short, when I export a time lapse I get flickering/flashing every few seconds because it has rendered certain frames out of order or in the wrong place.
Using a 2021 Macbook Pro (M1 Max), running MacOS 13.2.1 and FCPX 10.6.5, I'm taking a long and heavily edited Multicam clip (1080p 30fps), making it a compound clip, then retiming it to around 20x and exporting it to MPEG-4 in H264 or ProRes (happens with both).
I haven't found any other threads with the same issue. There's thread from last year - Jittery Playback and Export / Frames Out of Order - but my issue only happens when I'm retiming compounded multicam clips.
I can get around the problem by first exporting the full Multicam clip, then importing it back into FCPX and then applying the retiming. But we're talking about 2-3 hour videos that can be huge and time consuming to export. It really complicates my workflow.
Has anyone else experienced this? Any fixes? Thanks in advance!

I will look at this tomorrow when I get home from a field assignment. If someone wants to examine it before then, there is a replication scenario in that thread you mentioned for the earlier problem fixed in 10.6.4. Maybe if that was made into a multicam, then a compound clip, then retimed, it might show up.

Thanks, Joe.

Since I posted I did some troubleshooting based on your advice in the other thread, all unsuccessful.

I removed all effects.

I realized that my camera shoots in 29.97 fps, but I was creating 30 fps projects. But after replicating everything in a 29.97 fps project, it still happens.

I added a timecode to the video and after going through frame by frame saw that for a period of about 200 frames it will keep inserting the same repeat frame about every 10-15 frames (inconsistently), and then for the next 200 frames repeat the cycle, but with a different frame.

There's a lot more in that other thread, but a lot of it is beyond my level of expertise and I'm not sure if it applies to my problem. I've already sunk about 6 hours into troubleshooting this.

One amateur guess I had is that my heavily edited Multicam clip (I'd guess it's been cut 1000 times - not sure how to count that) is just too complicated for the retiming to work seamlessly. So I put the unedited Multicam clip in a new project, retimed it to the same amount (in this case, 17x), and the exported file was free of problems! (Note: I also tried making the uncut Multicam clip a Compound clip, and it was also free of errors.) So maybe the retiming feature just gets buggy if the source is too complicated? If true, this doesn't solve my problem, but at least I might be able to point Apple in the right direction.

Thanks again!

Update with fix!

TerryB suggested that I apply the retiming to each clip individually without grouping them into a compound clip first and that eliminated the issue!

So it seems that FCPX struggles to retime a large number of clips at once when they've been batched into a compound clip. But it's fine if you retime them individually. Seems so simple, but I'd just assumed that I had to group such a large number of clips before I could retime them.

Marcus44 wrote:

Update: this has been solved...

Could you please provide details on the resolution. Even if was as simple as updating to 10.6.5, that would help.

Several of us on this forum spent a huge amount of time researching the original problem and I filed the bug in Apple's database. Apple felt it was so important they released 10.6.4 containing *only* the fix for the original "wrong frame order" problem. To my knowledge, it's the only time Apple has ever done that and several of us here contributed to that.

Don't worry -- if it was some other issue, let us know and nobody will laugh at that. We have all done that before.

The bug fixed in 10.6.4 was gravely serious and for some users it "contaminated" downstream archival data. Any report of something remotely like this is very important, even if investigation shows there is some other answer.

Joe, the OP mentioned on the Apple forum that the issue was resolved by applying retiming to all of the separate multicam clips in the timeline, rather than to a compound clip containing them.

So, there seems to be an issue with applying retiming to a compound clip that contains multicam clips, at least in this instance for the OP...

So in theory there is still a problem if retiming is applied to the compound clip?

I made a few unsuccessful attempts to reproduce it by retiming a compound clip containing multicams on an M1 Ultra running 10.6.5. I used some of the effects which were implicated in the previous problem such as Trails and Film Grain, but still did not see it.

Hi Joe, I'm happy to. I actually submitted a detailed post here about the resolution right after TerryB provided the solution on the Apple Forum (3 days ago), but my post never showed up. Either the moderators never approved it or I didn't submit it correctly. Hopefully this shows up.

As DaveM confirmed, the bug occurs if you retime a compound clip that contains a large number of multicam clips. After editing a 2h50m mutlicam clip rather heavily to create a time lapse, I assumed the best practice was to first group it all into a compound clip and then retime it. But TerryB pointed out that I could just select them all and use the retime shortcut to speed them all up individually in one click. This eliminated the bug.

I’m pretty sure there aren’t any other issues with my project that might be causing it. Based on your suggestions in the earlier thread about a similar problem, I did all kinds of troubleshooting. I removed all effects, ruled out a frame rate issue, tried all kinds of different export settings, and further diagnosed the problem using a timecode. The timecode indicated that it was inserting the same repeated frame every 10 to 15 frames, for about 200 frames, then it would do the same with a different repeated frame and repeat the cycle.

I submitted feedback to Apple about this. Let me know if you require more info. Thanks for all that you to help eliminate these issues from the software!

joema wrote:

So in theory there is still a problem if retiming is applied to the compound clip?

Yes.

I made a few unsuccessful attempts to reproduce it by retiming a compound clip containing multicams on an M1 Ultra running 10.6.5. I used some of the effects which were implicated in the previous problem such as Trails and Film Grain, but still did not see it.

I also tried a test on a sequence I've been working on, i.e., a 4 angle MC timeline for an interview with some B-roll added (I was still in rough cut mode). I compounded the entire timeline and then retimed it to 20x and saw no issues, both playing back in FCP and with a ProRes 422 HQ export (2019 Mac Pro, macOS 12.6.3, FCP 10.6.5). All of my source media was UHD or HD ProRes 422 and stills in PNG format (timeline: 1080p29.97, ProRes 422 HQ, Rec. 709).

Dave, thanks very much for doing that. I'm following up with Marcus off line and will post any relevant items here.

At this point I'd suggest don't do any more work on it until I hear back from him.

joema wrote:

Dave, thanks very much for doing that. I'm following up with Marcus off line and will post any relevant items here.

At this point I'd suggest don't do any more work on it until I hear back from him.

Okay (I did my quick test several days ago, probably on the day that Marcus first posted it). Thanks for continuing to look into this, Joe. Much appreciated. Cheers.

Marcus44 wrote:

...the bug occurs if you retime a compound clip that contains a large number of multicam clips. After editing a 2h50m mutlicam clip rather heavily to create a time lapse, I assumed the best practice was to first group it all into a compound clip and then retime it...

I can easily reproduce it. As you said, it merely requires a multicam clip with lots of cuts, made into a compound clip and retimed. The multicam clip need not be 2 hr long, my current test version is only 5 min long and contains 600 cuts and no effects. If that is retimed to say 8x, then the timeline is rendered to cache via CTRL+R or exported to a file, the problem will manifest. It is similar to some manifestations of the previous frame order bug -- a bunch of frames in the wrong order, duplicated frames, etc. It may be a loophole in the previous fix.

There is another related bug which is an extreme slowdown and/or total FCP hang if the clips contain audio. I had to detach all audio from the multicam to even reproduce the frame order bug, else FCP would hang.

A spindump of the hung process shows it's stuck in some audio calls, possibly related to processing and displaying the thumbnail waveforms. Examination with XCode Instruments shows a worker thread is looping through SQLite calls recursively, maybe related to storing metadata related to the waveforms.

Even though the frame order problem seems somewhat esoteric, anything which involves incorrect frame order is gravely serious. The hang issue is also bad.

I'll work on this more tomorrow as a high priority. Areas to examine: Is it isolated to M1 Max and M1 Ultra like the previous problem? Does FCP 10.6.1 (the version before the previous frame order bug happened) show the problem? Does it happen on Monterey? Does it happen on Intel? What is the minimum replication scenario that shows the problem? Is it isolated to certain codecs? (all my tests were 4k/23.98 ProRes 422).

Cool, Joe. Glad you were able to reproduce without many days of effort.

I believe the OP was using a 1080p29.97 or 1080p30 timeline and exported H.264 and ProRes versions with the issue manifested.

If you have a test you'd like me to run on my 2019 Mac Pro, let me know. I'd imagine it would only be needed if it issue shows up on other Intel machines.

Thanks for doing this!

DaveM wrote:

...If you have a test you'd like me to run on my 2019 Mac Pro, let me know. I'd imagine it would only be needed if it issue shows up on other Intel machines...

Dave, below is a simple replication scenario. Incredibly, this bug has existed since at least 10.5.2. It happens on both Intel and Apple Silicon. Machines tested so far:

- M1 Ultra Mac Studio
- M1 Max MacBook Pro
- M2 Pro Mac Mini
- 2019 MacBook Pro 16
- 2017 iMac 27

MacOS versions tested: Monterey 10.6.3, Ventura 13.2.1
FCP versions tested: 10.5.2 (Intel), 10.6.5 (Intel & Apple Silicon)

This replication is very simple: a 3-sec 1080p/29.97 multicam with some blade edits, made into a compound clip and retimed.

The scenario uses about 150 cuts but it will happen with just a few. Note these are simple "through edits", not adjusting the clip head/tail. I will further narrow it down and discuss with Apple today.

Replication scenario: Incorrect frame order if retimed compound clip contains a multicam with edits: www.dropbox.com/sh/trbu87gcg9ppaou/AABj5...smnLhGPyVREq9Ca?dl=0

Investigation of this bug has also exposed an extreme performance problem which happens on larger (but not huge) compound clips containing certain edited clips. I'll examine that next. It apparently involves FCP getting bogged down processing the thumbnail audio waveforms.

Further testing shows it's not isolated to compound clips. ANY retimed compound clip containing a single-angle clip which has certain edits can cause this. The edits can be very simple -- even a few "through edits" (IOW a straight cut with no head/tail adjustment) can cause it.

I'll now re-test all the machines and versions to see if that holds across all of them.

Here is a simpler scenario that only requires a single 10-second clip. If a retimed compound clip contains a single clip having several "through edits", during playback or export the frame order may be wrong. It can appear as a jittery, stuttery playback or momentary flashes of the wrong frames. If the built-in timecode effect is applied to the compound clip, it also seems to show the frame anomalies.

www.dropbox.com/sh/0zuft9w6ntnc9y1/AABox...9joe5SEH3uuzbJa?dl=0

"Through edits" are not required -- that is just the simplest case. Edits involving head/tail trimming also make it happen.

It is not limited to 2x or faster retiming. It can also happen at other retiming rates such as 60% or 80%.

I retested this on the previously-stated versions and machines. It happens on all of them.

Joe, thanks again for taking the time to do the testing.

I tested your updated/latest test scenario and can confirm the glitching also happens on my 2019 Mac Pro, macOS Monterey 12.6.3, FCP 10.6.5.

I then wondered why my initial test didn't show the behavior. I thought maybe it was because I was testing a very fast retiming and didn't notice any glitches/flickering.

So, I simplified things until my test scenario stopped manifesting the issue.

Here's my test info and results:

- I took a 8.5 second clip of 3840 x 2160 ProRes 422 footage at 29.97 fps in a 1080p29.97 timeline and started to blade the clip at several spots (all simple through edits). I put everything into a compound clip and retimed the CC to 80% ("normal" quality). I could easily see the frame issues during playback, with and without rendering.

- I removed edit points inside the CC and the point where I only had one edit point, the frame issue went away.

- So, in my initial test case my cuts weren't close enough to trigger the issue. I then added more edit points.

- With my setup, the issue seems to occur at spots where the edits are less than one second apart (inside the CC). At one second or longer, no issue manifests.

- I speed up the CC to 2x and the issue still only shows at the points with the edit points being closer than one second.

- I didn't do more testing to determine the exact edit point interval where things go awry. It's something less than one second.

So, in my testing, the issue seems to be related to the interval between edit points for the clip inside the CC, and may be related to the clip/project frame rate (and other things).

Hope this helps.

Thanks Dave -- that is very useful. I will check that, then amend the bug I filed to include that info.

DaveM wrote:

...I didn't do more testing to determine the exact edit point interval where things go awry. It's something less than one second...

Dave, after more testing I think there is a relationship between the edit point interval and likelihood of seeing it, but that probability doesn't drop to zero with two seconds between each edit point. However I only tested 2x retiming, now 80%. In my past testing, 60% or 80% retiming was less likely to make it happen than 2x or 4x. Maybe that is what you saw?

I also mostly tested ProRes 422 files on the theory that the M1 Max/Ultra accelerators might be involved. We now know they are not since it happens on all machines but I kept using ProRes files, with a periodic output test to H264, not just ProRes.

I just don't get how this problem has existed so long and nobody apparently has seen it before. It's not that complex.

In my (crude) testing, at 80% retiming, if I space the edit points far enough apart I don't see any issue. At 200% I didn't see the issue, either. Same with rendering or without. To be clear, this is with edit point intervals greater than one second.

---

For a case with a single < 1 sec. edit point interval:

- At 80%, I see two glitches, one at each edit point where the interval is less than one second. When stepping through, frame by frame, at each edit point there is a repeated frame. You can see the two glitches during normal playback.

- At 200%, stepping through I don't see a glitch at either edit point. While holding the right arrow key down, I don't see a glitch. At normal playback speed, I just see one glitch, though it looks more like frame jutter, or out of order frames, and not duplicated frames as in the 80% case.

---

FYI, I did not export and look at the resulting outputs.

Your test case used a timeline at 23.976 fps. I used 29.97 fps.

Of course, there are so many variables that could be involved it's hard to really make any sort of definitive statement (for me, at least).

If you have a specific case(s) you'd like me to verify/test, let me know.

And, yes, it's a bit surprising that no one noticed this behavior before. Personally, I apply retiming to single clips, on a limited basis, so I've never run into this. Usually, I may apply audio effects or color effects to a compound clip in my typical usage scenario...