[Joe Marler]

It crashed in thread 59. That was in a deep call stack involving “Helium” functions. Helium is a private FCP framework that is apparently related to video processing or rendering. It was processing a queue of items managed by Grand Central Dispatch (GCD). IOW it was likely a worker thread managed by GCD on behalf of the FCP application.

The crash was in ProGL::ContextHandle::getVirtualScreen() const + 0. ProGL is a private FCP framework that might be a wrapper for OpenGL calls. With the advent of Metal I don’t know how that fits in, whether they retained former method names for compatibility with upper layers, or what.

Prior to the crash point it was in the private FCP framework “TextFramework”. That is a Motion framework, which implies Motion functions might have been processing some kind of text or title.

At the top of the crash log, it lists error code “KERN_INVALID_ADDRESS at 0x0000000000000010”. That suggests that the application tried to access an invalid memory address (0x10) that is not mapped or is in a restricted memory area.

It then said “Termination Reason:”, which indicates the process was terminated due to a segmentation fault (Code 11), which is a specific type of memory access violation that occurs when a program tries to access an invalid memory address.

“VM Region Info” indicates that the address 0x10 is not in any region, which may confirms an invalid memory access.

The crash point might indicate a null pointer dereference or an uninitialized pointer in the ProGL library, specifically in the ProGL::ContextHandle::getVirtualScreen() method.

Why that happened in this case is unknown but that’s a typical failure mode when multithreaded software crashes.

Can you give any additional info on what you were doing when it crashed? If it’s reproducible, is there anything in common? Can you export a project XML, create a new library, import the project XML and see if it happens there? If it does, duplicate the project, open the duplicate, select all clips with CMD+A and remove all effects with Edit>Remove Effects. Then see if that project crashes.

I didn’t see any references to 3rd-party plugins in the crash log but if you’re using any, state which ones.

If your computer has multiple monitors, as a troubleshooting step unplug that and any outboard video hubs and see if it crashes without that.

As always try the usual stuff such as reset FCP preferences, verify that all disk volumes have plenty of free space, etc.

[Joe Marler]

There are two ways cameras shoot slow motion: (1) Sensor and encoding frame rates are increased, with intention of retiming in the NLE, and (2) Sensor scan rate is increased but material is encoded at a lower frame rate and bit rate. IOW the slow motion is “baked in”. That is how the FX6 handles 120 fps material.

The FX6 can only do that frame rate in S+Q mode. I believe the reason for that restriction is the XAVC-I codec and MXF container format do not support the required encoding bit rate to shoot and record true 120 fps. In return the MXF container has much richer metadata than the MP4 container and better supports timecode.

The metadata which indicates the FX6 sensor frame rate is unfortunately esoteric, but it can be seen using Sony Catalyst Browse or the 3rd-party tools MediaInfo or Invisor. In Catalyst Browse, the metadata field is denoted “Capture frame rate”, as opposed to regular “frame rate”. In the other tools the metadata field is called “CaptureFrameRate_FirstFrame”.

Invisor: https://apps.apple.com/us/app/invisor-media-file-inspector/id442947586?mt=12

I tried using the command-line utilities ExifTool, ffmpeg and ffprobe but they do not reveal that metadata. If they did you could batch process a bunch of camera clips and rename them to indicate the 120 fps stuff. Then you could use Finder tags or an FCP filter to keyword those.

I also investigated what video metadata is indexed by MacOS Spotlight search and what metadata fields Finder can search. Unfortunately they don’t handle sensor scan rate in XAVC-I/MXF.

However Invisor can display metadata from about 10 clips at the same time in a spreadsheet-like grid, so you can find them like that.

MediaInfo is a GUI tool but has an available command-line interface, but it’s limited and I don’t think it handles sensor scan rate.

FX6 in S+Q mode at 120 fps does not record audio, so maybe you could find them like that (maybe even in FCP). In hindsight that might be the simplest method but I didn’t think about it until just now.

Of course that doesn’t consider all the camera operators who shoot normal frame rate and forget to turn on their camera mics 🙂

[Joe Marler]

I have observed this problem when certain Thunderbolt arrays are plugged in, I begin a normal MacOS normal shutdown, then it reboots. Upon reboot it displays a kernel panic error log which sometimes refers to a shutdown I/O stall or (more recently) “Halt/Restart Timed Out @IOPlatformExpert.cpp:883”.

Unlike user-mode code where exceptions can crash that app, the involved code here is kernel mode, so it will crash the entire OS. Of course it’s in the process of shutting down anyway, but it might cause an ungraceful shutdown — I don’t know where in the overall shutdown sequence it happens.

Fortunately this source code is open source and examination of it indicates that within IOPlatformExpert.cpp it was attempting to get the machine name from the device tree using the key value gIODTModelKey. For some reason that returned a NULL value, it dereferenced that variable which caused a crash. I don’t know the underlying cause; maybe it’s interrogating all I/O devices as part of sending dismount or shutdown commands and some Thunderbolt I/O devices do not respond within the expected period. It would seem a bug in the MacOS code because IMO it should continue the MacOS shutdown and log an error, not crash.

I have several RAID arrays and it only happens on one of them, an OWC Thunderbay 4 Mini which contains 4 x 4TB Samsung EVO 870 SATA III SSDs. It is using regular AppleRAID not SoftRAID.

This is on an M1 Ultra Mac Studio running MacOS Monterey 12.6.2, but it also happened on my iMac Pro on several prior versions of MacOS. My workaround is manually dismount and unplug that Thunderbolt array before I shut down or reboot the machine.

[Joe Marler]

I believe EditReady can transcode X-OCN files to various codecs inc’l ProRes 4444. You could possibly do that then relink the ProRes files to your current project files. It would preserve most of the original source fidelity. The filenames and extensions would have to be the same.

I haven’t tested X-OCN with EditReady but they said on their web site it works:

https://blog.hedge.video/editready22-2/

https://hedge.video/editready/

[Joe Marler]

I have both 27″ LG 5k and the 27″ Apple Studio display which I use on both M1 Max MBP16 and a M1 Ultra Mac Studio. The LG is good. However this is a good comparison of them which also reflects my experience: https://youtu.be/-ARS-htYzHQ

Some contents or functionalities here are not available due to your cookie preferences!

This happens because the functionality/content marked as “Google Youtube” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.

[Joe Marler]

Paul’s recommendation is good. I spend most of my time on a desktop machine and normally don’t need a laptop, but the M1 Mac laptops transform that experience.

I definitely would not get an Intel Mac at this point. I have top-spec 2015 and 2017 iMac 27, formerly had a 2013 iMac 27 and 12-core D700 “Trash Can” Mac Pro, a 10-core iMac Pro, and now have a M1 Max MPB 16 and M1 Ultra Mac Studio. Most any Apple Silicon machine (even a Mac Mini) is better than a 2017 iMac 27, and in some cases faster than a 2013 12-core Mac Pro or iMac Pro.

What “casual” editors often overlook is casual use usually equates to consumer codecs which are difficult to edit smoothly. I can’t count how many times I’ve head “I’m not a professional editor, why is it slow, it’s only GoPro/DJI material”. Those are among the most difficult to edit smoothly. The hardware accelerators in Apple Silicon machines make a big difference.

Try to get 16GB RAM and at least a 16-core GPU. Get as much SSD as you can afford.

[Joe Marler]

The fastest and safest way to clear up space is delete all render files. That’s done via File>Delete Generated Library Files>Delete Render Files>All. That does not delete optical flow or analysis files, which sometimes can be large.

Another approach is copy the project to a new library which will bring along just the media for that project timeline. You will be presented with a dialog about what media to copy.

You can determine which files are unused by your current project timeline by using the filter “unused media”, ie unused from the standpoint of the currently open timeline.

For any such cleanup work like this, it’s vital to *first* have a clear picture of where the media files are — internal to the library, or external and if so on what drive.

Imported files in FCP can either be copied within the library or with “leave files in place”. For “copy to library” files, deleting those within FCP will delete the media file from within the library, provided there are no other references to the file, ie no other timelines using it.

For external media imported with “leave files in place”, FCP will not delete those files. You must determine which are unused within FCP, make a list then delete those in FCP and use Finder to delete them on disk. Unfortunately there is no easy way to show which files are in each category.

Your best solution is getting the 3rd-party utility Final Cut Library Manager. It can safely delete all render, analysis and optical flow files across multiple libraries. It also has an optional feature to export a media list in .csv format showing the pathname to each file. That .csv file can help assess where your media is and how to handle it.

https://www.arcticwhiteness.com/finalcutlibrarymanager/

[Joe Marler]

Examining another Blackmagic gyro-stabilized 24 fps clip shows it has the same unavoidable issue as Sony. So that 1st demo was not representative. Starting at 1:45 in this video the frame blurring is obvious in the stabilized case. It’s nice to have that option, the integration with Resolve is handy but it’s not a magic solution which eliminates other types of stabilization (at least at 24 fps). If everything you shoot is 60 fps and 1/120 shutter, I’m sure it works better, just like on Sony.

https://youtu.be/WkyeOXMQxZU?t=106

Some contents or functionalities here are not available due to your cookie preferences!

This happens because the functionality/content marked as “Google Youtube” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.

[Joe Marler]

That Blackmagic gyro demo is good in that it’s mild and seems to avoid frame blurring or other artifacts. Here is a brief test I did with my Sony FX6 using Catalyst stabilization at 23.98 and 59.94 fps, both with 180-deg. shutter angle. Both were hand-held at 280mm which is a pretty severe test. Lens-based optical stabilization was off. This required a separate pass through Sony’s Catalyst Browse utility before importing to FCP, so Resolve’s integration of their gyro-stabilized clips is nice.

https://vimeo.com/manage/videos/598896853/2bde2933ac

[Joe Marler]

If it’s any consolation you can transcode BRAW to ProRes using EditReady, which also can transcode REDRAW, Canon Cinema RAW Lite and ARRIRAW to ProRes: https://hedge.video/editready