Why ProRes on Windows is Still Not a Good Option for Editors
[Updated August 3, 2018]
This article takes a frank look at the state of ProRes on Windows computers.
Can you make it work? Yes, sort of, sometimes. But it’s a bad idea for lots of reasons.
Playback is not enough – you have to encode, too
First off, we need to make a distinction between encoding and decoding.
Lots of software—including all of the major NLEs (Non-Linear Editors)—can decode ProRes on Windows. This means that they can play back and edit with ProRes just fine, but they are unable to export the results of those edits.
Practically speaking, the ability to only decode ProRes is not enough to build a solid ProRes workflow. It is possible to mix and match your codecs throughout your project, but there is a great advantage in the simplicity of using one codec all the way through your workflow. In order to be able to do that, you have to be able to encode your codec of choice.
Some higher-end cameras or external recorders are able to capture ProRes files, and a Windows user can then edit them directly (depending on what type of ProRes it is). That is a very valid workflow, but I wouldn’t call that a ProRes workflow so much as a starting-with-ProRes workflow.
Unlicensed encoders are a bad idea
Whenever the topic of ProRes on Windows comes up, you hear names like FFmpeg, Miraizon, Cinemartin and a tool just called “Prores On Windows.”
I don’t doubt that it’s possible to get good results with some of these, and they sound great when you’re reading their marketing materials. But they don’t provide the reliability and quality that a professional editor requires.
These tools use unlicensed, reverse-engineered encoders
Contrary to popular belief, this reverse-engineering is not actually illegal, but it’s… sketchy.
What does “reverse-engineered” really mean? It means that they took a clip, encoded it with a real Apple ProRes encoder, and then picked apart the resulting file to see what was inside it. After doing that lots of times, they can start making guesses about how the software works that produced the file.
The problem is that codecs are really complicated. It’s not possible to completely recreate a sophisticated encoder just by looking at its output files.
They can have image quality issues
This will vary by software, but there have been many reports of low image quality, gamma shifts, and bit-depth errors from reverse-engineered ProRes encoders. Google your 3rd-party codec of choice along with “image quality” and you’ll find people talking about it.
One of the main reasons why people use ProRes is because it’s a known system, a kind of universal standard of image quality. With 3rd-party encoders, you never really know if you’re going to get ProRes quality or not. You lose one of the main benefits of ProRes.
They aren’t guaranteed to even work
This is the primary reason why professional editors steer clear of reverse-engineered codecs. They can give errors, or they could literally not function at all. You could hand a video off to your client and discover that it doesn’t work with their software (this has actually happened for many people using 3rd-party ProRes encoders).
If you stay within the official, licensed ProRes ecosystem, Apple software is encoding the file and then Apple software is decoding the file. Even if you’re playing back your video in Premiere or Media Composer, they’re actually running Apple’s ProRes code under the hood. That gives a nice guarantee of good performance.
They don’t offer support
Apple offers very solid support and they have a huge user base of helpful people who can get your issues sorted out. The 3rd-party prores encoders are published by tiny companies (sometimes with no contact info at all), which may not be around very long. “Prores on Windows” was a thing, and then suddenly they stopped accepting orders.
As of the time of writing this article, no one knows whether they are shutting down or not. I wouldn’t count on this company to support a professional workflow.
And just to round out the list of cons, some of these 3rd-party encoders are very slow—much slower than the official ProRes, and also much slower than other intermediate codec options.
There are better options
One of the main reasons to use a codec like ProRes is because it’s tried and tested, rock-solid, and compatible with everyone. These reverse-engineered codecs are not that.
If you’re throwing out the reliability and interoperability of ProRes, why use ProRes at all? You’d be better off with DNxHR or Cineform.
To sum up, here is a quote from Apple.
“Using any unauthorized implementation (like the FFmpeg and derivative implementations) may lead to decoding errors, performance degradation, incompatibility, and instability.”
This isn’t just an example of Apple being paranoid. Users of unlicensed encoders have reported many issues. In many cases, the exports from unlicensed ProRes encoders seemed fine, but later on they failed to pass quality control for broadcast.
Edit: a note on FFmpeg
In response to some of the comments I’ve received on this article, I want to emphasize that FFmpeg is an amazing tool, which I personally use to do analysis and encode to h.264, h.265, and VP9. It is the ultimate transcoding swiss army knife and does a lot of amazing things.
In spite of all of that, FFmpeg’s ProRes encoders are still unlicensed and reverse-engineered, unlike its h.264/h.265/VP9 implementations. There have been many issues with ProRes exports from FFmpeg. I’m not going to list them here because that is not the point of this article, but I will add them in a comment for people who really want to dig into this.
Authorized ProRes on Windows options aren’t practical
Two pieces of mainstream software running on Windows (Scratch and Nuke) have licensed the ProRes encoder from Apple. That means that they’re actually running Apple’s code, so they produce real, dependable, ProRes files exactly as they would appear if encoded by Final Cut Pro.
If you’re already using Scratch or Nuke in your pipeline, then great, go ahead and encode your ProRes. But for most editors, sending your files through these programs is not a practical solution.
First of all, they’re expensive.
A full license of Scratch costs $3,000. You can rent it by the month at $79, but that’s still not cheap. Nuke costs $1,215 quarterly. These are amazing tools, but they’re finishing tools, so they’re designed to enter the workflow after the edit is finished.
One way to make it work is to do your entire edit in Media Composer or Premiere, export to an uncompressed or very high-fidelity intermediate codec, import that into your finishing software, and then re-compress that file into ProRes. Assuming you used the right intermediate codec, you could get perfectly good results with that workflow, but it’s adding a lot more time and complication. You’re also going to have to repeat that process every time you export a new version.
One other solution that’s technically not “on Windows” but could work for a Windows workflow is Telestream’s cloud transcode service. Telestream uses official Apple encoders, so you have the quality guarantee. You could theoretically repeat that same workflow I just mentioned. You would export a very-high-fidelity codec from your editing software, upload it to Telestream’s cloud, and download the compressed file. But that’s going to take even longer than the Scratch/Nuke solution because uploading that file is probably going to take a long time to upload. You have to pay for Telestream Cloud, though not nearly as much as the other two options.
Edit: [August 3, 2018] Assimilate has just released a new product called Scratch Play Pro. Unlike Scratch, which is a fully-featured finishing tool, this is primarily for playback, viewing, monitoring, and converting. It does, however, provide licensed ProRes encoding, and at a much cheaper price of $19/month or $199/year. That’s still a good bit to spend, ongoing, just for ProRes exports. And you also have to export twice (once from your NLE or finishing tool, and then again from Scratch Play Pro). But still, in a pinch, it’s one of the best options for exporting licensed ProRes on a PC.
Seriously, just use DNxHR
It’s ok, though. Avid’s DNxHR is a great intermediate codec that has been around for ages (even longer than ProRes, actually) and has pretty much universal support. It works on Macs, PCs, and even Linux.
(Note: DNxHD was the original name for this codec, but they changed the name to DNxHR when they started offering greater-than-HD resolutions)
If you want to use ProRes for a digital intermediate workflow, DNxHR will work pretty much exactly the same way (check out this article for a complete guide on DI workflows). DNxHR was designed to fill the same need as ProRes and offers the same benefits and drawbacks.
To compare different versions of ProRes and DNxHR, you can view/sort/filter them with this comparison tool. Click below:
No, I’m not just an Avid fanboy
Hang on, don’t post that angry comment just yet.
While I started out on an Avid, I’m not attached to it. I’ve cut films on all of the major NLEs and see strengths and weaknesses in each of them. This article is not about Apple vs Avid or Mac vs Windows. It’s an objective evaluation of the situation for Windows editors.
I’ve mentioned DNxHR a lot in this article because it’s very similar to ProRes and uses almost identical technology. But it’s not the only good ProRes alternative.
Cineform (now part of GoPro) has some great intermediate codec options. At the moment, Cineform is not widely used enough that you can send off your film and assume that everyone involved will be familiar with Cineform’s codecs, but they actually do a fantastic job in a digital intermediate workflow.
Cineform is not any harder to work with than ProRes and DNxHR, and it actually uses some newer technology that can give slightly better image quality. The downside is just that it doesn’t have the universal acceptance that ProRes and DNxHD do. Yet.
If you HAVE to deliver a ProRes file
Such is the state of this world that sometimes a client INSISTS that you deliver ProRes, so you’ve got to figure out a way to get ProRes on Windows.
You have a few options:
Option 1: Get all of your assets on a hard drive, connect it to a Mac with your NLE installed, and render it out.
Option 2: If that’s not practical, you can always export a high-quality DNxHR file (something even higher bit-rate than the target flavor of ProRes) and then send that off to a Mac-owning friend who can transcode it to ProRes and send it back.
Option 3: If none of your friends have Macs (are you living under a rock?), and you have a fast internet connection, you can upload your DNxHR file to telestream’s cloud encoder and have them encode your final output.
Option 4: You can buy Scratch and use Scratch to transcode your DNxHR file to ProRes. If it’s a one-off project, you can rent Scratch just for one month instead of buying a full, permanent copy. Now that Assimilate has released Scratch Play Pro at $19/month, it’s not an unreasonable cost.
Option 5: Or you can head to your local Apple store, plug in your thumb drive with the exported DNxHR, fire up Compressor, and transcode to ProRes. (Just kidding. Don’t actually do that.)