Final Cut Pro 10.8.1 - problem with HDR videos since upgrading to MacOS Sequoia

Hi Clint. I typically edit and export in HLG but switching to PQ partially fixes the issue. The clips display properly in the viewer when I hover over them in the timeline, but they display dark in the browser and viewer when I hover over them in the browser. This makes marking in/out points difficult because the viewer displays the clip at like 10 nits, but I can work with it.

@PF_Productions, IAmSkippermark and I above described your scenario. I said: "when the MacBook Pro detects the TV is connected via HDMI, it handshakes and this somehow restricts the FCP viewer from displaying HDR in the MacBook Pro XDR screen or the HDMI-connected TV. But it does not affect Quicktime Player display of HDR/HLG content on either MacBook display or the HDMI-connected TV."

We clearly stated it is FCP only. That is why IAmSkippermark questioned Apple: "does that mean that Final Cut Pro cannot be used with a third-party monitor?" Previously in this thread, he reported: "I use an external monitor and it gets HDR from the M1 from everything via the HDMI port EXCEPT FCPX!...the monitor I'm using will show HDR photos, etc, just nothing out of FCPX via the M1's HDMI port."

We first thought it was HDMI only because it tested OK with SDI monitors, but AlainBE said it happens in FCP on his LG 40WP95C-W Thunderbolt 4 monitor. That may be because there are few non-Apple Thunderbolt monitors and those Skipper and I tested were Apple.

IAmSkippermark: I don't want to spend hours (or days) debugging FCP with XCode, but if they are not being responsive, let me know, and I'll try to isolate what framework, class and method is responsible.

Thanks for the update! I've been editing in PQ since the HLG issue popped up. Clips are still dark in the viewer when hovering over them or marking in/out points in the browser, but once they're in the timeline, they work as expected. This makes editing in HDR possible if you're willing (and allowed to by a client or what-no) to work with a PQ project.

With the Display setting on extended, in FCP go to to Window>Show on Secondary Display>Viewers.

So the thing to figure out is if it's how your Mac is communicating with your specific monitor or if it's a general problem that applies to all HDR . This seems unlikely or there would likely be loads of posts about it. I've not installed Sequoia yet and don't intend to for a while so can't test directly. I will try installing it on an external drive later to check it out on my MacBook Pro XDR monitor to see if I am getting the same issue

Anyway I'm not entirely clear what is happening but you seem to be saying that Quicktime Player shows the original clips as HDR but the clips rendered by FCP are not showing as HDR either in FCP or Quicktime. When you have clips opened in Quicktime and open the Movie Inspector, Video Details, Code Points what numbers do you see for the original clips and those rendered as HLG by FCP. For HLG HDR you should be seeing 9-18-9 tags.

That's exactly my point Tom, it won't show as HDR out of FCPX from the HDMI!!! I have it set as extended display. And then in FCP I always use that for just the program output. Has worked perfectly since I got the M1 MAX. Now it won't output HDR in FCPX to the monitor. It used to, now it doesn't! All I did is upgrade to Sequoia. When it's being used as an extended display in any other mode (editing photos in lightroom, showing a mirror of my display etc.) it outputs in HDR as I showed in that photo where it says "HDR".

I appreciate your interest in this, but I've troubleshot it for hours and it's just not working in FCP to output an HDR signal over the built in HDMI on the M1 Max with Sequoia.

I know I'm super late to these posts, but the issue does seem to be related to how the Mac is communicating to external monitors. I replied to one of your other posts, and the issue occurs on my M1 desktop when tested on 4 different monitors connected directly to the HDMI port, but I couldn't duplicate the issue at an Apple Store using their demo Mac mini or Mac Studio hooked up to the Mac Studio monitor via USB-C at an apple store. They don't have the XDR on display, so I couldn't test that.

My M1 laptop displays correctly on the internal HDR display in all modes (HLG & PQ), but it acts the same as the desktop when hooked up via HDMI to any of the 4 monitors I tested with. Unfortunately, none of the monitors I tested support USB-C connections, so I couldn't test with different connections.

Oh, no. I don't have a contact at Apple. I just reached out to the support team through the Apple website support page located here:

Final Cut Pro - Official Apple Support

I think it would be good for others to contact them too so they know it's not just an isolated case. My guess is only a small percentage of users edit in HDR, so the issue we're experiencing probably doesn't come up very often.

I'd suggest contacting them through their official contact page I posed above (or search for Final Cut Pro Support) if you don't like to click unknown links. If you call, you'll probably end up at with the Mac support team (this always happens to me for some reason), and they'll transfer you to the FCP team.

The email I received was pretty generic and said, "Thanks for your patience. I’m still waiting to hear from our engineers about your case. As soon as I receive a response, I’ll email you to coordinate a good day and time to call."

I ended up calling support today to see if there was an update and let them know the issue still exists in FCP 11. The person I spoke with (different person than the person I spoke to before - they can't transfer you to a specific advisor) saw all the notes and said they updated them so the engineers know about FCP 11. They're just waiting on the engineering team to get get back to them with an update, which can take some time.

I've contacted Apple support a few times before, and they are actually very good about getting back to you once they know something, so if I get any updates, I will be sure to update it here.

To keep things simple, I have been using HDR footage from the iPhone, but it does happen with all footage from any camera.

The issue isn’t with the exported projects. It’s a display issue inside the app, where the clips appear dark in the viewer. Exported projects display correctly, even if you can barely see them on the screen to edit them.

When working with an HLG project, hovering over a clip in the browser or the timeline, it appears dark in the viewer.

When working with a PQ project, the clips appear dark in the viewer when hovering over them in the browser, but they display correctly in the viewer once added to the timeline.

The issue appeared immediately after upgrading to Sequoia and opening a project that worked perfectly in Sonoma, and they continue to work correctly on non-Sequoia machines, even if the monitor is the same as the one on the Sequoia machine. That’s what makes me think it’s an OS issue and not an FCP issue.

I’m the opposite of you. I don’t have any monitors that support Thunderbolt/USB-C, but I went to an Apple Store and tested on the demo machines hooked up to a studio monitor, and didn’t have the issue.

At home I tested on several HDR monitors ranging from a low quality gaming monitor to an Atomos Shinobi 7-Inch 4K HDMI HDR monitor, an LG C3 and a borrowed Flanders Scientific XMP310, all hooked up via HDMI. All except the gaming monitor have been calibrated and are using the calibrated profiles. Normally the Flanders is used with an UltraStudio 4K Mini, but for the sake of testing I hooked it up directly to the Mac’s HDMI.

I hope I explained this OK. It’s kind of hard to write it out to be easily understandable. When I called Apple support, they didn’t even know about HDR footage and kept calling it HGL instead of HLG, and the support rep said I was teaching them things they didn’t know about.

After my post last week, I've spoken with support a couple more times, and they asked if I could send in some quick details of what others here in the forum are experiencing, along with the model of their monitor, Mac, connection type (Thunderbolt/HDMI...) and a little about the Library/Project type and the video/clip type (iPhone HLG, etc...). They prefer the issue to be happening with iPhone footage since it's their own product.

Support wants to show engineering the issue is happening to more people than me alone, and the more examples they have, the more they might try to fix it.

Also, if you haven't contacted support about this, please do so. Hearing from others helps them know it's a real issue and not just a fringe issue affecting a small minority.

I WILL NOT include your username or any personal info, just the info about the problem.

I'll give it a few days for people to post their info and then send an email to support on Thursday, 1/16/25 at 10AM EST.

For me, I'm including this in my reply. Feel free to copy my "template" and just change any relevant info.

ISSUE: In an HLG project, all clip types (Rec.709, HLG, PQ) appear dark in the viewer when hovering over them in the browser and timeline. In a PQ project, the same clips appear dark in the viewer when hovering over them in the browser, but they appear correctly in the viewer when hovering over them in the timeline.

MACOS VERSION: Sequoia 15.2

FCP VERSION: 11.0

MACHINE: M1 Mac mini

CONNECTION TYPE: HDMI

MONITOR: LG C3, 42”, model OLED42C3PUA

ALSO TESTED WITH: Dell S3220DGF, LG 32GS95UE-B and a Sony BVM-X300 (Connected directly to the HDMI port on the monitor - NOT going through a Blackmagic Ultrastudio type device)

LIBRARY TYPE: Wide Gamut

PROJECT TYPE: HLG & PQ

FOOTAGE: Happens with ALL footage types (Rec.709, HLG, PQ) taken with iPhone 13 Pro Max and all other camera brands/models

Thanks!

Mark

A small correction that may be important if this happens to be a bug and you want to report it: in the image where you are showing the washed out image in the tv, it is not used as extended desktop but as "av output".

It seems that perhaps FCP is not sending its AV Output properly as HDR.

Hi - I'm curious. Is the monitor you're using with the Mac mini M2 an Apple monitor? I'm asking because I went to an Apple Store and couldn't replicate the error on the demo Mac mini M2 or the Mac Studio Ultra they had on display. Both were connected to Apple Studio displays via Thunderbolt 4.

My thinking is the issue is happening to all non-Apple displays, no matter how they're hooked up, but if you have an Apple monitor, that theory is out the widow.

From what I've been seeing, people with Apple displays aren't having this issue. Another poster in this thread said they're not experiencing the issue with their XDR display and a MacPro.

AlainBE, thank you, PF_Productions, IAmSkipperMark, Tom, Clint, and Luis *very* much for all your help on this. Re: why it's not sorted out: I don't work for Apple, but I have extensive experience in software testing, development, and escalation support, and I can explain how the system works.

• Usually, nothing will get fixed solely by people talking about it on a forum. From a user standpoint, it feels like you've "reported" it, especially if details are given, but that will not normally result in Apple product support or engineering taking action. With some products, such as DaVinci Resolve, actual developers monitor the forums, but that is rare. There is also a valid argument it's not the best use of a developer's time.
• Posting info on a forum is useful, and the more detail, the better. In this case, several users have collectively posted enough information to broadly understand the overall problem parameters. But took a while.
• There have been numerous situations where users refuse to provide the requested info, such as an EtreCheck report or an error log. This can greatly delay problem resolution.
• For complex hardware/software issues like this case, posting information on the Apple Product Feedback site is OK but will often not produce the desired results. That site allows just 800 characters max input (including spaces) and no ability to attach files, error logs, links, etc. It is simply not designed for that purpose.
• There is an Apple Feedback Assistant app, but it requires a developer account and is generally oriented toward app developers, not end users, and not even sophisticated IT users.
• The best approach for most users is to collect as much info as possible and then contact Apple Support. If the case is escalated, this can include ongoing two-way email discussions whereby you report new findings. I believe this particular case is in that state, and IAmSkippermark is driving this (thanks!)
• If you are an experienced software developer or have done similar work, you can get an Apple Developer account and report the problem, including attachments, logs, and files needed to reproduce the issue. However, this can require lots of work if done properly. When bugs are filed this way and followed up by contacting product support, Apple has been very responsive. See attached for an example of one I filed.

However, there is a good argument that customers should not have to spend hours or days researching a bug. OTOH, those customers may spend hours or days discussing the bug on a forum, so time is being spent anyway. There is no simple solution for this, but it's important for everyone to understand what is required to get a bug fixed.

The fastest way to get a bug fixed is by achieving a specific (ideally portable) reproducible scenario and reporting it to Apple Support by opening a case. The scenario allows engineering to reproduce the problem under a debugger and quickly fix it. It also allows later testing of that scenario to ensure it stays fixed in a new software version.

But it can take lots of time and work to achieve that well-documented, portable replication scenario. When working on critical problems that I or others encountered, I've heard people say "You're doing Apple's work for them." That betrays a lack of understanding about how the system works and how serious some problems are. If not for these efforts, some problems would not be fixed in an expedited time frame, and the cost to some end users could be significant.

Errorlogs and crash logs are useful, but those by themselves may not enable fixing a bug. The underlying technical factors are too complex to explain in this post, but if anyone is interested, I can elaborate in another thread.

Incorporating even a single fix to a complex product requires a full battery of regression tests, stress tests, functional tests, performance tests, localization tests, and security tests, individually repeated on a complex matrix of platforms and configurations. If the fix involves interactions between FCP and MacOS code, it might require a MacOS update, and those have their own schedule. The fastest I've seen Apple implement an FCP fix was about three weeks from the initial report, and that was a highly urgent matter where the release contained only that one fix.

I opened a case the first day the public (not beta) version of Sequoia was available and the problem appeared. Support has been very good, and I've been in frequent contact with an advisor who acts as the middleman between me and engineering.

They ask for something, and I send it to him, and he to them.

I've sent all kinds of system logs, the videos I'm working with, copies of the my projects and so on. When FCP 11 came out and with every update to MacOS, they've reached back out and had me try some things and then ask for more info.

We've done other test like create additional users, and I went so far as to do a complete system format with a fresh download of MacOS, with the only app installed being FCP.

Overall, support has been great, but ultimately, I don't know how big of priority it is. I imagine the number of us who edit in HDR is limited, but I do hope it gets fixed soon.