Muss ich also mal schauen, wie ich das künftig umschiffe, bis das gelöst ist. Vermutlich Karteninhalt erst mal auf die interne SSD kopieren und von dort aus importieren, so dass es dann auf meiner Arbeits-SSD landet.That bug is unique to FCP 11.1 on Apple Silicon. It does not happen on Intel. It has only been reported with 4k Sony XAVC-L (Long GOP) material from the FX6 camera, not XAVC-I, nor 1080p XAVC-L. It seems to happen with all frame rates except 59.94.
It only happens when importing from the camera SD card using the FCP import dialog, or if copying the full SD card contents to a disk folder and importing using the FCP import dialog.
It does not happen when drag/dropping clips from Finder to FCP, nor if only the MXF files are first copied to a hard drive folder and then ingested using the import dialog.
While the A7SIII can record Long GOP H.264 and HEVC files, those use the MP4 container and are not XAVC-L (note that term is not found in the A7SIII manual). XAVC-L is a specific category of H.264 recorded in the MXF container used by the FX6, and I think FS7 and FX9.
I believe the root problem is related to the AppleAVCLGCodec in /Library/Video/Professional\ Video\ Workflow\ Plug-Ins/, which is x86-only. Normally, Rosetta can handle that if using hardware decode acceleration. There may have been some change in MacOS 15.4.x that tightened or caused misinterpretation of an Info.plist entry within that codec for "Hardware Acceleration OK". QuickTime Player and the FCP import-dialog preview fall back to the non-accelerated Rosetta codec and suffer a first-decode JIT stall. Drag-drop from Finder to FCP takes a path that still qualifies for hardware, so it remains smooth. At least that's my current theory. The very laggy initial XAVC-L playback in Quicktime Player on Apple Silicon is easy to reproduce.
Diese Stories musst du jetzt alleine bringen. Frank fehlt.