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

"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.

It currently seems isolated to the M4, so other CPUs might not cause this. I can test on M2 Pro, M4 Pro, M1 Ultra and M1 Max (testing in progress right now), but I don't have an M5.

The simplest scenario is to resize a PNG image using Preview to 12001 x 12001 at 300 dpi. Procedure:

• With image open in Preview, navigate to the top menu bar and select Tools > Adjust Size....
• Set the Units: In the dialog box that appears, look at the dropdown menus immediately to the right of the Width and Height fields. Ensure they are set to pixels.
• Adjust the Dimensions (X/Y):
• Type 12001 value into the Width field.
• Type 12001 value into the Height field.
• Use 300 dpi (not sure this matters but it's what I used)

Then do this on an M4 running FCP 12.3:

• Create a new library
• Import the one 12001 x 12001 PNG file
• Create a manual 1080p project (I used 23.98 fps but I don't think it matters)
• Put only the PNG on timeline
• Export this way: File > Share > Export File > Settings, Format: Computer, Video Codec: Single-Pass, Resolution: 1920 x 1080.

It fails 100% of the time with the FCP error "Share Failed." Examination of the macOS log via the terminal command "log show" indicates these errors:

(AppleProResHW) ERROR: AppleProResHW (0x67a7f6b8): 5547: processDecodeFrameDone(): HW error decStatus=2 status0=0x37046000 statusCode=55 status2=0x2 crccrd0d=0x66c2da58 crccrd1d=0xe57e399c

VTDecoderXPCService[53788]: (AppleProResHWDecoder) ERROR: AppleProResHW (0x67a7f6b8): 2151: <private>(): failed decoding proresStatus=2 HWErrorCode=0x37 convertedForEmit=0xffffcd91

VTDecoderXPCService[53788]: (AppleProResHWDecoder) AppleProResHW (0x67a7f6b8): <private>(): Emit to client status=0xffffcd91 for subFrameId=2

So it is failing to decode the input, not to encode the output.

I am examining the actual failure mode as part of gathering background info to support filing a high-quality bug report. I'll also conduct additional testing to determine boundary conditions, such as file type, timeline composition, etc.

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.

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

On my M4 MacBook Air, it also fails with images having these frame sizes:

8048×8065

8048×8079

8192×8193

8000×8321

The failure only happens on images with alpha channels. Without alpha, it does not happen. It also only happens if the alpha channel image has a vertical (or Y-axis) that is not an even multiple of 16.

So one workaround is not to use alpha-channel images when they are not needed. Using macOS Preview, if you open the image and do CMD+I, if it contains alpha channel info, the right-sidebar will show "Has Alpha = 1."

If the image does not need alpha, it can be exported from Preview without alpha. In the export dialog under the Format and Resolution options, just uncheck the alpha box.

Another workaround is to trim the image slightly so that the Y-axis has an even multiple of 16 pixels, IOW the Y-axis divided by 16 is an even number.

If you can reproduce the export failure, then immediately do the following terminal command and send me the output, I will examine it. This exports the previous 60 seconds of the macOS system log, so the failure must have happened within the previous 60 sec. If necessary, trim down the timeline length and PNG image duration in the timeline so that the export takes less than 15 seconds, which will give you time to run the command below.

This command will ask for your Mac password, so you can enter that in advance but don't hit "Enter." Then as soon as the problem happens, switch back to Terminal and press Enter. ZIP the file and upload to me at this location:

https://we.tl/r-zOnSfP03FQNATWQo

sudo log show --info --debug --style syslog --last 60s > ~/Documents/FCP_PNG_Export_Log.txt   

@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.

I can reproduce it on my M4 MacBook Air using 12001 x 12001 PNG images generated using Preview. This enables me to perform much deeper analysis.

The reason for pursuing this is not limited to the "big PNG" scenario. It is always possible that this is only one manifestation of an underlying code problem that may surface in other, yet-unidentified areas. Any problem that causes a low-level decode failure must be treated seriously, so thanks for reporting this.

I also need to re-test on Resolve and Premiere to see if it may be a macOS or hardware issue, not just FCP.