It has been a busy week for codec news. We try to sift through the information, dispel the FUD and come out the other side in one piece.

When FCPX 10.4.4 was released, many saw the legacy media incompatibility warning and went into a state of shock.

Many other websites, (who really should know better, but depend on clickbait headlines to fund their unresearched minimal writings) instantly came to the conclusion that this was a huge problem or indeed, that old chestnut, it is another example of Apple ignoring the professional market / Wanting to make FCPX only work on iPads / Telling us what to do / Only caring about the iPhone etc. 

Wrong.

What Apple has done is clearly given the user a warning that some old files will be a problem in the future. Not now, but the next version of the macOS. So much for Apple not letting any information out before releasing new software or hardware!

They have also responded with a very clear list of what will and won't work and how to fix it if it doesn't. All the info can be found on this White Paper which we recommend you bookmark. Lots of very helpful information in there.

So why aren't Apple fixing things for these legacy files to work in future releases?

They are old. Old as floppy disks and Firewire 400 ports.

Although the new macOS will not support the files, if a bodge was enabled, these files wouldn't work too well with FCPX. You can get an indication of this already by using a sluggish animation codec file in FCPX. Strangely, this codec will still be supported, but if you are smart, you are probably already using ProRes 4444 as a much better replacement.

Out of all of them, the codec to worry about is DNxHD as this is Avid's ProRes style codec. Will Avid files work in FCPX? Not if they have been written with the QuickTime 7 framework. Which whilst we are on the subject, Apple clearly indicated that the move away from the 32-bit QuickTime APIs was going to happen when Snow Leopard was released back in 2009! That was the first outing of QuickTime X. 

Just think about that, that's nearly 10 years warning of change. If a company can't adapt its software in that time, who is to blame, Apple or Avid? 

Here is Avid's response, slightly vague, but if you are using their tools on macOS, it looks like you will be ok. As the dropping of 32 bit codecs is a macOS decision, how will that affect Premiere Pro and Resolve next year? There cannot be Premiere Pro 32 bit codecs or any others on macOS 10.15.

Yes I like Apple products and I prefer FCPX over any other NLE, so you could accuse me of being biased, but...  This does sound to me like Apple have put a lot of thought into this and ARE trying to look after their users. Yes the White Paper should have been published the day 10.4.4 was released, but it wasn't far behind when the FUD started appearing.

Only a few years ago, a few companies were recommending using Cineform as a Premiere mastering codec. Owned by GoPro, but open source since 2017, this is one of the casualties of the next macOS update. It is either a mistake or a deliberate move, but Cineform is now no longer on Premiere's list of supported formats. A separate web page describes how to work with the codec. Crazy eh?

This is where the real problem lies, as Apple moves forwards, there will be casualties, no software lasts forever.

I'll give you an example that went almost unreported, but if the offending company had been Apple, it would have created the usual 'the sky is falling in' headlines, tweets and confusion.

Adobe stopped supporting QuickTime IMX 50 on macOS. The once favourite broadcast SD codec of choice doesn't work in Premiere any more, which is a real pain if you have a large archive full of the stuff.

Why? Because of security and the threat of malicious code being included in the file and thus it gets blocked at the OS level. Premiere just reads the 'outside wrapper' ignoring the contents whereas FCPX inspects and checks the contents before importing. If they match, then FCPX can import it. 

Another example was the failure of FCPX to read timecode properly from EVS ProRes streams. After many emails and debate, EVS finally admitted that they were using FFmpeg to write the files and thus they were non-standard and were causing the problem. 

I can happily report that both Adobe and EVS are now on the approved list of third-party ProRes products. Again, a webpage well worth bookmarking and also take note of the warning about FFmpeg.

But this isn't the main codec news of the week. Adobe's announcement that the latest versions of Premiere, After Effects and Media Encoder will allow the export of ProRes on Windows is huge.

It is far from a nail in FCPX's coffin as was suggested online, it will encourage the the use of ProRes as a standard between systems. It will then keep the door open to users who might be tempted to switch back to the Mac when the new Mac Pro is revealed next year.

The ability for AE Windows users to render ProRes 4444 files without having to bounce them through a Mac is of enormous benefit. With the amount of devices now outputting ProRes, it means that editors and VFX artists can now have a complete ProRes workflow available on Windows.

We would expect that as Apple has close ties with Blackmagic (The eGPU for example) that Resolve won't be too far away from supporting ProRes exports on Windows either. Should you have a spare ten minutes, you can take a look at Resolve's support for codecs on macOS, Windows and Linux here.

So a thousand words later, what have we learnt? Only one thing and that's things will always change.

If you do get the legacy media warning, follow all the instructions on the Apple White Paper. You should then be fine with the next macOS. Apple has already said that there will be tools in a new update to FCPX next year that will help. 

Also stay away from 'unlisted' third party ProRes products such as FFmpeg and the GUI versions such as XxxTube.

FCPX, the macOS and the hardware have been optimised for ProRes, so to gain maximum performance, it makes sense to keep everything as much as you can in the ProRes family of codecs.

 Disagree? let me know in the comments below.

 

Peter Wiggins is a broadcast freelance editor based in the UK although his work takes him around the world. An early adopter of FCP setting up pioneering broadcasts workflows, his weapon of choice is now Final Cut Pro X.

You can follow him on Twitter as @peterwiggins or as he runs the majority of this site, you can contact him here.