Why ProRes on Windows is Still Not a Good Option for Editors

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.

If you’re using any kind of proxy workflow or intermediate workflow, then you’re going to need to choose a different codec to encode. Decode is not enough.

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.

ProRes On Windows Shutting Down

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 issues.

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.

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:

codec table image 1

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.

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.)



  • Tony Gallardo

    Great read…you can also add Blackmagic Design’s Fusion to the mix as well. It will render ProRes on Windows and is licensed by Apple…It’s avail in Fusion version 9, and it’s only $300 now

    • Roger Bolton

      What about the free version of Fusion 9, can that encode ProRes ?

      • Tony Gallardo

        No just studio version

  • stib

    I totally agree that there are better intermediate codecs for Windows, that’s one of the benefits of ditching the Apple platform: choice. You could add Grass Valley, HuffYUV and UTVideo to the list of lossless or near lossless codecs that are available.

    But your attitude to FFMPEG is pure bollocks. “…this reverse-engineering is not actually illegal, but it’s… sketchy” What does that even mean? I don’t know anything about it so I distrust it?

    Open source implementations of prores can be shown to be mathematically and visually just as good as the Apple implementation, and in some cases better. FFMPEG is a huge and long-lived open source project run by people with an amazing depth of knowledge about video encoding, and who are professionals in the field. It is used in professional workflows and on servers around the globe, in mission-critical applications. What software do you think YouTube, the world’s largest provider of video content uses to compress the myriad forms of video it receives? Yup it’s based on FFMPEG.

    For anyone working on Windows who needs to deliver ProRes content to those who are still mac-encumbered ffmpeg is a reliable, high-quality and free solution.

    • Roger Bolton

      I’m all in favour of open source where appropriate, but sorry you’re not being realistic here. The issue is an editor can’t afford to take the chance that their ProRes file will drop frames, glitch, stutter, show tearing or any slight image quality issue on ALL the different Pro Res players out there that their clients might be using. FFMpeg is great software, and yes it’s used in professional workflows but not specifically for encoding Pro Res, typically it’s used in that situation to encode formats where the specification is freely available so they know that it is compliant.

      • stib

        Sorry, what “prores players” are you talking about? Quicktime player and…

        Oh I know – VLC… Oh, wait.

    • mulvya

      To add to the above, this article is vague and doesn’t provide any concrete evidence of the FUD it presents. The author could have done or reported on A/B testing of the outputs of FFmpeg and a licensed encoder using a video quality metric such as PSNR, SSIM or the now public VMAF library by Netflix (they use it to assess content quality; can be included/compiled with FFmpeg now).

      The author could have also presented specific anecdotes of how open-source encoders’ output have failed in workflows i.e. which player or ingest tool, and what errors were reported. In which and how many cases did OSS output pass the test. A qualified assessment would have made this article a credible reference.

      As the author noted, writing codecs is hard and so is reverse-engineering, most (all?) open-source ProRes encoders available use libavcodec PR encoders from FFmpeg or Libav as their engine. In that scenario, the business practices of third-party vendors who lay a GUI and branding on top doesn’t reflect on the code quality of the engine underneath. It may be useful to review these tools for convenience and UI polish but the calibre of the encoding is best assessed by using FFmpeg as the benchmark.

    • David

      Stephen, I made an edit to the article to emphasize that I am actually a big fan of FFmpeg, just not its reverse-engineered ProRes implementation, for all of the reasons I mentioned in the article.

      Here is one example of a piece of software rejecting a reverse-engineered FFmpeg file. Also, as he noted, the frame rate was incorrectly specified by the encoder. http://community.avid.com/forums/p/130695/746688.aspx

      As you yourself discovered, FFmpeg’s ProRes implementation included some alpha-channel errors, and it took more than six months for the errors to be fixed. https://video.stackexchange.com/…/bad-quality-encodes… That is not an acceptable delay for a professional workflow.

      Here is an example of image quality issues from FFmpeg’s encoder: http://ffmpeg.gusari.org/viewtopic.php?f=11&t=2570

      My main point is that a professional workflow requires stable, dependable guaranteed performance. That is the reason why postproduction professionals use ProRes.

      • stib

        6 Months is pretty good by my reckoning. Just consider how long it takes Adobe or Apple to fix bugs, if ever.

        But yeah, I should reiterate that I agree with the main thrust of your article. Prores is a great codec, but when you haven’t bought into Apple’s vendor lock-in it’s not necessarily the best either for workflow, speed or technical quality.

  • Roger Bolton

    Are Scratch, Nuke and now Fusion really the ONLY licensed ProRes encoders on windows? No one makes simple watch folder app with a licensed encoder?
    However that does lead to another perfectly good solution. Buy a second hand mac mini, put it on your network and set up a watch folder on your shared server so that any movie file placed there is converted to ProRes by the mac mini. There’s a number of different ways of doing that, and the end result is very simple, just export from your windows NLE to the watch folder and within a few minutes your ProRes file will be sitting there back on the network share you set up.

    • Slayer of Fascist Slayer

      Software by Digital Vision is called LOKI. As all Digital Vision software, LOKI uses Apple licensed Prores and it does utilize watch folders. As an added bonus, it can add a myriad of wonderful plug in filters, like Clarity Noise reduction. But be aware, it is not cheap nor is it fast. Said that, LOKI is incredibly flexible and scriptable and it can utilize a render farm, if you have number of Windows computers in your facility.

    • Patrick Taylor

      Fusion 9, Studio version

  • Alex Gollner

    Apple could learn from Avid when it comes to the option for having alpha channels for all flavours of DNxHR.

  • Nina Staum

    Really timely. I’m researching a transition from Avid to Premiere on Windows and DNxHD is the leading contender for codecs.
    If anyone has trusted Resolve settings for encoding DNxHD intermediate files, please share!! I am looking at DNx175 MXF Op1A for web content.

  • medeasin

    I’m a newbie when it comes to ProRes, but my Ninja Flame monitor uses ProRes. I edit these files on Vegas Pro and then render and post to YouTube. Is it not ProRes when I render? Is there a step I need to keep it ProRes? And if it isn’t ProRes in the render, what is it?

    • David

      It is ProRes when you render, and you don’t need to do anything to keep it ProRes. PCs have no problem reading ProRes files – they just can’t write/encode/export ProRes files in a reliable way. When you render to post to YouTube, I imagine that you’re exporting to an h.264 codec.

  • Antoine Dorni

    The alpha bug in ffmpeg’s prores 4444 has been fixed 🙂 . There are some decoding bugs from After Effects but overall the encoder is reliable

  • Joe Nicklo

    Dumb question but, is there any quality loss whatsoever when going from DNxHR to ProRes when using Compressor?

    • David

      Not a dumb question 🙂 But a complicated answer. There will almost always be some theoretical loss if you move from one type of compression to another. But in practical terms, it really depends on how compressed the source and destination codecs are. Since ProRes and DNx use similar compression techniques, you can use the bitrate number as a proxy for the amount of compression happening. If you’re moving from a lower-bitrate DNx to a higher-bitrate ProRes, then you’re probably fine. If you’re moving to a lower-bitrate ProRes, then watch out.
      This spreadsheet will probably be helpful: https://blog.frame.io/2017/02/13/50-intermediate-codecs-compared/