Thoughts on 32-bit codecs being phased out in macOS

You may have read Apple's article about "legacy media" being phased out in the next version of macOS or even been alerted by an error message in the new version of FCPX. The article is fairly sparse and doesn't go into detail about the change or explain why it is occurring.

To be clear, it's not that 32-bit codecs are going away, it's that all 32-bit software is going away. But it affects video software the most because the only reason for an app to still be 32-bit in 2018 is because it uses QuickTime.

Why would an app still use QuickTime over the newer and non-deprecated AV Foundation? Because AV Foundation does not support third-party codecs. I filed an enhancement request to support third-party codecs several years ago and Apple closed it as "won't fix" so their position on that seems pretty clear. (Sure, you can go to a lower level and write your own parser but if you've reached that point, why bother using Apple's media frameworks at all?)

There is a Reddit thread with quite a lot of misunderstandings about what the change means. So to clear up some of the misunderstandings in that thread: there isn't really such a thing as a 32-bit file. You can have a file stored on a 32-bit file system or in a container with a 32-bit size header but the result of this is that these files will be limited to 2 or 4 GB in size. It has no bearing on which apps can read them, so they can still be read by both 32- and 64-bit apps or codecs. Also, do not confuse the QuickTime container (.mov) with the QuickTime API - the container is alive and well and still supported by the new frameworks. (The MP4 standard's container is about 99% identical to a regular MOV container after all.)

This isn't really about 32- vs 64-bit, it's about Apple no longer allowing extensibility. Next year's version of macOS won't support third-party codecs at all, so converting 32-bit codecs to 64-bit isn't a solution. A codec is a central piece of code that handles reading and writing to a particular format. Now instead of using that central code for free with no extra effort, every app needs to create its own version of that code.

But remember: this only affects macOS's native video frameworks. Developers don't have to use them and there's nothing to stop someone writing their own DNxHD parser. You don't need to worry about your files becoming unreadable because ffmpeg will always be there. (It still supports ancient long-dead codecs like Indeo!)

This is unlikely to change much with Adobe or Blackmagic. They use their own parsers for a lot of formats so will be immune to this change. The people it affects the most are small developers, who now have to come up with solutions to problems that Apple was taking care of for them in the past. By licensing certain codecs or allowing users to install their own codecs, Apple was providing an easy, free and legal way for these developers to read these files. They may not have the manpower to write their own parsers or the legal or financial ability to license the codecs in question. ffmpeg is a solution to the technical problems, but legal ones still remain - the code has to be compiled directly on the user's computer in order to be legally compliant, which can be complicated and user-unfriendly.

It may also affect FCPX negatively too. If the cross-platform NLEs are immune to this change, it means that FCPX is the only major NLE that will be affected by it. Apple's advice in the article is essentially "buy a new camera" but will people really shelve the cameras they paid thousands of dollars for to continue using FCPX? Or will they go for the cheaper option of switching to an NLE that can open them? I think the FCPX team are great, but they are sometimes hamstrung by corporate Apple which may not have the same interests as them or may be unable to see the bigger picture of how large changes like this affect Apple's smaller divisions.

Some people have speculated that the reasons for this are because Apple is planning to merge iOS and macOS or create ARM chips for desktop computers. Apple may well do these things in future, but I think this change was made for two more mundane reasons: security and efficiency. AV Foundation is fast because it is efficient so inefficiently-coded third-party codecs may cause performance or battery life problems. Supporting third-party codecs opens up the operating system to maliciously-crafted movie files meant to exploit bugs in third-party codecs that Apple doesn't have the ability to fix themselves. (I would argue that the benefits are still worth it despite these two potential costs.)

You may be wondering what solution we are planning for our products. The majority of our apps don't use QuickTime and the only one that relies on it heavily is QT Edit. For the apps that use QuickTime, we will convert them to have some level of base functionality with the default OS frameworks. When you launch the app for the first time, it will ask if you want to enable additional codecs and if you answer yes, it will install ffmpeg for you (the exact technical way this will work and the exact codecs that will be supported is still being figured out). Advanced users will also have the ability to compile ffmpeg themselves and link the executable to our apps to ensure they can definitely read the files they need to or to have greater control or better support  for their hardware. We feel that this is the best we can make of both worlds: trying to make it as user-friendly as possible while still giving power users control.

If this change affects you, here are the feedback links for macOS and FCPX. But Apple shouldn't postpone or cancel the death of QuickTime (it absolutely should die) - the solution is to allow third-party extensibility in the new frameworks. I'm not holding out hope that this will happen, and our ultimate goal is to be cross-platform so we'd probably go down the ffmpeg route regardless, however if enough people complain they may at least continue to support some additional codecs in FCPX.