fbpx
fcp.co logo transparent
fcp clapperboard
Welcome, Guest
Username: Password: Remember me
14 Nov 2020
Moving over to a new system, we couldn't take the old avatars - so please upload a new one!
  • Page:
  • 1

TOPIC: Bugs fixed in FCPX 10.4.9; performance improvements

Bugs fixed in FCPX 10.4.9; performance improvements 26 Aug 2020 13:14 #109537

  • joema
  • joema's Avatar Topic Author
  • Offline
  • Platinum Boarder
  • Platinum Boarder
  • Posts: 1712
  • Karma: 27
  • Thank you received: 372
It appears the following bugs are fixed in 10.4.9:

- Fixed: Intermittent FCPX hang or crash on 10.4.7 and 10.4.8 when handling certain HEVC codecs, commonly seen when transcoding to proxy or optimized media.

- Fixed: HSL masks not conveyed properly by XML

- Fixed: FCPX hang on Catalina if using Storage Locations>Modify Settings to create a new folder. This necessitated manually creating the folder in Finder then granting permissions to "everyone". That is no longer necessary.

On my 10-core Vega 64 iMac Pro, the BruceX benchmark was about 20% faster, or 4.75 sec. It's so fast on current versions of FCPX that I have to append 5 BruceX timelines and divide the execution time by 5 to get an accurate number.

On my 8-core 2019 MacBook Pro 16 with Radeon Pro 5500M, BruceX improved from 15 sec on 10.4.8 to 9.26 sec on 10.4.9, or about 38% faster.

Some brief tests may show modest improvement in viewer frame update rate on 10-bit 4k/25 H264 4:2:2 All-Intra material from a Panasonic GH5, S1, and similar H264 All-Intra material from a Sony A7SIII. Resolve 16.2.5 playback is still more responsive, with faster viewer frame rates and quicker playhead updates, but the FCPX skimmer is fast. Apparently FCPX is using a different code path for playhead position update vs skimmer position update, and playhead update is decoupled from viewer update rate. By contrast on Resolve playhead update rate is more closely tied to viewer update rate. That's not new but when examining FCPX responsiveness you can't go by playhead update rate because the viewer is often updating much faster. On "sluggish" codecs, using the skimmer (vs. playhead and JKL) may result in a smoother editing experience.

10-bit HEVC export is still slow on both my iMac Pro and 2019 MacBook Pro 16. It's very fast on Resolve on the same Mac platform, so this indicates a fix at the application layer is possible.

Please Log in or Create an account to join the conversation.

Bugs fixed in FCPX 10.4.9; performance improvements 26 Aug 2020 13:50 #109539

  • Ben Balser
  • Ben Balser's Avatar
  • Offline
  • Platinum Boarder
  • Platinum Boarder
  • bbalser.com
  • Posts: 3835
  • Karma: 34
  • Thank you received: 536
"On my 10-core Vega 64 iMac Pro, the BruceX benchmark was about 20% faster, or 4.75 sec. It's so fast on current versions of FCPX that I have to append 5 BruceX timelines and divide the execution time by 5 to get an accurate number."

I have the same setup. It'll be interesting to run it on my system. Thanks for this great info!

Please Log in or Create an account to join the conversation.

Bugs fixed in FCPX 10.4.9; performance improvements 27 Aug 2020 00:27 #109550

  • FelixLgr
  • FelixLgr's Avatar
  • Offline
  • Fresh Boarder
  • Fresh Boarder
  • Posts: 3
  • Thank you received: 0
Seems not all cameras gets all the Raw options... might be a bug..

Atomos engineer report there findings :

Nikon Z6 – No ISO / No Exposure Offset / No White Balance
Nikon Z7 – No ISO / No Exposure Offset / No White Balance

Panasonic S1H – ISO / Exposure Offset / White Balance
Panasonic EVA-1 – ISO / Exposure Offset / White Balance
Z CAM E2 (Original Version) – ISO / Exposure Offset / White Balance
Canon C300 MKII – ISO / Exposure Offset / No White Balance
SONY FS7 – ISO / Exposure Offset / No White Balance

Please Log in or Create an account to join the conversation.

Bugs fixed in FCPX 10.4.9; performance improvements 27 Aug 2020 13:30 #109575

  • joema
  • joema's Avatar Topic Author
  • Offline
  • Platinum Boarder
  • Platinum Boarder
  • Posts: 1712
  • Karma: 27
  • Thank you received: 372

FelixLgr wrote: Seems not all cameras gets all the Raw options... might be a bug...


There is some discussion of this and possible causes in the below Youtube webinar "FCP.co Live Show 16 FCPX 10.4.9 Update", starting at 00:26:15.



The speculation in the above webinar is it's a limitation based on the metadata the camera mfgs are currently supplying. However for Sony FS7 files, the camera white balance color temp is being supplied because you can see it in FCPX or in tools like Invisor, MediaInfo or ExifTool. See below downloadable sample footage.

Discussion and speculation:

Unlike EXIF data in still photos, video metadata is less standardized. Camera mfgs frequently hide info in "maker notes" or other encoded fields. For a proprietary RAW workflow using original camera files, that's OK -- the camera mfg is also supplying the conversion utilities and they know how they encoded that metadata. The metadata may also be in "sidecar files", not just the video file header. Their proprietary RAW format is hardware-dependent.

But with hardware-independent ProRes RAW, there are no sidecar files and there's no mfg-specific conversion utility. To the user's standpoint, ProRes RAW just works like regular ProRes - you can even press space bar to play in Quick Look. By contrast to play mfg-proprietary RAW you often need a special player utility.

With ProRes RAW in many cases you're not dealing with an original camera file but an Atomos-enoded file based on a RAW datastream from HDMI. That camera's datastream must include the necessary video metadata, and it must be documented so Atomos can encode that in the ProRes RAW file. I seriously doubt Atomos has separate code within their recorder to handle each unique camera. Rather the camera mfg. must supply HDMI data in an exact format. Otherwise you'd have to get an Atomos firmware update every time a new camera was released.

Historically, video camera mfgs have been notoriously tight-fisted with this data. That is why the developer of ExifTool must spend so much time reverse-engineering this data for each camera, and it's a very convoluted process: exiftool.org

There is probably a metadata format which Apple and/or Atomos have defined and which the camera mfg must adhere to. This could include camera ISO, white balance, color profile, shutter speed/angle but also aperture, ND setting, camera model, etc. Each data field must be packaged in the correct offset and using the correct data type within the ProRes RAW video file header.

Since for the Sony and Canon cases the camera color temp is apparently contained in the Atomos-encoded ProRes RAW file, and since FCPX displays this in Inspector>Settings, I don't know why FCPX does not expose a color temp control for those like they do for Panasonic and ZCam files.

While it superficially might look like a bug or limitation in FCPX or the Atomos encoding, maybe the camera metadata must be packaged in a specific format, else Atomos cannot encode it properly and FCPX cannot manipulate it. We could contrast this with Adobe Camera RAW for stills, where there's a conversion process that must be updated for each new camera, and ACR must know a hundred different RAW formats. With ProRes RAW the camera mfg probably must supply the data in a precise standardized format for Atomos to encode it and FCPX to use it.

There are non-Atomos ProRes RAW files, e.g, the DJI Inspire 2 drone, some ZCam models and the Kinefinity MAVO Edge will have in-camera ProRes RAW: www.kinefinity.com/en/mavo_edge/

It would be interesting to see how those are handled by FCPX since it bypasses Atomos encoding.

The only ProRes RAW test files I have are old ones from a Sony FS7 and Atomos Ninja Inferno. They are fun to play with, esp. if doing color grading with HSL masks. You quickly see how flexible the files are and how much adjustment latitude exists:

filmplusgear.com/prores-raw-testfiles-for-download-nab-2018

Please Log in or Create an account to join the conversation.

  • Page:
  • 1