FCP shows FFmpeg-generated ProRes 4444 alpha as opaque on Sonoma 14.4.1 Apple Silicon; Prores decode errors in log

[joema4]

This not an FCP bug and maybe not a MacOS bug. Filing this to avoid confusion because it may appear like an FCP or MacOS bug.

---

DESCRIPTION:

Starting with Sonoma 14.4.0 or 14.4.1 on Apple Silicon, FCP 10.7.1 will incorrectly show a transparent ProRes 4444 alpha channel as opaque if the file was generated by certain versions of FFmpeg and the associated Lavf library. Resolve Studio 18.6.6 and Premiere Pro 24.3.0 behave likewise. This does not happen on Intel.

FCP playback will also generate ProRes HW errors in the MacOS system log. There is no user-facing error. These do not appear in Console but can be seen using the terminal "log show" command. Example:

2024-05-11 10:00:27.683661-0500 0x2db Error 0x0 0 0 kernel: (AppleProResHW) ERROR: AppleProResHW (0x13e358d7): processDecodeFrameDone(): HW error decSatus=6 status0=0x7f043000 statusCode=63 status2=0x1

FFmpeg versions tested and behavior (Note: ALL cause ProRes HW decode errors, even if alpha transparency is OK)

FFmpeg 7.01, Lavf61.1.100 - transparent alpha channel OK
FFmpeg 7.00, Lavf61.3.103 - transparent alpha channel OK
FFmpeg 6.10, Lavf60.16.100 - transparent alpha channel shows as opaque
FFmpeg 5.??, Lavf58.43.100 - transparent alpha channel shows as opaque

This seems an interpretation problem due to something in the FFmpeg-encoded file. I inspected the alpha-channel values in the encoded file using the QCTools datascope and they had transparent values (ie close to 0x0000) but appeared as opaque in FCP. See attached datascope screen shot.

---

HOW TO REPRODUCE:

(1) Use an Apple Silicon machine running Sonoma 14.4.1.

(2) Attached are four 1080p ProRes 4444 files with a transparent alpha channel. Each one is generated by one of the above four versions of FFmpeg and has the above-stated behaviors (version numbers also in the filenames).

Files: https://www.dropbox.com/scl/fo/l6388h0co0q8gwvx1ojcm/AFHdiZwt6wp5MmSKSmT6vEc?rlkey=rvf3kedtlxek4w9gf7ng7lloe&dl=0

(3) Import the four ProRes 4444 files to FCP.

(4) Add each file to a project timeline.

(5) Add beneath each clip a built-in FCP generator to observe if alpha-channel transparency exists.

(6) Examine the MacOS system log using the terminal "log show" command. Example syntax (do within 10 sec of FCP playback):

sudo log show --last 10s > ~/Documents/LogShowOutput_10s.txt

(7) The log is verbose so use BBEdit or similar to filter through the file. Look for the string "AppleProResHW".

---

SCREENSHOTS:

Filename: QCTools_Datascope_PR4444_AlphaChannel.jpg. QCTools Datascope showing alpha-channel value of 0x0060 (should be nearly transparent), but shows as opaque in FCP on MacOS Sonoma 14.4.1 Apple Silicon.

---

SPECS:

• 2022 M1 Ultra Mac Studio (128GB RAM, 8TB SSD)
• macOS Sonoma 14.4.1
• Final Cut Pro 10.7.1
• Also tested: 2019 i9 MacBook Pro 16, 2023 M2 Pro Mac Mini, both running Sonoma 14.4.1

---

OTHER STEPS TAKEN:

• Did binary diff on video files starting with name "QT4444". They are the same except encoded using two different versions of FFmpeg. No apparent differences that would account for the behavior.
• Examined metadata of "good" and "bad" QT4444 video files using FFmpeg, FFprobe, ExifTool. No obvious differences at metadata level.
• Ran FCP under XCode and set breakpoints to find FFImageRepFFPixelBuffer during playback. Nothing obvious.

---

TO DO:

• Provide various statically-built versions of FFmpeg in both Intel and Apple Silicon versions
• Provide instructions and video files for encoding ProRes 4444 files using FFmpeg
• Provide instructions for using the self-encoded files for testing alpha-channel transparency issue

[joema4]

Re-tested on MacOS Sonoma 14.5 M1 Ultra; no change. If using ProRes 4444 files generated by FFmpeg 7.01 using Lavf61.1.100 from a "known good" ProRes source file, the opaque alpha problem does not happen, but both FCP 10.7.1 and Resolve Studio 18.6.6 still get ProResHW decoding errors in the MacOS system log during playback of the FFmpeg-generated ProRes 4444 file, as shown by the terminal command "log show". Does not happen with those same versions on Intel. Whether there are other negative ramifications from the ProResHW errors (stability, performance, etc) is not currently known.

Comments on possible impact:

In the document "Apple ProRes and ProRes RAW Authorized Products", Apple clearly states that "Using any unauthorized implementation (such as the FFmpeg and derivative implementations) might lead to decoding errors, performance degradation, incompatibility, and instability."
https://support.apple.com/en-us/118584

However, the above case was first seen when a customer used Ross Video XPression INcoder version 10.5, which is widely used throughout the broadcast TV industry: https://www.rossvideo.com/live-production/graphics/xpression/

Certain versions of XPression INcoder use FFmpeg to generate ProRes 4444 output. On Apple's above web page, it lists Ross Video XPression as an approved product, but my guess is that is (a) For the current version 11.5 product and (b) That approval does not include generating ProRes 4444 with FFmpeg.

Nonetheless it seems likely that FFmpeg-generated ProRes files are deeply intertwined throughout the post-production pipelines of various industries. Apparently, up until Sonoma 14.4.1 on Apple Silicon, those worked OK. Now they do not.

If FFmpeg is upgraded to version 7 and if the associated library to Lavf61.1.100 or later, the alpha channel behavior of ProRes 4444 files generated by that utility becomes normal as seen in FCP 10.7.1 and Resolve Studio 18.6.6 on Sonoma 14.4.1 and 14.5. But playback in FCP or Resolve Studio of those files still generates ProResHW decoding errors in the MacOS system log as shown by the terminal "log show" utility.

Other tests to run:

• Obtain ProRes 4444 files generated by Apple-approved cameras and recorders (DJI Ronin 4D, Atomos Ninja V, Atomos Shogun 7) and test those for both alpha-channel transparency and ProResHW errors using both FCP and Resolve Studio. Purpose: to inspect if any ProRes 4444 files generated by non-Apple (but approved) hardware devices encounter problems on Sonoma 14.4.1 and 14.5 on Apple Silicon.

• Transcode "known good" ProRes source files to ProRes 4444 using EditReady 24.2, Resolve Studio 18.6.6 and Premiere Pro 24.3.0 on Sonoma 14.4.1 and 14.5 on Apple Silicon. Purpose: inspect if any ProRes 4444 files generated by non-Apple (but approved) software create files that cause problems on Sonoma 14.4.1 and 14.5 on Apple Silicon.

• Devise and run stress tests to investigate if the ProResHW errors caused by FFmpeg-generated ProRes 4444 files on Sonoma 14.4.1 and 14.5 on Apple Silicon cascade to more serious problems such as performance degradation, instability, etc. Obtain XCode Instruments profiles during those tests and compare to normal baseline runs. Purpose: determine if the behavior has more serious ramifications than seemingly benign errors.

[RSK-FCP]

Sorry, but

a) this obviously isn't a Final Cut Pro or OS bug, no
b) how is it in any way surprising when Apple explicitly says that it won't work correctly? 🤨

There is clearly a reason why Apple has an arduous and lengthy certification process for any and all software and hardware that intends on encoding ProRes of any flavor. Now we know why. Whether something is "widely used throughout the broadcast TV industry" or not or if someone still insists on using it is irrelevant.

Certified: guaranteed to work
Uncertified: Kludge. Use at your own risk.

[joema4]

The title says: "Filing this to avoid confusion because it may appear like an FCP or MacOS bug." Yes, it's not an FCP or MacOS bug, which is why the title states that.

Apple did not state it (i.e, non-certified ProRes implementations) won't work correctly. Rather, they stated it might not work correctly. It's possible a customer could successfully use a non-certified version of ProRes for years and not encounter a problem. That's not a good practice, but the customer may not even know it's being used if embedded in another product. This background was included in the bug report to help those who encounter these cases in the future understand the various possible scenarios.

During the 60 hours of work spent isolating, testing, and defining the boundaries of this scenario, it became obvious the customer workflow that created the problem may be common in the industry. That has nothing to do with whether it's an Apple bug. It is simply advisory information to any people who subsequently encounter this. E.g, Apple Engineering could look at this bug report and wonder if they should intervene with Ross Video about the illegal ProRes use. The background info helps them understand it's not just a single case.

[RSK-FCP]

Ah. My bad, I missed the clarifying subtitle.

And sure, Apple may write, "might lead to decoding errors...", but for me, that's Apple-speak for "will." Be it right off the bat or after changes/updates. Why else would they insist on the almost excessive certification process?

For me, it's like joints such as PFS making plugins that use private APIs and only very sloppily adhere to FXPlug guidelines – if at all – so that they (may) work at first, but generally only barely as advertised and then break altogether after the first, maybe second FC or OS update.

But ok, I may well have misinterpreted the overarching point. If so, my bad. But I also think that anyone at Apple would read this and just think what I already wrote: Certified: guaranteed to work. Uncertified: Kludge. Use at your own peril. We won't feel sorry for you when stuff like this happens. 😏

But in the end, I have to wonder what the alleged advantage of using it is to begin with. Especially in light of issues such as this. Because it's cross-platform? There are, of course, a plethora of certified transcoders that are cross-platform and offer the same. So, if you're a "pro," why would you prefer this and, on top of it all, a completely outdated version? 🤨

[joema4]

This was part of a previously-established workflow at a TV station. The TV station did not intentionally pick or contrive some workflow involving ProRes generated by FFMpeg. Rather, the FFMpeg component was invisibly embedded inside of Ross Video XPression INcoder version 10.5, similar to how it's embedded in many other products. For unknown reasons it worked for a period of time, then this problem arose.

The TV station did not understand the problem source until I spent many hours debugging it. They then faced the choice of licensing a new $5,200 version of XPression INcoder, which I believe used a licensed version of ProRes, testing it on their live TV workflow, or manually updating FFMpeg (once I explained how). As a contingency step, they picked the latter. BTW this was all volunteer work on my part; I don't work for Apple, and I wasn't a paid consultant.

So they did not "pick" FFmpeg. Back when they obtained Ross Video XPression INcoder version 10.5, there was no ProRes version, just the FFMpeg version, and this was not apparent.

Similarly, FFMpeg is embedded in many other turnkey products, and the end users have no idea of what internal software code is used. E.g, decompilation study of DaVinci Resolve indicates it also uses FFMpeg internally. This is not an issue of customers intentionally creating a ProRes workflow based on FFMpeg. It is hidden from the customer.

There are many regulatory, licensing and standards bodies with control over consumer electronics items like RFI, AC power safety, etc. However, there is no regulatory or standards body having control over data quality produced by hardware or software products.

I just found a case last week where an ASUS - ROG Ally X gaming handheld produced damaged H.264 that was then imported to a post-production video workflow, and it caused downstream problems. This wasn't a one-off problem, it was a design error in the device. There is absolutely no regulation or QC of this beyond what the manufacturer chooses to do (or not do).