Jittery Playback and Export / Frames Out of Order

After a recent iMac boot drive failure we are just about to pull the trigger on a Mac Studio with M1 Max but want to clarify the latest findings first.

joema, does your most recent test imply that any rate conformed footage exported to any codec, like H.264 and not just ProRes, runs the risk of frame jitter?

I get plenty of jitters without changing the timing or reconforming anything, though it has happened when connected to a clip that was time-stretched (though that particular clip wasn't ProRes). The only prerequisite for the jitters is being ProRes. I always use ProRes 422 HQ, specifically.

TerryB wrote:

...just about to pull the trigger on a Mac Studio with M1 Max but want to clarify the latest findings first...joema, does your most recent test imply that any rate conformed footage exported to any codec, like H.264 and not just ProRes, runs the risk of frame jitter?

I understand your concern -- my team has several M1 Ultra and Max machines. In general they are really great. I think Apple understands this is a serious CPU-specific issue in FCP and/or MacOS and will fix it ASAP, but I don't know when that will be. 

Despite the massive amount of testing Redifer, I and others have done, the exact contours of the problem are not fully defined. That is partially due to prioritizing a portable, reliable replication scenario and getting it to Apple. Part of it is the intermittent, elusive nature of the bug. Just nailing down any behavioral facet takes a tremendous amount of repetitive testing. The developers at Neat Video sent their scenario to Apple about two weeks ago, and I sent them mine yesterday. I will be discussing it with Apple tomorrow morning.

Today I did more testing, found it did not require a retimed clip, only rate conforming plus use of one more certain effects. 

Just now, before answering you, I did some additional tests to see if I could reproduce it with H264 source files. One out of several tries I did. That was 4 x 1080p/59.94 stacked 50% scaled H264 clips in a 1080p/23.98 project, no retiming, built-in FCP "Trails" effect on each clip. I need to follow up with more testing tomorrow.

Like Redifer, I was under the impression it only happened with ProRes source files. But due to the urgency of getting Apple a reliable canned replication scenario I did not extensively test H264. I obviously need to.

OTOH it's important not to blow it out of proportion. I have delivered several small projects since I got the M1 Ultra in mid-April (using FCP 10.6.2) and I never saw this problem (enough to recognize it) until recently. I don't think anyone on my team using those machines has seen it yet, but maybe they have and didn't recognize it.

It appears that running FCP 10.6.1 is a workaround, maybe Redifer could comment on how reliable that is.

Thanks as always for your thoughtful and informative post joema. I'm subscribed and probably like many others here, anxiously await any developments.

Hi everyone, just found this thread. I had the same problem exporting to prores LT. Short project, just over 30 minutes and starting from 28 minutes some frames are out of order in the export. source clips (prores proxy) are fine and playback in timeline is fine. This was on a MacBook Pro 16 inch max, fcpx 10.6.3, OS 12.4.
No effects on the clips affected, no retiming. Temporarily solved by using my older intel MacBook Pro 15 inch late 2017, also on fcpx 10.6.3, OS 12.4. Just exported the project and watched it, no problems.
Contacted Apple support, but after finding this thread I don't think reinstalling FCPX will solve this. (did trash preferences, no change, second export also had artefacts at the end, but not on the same place or clip)
Thanks everyone for testing, 

Redifer wrote:

...The only prerequisite for the jitters is being ProRes...

This is following up on my post from yesterday saying I reproduced it using H264 source files.

I've done more testing and after 20 attempts I only saw the jitter problem one time. By contrast with ProRes 422 source files it is easy to make happen on retimed or rate conformed clips if using certain FCP built-in effects such as "Trails".

Testing with Neat Video (which readily exposes the bug) shows it's much more likely to happen with a ProRes source clip vs H264. As you said, using ProRes source files is either a prerequisite or close to it. OTOH I have seen it happen with H264 source clips, just not nearly as often. So using H264 source doesn't mean you are guaranteed of never seeing it.

In my testing, the export codec seems less important. If the source is ProRes and the conditions are met, whether the export is ProRes, H264 or HEVC the error can be in the output file. However whether a visible jitter error in a cached timeline is preserved in an exported file tends to fluctuate.

Has anyone noticed jitter in exports using FX6 footage as source? We typically just edit with the XAVC straight from the FX6s.

TerryB wrote:

Has anyone noticed jitter in exports using FX6 footage as source? We typically just edit with the XAVC straight from the FX6s.

I just tested some FX6 UHD 4k/23.98 footage using the same scenario that reliably causes it with ProRes files, and I did not see it. However I only did about 5 tests, not 20.

Thank you very much joema! That makes me feel a little more comfortable purchasing a Mac Studio M1 Max.

This can also be triggered by CoreMelt Lock & Load stabilizer, version 4.0.2. However I could not reproduce it using Digital Anarchy's Flicker Free plugin. In these tests I used four layers and a 1080p 29.97 ProRes 422 clip, retimed to 25% speed. That is just to make it more frequent but I think in many of these cases it will happen with a single layer (single stream input) but it takes too long to test that.

Edit/Add: It also happens with the FCP built-in Keyer.

Redifer wrote:

I get plenty of jitters without changing the timing or reconforming anything, though it has happened when connected to a clip that was time-stretched..

I just noticed FCP 10.6.4 was just released. There is a single listed fix: "Fixes an issue where video frames may be out of order during playback or export". I suggest anyone in this thread who encountered the problem get 10.6.4 and test that. 

Oh snap! Absolutely!

Very curious to hear about your findings Redifer.

Me too.

It appears that the issue goes (or went, hopefully) deeper than just FCP (or similar code/calls are used in all of the applications), as the new updates for Compressor, Motion, and iMovie also mention the fix.

For anyone not seeing the updates yet, open the App Store, select Updates, then reload the page (command-R) and the updates should appear.

The updates never appear for me, even with Command + R. I have to go to each product's page by searching for it and then the button will change from DOWNLOAD to UPDATE. I didn't know Compressor and Motion were updated as well. Will definitely update them now.

I've never been this excited for a bug fix. Can't wait to dig in for the next few days.

Redifer, I've experienced the same behavior before (with the App Store). I found that if I clicked on a different category or two, then select Updates again, then refresh (command-R), things show up. No guarantees...

Eagerly waiting for your report(s). Hope things are fixed...

And, big kudos again to joema for all the leg work in replicating the issue, setting up test cases, and reporting it to Apple!

DaveM wrote:

...And, big kudos again to joema for all the leg work in replicating the issue, setting up test cases, and reporting it to Apple!

This was a team effort; several of us did a lot of work on this. It is quite possible that Redifer posting it here then everyone pitching in and helping with testing has resulted in the rapid turnaround on this bug. Apple apparently did the 10.6.4 release just for this one bug. 

I've now tested the public 10.6.4 release on M1 Ultra and M1 Max and the fix seems solid. I also did some rudimentary performance tests and I don't see any slowdowns in encode/decode performance. That was a concern since the symptoms implied a possible race condition or an unprotected critical section, and when those are in a "hot" code path, the fix can cost some performance. But it seems OK in this case.

I'm experiencing the same issue... bad news are that I deleted original footage of some clips which suffer the glitch.
lots of lost footage in ma case. Crying at nights...