FCP 12.3: PNG in project causes export to fail on M4, works on M2

In an effort to track down more information for an open Apple Support ticket, maybe someone else has ran into this.


  • macOS 26.5.2 - freshly installed on an M4 Mac mini with 24GB RAM.
  • Final Cut Pro 12.3 - freshly installed on that M4 Mac


Existing projects that export fine on an M2 Mac fail on the M4 - no error, no pop up, it just starts, then a second or two later it fails.


I spent time with Support trying to figure out what was happening. There appears to be an issue with PNG and other files that affects the M4 but not the M2. Files that export fine on the M2 are not working on the M4.


I have four different PNGs I use, and they all fail.


  • I opened them up in preview, then exported a fresh PNG file. Same problem.
  • I converted them to HEIF, and tried them. Same failure. Again, works fine on the M2.
  • I converted them to TIFF, and tried them. Same failure.


But the more I check the more it looks like some kind of image handling issue with the M4 version of macOS.




M2 - just fine.

M4 - no export.


I have been focusing my testing on PNG files initially, and someone already pointed me to an older topic where someone had a very large PNG that would crash FCP. These are not very big. They are just logos (nadir logos for 360 video).


I can reproduce the failure -- but only on the M4 -- in both normal 1080 videos, and 360 videos now. Earlier today, they worked on normal videos on the M4, and now they do not. It is intermittent.


Has anyone had any issues with PNG files on an M4 Mac with the current macOS and FCP versions?

Mac mini (M4, 2024)

Posted on Jul 8, 2026 3:09 PM

Reply
Question marked as Top-ranking reply

Posted on Jul 12, 2026 5:56 PM

"there are so many alternative/workarounds that it is not worth bothering about"


As I said above, any low-level hardware decode failure must be treated seriously. The fact it wasn't failing on a power of 2 filesize was suspicious. I became so concerned I've spent about 20 hours working on this.


Any failure which seems isolated to a specific CPU is gravely serious. In 2022, there was a very infrequent, elusive frame order bug that only happened on the M1 Ultra and M1 Max and only under very specific conditions. I filed this bug, and FCP development called me to discuss it. Even though a casual observer might think it wasn't serious, they did a special FCP release 10.6.4 that contained only that one fix, and they did that within four weeks, including all testing and localization.


For the bug reported by Allen, further testing shows it's not a simple failure above a 12000-pixel threshold (which is not even that big).


Rather various combinations of X/Y pixel dimensions fail, e.g,


11000 x 11008 works, but

11008 x 11000 fails


The issue seems related to vertical dimension: every tested frame with height divisible by 16 works, even with an unaligned width. By contrast, every large frame with a height not aligned by 16 pixels fails.


The hardware decoder seems to round height to macroblock rows and divides large frames into vertical bands. If a non-16-aligned global height exists, it is somehow causing a submitted subframe to cause hardware status code 55, and the AppleProResHW plug-in converts it to kVTVideoDecoderMalfunctionErr (-12911).


As of right now, a possible workaround is to make the PNG canvas height a multiple of 16 pixels.


I'll continue examining this tomorrow.

40 replies

Jul 8, 2026 4:18 PM in response to Allen Huffman

UPDATE: It looks like it might be DPI related, as the original crash was noticed on an image that was exported at 300dpi. I have been using the wrong version for years, but the M2 never had an issue with it.


Testing shows that 12000x12000 works on both, but 12001x12001 breaks the M4 export. I do not know if FCP does something different with a 1280x1280 300dpi versus 72dpi when loading it into memory, but it sure looks like the overall pixel size has something to do with the M4 failing to export.


I'm going to go update Apple now with a clean and simple test that works fine on M2, and fails on the M4.

Jul 9, 2026 5:58 AM in response to Ian R. Brown

Ian R. Brown wrote:
Just curious but is it essential for you to use PNGs?
Would JPEGs, TIFFs etc. be unsuitable?

It fails with PNG, HEIF, and even TIFF. It has moved beyond my original assumption. Apple Preview can create a file that will cause FCP on the M4 to fail to export, but the same file will work fine on FCP on an M2. Very odd.


Someone on FB recreated the issue, but when he used images exported with a different tool, they work, so it's looking like:


1) FCP has some image procession issue on M4 with "bad" images where it fails without an error.

2) Apple Preview can export such a "bad" image.


Jul 10, 2026 8:59 AM in response to Ian R. Brown

Ian R. Brown wrote:
It's such a unique problem that I doubt whether they will do anything especially as there are so many workarounds.

Well, the workaround for me is "don't edit on the M4". ;-)


I suspect it is some underlying issue with the Core Image routines that will get resolved since it likely impacts more than just FCP.


For my specific case, none of the built-in or free tools worked. But at least two pay-tools have been verified so far. I can resize mine since its just a logo and was never meant to be this large, but for those of us doing 8K-sized video editing, having larger images so you can zoom in and such is pretty common. It is just weird it breaks at 12000. I need to see if it is just the width or height that breaks. And maybe test 1-bit black and white versus 32-bit color to see if it has more to do with file size.

Jul 10, 2026 9:42 AM in response to Allen Huffman

@Allen Huffman, thank you for keeping us posted on the progress. We typically work with 4K material in HD projects and only ran into this issue with a png that was 3,256 × 37,546 pixels, which is well over 32,766 - the max size of a 16 bit integer. As I mentioned in other discussions, the M1 Ultra handled it fine but the M4 Pro MacMini would silently bail out on exports.

Jul 10, 2026 7:34 PM in response to Allen Huffman

What Terry said is correct. There is a hardware limit on some Apple Silicon GPU texture units at 16,384-pixels. I don't have any other details. If used in the FCP timeline, it is probably safer to pre-scale high-pixel-count images to at most 16,000 x 16,000. I saw a Resolve failure on Apple Silicon due to a 24,000 x 12,000 image. I think if either X or Y dimension is over 16,384 it might fail in some conditions.


There is some technical info about Apple Silicon GPU limits on the Apple Developer site: https://developer.apple.com/metal/Metal-Feature-Set-Tables.pdf


Jul 10, 2026 7:45 PM in response to terryb

terryb wrote:
@Allen Huffman, thank you for keeping us posted on the progress. We typically work with 4K material in HD projects and only ran into this issue with a png that was 3,256 × 37,546 pixels, which is well over 32,766 - the max size of a 16 bit integer. As I mentioned in other discussions, the M1 Ultra handled it fine but the M4 Pro MacMini would silently bail out on exports.

Yeah, a 16-bit limit would make sense. But 12001 seems ... almost like it was some intentional upper limit, which does not make sense.

Jul 10, 2026 10:15 PM in response to joema

I am baffled and curious.


Why would anyone need a 12,000 x 12,000 image? Those figures had not registered in my mind until now . . . I suppose I was thinking 1,200 x 1,200.


The highest resolution TVs commercially available (8K) are 7680 x 4320 and I don't know of anyone who has one.


Can cinema projectors resolve more and if so, is the human eye able to tell the difference under normal viewing conditions?


Or has the PNG to be so big because there is a need to zoom dramatically (like 10x) into it?

FCP 12.3: PNG in project causes export to fail on M4, works on M2

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.