TOPIC:

I hope Apple fixes this issue soon or I might have to jump ship to Resolve if I want reliable exports. I had a program that was over an hour long. It's absolutely nerve-racking to export. Every area of the video must be combed through to ensure no jittery issues. I had to export 3 times before I got one that was good all the way through. I hope Apple still cares about us lowly users.

Redifer wrote:

I hope Apple fixes this issue soon or I might have to jump ship to Resolve if I want reliable exports. I had a program that was over an hour long. It's absolutely nerve-racking to export. Every area of the video must be combed through to ensure no jittery issues. I had to export 3 times before I got one that was good all the way through. I hope Apple still cares about us lowly users.

I am still working on this, however there is a superficially similar separate bug with FCP built-in video noise reduction. Since the main bug happens frequently with Neat Video, I switched to the built-in NR and hit the other problem. That also is very serious. I will have that filed with Apple today then I'll give my full attention to the main "Jitter / out of order" bug.

You have well described the impact. We can't afford to single-step through every frame for every export to check those. For any material submitted to major media companies, it will likely fail their QC validation. They have sophisticated software to check for anomalous duplicated/dropped frames, etc.

Frustrating as these issues are, I use Resolve daily and it has its own problems.

This bug is potentially gonna cost me a great deal of money. Is there a way to transcode clips to non-ProRes once they're already imported, or do I have to start from scratch?

This is a superficially similar but separate bug I encountered: fcp.co/forum/4-final-cut-pro-x-fcpx/3704...onformed-clip#121260

At first I thought it was the same thing or a different manifestation as the OP scenario, but it now appears to be totally different. I've filed this new one with Apple, and will resume working on the OP problem: fcp.co/forum/4-final-cut-pro-x-fcpx/3704...onformed-clip#121260

Redifer wrote:

This bug is potentially gonna cost me a great deal of money. Is there a way to transcode clips to non-ProRes once they're already imported, or do I have to start from scratch?

You can transcode the clips using Compressor to H264, and if the filenames are the same and it meets all the relink criteria I think it would relink. However I'm not sure that would totally prevent the problem.

I've made some progress today, the Jitter problem appears reproducible if using the FCP built-in "Trails" effect. However there is apparently yet another issue -- I've had several hangs if using the Trails effect and Hawaiki Keyer 4.6. I took several spindumps so I will compare to other spindumps users have sent me.

The developers at Neat Video are actively working with FCP engineering on this, so the problem is getting a lot of attention. It's not the fault of Neat Video but the bug frequently affects their plugin.

The current situation is you can't safely use the FCP built-in video noise reduction because of the bug I filed today and you can't safely use Neat Video because of the Jitter/frame order bug. But as you experienced and we are now able to reproduce, the jitter/frame order bug happens without those plugins.

The most serious aspect is it has many manifestations from almost unnoticeable to severe. If you submit videos with a a few dropped frames to a big media house their QC utilities will probably catch it but in other cases it could easily evade detection and compromise archival quality.

I tried transcoding the original clips to HEVC and they would not relink. I think they look at the codec and approximate file size when relinking. I did try to transcode to proxy and that worked in letting me export without jitteriness, but it took a severe hit in video quality. ProRes Proxy looked better than H.264 proxy, but not by much.

Interestingly, I have yet to see the issue using Hawaikiki Keyer on ProRes 422 HQ footage.

I'm sure all of these problems are linked to a common cause somewhere deep within Final Cut Pro.

Redifer wrote:

...I'm sure all of these problems are linked to a common cause somewhere deep within Final Cut Pro...

I can now reproduce it intermittently but with sufficient frequency to file a bug. I talked to a Sr. Pro Apps support advisor today. He remotely connected to my machine and observed the problem. It will take me a day or so for some final tests and getting the bug written up. I will upload a complete scenario to Apple to reproduce it, including media files.

In the meantime, a possible workaround might be dropping back to 10.6.1. According to Neat Video developers, this problem began with 10.6.2. Can you try 10.6.1? I will also test that, plus I need to test some Intel machines that are running Monterey 12.4 and 10.6.3. It's important to know whether this is unique to Apple Silicon or maybe unique to M1 Max/Ultra.

Can I open my 10.6.3 Libraries in 10.6.1? If not, I cannot go back. I have several shows already edited in 10.6.3. If they will work, where can I get 10.6.1?

Redifer wrote:

Can I open my 10.6.3 Libraries in 10.6.1? If not, I cannot go back. I have several shows already edited in 10.6.3. If they will work, where can I get 10.6.1?

I just verified it definitely began with 10.6.2. You're right there was a library update from 10.6.1 to 10.6.2, so you can't just run 10.6.1 against a version 10.6.3 library. However it should be possible to export a project or library XML from 10.6.3, then run 10.6.1 and import that XML to a new 10.6.1 library.

Check your friend requests on Facebook to discuss this further.

I could try that. Where do I get 10.6.1? I hope I don't have to pirate it.

Redifer wrote:

I could try that. Where do I get 10.6.1? I hope I don't have to pirate it.

I'd offer to make a copy available to you, but I don't have the fastest Internet connection. joema can probably do it more easily.

A thing I started to do a few years ago (Tom Wolsky or the Ripple Training guys might have suggested it) is to zip your current copy of FCP (ideally after a new version installs). This way, you have saved copies of FCP going back as far as you'd like. I have FCP 10.4.6 onwards with each version (I've installed) zipped. Of course, I doubt 10.4.6 will run on Monterey, but it could be useful in the future...

It's too bad Apple doesn't make rollback versions available for the times when they do create a critical bug, like now.

But hey, Apple is as Apple does.

Redifer wrote:

It's too bad Apple doesn't make rollback versions available for the times when they do create a critical bug, like now...

I have been bitten by situations like this often enough that I always keep several prior FCP versions. But I agree Apple should make them available, if nothing else through a support call.

Redifer, do you have an Intel Mac to try and reproduce this? I ask because I cannot reproduce it so far on Intel, and it seems you have the most reliable problem replication.

I do have an Intel Mac, but it's forever restricted to Mojave and FCP 10.4.x.

I've got a 2019 Intel iMac that I could test with later tonight, if that helps. All software is current. I'd need to know what parameters/media to try, unless you've got a Library and some test media that I could download... don't have Neat, btw.

dmetz wrote:

I've got a 2019 Intel iMac that I could test with later tonight, if that helps. All software is current. I'd need to know what parameters/media to try, unless you've got a Library and some test media that I could download... don't have Neat, btw.

Thank you very much for the offer but after some thought, I think it's not currently warranted on x86. I have tested extensively on an 8-core i9 and I cannot make it happen. I think Neat Video only has a single report from a 2019 Xeon Mac Pro claiming they saw this, not sure how reliable that is. It is definitely NOT caused by the Neat Video *plugin* since it happens without that. But their developers are working hard on it because it negatively impacts their customers since it happens rapidly with that plugin.

I now have a very reliable replication scenario (on M1 Max/Ultra) that does not involve any non-Apple software. If we could have someone run it on a regular M1 or M1 Pro that might help. If anyone can do that, I can send them a small file package and instructions on running it. It's fairly simple but might take 10 min to set up and run.

I'm sitting in front of an M1 Mini right now, with a MBP Max nearby.

And a little time on my hands. Got a link / instructions?

dmetz wrote:

I'm sitting in front of an M1 Mini right now, with a MBP Max nearby.

And a little time on my hands. Got a link / instructions?

Stand by, it will take me a few minutes.

dmetz wrote:

I'm sitting in front of an M1 Mini right now, with a MBP Max nearby.

And a little time on my hands. Got a link / instructions?

OK here it is. It may be a little rough; I was going to work on it a few more hrs, but it should be straightforward. It reliably reproduces the problem on M1 Ultra and M1 Max at least 50% of the time.

www.dropbox.com/s/tpkp977lc4qf4km/FCP_Fr...er_Repro_V1.zip?dl=0

Downloaded. I'll test on the 1TB internal SSD, and again on the Thunderbay8 (SoftRAID).