I shot some XAVC S 4K 10 bit 422 footage on the new A7S III and imported it into final cut pro. I shot both 24 fps and 60 fps footage and the playback of the footage alone in FCP was very choppy and skipped some frames. Does anybody know if FCP has not released a codec to properly decode the footage yet?
I have some decent specs on my Macbook that should allow me to playback the footage fine:
2.7 GHz quad core
Radeon Pro 455 w/ 2GB memory
1TB SSD hard drive.
Being that I was skeptical that it may have been due to my laptop being from 2016, I took the footage to a Best Buy store to try on their newer Macbook and iMac models. But the same thing happened as well in terms of the choppy/skippy playback on FCP.
Been searching the web nonstop for something but haven't seen anything. Anybody experience the same thing?
JonnyBoy wrote: I shot some XAVC S 4K 10 bit 422 footage on the new A7S III and imported it into final cut pro. I shot both 24 fps and 60 fps footage and the playback of the footage alone in FCP was very choppy and skipped some frames. Does anybody know if FCP has not released a codec to properly decode the footage yet?..
I've tested various A7SIII 4k 10-bit footage using FCPX 10.4.10, Premiere 14.4.0 and Resolve 16.2.7 on my 10-core Vega 64 iMac Pro. In general it is somewhat choppy, but how each NLE handles each codec varies.
On Premiere all 4k A7SIII codecs I've tested are just plain slow. On Resolve and FCPX All-Intra are fairly fast, but HEVC and Long GOP are sluggish.
However on FCPX you must distinguish between playhead responsiveness vs viewer frame rate. In general FCPX prioritizes viewer update rate over playhead updates, so if you look at the viewer it is often updating fairly quickly even though the playhead is laggy.
Also on FCPX there's apparently a separate optimized software code path for the skimmer vs the playhead. If you skim the thumbnails in the Event Browser, the viewer update rate is usually faster than using the playhead in the timeline.
In general 4k 10-bit 4:2:2 "Long GOP" and HEVC codecs are very difficult to decode, possibly because the hardware accelerators don't handle this well. Your only current option is transcode to proxy, and fortunately FCPX 10.4.10 now gives many different proxy options -- varying frame sizes and both H264 and ProRes. On my machine using 50% H264 proxies works fairly well. That is about 1/5 the size of regular 50% ProRes proxies, yet delivers good playback performance (at least on my machine).
Even though we often view a certain encoding format in broad terms (e.g, 4k H264), internally there are many variations. The GOP length, number of reference frames, bit rate, frame rate, etc all vary. This is why two apparently-similar codecs may perform so differently on a given platform.
Likewise we view hardware accelerated decoders in simple broad categories, e.g, Quick Sync. But for each given decoder type there are multiple versions, each with varying capabilities, often poorly-documented. There is a multi-year lead time to develop, produce and integrate new hardware decoders into a product line.
Ideally, early during development each camera manufacturer should collaborate closely with computer and system software developers to ensure their new codecs will be well supported when the product is released. The cameras are using their own hardware ASIC to format the codec. The ASIC also has a long design lead time, so in theory there is a significant overlap period during development of a new camera and new CPUs or hardware accelerators during which collaboration and coordination could occur.
Unfortunately I don't think this happens very consistently, so there is a long history of cameras being "dumped on the market" with poor NLE and hardware support, which then takes years to catch up.
Hopefully the new Apple Silicon Macs will enable a more agile and capable hardware acceleration approach, which may reduce this problem.