ProRes 4444 Alpha ignored on DR 18.6 Running on ...

kfriis, do you have any example files generated using the two versions of ffmpeg you can send me? IOW one generated with the older version that causes the problem, and ideally the same file generated with the newer ffmpeg version? Or if not, a file generated with the newer ffmpeg having the same resolution, frame rate and chroma subsampling?

If you have those, please put them here and I will investigate: https://www.dropbox.com/request/3XDbMMOLNZ1PBQrcfe25

Even though this seems like a MacOS Sonoma issue on Apple Silicon, it might be an exceedance in a certain spec that by chance is exposed by certain downstream software. In that case there could be dozens of video processing apps affected by this. If possible we need to figure out the underlying technical issue.

No. I only have “problematic” version, but another poster has established, that a never version of ffmpeg is not “flawed” on Sonoma 14,4.1 on Apple Silicon based on the same original material.

Maybe the poster of the original file can supply the new, working version with otherwise identical content.

It could be interesting to establish the detailed file differences.

Regards

I can't remember what version of FFMPEG I used to generate the original file (it was in 2021), but I think it was from v4. I recently replaced FFMPEG with v 6.1.1 to see if that would fix it, but it didn't. I've tried even newer versions of FFMPEG than that (nightlies), but XPression doesn't produce a useable file out of those.

Maybe I should be contacting Ross Video about this, in case it's an XPression issue. BTW, Apple's Animation Codec works fine, but the files are bigger.

Might be related to XPression then.

But don't use the Animation codec. It's not only very inefficient, but limited to 8 bit. Being RLE compression only, it was initially made for flat colour animation, at a time when everybody was still happy with 8 bit in production.

I don't know XPression, but if the issue is related to Apple's hardware decoder in M3 Max, what about DNxHR or Cineform? Both can carry an alpha channel with the right settings.

I only use the animation codec as a last resort.

The only alpha-enabled formats XPression exports to are ProRes and Animation Codec (through FFMPEG) and their own internal codec. So I'd have to convert it anyway to try the other formats, so may as well just use Media Encoder to fix it.

But don't use the Animation codec. It's not only very inefficient, but limited to 8 bit. Being RLE compression only, it was initially made for flat colour animation, at a time when everybody was still happy with 8 bit in production.

Slightly offtopic. I don’t know exactly whether animation codec expects premulted data or not, but for premulted, RLE can be relatively effective because big areas in all RGBA channels are potentially zeroed. In practice, it is useful above other compression methods mostly for animation, true that.

Exr also encodes alpha channel with RLE by the way, due to same efficiency.

If you only need the alpha, yes, the codec is OK.
But I was under the impression that there is an image too.

Image channels get zeroed on premult in zero-alpha regions. But it is all offtopic.

I can't remember what version of FFMPEG I used to generate the original file (it was in 2021), but I think it was from v4. I recently replaced FFMPEG with v 6.1.1 to see if that would fix it, but it didn't. I've tried even newer versions of FFMPEG than that (nightlies), but XPression doesn't produce a useable file out of those.

Maybe I should be contacting Ross Video about this, in case it's an XPression issue. BTW, Apple's Animation Codec works fine, but the files are bigger.

Can’t you link to download of the newest version produced with the newest ffmpeg?

We’ve tested so much, we might as well have a look.

Am I correct in assuming, that you get a file (in what format), and that file is converted to ProRES 4444 with Alpha in ffmpeg. Whatever version of ffmpeg you use, results in a Sonoma 14.4.1 problem on Apple Silicon (anyone tested 14.4.0?), that according to one poster doesn’t exist on 14.3.1, and certainly not on Ventura or Monterey.

It may be a limited time “Sonoma for Apple Silicon” side effect, that will vanish from version 14.5 - anyone brave enough to test betas? In that case it’s a waste of time to look further into the matter.

Why is the extra ffmpeg step necessary at all? In the following link, it is mentioned that export to a list of codecs targeted for MOV and AVI is possible: https://www.rossvideo.com/resources/ros ... as-videos/

I haven’t got time to look in detail, and especially not getting acquanted with the production system, but if the system can handle multiple codecs, why not install Apples ProRES codecs directly on the Windows Machine and instead of export to (for instance) AVI (or whatever intermediate codec is used) choose an installed (MOV) ProRES codec, like… errmmm… ProRES 4444 with Alpha? Are the Apple codecs for reading only?

Just asking.

Regards

The latest release build of FFMPEG I can get is 6.1.1. The nightlies don't produce a usable .mov.

XPression can only export to those codecs using FFMPEG. You have to tell XPression where FFMPEG is installed in the preferences, and it handles the rest from the UI. As far as I know it just sends a stream through standard input to FFMPEG, so there's no intermediary file to look at.

On the other hand, XPression can decode ProRes natively, though they encourage the use of the XPN Codec, which is more efficient in XPression.

EDIT: I was going to the wrong page on the gyan.dev. The FFMPEG website redirects to the git master builds page, not the release page.
I did try using FFMPEG 7.0 from BtbN, but that didn't produce a usable file either (nothing could open it).

The latest release build of FFMPEG I can get is 6.1.1. The nightlies don't produce a usable .mov.

XPression can only export to those codecs using FFMPEG. You have to tell XPression where FFMPEG is installed in the preferences, and it handles the rest from the UI. As far as I know it just sends a stream through standard input to FFMPEG, so there's no intermediary file to look at.

On the other hand, XPression can decode ProRes natively, though they encourage the use of the XPN Codec, which is more efficient in XPression.

EDIT: I was going to the wrong page on the gyan.dev. The FFMPEG website redirects to the git master builds page, not the release page.
I did try using FFMPEG 7.0 from BtbN, but that didn't produce a usable file either (nothing could open it).

Ok. Then let’s just wait for Sonoma 14.5 and see, what gives.

IF ffmpeg works (as I assume) in all other cases, than 14.4.1, and there are numerous alternatives for producing working ProRES 4444 with Alpha (also on 14.4.1 on Apple silicon), there’s no reason to get hung up on some unknown incompatibility, that may even be caused by a minor inconsistency in the ffmpeg input stream affecting use in (only?) Sonoma 14.4.1 and then only on Apple Silicon.

Anyone needing to produce output, can be instructed to avoid Sonoma 14.4.1 on Apple Silicon (maybe 14.4 too - who knows) for the time being. There are Windows machines working and Intel machines with working Sonoma 14.4.1, so… not really anything but a slight practical inconvenience, or…?

Regards

...Ok. Then let’s just wait for Sonoma 14.5 and see, what gives.

IF ffmpeg works (as I assume) in all other cases, than 14.4.1, and there are numerous alternatives for producing working ProRES 4444 with Alpha (also on 14.4.1 on Apple silicon), there’s no reason to get hung up on some unknown incompatibility, that may even be caused by a minor inconsistency in the ffmpeg input stream affecting use in (only?) Sonoma 14.4.1 and then only on Apple Silicon....

I definitely understand not spending lots of time chasing a narrow incompatibility. However, this isn't isolated to Resolve. On MacOS Sonoma 14.4.1 and Apple Silicon, it happens on FCP, Premiere Pro, EditReady, and probably other NLEs and utilities.

It might be a bug in Sonoma 14.x on Apple Silicon, or it might be an out-of-spec encoding issue caused by certain versions of FFMPEG, or how XPression calls it, or it might be a gray area in the spec.

I just checked the "Learn More" test video using the iPadOS version of FCP (ver. 1.3) and Resolve (18.6.6) on a 3rd-gen iPad Pro with M1 CPU on iPadOS 17.4.1, and the alpha channel behavior worked fine on both NLEs. So that is M1, just iPadOS not MacOS.

...Ok. Then let’s just wait for Sonoma 14.5 and see, what gives.

IF ffmpeg works (as I assume) in all other cases, than 14.4.1, and there are numerous alternatives for producing working ProRES 4444 with Alpha (also on 14.4.1 on Apple silicon), there’s no reason to get hung up on some unknown incompatibility, that may even be caused by a minor inconsistency in the ffmpeg input stream affecting use in (only?) Sonoma 14.4.1 and then only on Apple Silicon....

I definitely understand not spending lots of time chasing a narrow incompatibility. However, this isn't isolated to Resolve. On MacOS Sonoma 14.4.1 and Apple Silicon, it happens on FCP, Premiere Pro, EditReady, and probably other NLEs and utilities.

It might be a bug in Sonoma 14.x on Apple Silicon, or it might be an out-of-spec encoding issue caused by certain versions of FFMPEG, or how XPression calls it, or it might be a gray area in the spec.

I just checked the "Learn More" test video using the iPadOS version of FCP (ver. 1.3) and Resolve (18.6.6) on a 3rd-gen iPad Pro with M1 CPU on iPadOS 17.4.1, and the alpha channel behavior worked fine on both NLEs. So that is M1, just iPadOS not MacOS.

I can add, that anything produced from Apple Motion via Apple Compressor (4444 with Alpha) works as intended on Resolve 18.6.6 and FCPX 10.7.1 on Sonoma 14.4.1 (and all earlier versions of Sonoma, Ventura, Monterey etc - either one or both of the NLE's) on Apple Silicon (my MacBook 14 Pro M1 Pro) and any other silicon employed over the years.

What makes me feel a bit "iffy" on the matter, is that there seems to have been scant control regarding the ffmpeg versions actually used, and the command line arguments employed on unknown "included source material" have not been disclosed for scrutiny either. Making it impossible to establish any possible cause. Only an extremely rare effect under extremely narrow circumstances.

I have one file of "unknown origin and content" misbehaving. ONE. Only One!

And absolutely no known way, to check for possible causes.

Only known - ahem - spec is the extremely broad term "ffmpeg" and a file, that can trigger misbehavior in a rare combination and limited set of circumstances (otherwise, we wouldn't have had such trouble discovering the narrow combination of elements required).

I'm not criticizing ffmpeg; it is a wonderfull tool akin to the Swiss Army knife of video manipulation, extraction and conversion - if used correctly in the most current version.

Regards

...scant control regarding the ffmpeg versions actually used, and the command line arguments employed on unknown "included source material" have not been disclosed for scrutiny either. Making it impossible to establish any possible cause. Only an extremely rare effect under extremely narrow circumstances.

I have one file of "unknown origin and content" misbehaving. ONE. Only One!

And absolutely no known way, to check for possible causes...

All good points. Because of insufficient information, I would have to spend several days plowing through test cases to narrow down the cause.

If we had the original clip before transformation by XPression & FFMPEG, that would help a lot.

I tested a ProRes w Alpha file in Premiere for another user. Worked normally on my PC. Another user tested on a Mac still "pre-Sonoma" and it was normal on his machine.

Seems some ProRes w alpha files don't work on Sonoma Macs. No clue as to why of course.

But it isn't just in Resolve.

Sent from my SM-S908U using Tapatalk

If we had the original clip before transformation by XPression & FFMPEG, that would help a lot.

There is no original file. It's a 3D animation rendered out of XPression.

As for the parameters used for FFMPEG, I have no idea what those are. It's all handled within the innards of XPression.

I can supply another file I exported yesterday for another program. It's a lower-third super, and the alpha isn't working either on Sonoma. But I don't think it's going to add any extra light to the issue.

The reason for using Sonoma is because I had trouble exporting from DR on Windows. It would drop the source files during export for some unknown reason, and I found I could only do it reliably on macOS. Then this problem cropped up.

I've posted a question about this issue on the Ross Community, but so far no response.

I'm going to wait until Sonoma 14.5 comes out and see if there's a fix there. It's in RC at the moment.

What’s a bug and where is it?

I have traced bugs in tens of years before retiring. In own code and code made by others. Also code, where ten, twenty or more code elements, units, programs, servers were part of a solution.

Let me try to illustrate a “typical” conundrum to the best of my abilities. Well knowing, that typical bugs are pure hearsay. Typical coding or process errors are legion, but bugs have some - ahem - “qualities”, that may initially defy reason, until ALL parts involved have been inspected.

Question always being “WHERE’s the bug” in an often “messy” conglomeration of parts, routines and methods, where all parties involved are certain, who’s not responsible. Truth can be extremely hard to swallow for some.

The following example is deliberately made very simple in nature; to prove a point!

Imagine a series of transport belts in a storage area of a factory. Many storage rooms. One after another. Rooms added, when needed.

Belts moving packages from manufacturing area to final storage area. Passing through portals in walls en route. All portals must allow pass-thru of packages up to 1.80 meters in height to live up to minimum specs. The portals must have absolutely level “tops” and truly vertical sides too. Clear specs!

Leave out anything else in this example.

Each portal is created with least possible costs. Last year, there were 13 portals. One allowed up to 3m. Some 2 meters or more. One 1.85 meters and so on.

ALL clearly within specs. Never been a problem to move packages along the line.

The newest package area added to the end of the transport line has a portal allowing packages up to 1.81 meter. Perfectly within specs, but suddenly a package gets stuck.

Seemingly there’s a bug, a design error in the last portal. Or…?

Maybe not the best example, but illustrates the basic problem.

Until someone measures the height of the “offending” package, it’s easy to blame the designers of the last portal added. That portal may still contain an error of some “hidden nature”, but the height allowance is certainly within specs. Until every part of the process is minutely tested, we don’t know, if the portal is the culprit.

In our case, nobody seems to be willing or able to measure the “package height”. Every bad excuse in the book has been used including “don’t know”!

Was a bug discovered or a signal of an error produced at an earlier stage?

Regards

P.S. I’m absolutely no fan of Sonoma, but personal views or animosities do not solve problems involving complicated systems. Bugs are pesky critters.

In our case, we have ONLY discovered a correlation involving one specific detail in very limited circumstances involving one example of unknown origin with content within unknown limits.

The discovered correlation may involve a bug present in the delivery system (Sonoma 1.4.1) on specific hardware (Apple Silicon) and NOWHERE else and not in earlier versions.

Is this truly a bug in Sonoma 1.4.1 or just a “signal” indicating another, hitherto not discovered bug elsewhere in the “production line”?

If you truly want to find the bug, you have to analyze all involved parties, parts and methods.

Blame is far easier to meter out. It’s always the other guy

As stated earlier, I’m certainly no fan of Sonoma, but…

...In our case, nobody seems to be willing or able to measure the “package height”. Every bad excuse in the book has been used including “don’t know”!....

Your analogy is good, except in this case it's much harder than measuring a package.

The file was not produced by a camera but by a graphics app using a certain version of FFmpeg, which in turn used a certain version of the (Lavf) libavformat library for muxing and demuxing media containers.

The Lavf version used to produced the "Learn More" sample video was Lavf58.43.100.
Last night, Lucjan sent me two test files he built with Lavf60.16.100 and Lavf61.3.103. I will examine those today.

The root cause might be a MacOS bug, it might be some out-of-spec encoding violation, or it could be a gray area in a spec. The general principle in such cases is to pursue and fix it upstream (if that's where the error is). It's often not feasible to fix multiple downstream apps because somebody upstream violated a standard.

If the error is in MacOS, we can get that fixed but it will happen faster if the problem conditions are well-bounded.

Let's take a pragmatic approach, instead of waiting for a fix for such a rare incompatibility.
If you have any spare storage with reasonable speed, install Ventura, boot from there, and add DR. Or do you have M3?
The file works as expected under Ventura.

I tested using both Lucjan's files and the original "Learn More" clip from James Hope, and it doesn't happen on MacOS Sonoma 14.4.1 on Intel. Maybe somebody already tested that, but I wanted to verify it.

Lucjan's files are especially useful because he created an alpha-channel pattern using FFmpeg (library=Lavf60.16.100) which manifests the problem on Sonoma 14.4.1 Apple Silicon, and FFmpeg (library=Lavf61.3.103) which does not manifest the problem on Sonoma 14.4.1 Apple Silicon.

Lucjan's files are 1080p/25, progressive, so that eliminates any concern about interlacing being a factor.

This is sufficient to file a bug report with Apple and also advise Ross Video (maker of XPression) which created the original file. I will handle that, and I tend to think it's more likely a MacOS bug on Apple Silicon, but I want to first look a little deeper into the encoded file to see if I can spot what might be triggering this.

Using Lucjan's files, I've already compared the output of MediaInfo, ExifTool and ffprobe, and there is no obvious difference at that level. It must be on a lower level.

If it's achievable, the purpose of this is to provide more detailed info about the underlying encoding difference. This might help Apple achieve a quicker or more reliable fix. It is conceivable it's not isolated to Sonoma 14.4.1, but might happen on other platforms such as Linux. If I can't obtain the lower-level info, I'm sure they Apple can fix it anyway.

Yesterday I extensively studied the Lucjan's two clips (each rendered with a different FFmpeg library, Lavf60.16.100 vs Lavf61.3.103), and I couldn't see any internal differences. A binary diff of course shows differences but the question is whether the encoding or metadata is different. I couldn't find any differences.

Since this also affects FCP and I'm more familiar with FCP internals, plus FCP libraries are fully symbolicated, I ran that under XCode and set various breakpoints to try and find how it handles the different video files. The idea is find what it's checking and then inspect that part of the video file, then compare the two video file versions built with different FFmpeg libraries. I found one code path where it's checking the alpha type in a buffer, but I haven't yet back-tracked to the file offset.

If I simply file a MacOS bug with Apple stating a ProRes 4444 video file built with an older version of an FFmpeg library doesn't handle alpha properly on Apple Silicon, I'm not sure it would be fixed anytime soon. If it were a Resolve bug, I'm confident that Resolve development would immediately fix it. But it's apparently a MacOS bug that only manifests in this narrow area. The more specific info in the bug report, the more likely it will be fixed. Also we gain a better understanding of how broad the problem is.

You are doing the community a great service. Maybe the issue is also connected with the random offline error?

…cut

Since this also affects FCP and I'm more familiar with FCP internals, plus FCP libraries are fully symbolicated, I ran that under XCode and set various breakpoints to try and find how it handles the different video files. The idea is find what it's checking and then inspect that part of the video file, then compare the two video file versions built with different FFmpeg libraries. I found one code path where it's checking the alpha type in a buffer, but I haven't yet back-tracked to the file offset.

If you want a second pair of eyes on the matter, send me a private message, detailing what you would want me to do or replicate in my XCode (fully updated). I’m in no way offended, if you decide you don’t have the time to handle that too, without any guarantee of success.

If I simply file a MacOS bug with Apple stating a ProRes 4444 video file built with an older version of an FFmpeg library doesn't handle alpha properly on Apple Silicon, I'm not sure it would be fixed anytime soon. Cut…

I’m convinced, like you suspect, that old ffmpeg version files behaving badly and a never version not (I got that impression, but correct me, of I’m wrong) will not entice Apple to use valuable talent on the case.

Regards

Definitely not, since ProRes by ffmpeg is not Apple 'blessed', just tolerated.

Definitely not, since ProRes by ffmpeg is not Apple 'blessed', just tolerated.

They may not "bless" the use of ffmpeg, but I trust, that true professionals in Apples video/media/tech/code departments recognizes the value of this universal tool, that can be employed on a host of platforms.

I would venture so far as to state, if "Tim Apple" decided to even hint at accepting the existence of ffmpeg, I would be scared (he's the SOE - Stock (value) Optimizer Engine of Apple. His reign often make me think of a former trustworthy US airline manufacturer).

The details I referred to was this:

Lucjan's files are especially useful because he created an alpha-channel pattern using FFmpeg (library=Lavf60.16.100) which manifests the problem on Sonoma 14.4.1 Apple Silicon, and FFmpeg (library=Lavf61.3.103) which does not manifest the problem on Sonoma 14.4.1 Apple Silicon.

It's a bit "hazy", what was involved in this (maybe) hastily written down sentence - I may (erroneously?) have seen this, as involving different ffmpeg versions too. Any clarification highly welcome.

Regards

Further testing shows the problem may be broader than it first appears. I checked the verbose system log using the terminal "log show" command, and any ProRes 4444 file generated by any version of FFmpeg I've thus far tested is causing h/w decode errors during playback by either FCP 10.7.1 or Resolve Studio 18.6.6 on an M1 Ultra running Sonoma 14.4.1. Whether it causes the "opaque alpha" problem varies on the FFmpeg and libavformat version, which we already knew.

The relationship of the decoding errors to the alpha compositing issue is unknown, but it's suspicious. My initial reaction is if you're getting decoding errors the outcome could be unpredictable.

On Resolve these errors still happen if H.264/H.265 h/w acceleration is disabled, not unexpected since it's a ProRes file and there's no apparent way to disable ProRes acceleration.

I'll test this on my M1 Max MBP 16 and M2 Pro Mac Mini, plus some other Intel Macs (but we don't think it happens there). It would be useful to know whether this began with Sonoma 14.4.0 or what version.

I encoded this 1080p/23.98 ProRes 4444 chroma-keyed test file using FFmpeg 7.01, libavformat 61.1.100. Alpha compositing seems to work on this one, but it still causes the decode errors.

https://www.dropbox.com/scl/fi/e9i1daus ... l4suu&dl=0

Log show example syntax to capture previous 10 seconds is below. Even for 10 sec it is verbose, so using BBEdit or similar programming editors with grep filtering are best.

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

Resolve Studio 18.6.6, Sonoma 14.4.1, M1 Ultra, h/w decode off, FFmpeg 7.01, libavformat 61.1.100, 1080p/23.98 PRQ4:

2024-05-11 09:53:39.630131-0500 0x2db Error 0x0 0 0 kernel: (AppleProResHW) ERROR: AppleProResHW (0x59cd9b0a): processDecodeFrameDone(): HW error decSatus=6 status0=0x7f043000 statusCode=63 status2=0x1

Resolve H264/H265 h/w decode on:

2024-05-11 09:57:42.588645-0500 0x2db Error 0x0 0 0 kernel: (AppleProResHW) ERROR: AppleProResHW (0x39b02ea): processDecodeFrameDone(): HW error decSatus=6 status0=0x7f043000 statusCode=63 status2=0x1

FCP 10.7.1, Sonoma 14.4.1, M1 Ultra:

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

Definitely not, since ProRes by ffmpeg is not Apple 'blessed', just tolerated.

This is an important statement. It's not just Uli's personal opinion. Apple states this explicitly:

https://support.apple.com/en-us/118584

"Unauthorized codec implementations

In some instances, unauthorized codec implementations have been used in third-party software and hardware products. Using any unauthorized implementation (such as the FFmpeg and derivative implementations) might lead to decoding errors, performance degradation, incompatibility, and instability.

If you're using or considering the purchase of a product that encodes or decodes ProRes but isn't on the list below, please contact us at ProRes@apple.com."

The implication is we can't ask Blackmagic to fix this, since it's not a Resolve bug. And we can't ask Apple to alter MacOS to accommodate an unapproved third-party encoder.

Definitely not, since ProRes by ffmpeg is not Apple 'blessed', just tolerated.

This is an important statement. It's not just Uli's personal opinion. Apple states this explicitly:

https://support.apple.com/en-us/118584

"Unauthorized codec implementations

In some instances, unauthorized codec implementations have been used in third-party software and hardware products. Using any unauthorized implementation (such as the FFmpeg and derivative implementations) might lead to decoding errors, performance degradation, incompatibility, and instability.

If you're using or considering the purchase of a product that encodes or decodes ProRes but isn't on the list below, please contact us at ProRes@apple.com."

The implication is we can't ask Blackmagic to fix this, since it's not a Resolve bug. And we can't ask Apple to alter MacOS to accommodate an unapproved third-party encoder.

I assume, that ffmpeg is NOT on the "official list".

Doesn't alter my view on "True professionals...." and all that jazz.

Corporate "views" also have down to earth pecuniary importance (anything can lead to costly law suits, when rich moguls decide to live out a hatefull moment in court).

Before retirement, I often had to pull the "officially we don't support", and that was perfectly true. It din't alter the fact, that the "unsupported tool" was used from time to time as a reality check. If our tool failed on our products, and the "unsupported tool" didn't, it was hard for the "upper echelons" to reject, that we needed to look at a detail or two (in order to avoid, that an important customer later decided to pursue ideas emanating from their own IT department

Regards

Apple states this explicitly:

https://support.apple.com/en-us/118584

"Unauthorized codec implementations

In some instances, unauthorized codec implementations have been used in third-party software and hardware products. Using any unauthorized implementation (such as the FFmpeg and derivative implementations) might lead to decoding errors, performance degradation, incompatibility, and instability.

I’ve singled out the important text. When reading Apples document, I see, that “Ross Video” product “Xpression Incoder” is supported (maybe with strict rules), but isn’t that the product, that was used to generate the files, we tested?

Just asking (ALLWAYS read the “small print”

Regards

You are correct, by definition ProRes generated from Ross Xpression Incoder is a supported product, so we can't "kick it to the curb" as non-supported.

That said, James posted a message on the Ross forums and nobody responded.

This is a MacOS compatibility issue with (apparently) licensed ProRes media generated by Ross Xpression Incoder.

Awareness of this surfaced while using Resolve but it also affects FCP and Premiere. It's an issue for Ross to discuss with Apple.

Ross knows who their customers are and which of them might need tech bulletins warning of this and advising them what actions to take.

I'm willing to provide information as needed, but it should probably be driven by Ross and their customers.

You are correct, by definition ProRes generated from Ross Xpression Incoder is a supported product, so we can't "kick it to the curb" as non-supported.

That said, James posted a message on the Ross forums and nobody responded.

This is a MacOS compatibility issue with (apparently) licensed ProRes media generated by Ross Xpression Incoder.

Awareness of this surfaced while using Resolve but it also affects FCP and Premiere. It's an issue for Ross to discuss with Apple.

Ross knows who their customers are and which of them might need tech bulletins warning of this and advising them what actions to take.

I'm willing to provide information as needed, but it should probably be driven by Ross and their customers.

Let’s celebrate, that we’re not involved - we just “played along” for a moment or two out of sheer curiosity.

It was rather fun, to get a blast of fresh air into the dark corners and “debugging webs” left many years ago

After further thought, I should contact Apple and Ross Video about this. I will do that on Monday.

After further thought, I should contact Apple and Ross Video about this. I will do that on Monday.

Don’t.

Contact Ross if you absolutely must, but keep it there.

My two cents.

Regards

My understanding of Ross XPression being on that list is it's for a newer version than we have. We can't upgrade to 11 or 11.5 due to our license. We're capped at 10.5. It's super expensive to upgrade, requiring us to pay the intervening years' worth of maintenance to upgrade.

My understanding of Ross XPression being on that list is it's for a newer version than we have. We can't upgrade to 11 or 11.5 due to our license. We're capped at 10.5. It's super expensive to upgrade, requiring us to pay the intervening years' worth of maintenance to upgrade.

OK. Interesting! Hmmm…. Is it OK to sigh?

Maybe, just maybe, a more “standard and progress friendly” tools supplier should be on the charts, when future investments are planned?

At least I rediscovered a seldom seen approach to code maintenance (ignore any future development or required adjustments). That’s also a management - ahem - approach - maybe even pleasing short term investors

Regards

Just out pf curiosity: Has anyone checked, if material produced in Resolve Studio (any version) rendered as ProRES 4444 with Alpha (for a reason) is acting up in Resolve 18.6.6 or FCPX 10.7.1 on Apple Silicon?

Haven’t had time to check creation, yet, but if you have (old) material lying around, it’s easy to check.

Regards

Using Sonoma 14.4.1 on M1 Ultra Mac Studio, I used ProRes 4444 material, keyed it and exported as ProRes 4444 with alpha from Resolve Studio 18.6.6. That looks OK and FCP 10.7.1 on the same machine interprets it OK. I also checked the reverse, from FCP to Resolve and that also works.

Using Sonoma 14.4.1 on M1 Ultra Mac Studio, I used ProRes 4444 material, keyed it and exported as ProRes 4444 with alpha from Resolve Studio 18.6.6. That looks OK and FCP 10.7.1 on the same machine interprets it OK. I also checked the reverse, from FCP to Resolve and that also works.

Thank you!

Material from Motion rendered in Compressor shows no problems either. Recent or old renders no difference.

Regards

OK. Interesting! Hmmm…. Is it OK to sigh?

Maybe, just maybe, a more “standard and progress friendly” tools supplier should be on the charts, when future investments are planned?

If another software vendor had a live broadcast graphics system that was as fully featured for the price, then maybe we would, but everything else is either nowhere near as good or much more expensive. But that's beside the point.

As this issue is not a Resolve or Mac OS problem, maybe the topic title should be changed.

As this issue is not a Resolve or Mac OS problem, maybe the topic title should be changed.

It serves as a good illustration on how initial impressions, based on old, ill maintained software output, can lead to a lot of unnecessary problems in modern systems, and a huge amount of unnecessary work in order to end up with a conclusion, that the whole shebang was utterly unnecessary, if we got the whole story from the beginning

A real life case.

That's what makes bug-hunting so complicated. Establishing facts - not hearsay, beliefs, guesses, probabilities or worse - is hard work best performed BEFORE even starting the quest.

YMMV.

Regards

It serves as a good illustration on how initial impressions, based on old, ill maintained software output, can lead to a lot of unnecessary problems in modern systems, and a huge amount of unnecessary work in order to end up with a conclusion, that the whole shebang was utterly unnecessary, if we got the whole story from the beginning

A real life case.

That's what makes bug-hunting so complicated. Establishing facts - not hearsay, beliefs, guesses, probabilities or worse - is hard work best performed BEFORE even starting the quest.

The original post was just a question to see if anyone else had the problem, in my quest to find out if it's more than a DR issue. It didn't need to go into the detail it has since we discovered it was FFMPEG that was the culprit. I did change the subject to say this was "solved" a week ago, but someone removed it and continued on with the discussion for some unknown reason. The quoted comment seems a little unfair to me.

Thank you for looking into it and helping point me in the right direction. I think this thread can stop here now.

...It didn't need to go into the detail it has since we discovered it was FFMPEG that was the culprit....

To be clear, (even if I previously described it that way) we don't absolutely know that FFmpeg was the sole culprit. The initial problem description was a ProRes 4444 opaque alpha-channel problem starting with about MacOS Sonoma 14.4.1 on Apple Silicon. That aspect was traced to certain older versions of FFmpeg and the associated Lavf library.

However even ProRes 4444 generated by the latest version of FFmpeg and Lavf library still causes ProRes hardware decoding errors on Sonoma 14.4.1 on Apple Silicon. So far those are just in the MacOS system log -- I haven't seen user-facing problems from that. But it's quite possible there are other complications.

This is possibly a bigger issue than alpha-channel transparency problems on ProRes 4444 generated by older versions of FFmpeg. Use of FFmpeg is pervasive throughout the video industry. If there's a generic problem that only materialized since Sonoma 14.4.1 on Apple Silicon, it needs further investigation, no matter who is at fault.

In a software ecosystem, the general policy is the upstream people must fix their product. E.g, if a brand of gasoline is found contaminated, you don't upgrade all the cars to accommodate that. You correct the problem at the source.

However, sometimes you have to pragmatically compromise. When I worked on SQL Server at Microsoft, we encountered a rare network fragmentation error that would crash our server. It wasn't our fault, so we could have told the third-party network vendor "you fix it." However we decided it was better to compromise and compensate with a fix in our application -- but it was in a "hot" code path which cost us 5% on a prominent benchmark. Recovering the performance caused by the fix required major work. Apple may decide to fix this even if it's not their fault (which we still don't know for certain).

From that perspective, none of this investigative effort has been wasted. The "opaque alpha" problem has already been independently encountered by FCP users on the above platforms, and is being discussed on Apple forums. It is very likely Premiere users have also encountered it.

Large media publishers have automated batch workflows using FFmpeg. It is possible at this moment, their pipelines are producing intermediate content which is problematic on Sonoma 14.4.1 and Apple Silicon.

I don't work for Blackmagic or anyone else, but I have a professional responsibility to ensure that my technical counterparts are informed about this. I've filed a detailed bug report in Chris Hocking's database and he or I will discuss this with other industry people.