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

Hi,

I've searched the forums and the net and can't find anything about this, but since 18.5, and continuing with 18.6, the alpha channel on ProRes 4444 footage seems to be ignored when running on macOS 14 (Sonoma). It works perfectly fine on Windows 11 and older versions of macOS.

Has anyone else had this issue? The computer is on the latest version of Sonoma with the Pro Video Codecs up to date.

How exactly is it ignored? When on an upper layer? Or when switching the composite mode in the Inspector?
Do you have any other software to try it, like Motion or FCP-X, to see if it's DR or the MacOS itself causing the issue?

Hey

Yes I had this issue but in Fusion Studio. Oddly I "fixed" it by having Fusion run under Rosetta. I doubt Sonoma allows this anymore, does it ? If yes, give it a try, it may be a good start for investigation...

Secondly, did you a look in the Fusion tab to see if it's the same there ?

How exactly is it ignored? When on an upper layer? Or when switching the composite mode in the Inspector?
Do you have any other software to try it, like Motion or FCP-X, to see if it's DR or the MacOS itself causing the issue?

What I mean by ignored, it doesn't use it at all. When putting these clips on a higher track, instead of "seeing through" them when the alpha is not opaque, there's just black behind, as if it's got nothing on lower tracks.

I've tested the clips with OBS on the same computer, and they work fine. I don't have FCP on it.

Please check the Clip Attributes too.

Done that. I've tried all the alpha options. Nothing changes, except for "invert", which of course makes it 100% transparent.

Last attempt : try-in-fusion

Fusion has been handling alpha for ages, without any need of poor alpha output connection.
Select your 2 stacked clip > make a fusion clip > go to your Fusion page > be sure the BG clip is in the orange input of the merge node and the ProRes4444piped in the green one > check the Merge node in the viewer : now what ?

So, I've tried Fusion. No luck.

I also decided to put FCPX on that computer. Very odd result. If the transition is rendered, then it does the same thing as DR. But, if it's not rendered (i.e. background rendering is turned off and I don't render it manually), the alpha channel works.

As suggested earlier, this might be an OS bug. I wouldn't be surprised now thinking about Apple's latest issues with buggy macOS updates.

Hi,

I've searched the forums and the net and can't find anything about this, but since 18.5, and continuing with 18.6, the alpha channel on ProRes 4444 footage seems to be ignored when running on macOS 14 (Sonoma). It works perfectly fine on Windows 11 and older versions of macOS.

Has anyone else had this issue? The computer is on the latest version of Sonoma with the Pro Video Codecs up to date.

Davinci Resolve Studio 18.6.6 Build 7 running on Sonoma 14.4.1 on MacBook 14 Pro M1 Pro, with a quickly created "dummy project and timeline" just to check the feasibility one extra time, without any other disturbing influence or takes of doubtful origin. All material by my own hands, created at one time or other not too long ago.

ProRES 4444 with Alpha overlayed on ProRES 422HQ in Resolve 18.6.6 on Sonoma 14.4.1

Skærmbillede 2024-05-01 kl. 10.05.02.jpg (566.62 KiB) Viewed 2539 times

ProRES 4444 created in Apple Motion and Exported as "ProRES 4444 (With Alpa)" via Apple Compressor (my environment). It is fairly common, that people just select "ProRES 4444" and just assume with Alpha as a "freebee".

The ProRES 422HQ file recorded in Apple Camera App on iPhone 15 Pro.

Regards

So, I've tried Fusion. No luck.

Ok... (though "no luck" doesn't ring a bell to me)

Now where is this PR4444 file coming from ? Is it the same with ANY PR4444 with alpha embedded ? And the least : what does MediaInfo "say" about it ?

"No luck" just means it didn't work out.

They're rendered through FFMPEG from a broadcast graphics system from Ross Video called XPression. I've used these files many times in the past with no problems. As I've said before, it works fine on DR in Windows 11 and on Ventura.

This is what Mediainfo says about one of the clips I'm having trouble with:

Code: Select all

General
Complete name                            : /Volumes/Groups/Production/Programs/NOW/Graphics_22/Transition/Flash Transition.mov
Format                                   : MPEG-4
Format profile                           : QuickTime
Codec ID                                 : qt   0000.02 (qt  )
File size                                : 64.3 MiB
Duration                                 : 2 s 169 ms
Overall bit rate mode                    : Variable
Overall bit rate                         : 249 Mb/s
Frame rate                               : 29.970 FPS
Writing application                      : Lavf58.43.100

Video
ID                                       : 1
Format                                   : ProRes
Format version                           : Version 0
Format profile                           : 4444
Codec ID                                 : ap4h
Duration                                 : 2 s 169 ms
Bit rate mode                            : Variable
Bit rate                                 : 247 Mb/s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 29.970 (29970/1000) FPS
Color space                              : YUVA
Chroma subsampling                       : 4:4:4
Scan type                                : Interlaced
Original scan type                       : Progressive
Scan type, store method                  : Interleaved fields
Scan order                               : Top Field First
Bits/(Pixel*Frame)                       : 3.976
Stream size                              : 63.9 MiB (99%)
Writing library                          : Lavc
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709

Audio
ID                                       : 2
Format                                   : PCM
Format settings                          : Little / Signed
Codec ID                                 : sowt
Duration                                 : 2 s 169 ms
Bit rate mode                            : Constant
Bit rate                                 : 1 536 kb/s
Channel(s)                               : 2 channels
Channel layout                           : L R
Sampling rate                            : 48.0 kHz
Bit depth                                : 16 bits
Stream size                              : 407 KiB (1%)
Default                                  : Yes
Alternate group                          : 1


I should probably add that the computer I'm having trouble with this on is a Mac Studio with an M2 Max chip in it, running macOS Sonoma 14.4.1. I have the latest DR 18.6.6 on it, though this was happening before with 18.5 as well (I updated to the latest version to see if that would fix the issue).

Maybe you could provide a sample file on a cloud share for someone to test. I just tried creating a ProRess 4444 w/ alpha in Resolve and then brought it back in and it worked perfectly.

I should probably add that the computer I'm having trouble with this on is a Mac Studio with an M2 Max chip in it, running macOS Sonoma 14.4.1. I have the latest DR 18.6.6 on it, though this was happening before with 18.5 as well (I updated to the latest version to see if that would fix the issue).

Should work. My working ProRES 4444 (with Alpha) delivers these MediaInfo Specs:

Code: Select all

Format                                   : MPEG-4
Format profile                           : QuickTime
Codec ID                                 : qt   0000.00 (qt  )
File size                                : 67.5 MiB
Duration                                 : 5 s 0 ms
Overall bit rate mode                    : Variable
Overall bit rate                         : 113 Mb/s
Frame rate                               : 25.000 FPS
Movie name                               : kuddibras-only
Movie_More                               : kuddibras logo only
Performer                                : Kurt Friis Hansen
Description                              : kuddibras logo only
Encoded date                             : 2024-04-23 17:56:06 UTC
Tagged date                              : 2024-04-23 17:56:11 UTC
Writing library                          : Apple QuickTime

Video
ID                                       : 2
Format                                   : ProRes
Format version                           : Version 1
Format profile                           : 4444
Codec ID                                 : ap4h
Duration                                 : 5 s 0 ms
Bit rate mode                            : Variable
Bit rate                                 : 110 Mb/s
Width                                    : 2 800 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 2.593
Frame rate mode                          : Constant
Frame rate                               : 25.000 FPS
Color space                              : YUVA
Chroma subsampling                       : 4:4:4
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 1.461
Stream size                              : 65.8 MiB (98%)
Title                                    : Core Media Video
Writing library                          : Apple
Encoded date                             : 2024-04-23 17:56:06 UTC
Tagged date                              : 2024-04-23 17:56:11 UTC
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709

Audio
ID                                       : 1
Format                                   : PCM
Format settings                          : Little / Signed
Codec ID                                 : lpcm
Duration                                 : 5 s 0 ms
Bit rate mode                            : Constant
Bit rate                                 : 2 822 kb/s
Channel(s)                               : 2 channels
Channel layout                           : L R
Sampling rate                            : 44.1 kHz
Bit depth                                : 32 bits
Stream size                              : 1.68 MiB (2%)
Title                                    : Core Media Audio
Language                                 : English
Encoded date                             : 2024-04-23 17:56:06 UTC
Tagged date                              : 2024-04-23 17:56:11 UTC

Other
ID                                       : 3
Type                                     : Time code
Format                                   : QuickTime TC
Duration                                 : 5 s 0 ms
Frame rate                               : 25.000 FPS
Time code of first frame                 : 00:00:00:00
Time code of last frame                  : 00:00:04:24
Time code, stripped                      : Yes
Title                                    : Core Media Time Code
Encoded date                             : 2024-04-23 17:56:06 UTC
Tagged date                              : 2024-04-23 17:56:11 UTC

Very similar to yours. I've removed filename, location and keywords, author, title.

Have your tried to create a "clean project"? Just for testing the ProRES 4444 (With Alpha) functionality?

Sometimes, when fiddling around with settings - more or less in panic - the project end result can be "confused". Just to verify, what is possible and not?

I have never imported projects directly from the same version Davinchi Resolve Studio from Windows to macOS, so I'm on shaky ground here, but... have you tried to export the project to drp from the Working Windows 11 machine, then importing the drp project into the macOS version?

Regards

Added 20240501-1550: Ahhh.... I see.... Could this be the problem:

Code: Select all

Scan type                                : Interlaced
Original scan type                       : Progressive
Scan type, store method                  : Interleaved fields
Scan order                               : Top Field First


That's the only important difference I see, so being interlaced could be the issue.
If so, it's clearly a bug, 1080i is a 'legal' format.

I tried rendering the same file to ProRES 4444 With Alpha, but interlaced:

Quick and dirty ProRES 4444 With Alpha interlaced project

Interlaced 2024-05-01 kl. 20.25.13.jpg (594.62 KiB) Viewed 2353 times

No problems. The ONLY oddity I can see in your file is this

Code: Select all

Frame rate mode                          : Constant
---------
Frame rate                               : 29.970 (29970/1000) FPS
---------
Color space                              : YUVA
Chroma subsampling                       : 4:4:4
Scan type                                : Interlaced
Original scan type                       : Progressive
Scan type, store method                  : Interleaved fields
Scan order                               : Top Field First


In rounded figures, this only leaves the equivalent of ~15 "full" frames (bad expression, but you know, what I mean) per second (if I understand interleaved correctly).

If interlacing is not required at all, then why not use progressive 29.970 fps or interlaced 59.940 fps?

I used these settings, and experienced no problems:

Code: Select all

Video
ID                                       : 2
Format                                   : ProRes
Format version                           : Version 1
Format profile                           : 4444
Codec ID                                 : ap4h
Duration                                 : 5 s 0 ms
Bit rate mode                            : Variable
Bit rate                                 : 270 Mb/s
Width                                    : 2 800 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 2.593
Frame rate mode                          : Constant
Frame rate                               : 50.000 FPS
Color space                              : YUVA
Chroma subsampling                       : 4:4:4
Scan type                                : Interlaced
Scan type, store method                  : Interleaved fields
Scan order                               : Top Field First
Bits/(Pixel*Frame)                       : 1.787
Stream size                              : 161 MiB (99%)
Title                                    : Core Media Video
Writing library                          : Apple
Encoded date                             : 2024-05-01 18:16:48 UTC
Tagged date                              : 2024-05-01 18:16:59 UTC
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709


In my case (again, if I understand interleaved correctly), I get 50 half frames per second, somewhat equivalent (in the ol' cathode ray days) to 25 progressive frames (bad expression) per second, but with the benefit of the higher frame rate (especially important for early (color)TV with analogue over the air transmission and limited bandwidth)

The file poses no problems as you can see. And Alpha works too.

Regards

That's a misunderstanding. 29.97 is the number of full frames, composed of two fields.
But, nevertheless, trying a progressive version under identical conditions should reveal if that's the cause.

That's a misunderstanding. 29.97 is the number of full frames, composed of two fields.
But, nevertheless, trying a progressive version under identical conditions should reveal if that's the cause.

Thankyou - good to know.

In effect: The fps specifies the (full) frame rate, where scantype store metod specifies (two) interleaved fields, and the added info is top field first.

Makes sense now.

Regards

Our entire workflow from capture to playout is interlaced, so no going progressive for that.

I've used the clips in both macOS and Windows in separate projects, as well as hosted through Project Server, where I can access the same project from multiple computers. There's no exporting of projects involved in this.

Because I've done it both these ways, it's not the project that's the issue.

When I'm back in the office, I'll see if I can share one of the clips on here. What's the best way to host it?

Our entire workflow from capture to playout is interlaced, so no going progressive for that.

I've used the clips in both macOS and Windows in separate projects, as well as hosted through Project Server, where I can access the same project from multiple computers. There's no exporting of projects involved in this.

Because I've done it both these ways, it's not the project that's the issue.

When I'm back in the office, I'll see if I can share one of the clips on here. What's the best way to host it?

If you have Google Drive or iCloud you can upload and share the file.

You use the setting, that all who has the link can ONLY download or see the file, NOT edit, comment or otherwise affect the system. Test before you send the link. Ideally on Chrome or Firefox without automatic login (if you use Safari as default). If you're asked to login, you need to adjust settings to "anyone with the link" can download. It happens to everybody, but if you do not know, it's hard to spot the problem.

When the file has been "shared", that way, you enter the "admin" settings, and re-check conditions, and copy the link to your editor, and post that link copied into to your message in the forum for interested parties. If you set a "download before date", we all know, when the file will be unavailable or deleted again. Just a practical measure. A week will often suffice. If someone discovers the link after a month, it probably will be of no importance to you.

The iOS interface is a bit "kludgy" in my view, but it works, and is integrated into the macOS finder (in a somewhat non obvious manner as is usual with modern Apple). At least since macOS 14 (Sonoma) and iOS 17.

The Google Drive interface is my favorite (even running macOS), since any browser on any platform can be used; you just need web access, not the full iCloud access. I have maintained a small but free Google Drive partition since it became available a looong time ago. Used for this purpose alone.

Regards

Here's one of the clips: https://drive.google.com/file/d/1UBVZJk ... sp=sharing

If it's meant to have alpha at the beginning and the end, it looks perfectly normal to me.
Sorry, but I'm not going to install Sonoma as long as I can avoid it.

Alpha_Test.jpg (859.56 KiB) Viewed 1948 times

If it's meant to have alpha at the beginning and the end, it looks perfectly normal to me.
Sorry, but I'm not going to install Sonoma as long as I can avoid it.

I'm with Uli on that.

Well, we've established there's nothing wrong with the clip, which I knew anyway. So has anyone else got Sonoma and are able to confirm that there's a problem? Is it a Sonoma issue, or a DR issue?

Unfortunately the computer came with Sonoma, and there's no way I'm going to downgrade it now (if it's possible) because we've got too much set up on it.

Being M2, your computer can still run under Ventura. So, as long as nobody with similar hardware is going to test your clip under Sonoma, you could make an external boot system with Ventura and try from there.

Here's one of the clips: https://drive.google.com/file/d/1UBVZJk ... sp=sharing

I have played a bit with the file, and in both FCPX (10.7.1) and Resolve Studio (18.6.6) I see the same problem with your file. And depending on settings in motion, I can "control" the outcome on my 4444 with Alpha render (se example later in text).

My 4444 with Alpha original file has specifically been produced with these settings in motion:

Transparent background

Transparent 2024-05-06 kl. 09.17.16.png (41.41 KiB) Viewed 1889 times

I have different options, where a background color is defined as "solid" in:

Solid background

Solid 2024-05-06 kl. 09.49.58.png (50.79 KiB) Viewed 1889 times

And when I combine “kuddibras” (transparent alpha channel), your 4444 (solid alpha channel???) and my “kuddibras” (solid Alpha channel) I get this result:

Example reproducing the behaviour

transparent-solid-solid 2024-05-06 kl. 09.30.28.png (927.87 KiB) Viewed 1889 times

Each “overlay is placed into ⅓ of the total frame (1280 pixel) by cropping the first example (transparent Alpha) 0 left and 2560 right, your example 1280 left and 1280 right, and my solid background color 2560 left and 0 right.

I’m not going to say, what is right or wrong or how things should be, but it is clear, that if the background is rendered as transparent, there is no Alpha problem, whereas if the background is rendered as solid, there is an Alpha problem. Whether it is a case of “strict interpretation” (previous behaviour “only” convention) or “wrong interpretation” (previous behaviour correct) in Sonoma may require the study of the actual technical reference on ProRES 4444 including all comments and amendments over the years.

Not my task to be referee or even judge here. I can only say, that I can reproduce the problem, and I can render identical media with different Alpha behavior, depending on background being defined as solid or transparent.

When working in Resolve, I can remove the BLUE background in Delta-keyer, but since I have NO original render (some image, with the 4444 with Alpha overlay), that demonstrates the intended outcome, I’m guessing here, and cannot know, if I get the actual and intended outcome in Sonoma.

Could probably also be done in FCPX - just haven't tried.

Regards

Isn't that just Apple-speak for straight vs. premultiplied?

Isn't that just Apple-speak for straight vs. premultiplied?

Solid background implies alpha is forced to 1.0 everywhere, making background "solid", "not-see-through", "not transparent". Premulted vs straight only affects blending, wrong interpretation either produces darkened semitransparent areas (double multiplication) or brightened (due to additive effect). It will not make transparent bg opaque and vice versa, to have that happen, alpha channel must be not used at all or it already has to have values forced to 1.0.

Isn't that just Apple-speak for straight vs. premultiplied?

I don’t know!

I can ONLY show the options with associated explanations, and then document the outcome.

I distinctly have the impression, that “Apple-speak” is a more - ahem - flexible term, sometimes even depending on the mood and press of the day before

Re Sonoma: Don’t install.

The predecessor was “near hell” in some respects (acceptable and necessary trade off to lay hands on Apple Silicon). Sonoma is “pure hell”; Apple demonstrating similar approach to quality control as Boeing in order to please stockholders. Apples recently announced 110 “gazillion” stock buyback may have been better invested in development and quality control benefiting stock holders far more in the long run.

Both Sonoma (MacOS 14.4.1 currently) and iOS 17.4.1 are pure g**b*g* in my personal view.

I’ve been on Windows since 3.0 (even PC/MS-DOS) and compared to the worst seen on that OS, Sonoma is fully capable of demonstrating, that worse I possible (who’d have “thunk”, that TimeMachine should still be that unreliable after so many updates;-) The iOS 17.4.1 is - maybe - not worse (both version 17.4.1 (21E236) and the version 17.4.1 (21E237), that was realeased the next day - as far as I remember). Your version may differ, and the “237” version is not “naturally visible” for download if you have “236” (you can download “manually” via Finder, if you just ignore Apple’s statement, that you’re fully updated, if you want a few different shortcomings relative 236

No Android version (Since my first Samsung Note (zero) around 2012, has been that flaky

Sonoma was my “Boeing moment”

As always YMMV!

Regards

I'm so glad I can still run Monterey!
Regarding stock holders: those who gamble with heaps of money are not interested in long term outcome. They don't even care if the company ceases to exist once they sold their stock. "Sell in may and walk away."
It's the small guys who get hurt, believing that stocks may secure them some income in old age…

I've tried this approach on the supplied media:

viewtopic.php?f=21&t=41654#p240691

First node "extracts" the "key" output to "RGB" in the second node.

First my file rendered in "standard" fashion from Apple Motion (newest, current version):

The "kuddibras" file rendered in Motion with "transparent background" to ProRES 4444 with Alpha

Skærmbillede 2024-05-06 kl. 14.34.56.png (113.03 KiB) Viewed 1774 times

Second your file submitted above:

Your file assumed rendered to ProRES 4444 with Alpha

Skærmbillede 2024-05-06 kl. 14.08.05.png (113.21 KiB) Viewed 1774 times

Whatever has gone wrong here, to me - and Resolve 18.6.6 - it looks as if, there is no Alpha "key" in your file, but only a "solid" background.

I'm not able to do more checks (I have tried a few "non-standard" tools, with the same result, but since I cannot verify their approach... they're left out).

BUT.... if you have access to a Resolve version NOT installed on Sonoma, you could try the same set of nodes in that version, and post the result here.

I also - in shear panic - tried to kick your file through Apple Compressor requisiting delivery with ProRES 4444 Alpa (inheriting ALL your input file specs as "automatic" settings), and output contained no "Alpha" as far as I could determine (not sent through above "test" node set). This may - of course - be caused by the Apple codec in Sonoma - I have no way to avoid that in Sonoma (unless someone can send me a NATIVELY rendering "app" I could use in Sonora;-)

We're down to, that the Sonoma codec intreprets your file as containing - in effect - no "key", but a solid Alpha background. For whatever reason. I cannot find the link again, and I will not use more time on this, but I have weeks or months ago read a thread "somewhere on the web" (no clue whatsoever anymore), that stated that ffmpeg in one version or other, with a certain set of parameters, delivered what I construed to be "solid" Alpha, and the post included a set of parameters, that would avoid this side effect.

Regards

I'm so glad I can still run Monterey!
Regarding stock holders: those who gamble with heaps of money are not interested in long term outcome. They don't even care if the company ceases to exist once they sold their stock. "Sell in may and walk away."
It's the small guys who get hurt, believing that stocks may secure them some income in old age…

There are lot's of people experiencing the problems first hand. Not all of the problems, and depending on use (simple telephone, notebook, calendar and web browser) seldom experiencing much untoward.

This link at least indicates, that Apple may have sudden, unscheduled (?), periodic problems seen from some users: https://www.macrumors.com/2024/04/27/ap ... out-users/

I would not like to be - for instance - on vacation in Tokyo, and suddenly not having access to most vital info (like credit cards, ID's, boarding cards, flight plans, activity tickets, calendar and contacts, one time passwords invalidated etc.). My mail is hosted "outside" the "the big guys" on my own(ed) domains. At least that has always worked

The above thread made me decide, that I would take my time to migrate away from dependance on the "walled garden" controlled by Apple and delivered as iCloud in an orderly and safe manner (first action was to establish a "secure share" called "iClout". Now in daily use

My existing Samsung Android is coming back to use (replacing my iPhone 12 Pro as travel backup). It has "flexibilities", that are not present inside "the walled garden".

It may not be safer - per se - but the mounting numbers of Apple hiccups in recent months, has made me wary of placing so to say "both my eggs" in one basket

Please note, that I do NOT recommend ANYONE to do ANYTHING. I'm just describing MY PERSONAL DECISION. As always: YMMV!

Regards

Back to the subject at hand: the supplied test sample definitely has alpha and it works.
I can put it on the upper track, both in a progressive timeline or an interlaced one, and it superimposes the lettering at the beginning and the end.
This is under Ventura, which I only installed being forced by an important software I use. DR is still running fine under Monterey, even the beta.

Back to the subject at hand: the supplied test sample definitely has alpha and it works.
I can put it on the upper track, both in a progressive timeline or an interlaced one, and it superimposes the lettering at the beginning and the end.
This is under Ventura, which I only installed being forced by an important software I use. DR is still running fine under Monterey, even the beta.

Did you try the “two nodes” approach?

Just to make sure, that it is actually usable (even if dependent on available and used codecs)?

I can easily accept a Sonora problem, and I will have one last look at my Resolve Studio 18.6.6 on my Windows critter, to see what gives (both overlaid on the same base ProRES file and the dual-node setup pinched from another post in the forum as well).

Later today (EU evening time)

Regards

Tested on my old Windows 10 (22H2) Pro Asus Business machine
Resolve Studio 18.6.6 Build 7. (Same as Mac version)
Windows ProRES codecs installed recently (less than a month ago)

The ProRES 4444 file downloaded, contains alfa. No doubt about that.

The dual Node approach used earlier also confirms the presence of alfa.

Conclusion

Windows 10 (22H2) Pro Platform (fully updated)

1. IF the Apple ProRES codecs for Windows are used by Resolve Studio, they are working.

2. The Resolve Studio works as expected on my Windows 10 platform with the given files.

Sonoma 14.4.1 Platform (fully updated - sigh may have one or a combinations of these problems

1. There may be a problem handling ProRES 4444 with Alpha on Sonoma 14.4.1 (I have no access to other versions on my three Macs).

2. The ProRES 4444 with Alpha codecs on Sonoma 14.4.1 may have a bug, IF deviating from the Ventura or Mavericks versions and deviating functionally from the Windows codecs.

3. Resolve Studio 18.6.6 Build 7 may exhibit problems (“cooperative difficulties”) on the Sonoma 14.4.1 platform.

4. Both codecs and Resolve may have catched the “Sonoma side effects disease”.

Initially I assume, that the codecs used on Sonoma, Ventura and Mavericks are more or less identical (also functionally identical to the codecs available for Windows).

Regards

Here's one of the clips: https://drive.google.com/file/d/1UBVZJk ... sp=sharing

Hi, I'm here with a 16-inch MacBook Pro, Intel 8-core i9 processor, and running macOS Sonoma 14.4.1. I just downloaded the APR4444 file, dragged it into a new, empty DaVinci Resolve 19b2 project, added a color bar underneath and the alpha channel seems to work. The beginning and end of the clip also have transparency.

Timeline 1_01_00_01_17.png (698.13 KiB) Viewed 1628 times

Here's one of the clips: https://drive.google.com/file/d/1UBVZJk ... sp=sharing

Hi, I'm here with a 16-inch MacBook Pro, Intel 8-core i9 processor, and running macOS Sonoma 14.4.1. I just downloaded the APR4444 file, dragged it into a new, empty DaVinci Resolve 19b2 project, added a color bar underneath and the alpha channel seems to work. The beginning and end of the clip also have transparency.

Timeline 1_01_00_01_17.png

Interesting. I'm using the Apple Silicon M1 Pro 10 CPU 16 GPU chip with Sonoma 14.4.1, and that leads to a problem with ProRES 4444 Alpha channel. Also on FCPX 10.7.1. Do you have a chance to test, if FCPX handles Alpha differently on Intel silicon?

I have an old Intel based MacBook Pro 13 (4 thunderbolt), that is still supported, but I'm not too keen on moving my Resolve Studio license to that one (it's very "weak-breasted"

Anyone else using Sonoma 14.4.1 or FCPX on Intel silicon?

Might be interesting, if the problem is not present on Intel based gear.

Regards

Addendum: I've just tested a cleanly created project on FCPX on my Intel MacBook Pro 13. There is NO problems with ProRES 4444 with Alpha on the Intel critter (same versions of FCPX and Sonoma).

Here's one of the clips: https://drive.google.com/file/d/1UBVZJk ... sp=sharing

Interesting. I'm using the Apple Silicon M1 Pro 10 CPU 16 GPU chip with Sonoma 14.4.1, and that leads to a problem with ProRES 4444 Alpha channel. Also on FCPX 10.7.1. Do you have a chance to test, if FCPX handles Alpha differently on Intel silicon?

Addendum: I've just tested a cleanly created project on FCPX on my Intel MacBook Pro 13. There is NO problems with ProRES 4444 with Alpha on the Intel critter (same versions of FCPX and Sonoma).

Same here, no problems with the APR4444 test material in FCPX on an Intel MBP with Sonoma 14.4.1:

FCPX_alpha_test.png (959.87 KiB) Viewed 1604 times

Thanks guys for all the tests.

It seems clear to me, then, that this is a problem with the ProRes codecs on macOS Sonoma running on Apple Silicon interpreting the alpha channel in the clips.

Is it an ffmpeg encoding compatibility issue? I'll try running those clips through Compressor on a different Mac or on Windows through Media Encoder and see what happens. I'll report back when I'm done.

Ok, here's the update.

I ran the clip through Adobe Media Encoder on a Windows PC. The alpha now works on Sonoma on Apple Silicon. So it must be an issue with how FFMPEG is doing the alpha, and while it works on most platforms, it doesn't work on Sonoma running on Apple Silicon.

While having to run everything I export out of XPression now through Media Encoder is inconvenient, maybe that's what I'll need to do, while also testing newer FFMPEG releases.

I guess this has been solved then.

New version of FFMpeg fixed the problem apparently.

I can confirm such issue did exist, I had big presentation in keynote developed on rosetta based M2 and a few alpha channel based qt4444 rendered via ffmpeg none of these did work on the show macbook sonoma m3 although there were no problems with older os. Had to reconvert (from the not working qt4444) in adobe media encoder on mac and they became usable.

Good news is I just tested new version of ffmpeg and it seems to work ok.

New version of FFMpeg fixed the problem apparently.

I can confirm such issue did exist, I had big presentation in keynote developed on rosetta based M2 and a few alpha channel based qt4444 rendered via ffmpeg none of these did work on the show macbook sonoma m3 although there were no problems with older os. Had to reconvert (from the not working qt4444) in adobe media encoder on mac and they became usable.

Good news is I just tested new version of ffmpeg and it seems to work ok.

Thankyou for the feedback. Always good to know!

Regards

I tested the 1080i PR4444 "Learn More" clip on Resolve 18.6.6 and Sonoma 14.4.1 on an M1 Ultra and on a 2017 iMac 27 on Ventura 13.6.6. In neither case did the blue background show transparency during "normal" blend mode. FCP 10.7.1 behaved likewise.

I then used the datascope in the third-party QCTools utility (see attached): https://mediaarea.net/QCTools

I don't see the correct hex values for alpha-channel transparency.

At that point of the video it's supposed to be 100% opaque. You need to check the start and end of the clip. It's a transition.

EDIT: I just tried it in datascope and there's definitely correct alpha in the parts that are meant to be transparent.

Hi James,

This is the problem with old ffmpeg qt library <-> sonoma compatibility/interpretation, as mentioned earlier new ffmpeg version has this issue corrected.

I am using ffmpeg to convert exr sequences on daily basis, had this problem just with sonoma based macs.

At that point of the video it's supposed to be 100% opaque. You need to check the start and end of the clip. It's a transition...

Thanks, I confirm the alpha-channel data is OK (meaning high-transparency) at the start/end of the clip.

This is not a Resolve problem. FCP 10.7.1 behaves exactly the same as Resolve Studio 18.6.6 on Sonoma 14.3.1 on Apple Silicon. Both FCP and Resolve behave OK on Ventura 13.6.6 x86.

It might be a system-layer MacOS bug, or there could be something illegal about the clip's encoding which is causing this.

At that point of the video it's supposed to be 100% opaque. You need to check the start and end of the clip. It's a transition...

Thanks, I confirm the alpha-channel data is OK (meaning high-transparency) at the start/end of the clip.

This is not a Resolve problem. FCP 10.7.1 behaves exactly the same as Resolve Studio 18.6.6 on Sonoma 14.3.1 on Apple Silicon. Both FCP and Resolve behave OK on Ventura 13.6.6 x86.

It might be a system-layer MacOS bug, or there could be something illegal about the clip's encoding which is causing this.

The problem exists on Sonoma 14.4.1 on Apple Silicon only. Both Resolve Studio 18.6.6 and FCPX 10.7.1.

File start: 10:17:28:22, position 10:17:29:00 on Apple MacBook 14 Pro M1 Pro

Skærmbillede 2024-05-08 kl. 19.12.32.png (480.13 KiB) Viewed 966 times

File start: 10:17:28:22, position 10:17:29:00 on Apple MacBook 14 Pro M1 Pro

File start:10:17:28:22, position 10:17:29:00 on Apple MacBook 13 Pro Intel 4 Thunderbolt

Skærmbillede 2024-05-08 kl. 19.32.41.jpg (571.78 KiB) Viewed 966 times

File start:10:17:28:22, position 10:17:29:00 on Apple MacBook 13 Pro Intel 4 Thunderbolt

Both examples on Sonoma 14.4.1 and FCPX 10.7·1 .

Problem does not exist on Windows 10 with Resolve Studio 18.6.6 and identical files/project setup.

It's interesting to know, that the problem is fairly recent (not existing on your Sonoma 14.3.1).

Regards

I confirm this also happens on Premiere Pro 24.3.0 on Sonoma 14.4.1 Apple Silicon, likewise if transcoding using EditReady 24.2.

However -- this is only if using the original "Learn More" 1080i/29.97 file, which was generated using a certain version of ffmpeg, and it does not happen using a newer version of ffmpeg.

Do we know anything about what version of ffmpeg was used to create the problematic file, and what newer version of ffmpeg generates files that don't cause this behavior?

I confirm this also happens on Premiere Pro 24.3.0 on Sonoma 14.4.1 Apple Silicon, likewise if transcoding using EditReady 24.2.

However -- this is only if using the original "Learn More" 1080i/29.97 file, which was generated using a certain version of ffmpeg, and it does not happen using a newer version of ffmpeg.

Do we know anything about what version of ffmpeg was used to create the problematic file, and what newer version of ffmpeg generates files that don't cause this behavior?

Correct. And the generating ffmpeg was probably “flawed” or “sensitive” to various outlying cases or interpretations of 4444 with Alpha.

This does not however explain, that identical files behave civilized on Intel silicon (same version software, OS and codecs) compared to Apple Silicon. That is the real puzzle.

Regards

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.