The recent brouhaha surrounding the Legacy media codec warning in November’s Final Cut Pro X 10.4.4 release caused a lot of, shall we say … discussion, around the internet. As usual with something that many people don’t understand there was everything from the No Film School way of alerting readers (sorry but I won’t link to misinformation) where there is absolutely no clarification on the issue to what was the best discussion of this new topic from Digital Rebellion. I didn’t know exactly what to make of it so instead of opening my mouth I reached out to Apple with a few questions about what some of this means.

In the first half of 2019, an updated version of Final Cut Pro will include a feature to help you identify and convert legacy media files.

Today we got more information in the form of an update to the Apple knowledge base article About legacy media in Final Cut Pro X.

I had a chat with some folks from Apple to clarify some of this information. I think Jon Chappell of Digital Rebellion got it right when he wrote that in the future these codecs which aren’t supported by the OS could easily be supported in your video editing application, video player application or really any other application as long as the developer writes that support in. Apple said the same thing. Do read Jon’s article if you haven’t already as that is the most well-reasoned analysis of the subject.

The updated Apple knowledge base article has a long list of codecs that might be “affected by the transition to 64-bit technology” so click over to see that list in its entirety but here are a few post-production codecs that might come into play.

• Avid DNxHD / DNxHR
• Avid DV / DV100 / JFIF / Motion JPEG
• Avid Meridien / 1:1x / Packed / RGBPacked
• CineForm
• GlueTools codecs for Cineon/DPX, Phantom Cine, ARRIRAW, Uncompressed RGB
• Motion JPEG A
• Motion JPEG B
• Perian collection of codecs (such as Microsoft MPEG–4, DivX, 3ivx, VP6, and VP3)
• REDCODE QuickTime Decoder (.mov)
• Sony HDCAM-SR (SStP)

We won’t get the support for some of these legacy codecs in the base level of the operating system. I honestly think it won’t make that big of a deal as most of the software that editors will be working in will be able to support the various post-production codecs that we need. This same day we saw Adobe’s announcement of ProRes encode and export on Windows which has probably been asked for more than any other codec in post-production history.

Avid even addressed this issue with The future of Avid DNx on the Apple platform. From that knowledge base article:

DNxHD, DNxHR, Pro Tools and Media Composer will continue to be supported and will be compatible with the current and future releases of macOS. We will continue to improve or introduce new features for DNxHD and DNxHR, proven by recent release of DNxUncompressed option, and will support these new features on various operating systems, including macOS

So we have Adobe releasing ProRes on Windows, Avid telling us DNxHD/DNxHR on the MacOS isn’t going anywhere for Media Composer editors and Apple addressing this legacy codec issue head-on. There’s nothing to worry about.

This brouhaha was more much ado about nothing because some of these Legacy codec issues won’t be an issue at all in Final Cut Pro X, today or in the future. I don’t know how many people are really editing DNxHD/DNxHR or Cineform in Final Cut Pro X anyway. Maybe a few more with Cineform since that is GoPro’s intermediary codec but overall it’s more of a non-issue than a big issue. But of course, it’s the Internet so there often has to be a big stink made before anyone understands. Apple didn’t help matters as they provided very little information about these unsupported legacy codecs upon this last FCPX release. The December 11 article would have curbed a lot of those questions. I did notice they removed the talk of non-support for codecs “created with software.” I asked about a potential difference for something like Avid DNxHD created with Media Composer or DNxHD files created in-camera with an ARRI Alexa and there is probably little difference so removing that created with software should alleviate some confusion.

This non-support of old codecs shouldn’t come as new information to anyone who has been paying attention. This began back in 2009 as the Mac OS began its transition to everything 64-bit and that meant that underlying architecture had to move to 64-bit as well. Quicktime was deprecated around 2013 and another brouhaha came about when Apple stopped supporting Quicktime on Windows. But what we’re looking at here is a nearly 10-year transition once an upcoming release of Mac OS finally kills all support for old 32-bit codecs.

A new version of FCPX?

The biggest news here is that a future version of Final Cut Pro X, that should come sometime in early 2019, will get tools to identify and deal with these legacy codecs so we can move these projects into the future.

This isn’t just Apple commenting on an upcoming version of FCPX but an important mention that editors won’t be left dependent on their own codec sleuthing when it comes to making sure their media will be usable in future versions of the application and future versions of Mac OS.

In the short term, editors don’t have to do anything as the current version of Mac OS Mojave supports all of these legacy codecs. If you’re a Final Cut Pro X editor then dig into an upcoming release of FCPX and make sure media in your current project (and any projects you might have to access in the future) is transcoded into something future-proof. If you’re an Adobe Premiere Pro or Media Composer editor you most likely won’t be affected as those NLEs will use their own internal playback architecture to support most all codecs you want to edit with. If you’re still a Final Cut Pro 7 Classic editor … then you’re staying on an old OS anyway.