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.
jjsereday wrote: Its interesting that FCPX has issues / stutters with H265 10Bit 422 (23.98) but Kyno plays it back flawlessly. Both have issues 60fps though.
1x playback speed is an easy test. The real issue is how well the NLE supports rapid scrubbing through a given codec in both forward and reverse, esp. via JKL commands.
I just tested three codecs from a Sony A7SIII on FCP 10.5.1, Premiere 14.8.0, and Resolve Studio 16.2.8.005, also on Kyno 1.8.3, all on a 10-core Vega64 iMac Pro running MacOS 10.15.7.
The three codecs were: 4k/23.98 10-bit 4:2:2 XAVC-S (H264), 4k/23.98 10-bit 4:2:2 XAVC HS (HEVC/H265), and 4k/23.98 10-bit 4:2:2 XAVC-I (All-Intraframe).
FCP was by far the smoothest of all the NLEs when doing 4x playback forward and reverse via JKL commands. The viewer update rate was the quickest and response lag to JKL commands was fastest. Both H264 and HEVC 10-bit 4:2:2 codecs were a bit sluggish but usable. The All-I codec was fast and smooth.
Resolve was slower than FCP on H264 and HEVC but still usable. It was also fairly fast on All-I.
Premiere was extremely slow and sluggish on all three codecs, despite running the program monitor at 1/4 resolution. The viewer update rate was so slow and the lag time to JKL input so great (even on All-I) it was difficult to use.
Kyno was impossible to test properly because it apparently does not support high-speed playback and does not support standardized JKL commands like the NLEs. This has been requested for years, and two years ago Kyno said they planned this for ver. 1.7, but it is not fully implemented. Those keys will jump forward and back but not change playback speed.
However it is possible to roughly approximate Kyno decode performance and viewer update rate by manually scrubbing the playhead. On the tested platform and codecs, I'd characterize it as slower than FCP, maybe about equal to Resolve but faster than Premiere.