search

CommandPost / FCPCafe

FCP Cafe Website
https://fcp.cafe
MIT License
27 stars 15 forks source link

10-bit H.264 black clips and timeline export failure with certain formats #119

Open joema4 opened 1 year ago

joema4 commented 1 year ago

Apple Feedback ID: FB12218743

Starting with Ventura 13.4, FCP 10.6.5, 10.6.6 and DaVinci Resolve Studio 18.1.4 and later on Apple Silicon will show black (FCP) or red (Resolve) offline clips for certain codecs. If an FCP timeline contains one of these clips among many other “normal” clips, various export failures can happen. These failure modes can include:

The exact failure mode can vary, but the failure itself is 100% consistent

This FCP error is sometimes seen: "Render job failed as the current clip could not be processed", and "The clip could not be decoded correctly". The export halts at the first XAVC-S clip in the timeline. The material before that point may sometimes be exported or can produce a zero-length file. Export codec type does not matter.

The terminal “log stream” command shows these FCP errors when trying to export the XAVC-S 120 fps clip:

Final Cut Pro: (ProCore) An error was generated when rendering the frame: Error (10005 f)“BlackClip2“ cannot be rendered at 00:00:10:23. Error (-8969): bad data in source file. “JDM0855.mp4“ cannot be decoded at 00:00:10:118.

When trying to export the DJI 5k/23.98 clips, these errors are seen in the log:

Final Cut Pro: (ProCore) assertion failed: newUnmodifiedHGNodeRetPF: Unable to create output node (__null != result) :: -[FFImage(HGNode) newUnmodifiedHGNodeRetPF:retCS:] (file: /Library/Caches/com.apple.xbs/Sources/Flexo/Flexo-40600.302.16/framework/image/FFImageRepHGNode.mm, line: 1940)

Final Cut Pro: (ProCore) assertion failed: newHGNodeInFormat: Unable to create output node (__null != result) :: -[FFImage(HGNode) newHGNodeInFormat:withPT:workingSpace:filterQuality:filterToField:] (file: /Library/Caches/com.apple.xbs/Sources/Flexo/Flexo-40600.302.16/framework/image/FFImageRepHGNode.mm, line: 1859)

Final Cut Pro: (ProCore) An error was generated when rendering the frame: Error (10008): processing frame. “BlackClip2“ cannot be rendered at 00:00:10:23. Error (-8969): bad data in source file. “DJI_0182.mp4“ cannot be decoded at 00:00:10:23.

Study is ongoing but currently-known formats which cause this are:

4k Sony XAVC-S 10-bit 4:2:2, 100 fps or 120 fps DJI 5120 x 2700 10-bit 4:2:0 H264, 23.98 fps or 29.97 fps

See test clips and associated metadata printout of these formats:

https://www.dropbox.com/sh/66ql58c31bdyrfl/AAAt7QEkVMcxzw-IercZ0svPa?dl=0

Machines and versions tested:

Pro Video Formats: 2.2.5

STEPS TO REPRODUCE:

(1) Import test files to FCP on Apple Silicon machine running FCP 10.6.5 or later on Ventura 13.4 (2) Observe clips are black in Event Browser (3) Add clip to timeline and export or export from Event Browser (4) Behavior and failure mode varies based on export type and timeline composition, but it fails 100% of the time (5) Suggest trying both H264 and ProRes 422 exports to see different failure modes

6-9-23:

I tested all combinations of the Mavic 3 codec at 4k and above. This includes UHD 4k, DCI 4k, 5k (5120 x 2700), H264, H265 (HEVC), MOV, and MP4, at all frame rates for each one. This was over 70 combinations. The only ones that failed were 5k 10-bit 4:2:0 H264 (all frame rates, MOV and MP4). See attached table showing metadata for the failed formats. Filename: DJI_Codecs_Tested_FCP_Ventura_13_4_Black_Clip_Apple_Silicon.jpg

All these used the D-Log color profile, for which the Mavic 3 automatically selects 10-bit depth. I spot checked other color profiles and did not see a failure. To test them all would entail hundreds of tests, but I’m fairly confident that for this device it is isolated to the formats shown in the attached table.

This might not be isolated to the Mavic 3 drone, as DJI often uses the same encoder across multiple products. Testing is ongoing. However thus far it has only been reported on Sony XAVC-S 10-bit 4:2:2 at 100 and 120 fps and the below listed DJI formats from the Mavic 3. I plan on testing the DJI Ronin 4D gimbal tonight.

A short DJI clip for each "failed" format is here: https://www.dropbox.com/sh/b9tu3fdq745dx2t/AADXYPZZqEGbJamV5D3WL70ua?dl=0 DJI_Codecs_Tested_FCP_Ventura_13_4_Black_Clip_Apple_Silicon

7-25-23:

Verified the Sony XAVC-S variant of this bug is fixed on Apple Silicon Ventura 13.5 for FCP 10.6.6. The DJI 5.1k variant is not fixed.

joema4 commented 1 year ago

Filed as bug FB12218743 on 1-July 2023 using MacOS Feedback Assistant.

WhiteFoxPictures commented 1 year ago

Any workaround as of now for this bug? Many thanks! Same issue here with Mavic 3 10 bits 5K 50p H264 shots. On Ventura 13.4, FCP X 10.6.6 and Macbook Pro M2 Max. Viewer is black on all Mavic 3 shots. MAJOR SHOWSTOPPER for us here.

joema4 commented 1 year ago

I think it is isolated to 5k (5120 x 2700). It does not happen at DCI 4k (4096 x 2160) or UHD 4k (3840 x 2160). Although seen in FCP it is not an FCP bug, rather a bug in Ventura 13.4. The same problem happens on DaVinci Resolve.

The Ventura 13.4 "black frame" problem was originally and most commonly reported with Sony 10-bit 4:2:2 XAVC-S at 100 and 120 fps. I updated the bug I filed and tried to ensure Apple is aware of it.

An Apple "Carpe Facto" advisor initially called me to discuss the problem. That is a special team that gathers information about urgent problems to expedite an engineering fix. He connected to my machine, gathered debug info, we discussed the problem for 20 minutes. That was right before I saw it on DJI 5k, but I told him we don't know if it is isolated to Sony XAVC-S.

The next day I saw the DJI 5k problem, didn't have his contact info so placed a new support call to Apple. They refused to take any info from me or contact Carpe Facto about the problem, claiming it was a closed issue. I told them I was gravely concerned that the new info about DJI 5k was not known to Apple Engineering and it was vital they be informed. This made no difference to them. I updated my bug report in Feedback Assistant and on github, and posted the DJI details on several FCP forums. Besides calling Executive Relations (which I am considering) that is all I can do.

I have heard the Sony XAVC-S problem has been fixed in Ventura 13.5 beta 2, but I don't know about the DJI 5k problem. If this does not get fixed on DJI because of intransigence from Apple Support, there will be repercussions.

In the meantime you can avoid this by shooting new material at DCI 4k or UHD 4k. For existing 5k material you will have to transcode that using Handbrake before importing to FCP. It is specific to Apple Silicon so Intel Macs on Ventura 13.4 do not experience it.

If it is already imported and edited into a project and you don't have access to an Intel Mac, that is a problem. The only other alternative is revert to Ventura 13.3.1(a).

On Tue, Jun 6, 2023 at 3:20 AM WhiteFoxPictures @.***> wrote:

Any workaround as of now for this bug? Many thanks! Same issue here with Mavic 3 10 bits 5K 50p H264 shots. On Ventura 13.4, FCP X 10.6.6 and Macbook Pro M2 Max. Viewer is black on all Mavic 3 shots. MAJOR SHOWSTOPPER for us here.

— Reply to this email directly, view it on GitHub https://github.com/CommandPost/FCPCafe/issues/119#issuecomment-1578161448, or unsubscribe https://github.com/notifications/unsubscribe-auth/APRV3AR7GV375HV52G7YDDLXJ3R4TANCNFSM6AAAAAAYXRXGEY . You are receiving this because you authored the thread.Message ID: @.***>

joema4 commented 1 year ago

I am re-testing all permutations of 4k, C4k and 5.1k from the Mavic 3. I think there are some 5.1k options which bypass the problem, but I have a total of 50 files to check so it will take a while. I also need to check similar material from our DJI Ronin 4D. We always shoot ProRes but lots of users don't, so the H264/H265 from that camera is a possible concern.

Here is another complication I just noticed today: if an import contains just one of the "problem" files, then you attempt to create proxies or optimized media or do so as part of import, various worker threads in FCP will deadlock in a wait condition.

The UI does not hang, the background task icon gets stuck on a dark color, neither finished or busy. Attempting to delete clips causes the error "Final Cut Pro cannot move media to Trash. One or more media files are in use and can't be moved to the Trash while Transcoding Clip is in progress. Use the Background Tasks window to monitor or cancel the task, then try again". I'm still studying the condition that creates in FCP.

I will try to have this mapped out by tonight and will update the bug report.

latenitefilms commented 1 year ago

Thanks for all the detailed information in this thread! I'll make sure the Final Cut Pro team are aware of this GitHub issue.

latenitefilms commented 1 year ago

FWIW - I've been reassured Apple is actively investigating this.

joema4 commented 1 year ago

I just finished testing all permutations of resolution, frame rate, container and codec on D-Log (78 total). I did spot testing of non-D-Log profiles and I don't think any of those are affected. Reason: the Mavic 3 automatically uses 10-bit encoding when color profile is switched to D-Log. For all other profiles it is 8-bit. Below is a table of the ones that failed. Anything not on this table should work (including some 5k formats). If you hear otherwise, please report that. I will update the bug report shortly.

https://joema.smugmug.com/DJI-Black-Clip-Problem-on-Apple-Silicon-FCP-and-Ventura-134/n-MqkcqR/

joema4 commented 1 year ago

I updated the bug report, also the corresponding bug report FB12218743 in MacOS Feedback Assistant. Samples of all currently-known "failed" DJI files are here: https://www.dropbox.com/sh/b9tu3fdq745dx2t/AADXYPZZqEGbJamV5D3WL70ua?dl=0

joema4 commented 1 year ago

Last night I tested eight H264 codec variants from the DJI Ronin 4D gimbal, and they all worked OK. However none of them were over 4k resolution or over a 60 fps frame rate, so I did not really expect them to exhibit the "black clip" behavior. We always record 6k ProRes 422HQ on the Ronin 4D, so testing the H264 codecs was just to improve coverage.

hexeric commented 1 year ago

I updated the bug report, also the corresponding bug report FB12218743 in MacOS Feedback Assistant. Samples of all currently-known "failed" DJI files are here: https://www.dropbox.com/sh/b9tu3fdq745dx2t/AADXYPZZqEGbJamV5D3WL70ua?dl=0

confirm these files do not work! they also do not open in QT which means: AVfoundation mess-up

also happens to SOME of my HEVC 10bit (422) clips in 4K from DJI and SONY alike! non-LOG but re-importing and replacing them solves the issue. tedious but fixable. they do open in QT though, just FCP sometimes 'forgets' them

WhiteFoxPictures commented 1 year ago

Anyone has any update on this or is in contact with Apple? Updated to Ventura 13.4.1 with no change on the issue. Many thanks!

joema4 commented 1 year ago

Beta testers report it is fixed in Ventura 13.5 beta 3, so we expect it will be in the final 13.5 release. I don't know when that is. The last Ventura 13.5 developer beta 3 was released June 15, and oftentimes the public beta shortly follows a given developer beta release.

13.4.1 was strictly a critical security update, so did not contain any other improvements or fixes.

The problem is apparently related to hardware-accelerated decode on Apple Silicon, or the frameworks which support that. It is not an application bug in FCP or Resolve. On Resolve it's possible to fully disable hardware acceleration which avoids the problem (at a performance cost).

I think at one time there might have been a terminal defaults setting which would disable Metal or video acceleration on Final Cut but apparently it no longer exists or works.

-- Joe Marler

On Tue, Jun 27, 2023 at 8:32 AM WhiteFoxPictures @.***> wrote:

Anyone has any update on this or is in contact with Apple? Updated to Ventura 13.4.1 with no change on the issue. Many thanks!

— Reply to this email directly, view it on GitHub https://github.com/CommandPost/FCPCafe/issues/119#issuecomment-1609514374, or unsubscribe https://github.com/notifications/unsubscribe-auth/APRV3AWQIZ25WFZOICDG5VTXNLOFLANCNFSM6AAAAAAYXRXGEY . You are receiving this because you authored the thread.Message ID: @.***>

joema4 commented 1 year ago

I verify the Apple Silicon 10-bit XAVC-S 100/120 fps issues are fixed in Ventura 13.5 on FCP 10.6.6 and Resolve Studio 18.5.

Unfortunately the similar DJI 5.1k H264 10-bit 4:2:0 issues (all frame rates) were not fixed. They still show as black clips on Apple Silicon Ventura 13.5 in both FCP 10.6.6 and Resolve 18.5.

latenitefilms commented 1 year ago

@joema4 is this now fixed in macOS Ventura 13.5.2?

joema4 commented 1 year ago

Unfortunately, the "black clip" problem on DJI 5k 10-bit 4:2:0 H264 DLog (all frame rates) is not fixed on Ventura 13.5.2 for either FCP 10.6.8 (using Pro Video Formats 2.2.6) nor for Resolve Studio 18.5.1. That is on an M1 Ultra Mac Studio.

On Mon, Sep 11, 2023 at 5:33 PM Chris Hocking @.***> wrote:

@joema4 https://github.com/joema4 is this now fixed in macOS Ventura 13.5.2?

— Reply to this email directly, view it on GitHub https://github.com/CommandPost/FCPCafe/issues/119#issuecomment-1714673856, or unsubscribe https://github.com/notifications/unsubscribe-auth/APRV3AQDGVUCRHLOU7J6JULXZ6GUNANCNFSM6AAAAAAYXRXGEY . You are receiving this because you were mentioned.Message ID: @.***>

hexeric commented 1 year ago

works on sonoma beta

WhiteFoxPictures commented 1 year ago

Just updated to SONOMA, on a Macbook Pro 23, M2 MAX, FCP 10.6.9, and still same problem with H264 5.1K DLOG DJI files coming from MAVIC 3.

beardoswaggins commented 1 year ago

@WhiteFoxPictures just tested several files formats on the MAVIC 3 in Sonoma: 5.1K D-LOG 50p H.265 in .MOV works, C4K D-LOG H.265 .MOV works while the H.264 in the .MP4 bucket does not. 5.1K D-LOG H.264 in .MP4 does not work either. It appears to be tied to the compression and file format. Hope that helps.

This has been absolutely catastrophic for us as well and had an even more interesting issue with FCP crashing hard at the height of the problem over a month ago with external RAID drives connected containing the MAVIC 3 footage files. When rebooted those files that were in the project file within FCP now showed as 0kb in the hard drives. A very unfortunate circumstance. After two weeks with a HDD recovery company we were able to get the files manually rebuilt from a fractured file structure. So be warned if you are using a RAID to back-up and edit from as we were. The client was at least understanding in the matter.

Apple needs to fix this as we still have a lot of 5.1K H.264 footage to contend with and that leads me to a question: Does anyone know of a consistent and safe method to convert the H.264 footage to H.265 without losing too much exposure, colour and temp data?

Thank you to all who diagnosed this issue, this thread has been a godsend for our sanity!

WhiteFoxPictures commented 1 year ago

@WhiteFoxPictures just tested several files formats on the MAVIC 3 in Sonoma: 5.1K D-LOG 50p H.265 in .MOV works, C4K D-LOG H.265 .MOV works while the H.264 in the .MP4 bucket does not. 5.1K D-LOG H.264 in .MP4 does not work either. It appears to be tied to the compression and file format. Hope that helps.

This has been absolutely catastrophic for us as well and had an even more interesting issue with FCP crashing hard at the height of the problem over a month ago with external RAID drives connected containing the MAVIC 3 footage files. When rebooted those files that were in the project file within FCP now showed as 0kb in the hard drives. A very unfortunate circumstance. After two weeks with a HDD recovery company we were able to get the files manually rebuilt from a fractured file structure. So be warned if you are using a RAID to back-up and edit from as we were. The client was at least understanding in the matter.

Apple needs to fix this as we still have a lot of 5.1K H.264 footage to contend with and that leads me to a question: Does anyone know of a consistent and safe method to convert the H.264 footage to H.265 without losing too much exposure, colour and temp data?

Thank you to all who diagnosed this issue, this thread has been a godsend for our sanity!

Totally nightmarish for us too. I can't believe and understand why Apple is not taking care of this. At the beginning, I was absolutely sure they were going to fix within a week considering the massive problem it was for countless production Cies using DJI drones. But...nothing. The only trick we found was to use Handbrake to convert ALL the H264 files into H265 and from now on shooting only in H265 with our DJI MAVIC 3. If I could just forget about FCPX I would.

beardoswaggins commented 1 year ago

@WhiteFoxPictures Okay it seems Handbrake is the best option then. If I may ask, how long has it taken for you to convert these files? I tried in Monterey but one clip was over 30 minutes (approx a 5 minute clip) and with hundreds to contend with that seems like a huge time investment. On another note, have you noticed any degradation in colour correcting the converted clips? Thank you in advance!

WhiteFoxPictures commented 1 year ago

@WhiteFoxPictures Okay it seems Handbrake is the best option then. If I may ask, how long has it taken for you to convert these files? I tried in Monterey but one clip was over 30 minutes (approx a 5 minute clip) and with hundreds to contend with that seems like a huge time investment. On another note, have you noticed any degradation in colour correcting the converted clips? Thank you in advance!

Converting something like 100 files took a whole night. It really depends on the quality you ask from Handbrake, this can dramatically makes things longer (and files bigger), you just have to find what works for you. I can't remember what settings we used, but H265 (of course), same image frequency and definition (of course) and Video quality 14 or 18 I think.

I didn't notice any change in quality, but id DEFINITELY is a huge pain to do.

joema4 commented 6 months ago

I retested the DJI 5.1k 10-bit H.264 variant of this bug today and it still exists on FCP 10.7.1 and Sonoma 14.4.1, but it's fixed on Resolve Studio 18.6.6.

Maybe Blackmagic got tired of waiting for a MacOS fix and did a workaround in Resolve. If so this happened between Resolve Studio 18.6.2 on Sonoma 14.0, (where it still happened) and 18.6.6 / 14.4.1 where it's fixed.