Post Production

Windows ProRes: First Impression

Is this new ProRes encoder the grail you’ve been looking for?

I’ve missed ProRes. I’m used to jumping between Mac and Windows, and I often say that once I’m in Adobe-land I can’t tell the difference. But a few months ago I switched to Windows permanently and the thing I miss most is ProRes.

Last week on the ProVideo Coalition Facebook page, a PVC reader posted a link to a new product offering the ability to encode ProRes on Windows. Krzysztof Karnicki had a simple question – is this for real? I was intrigued, but most of all I was excited – could this be the product I was looking for? Please let it be true…

There’s a lot to like about Apple’s ProRes family. There are just enough variations – from lower bandwidth proxy & LT versions, to higher-bandwidth 422 & HQ, and then the 4444 version with alpha channel support. It works at pretty much any resolution you’re likely to encounter, and most of all it’s commonly used in the production industry. In the 10 years since Apple launched ProRes, it’s something that has fulfilled a need and just worked.

While I am generally platform agnostic, there’s no denying that Mac and Windows each have their own strengths and weaknesses. And one of the more annoying problems with working on Windows machines is the lack of full ProRes support. Yes, Apple provide a ProRes decoder for Windows, but there hasn’t been any official way to encode ProRes files on Windows. Telestream offer ProRes encoding as a cloud-based service, but that’s not the same as rendering out of After Effects on your local machine.

Considering that the first version of ProRes was announced in 2007, this is a little surprising. And it’s not an uncommon question – ProRes is a fundamental part of many post workflows and it only takes a simple Google search to see how many Windows users are looking for some way of rendering ProRes. There have been previous attempts to get ProRes encoding working on Windows machines – you can do it using ffmpeg – but the results haven’t been as good as the real thing.

The lack of ProRes encoding on Windows is a common problem, especially for those who have switched from Macs to Windows and are trying to maintain their existing workflows. While there’s a lot of love out there for the Avid DNx codecs, they’re simply not as friendly as the ProRes family and it doesn’t appear to be as simple as just using DNx instead.

This is what greets the casual After Effects user setting up a render with an Avid DnX codec.

If you’re used to using ProRes, then the first encounter with a DNx codec can be surprising – why do you have to choose different versions depending on the resolution? Or frame rate? Why so many options? Does the i stand for interlaced, or just plain intimidation?

Compared to good old ProRes, the Avid DNx codecs are like kale smoothies. There’s a lot of people out there telling you how great they are, but the first time you try one it’s a shock to the system.

Last year I worked at a company that had purchased a product called “miraizon” – a product that rendered ProRes files on Windows machines. It was the first time I’d seen ProRes encoding on Windows, and I was a little surprised I hadn’t heard of it before. But I quickly noticed the problem – it simply wasn’t very good. Even by eye I could see blockiness, and I quickly discovered that it always encoded 8-bit files regardless of the settings in After Effects. When I looked up the company’s website to see if there were bug fixes or updates, I discovered they had closed down and miraizon was no longer supported.

The Windows ProRes website is as functional as you’d expect for a company that only launched two weeks ago.

But now there’s a new contender – simply called “Windows ProRes”. Thanks to Krzysztof on the ProVideo Coalition Facebook page, I headed over to the website and had a quick look. It seemed to offer everything I’d want, and they had discount pricing for the month of January. While my previous experience with miraizon left me skeptical, we purchased a couple of copies to see how it performed.

When I sent them an email, Arnold replied promptly and confirmed that yes – Windows ProRes is still in beta and no, this has not been officially licensed from Apple. The company only launched two weeks ago and the current product isn’t considered a “final” just yet.


The thing I like about ProRes is that it just works. There’s not a lot to fiddle with. Testing a ProRes encoder is not like testing a camera, where there are knobs and menus to adjust and lots of competitors to measure against.

The basic test for Windows ProRes is to see if it works the same as ProRes does on a Mac. That’s about it.

Having been less than impressed by the miraizon product, which is no longer available, my main priority was to compare the encodes from a Mac with the same content encoded using Windows ProRes.

I opened After Effects on my Mac and put together a quick collection of footage from different jobs I’ve been working on. I set up a variety of ProRes renders – LT and 422 at “millions of colours”, 422HQ and 4444 at “trillions” of colours. Before I hit “render”, I saved.

Then I opened the same project on my Windows machine, and rendered exactly the same thing.

Before I even hit the “render” button I noticed something promising – when I opened up the project on my Windows machine I didn’t get an error message about missing output modules. It seemed as though After Effects on Windows was recognizing the ProRes items that I queued up on my Mac.

Render queue to test normal footage at HD resolution.

When checking the output modules the codec shows up as “Windows ProRes”, but all of the dialogue boxes and options appear to be the same as on a Mac.

This is worth emphasizing. I queued up the renders on my Mac, and opened the project on Windows. No errors. I wasn’t just rendering the same footage, I was rendering exactly the same render queue, with exactly the same render and output settings.

This might seem like a little thing but it’s quite significant. It means that After Effects is not seeing the Windows ProRes codec any differently to the Apple one. It means you can queue up ProRes renders on a Windows machine and then open the project on a Mac without any problems, and vice versa.

Although I work on a Windows machine, our render farm is comprised of headless Mac Minis and so this is very important. If the Macs didn’t recognize the Windows ProRes codec as ProRes, then we wouldn’t be able to queue up ProRes renders on our desktop Windows machines and submit them remotely – the mac minis would open up the project but think the output module was missing. So this cross-platform transparency is very important, and a big tick for Windows ProRes.

As I said above – the most you can really ask for is that Windows ProRes works the same as Apple’s ProRes does on a Mac. So far, so good.


At first glance, the outputs from both machines looked identical. There was none of the blockiness or banding which was easily visible in the older miraizon product.

The file sizes were similar but not identical, and the data rates were too.

File size comparison for the HD footage tests

The next step was to stack the Windows renders on top of the Mac render and set the top layer to “difference”. If both layers were 100% identical then the result would be a perfectly black frame.

Simple difference test to compare Mac vs Windows outputs.

And that’s what it looked like to the eye – just black – so to emphasise any differences we need to boost them with the levels effect.

The levels effect boosts the difference between the two layers to make it visible. White is normally 255, but lowering it to 4 exaggerates the differences.

I added an adjustment layer with the levels effect and decreased the “input white” parameter until I started to see something. While this test demonstrates that the two files are not exactly identical, they are very very close. In order to make the differences clearly visible, I had to set the input white value to 4. What was also promising was that the differences – as minimal as they were – were more like an even noise, and not confined to edges or gradients.

Even with the levels effect boosted by setting the “input white” value to 4, instead of 255, the differences between the two outputs are barely visible.

While Windows ProRes is a beta product, this was enough for me to be satisfied with the purchase. But having been burned by miraizon, there were a few more things I wanted to try.

A great feature of ProRes is its support for bit depths greater than 8-bit. Because I had discovered that the miraizon encoder always appeared to output an 8-bit image, regardless of the settings in After Effects, I wanted to test Windows ProRes.

When I ask for trillions of colours, I expect to get trillions of colours…

I have a simple test that I use to demonstrate the difference in bit depth to new users. I simply make a new comp and apply the “4 colour gradient” effect. Then I apply the “exposure” effect and darken the image down significantly: –10 stops is a good value. At this point, the display looks almost completely black. Then I duplicate the exposure effect and change the second one to +10 stops. This completely reverses the previous exposure effect, so the image should look the same as the default colour gradient.

This is how I demonstrate bit depth in After Effects. The first exposure effect darkens the image by 10 stops, the second brightens it by 10 stops. In 8-bit mode the result has severe banding, in 16-bit mode the result is exactly the same as the original gradient.

But in 8-bit mode, the result is very visible artifacts. When working with 8-bit colour depth, the 0-255 range of each pixel isn’t enough to preserve image data through such a large adjustment. Darkening the image so significantly and then brightening it again results is very visible banding and blockiness.   If you do the same thing to footage, you end up with a heavily distorted and posterised look.

But as soon as you switch to 16 or 32 bit mode, these artifacts go away. The range of each pixel has now expanded from 256 levels to 65,556. This massive jump in fidelity is enough to completely preserve the original image through the -10 / +10 stop exposure process. In fact – if you compare the original 4 colour gradient with one that has been through the -10 / +10 stops adjustment, the results are identical. There is absolutely no difference at all.

In order to test whether Windows ProRes is really encoding 8,10 or 16 bit movies, I would render out clips with only the first exposure adjustment. Then I would import them and apply the second exposure adjustment and see what the result was.

With a lossless 16 bit file format, the end result is still identical to the source. As a control case I rendered out a frame of the 4 colour gradient with -10 stops exposure, using a 16 bit TIFF file format. When I re-imported the TIFF file, applied the exposure effect with +10 stops and compared it to the original gradient (using the same difference mode and adjustment layer mentioned before) there was no difference at all.

Unfortunately my first test with ProRes was disappointing. The renders out of After Effects were dark as expected – but after I reimported them, applying the exposure effect failed to reveal any information at all.  The black screen really was just that – pure black, with no hidden image.

ProRes is a lossy format, and only 10-bit as opposed to the full 16-bits that After Effects can work at. So perhaps I was asking too much of it.

I tried again using an 8 stops round-trip instead of 10, and this time I had more success. All of the renders – on both Mac and Windows – responded to the second exposure effect to reveal an image similar to the original 4 colour gradient.

As expected, the ProRes LT and ProRes 422 renders (which were rendered with the 8-bit “millions of colours” setting)  looked noisy and had extreme banding that showed the limits of doing such heavy processing with only 256 values available for each pixel. Interestingly, the LT and 422 renders looked visually the same.

The 8-stop round trip results in severe blockiness and banding as the codecs only have 256 values per pixel, not enough to survive the 8 stops round-trip.

The ProRes HQ and ProRes 4444 renders (using the “trillions of colours” setting) fared much better – but they still weren’t perfect. While there was much more detail than in the LT and 422 renders, there was still visible banding and blockiness. A 10-bit format provides 1024 values for each pixel – which is four times as much as the 256 levels of 8-bit images, but still a long way short of the 65,556 in a 16 bit format.

ProRes 422HQ, when rendered using “trillions of colours” is a 10-bit format, so there’s far less banding and blockiness even after the same 8-stop round trip.  Each pixel has 1024 values, not just 256.

The point of this test was to see if there was a clear difference between the way the Windows ProRes encoder deals with 8-bit data from After Effects, as compared to 16-bit.  This corresponds to choosing “millions” or “trillions” of colours in the output module. Clearly there is a differemce, and so the Windows ProRes codecs are working as expected.

Even with the additional bit depth, the HQ and 4444 examples didn’t look that great, so I did the same test on a Mac to see if Apple’s codecs performed differently.

The results for the LT and 422 versions rendered on a Mac were visually indistinguishable from the Windows ProRes versions, but the ProRes HQ looked noticeably different.

Exactly the same ProRes 422HQ render done on a Mac exhibits different artifacts to the Windows ProRes encoder.

The Mac version also displayed visible banding, but in a different and less blocky way. Generally, the Windows and Mac renders were very similar even with these artificially challenging tests, but it was the only time that the Windows ProRes result looked visibly different to the Mac equivalent.   While this doesn’t mean either is better than the other, it does serve as a reminder that the Windows and Mac ProRes results aren’t identical, and that in difficult circumstances these differences are more pronounced.

When I repeated the process yet again using a -4 / +4 stops round trip, the results were encouraging. Again, the ProRes LT and 422 @ “millions” displayed the 8-bit limitations with extensive banding and blockiness on both Mac and Windows machines. But this time, the ProRes HQ and 4444 renders @ “trillions” survived the aggressive processing to be visually indistinguishable from the original gradient.  In the same way that the LT and 422 renders looked the same visually, the 422HQ and 4444 renders also looked the same to the eye.

While this demonstrates that the Windows ProRes encoders are true 10-bit when given sources that higher than 8-bit, it also suggests that the ProRes 4444 codec is 10-bit as well – otherwise there would have been a visible difference between the 422HQ render and the 4444 render.  Apparently, the 4444 version of ProRes has the ability to do 12-bit RGB encoding, but there are no settings within After Effects to control this – on Mac or Windows.  So if it’s true then either the capability is not supported by After Effects, or the Windows ProRes encoder, or both.

By this stage I had satisfied my main concerns with the product. I was very happy with the quality of the renders when compared to the same renders from a Mac. I was satisfied that the HQ and 4444 variations of the codec used 10-bits when fed with 16-bit data, and I was relieved that After Effects treated the Windows ProRes codec in the same way as the Apple version, so that renders on one OS can be queued up and opened on the other OS without errors.


Arnold was quite open about this being a beta product, and happily shared a few known bugs. He said there are some issues with alpha channel tearing when rendering 4K with ProRes 4444, that unusual aspect ratios can cause problems, as can rendering 6K images – the largest size currently supported.

As I was working through my tests, I noticed a few anomalies with file sizes. All of my initial tests had been with “real” footage – and as expected the different variations of ProRes codec rendered to different files sizes. The ProRes LT codec was the smallest, then ProRes 422, then ProRes 422HQ, with ProRes 4444 being the largest. As noted earlier, the files sizes were pretty close to the same clips rendered on a Mac.

But once I started rendering out the 4 colour gradients with different exposure adjustments, this changed. The 4 colour gradient with a -10 stops adjustment looked almost black, but the LT file was suddenly larger than the ProRes 422HQ file. More renders revealed more anomalies with the files sizes of ProRes LT and 422 renders. It appears that while regular footage encodes as expected, more extreme footage and artificial test patterns produce inconsistent results.

The same files rendered on a Mac did not show these anomalies – suggesting that this is an issue for the Windows ProRes team to look at.

With the file size differences piquing my interest, I decided to try encoding another batch of normal footage to see how the file sizes differed between the Mac and Windows versions.

This time, I queued up my outputs on my Windows machine and hit render, then a few seconds later I heard the distinctive sheep-bleat announcing a failed render. It appeared that the ProRes 422HQ output had failed, without any clear indication of why. I re-queued it and re-rendered, and it failed again. I tried lots of different things – restarting, rebooting, different file names, different destinations, but both the 422HQ and 4444 encodes consistently failed on exactly the same frame every time.

The “voodoo frame” tripped up the HQ and 4444 codecs every time.

The interesting thing was that the renders would only fail if I rendered the entire composition. If I rendered a shorter version – eg ten frames before the ‘voodoo’ frame, then it would work. If I changed the “voodoo” frame even slightly, it would work. But somehow, the combination of a specific type of image and its location in the timeline combined to trip up the encoder. This was pretty interesting, so I reduced the project down to just the incriminating items, confirmed again that it would always consistently fail on exactly the same frame, and then zipped everything up and emailed it to Arnold for his diagnosis.


Windows ProRes is a beta product, and it has a few quirks. But in ordinary usage the product works exactly as you would expect- and it does it better than the only alternative I’ve seen  before – the now defunct miraizon.

For a company that only launched two weeks ago, this is a very promising product. It’s already changed the way I work and solved some basic workflow issues that I’ve had since switching to Windows last year. Just being able to queue up a ProRes render on my Windows machine has made my life easier, and considering the investment we’ve made in our mac mini render farm, this benefit alone is worth us paying for before we even consider desktop rendering (after we switched to Windows last year, we’ve still needed a desktop Mac to queue up ProRes encodes for our render farm).

ProRes is a great codec family and it isn’t going away any time soon. Windows ProRes is a product that is filling a very obvious gap in the market, and although the beta has a few quirks the product is very impressive for a company that only launched two weeks ago.

I don’t think our spare Mac is going away any time soon, and we’ll probably need to have it as a backup until some of the quirks in the Windows ProRes beta are sorted out. But already this has dramatically changed our workflow and made the switch to Windows that much easier.

As the Windows ProRes team move the product out of beta and fix some of their issues, I’ll post updates in the future.

Update – 3rd Feb

Some of our readers have reported problems trying to install the Windows ProRes product:

I sent a quick email to the support address, and received the following reply from Arnold:

“There have been about 5 cases, out of hundreds, where it didn’t immediately show up in their programs.  We try and diagnose the program first by asking them to make sure it’s installed correctly and then double checking whether they have Quicktime installed.  Reinstalling Quicktime fixed it for a couple people and reinstalling the specific Adobe program fixed it for one so far.  It’s impossible for us to diagnose what could be wrong on their end of the setup process so we have just been asking them to try these options.  There’s only one open case now where the guy still hasn’t gotten it to show up but we’re waiting on his response now.  I don’t think that in any of these cases it’s a larger scale bug on our end.”

Update – 4th Feb

It seems that encoding ProRes on Windows is something lots of people are interested in, as there have been more comments and feedback on this article than everything else I have previously written for the PVC, combined.

A number of people have pointed out some inaccuracies regarding ProRes and bit depth.  James (commenting below) is correct that I had not read the Apple ProRes white paper, because I didn’t know there was one.  The white paper makes for a good read and clarifies issues such as data rate and bit-depth.  As an After Effects compositor, I generally only think in terms of working with After Effects – which offers 8 and 16 bit depth but not 10 or 12, and when rendering the options are only “millions” or “trillions” of colours.  When I rendered to ProRes LT and 422, I deliberately had After Effects working at 16-bit depth, but I set the output module to 8-bits by setting it to “millions of colours”.

But many more people have commented on the fact that this is an unauthorised implementation of Apple technology.  The ProRes white paper even addresses unauthorised products at the very start, before they even get into the technical details, and warns:

“Using any unauthorized implementation (like the FFmpeg and derivative implementations) may lead to decoding errors, performance degradation, incompatibility, and instability.”

The fact that Windows ProRes is unauthorised isn’t something that I focussed on, but evidently it is important to many people.  It isn’t something I have a strong personal opinion about, and I would hope that it’s clear that I am an animator and not a lawyer.  But despite my own personal ambivalence towards the topic, there are a few points I can add.

Firstly, Windows ProRes has always been open that their product is unauthorised.  When I specifically asked them , Arnold responded:

“All I can say is we’re all Apple fans and own a ton of Apple products in addition to previously being a Mac-only post house.  Apple has chosen to focus on their consumer market, leaving most of their professional market in the dark.  From the end of Final Cut Pro to discontinuation of their Mac Pro Towers, they have put many high-end visual professionals in a bind.  ProRes became a standard years ago and Windows ProRes is simply meant as a compatibility bridge for those looking to use latest high-end hardware without having to force their clients learn something new.” – Windows ProRes

Secondly, an unauthorised implementation of ProRes is not illegal.  It’s actually quite common for standards in the IT industry to have unauthorised versions.  SAMBA is an “unauthorised” implementation of the  Windows SMB protocol, and is so prevalent that even some IT professionals don’t realise they’re different.  WINE is an unauthorised implementation of the Win32 API, and there are unauthorised implementations of file systems like NTFS.  But perhaps one of the most prevalent examples is AMD, who have been manufacturing chips that use the Intel x86 instruction set for decades.

Creating an unauthorised implementation of another company’s protocols is nothing new to the IT industry, and someone on this page suggests that the PC itself owes its history to such a process – citing this old article which discusses the “clean room” approach.

So Apple have a generic warning against using unauthorised ProRes codecs, and Windows ProRes are quite open about being an unauthorised implementation.  If there was an alternative, authorised way of rendering to ProRes on Windows directly out of After Effects, then perhaps the discussion may be different.  But right now, there isn’t, and if Apple were really serious about getting people to stop using unauthorised ProRes codecs, they should start by releasing their own, official Apple ProRes codec for Windows.

Was This Post Helpful:

0 votes, 0 avg. rating

Share Our Article

Chris was born a geek, and was lucky enough to own a Commodore 64 at a time when the number of students at his primary school who owned a computer could be counted on one…

Leave a Reply

22 Comment threads
32 Thread replies
Most reacted comment
Hottest comment thread
30 Comment authors
Farhan ThakurFederico OndartsJoseemarch 2018 calendarJames Recent comment authors
newest oldest most voted
Notify of

Your article alludes to, but simply doesn’t confront, the reality that this is essentially bound to remain an illegal piece of software unless Apple licenses it (and I don’t believe they will, and/or already refused as always).


Cinemartin already has a product on the market.

I can’t help but think Apple is going to find a way to detect and prevent these from being used (decoded) on products running on macOS.

Chris Zwar
Chris Zwar

Thanks guys for your comments. I hadn’t seen the Cinemartin product, but apart from it being very expensive it works in a different way. I only watched their YouTube video but it’s clear they were not rendering ProRes directly out of After Effects. Their product would not allow you to queue up ProRes renders on a Windows machine and then open the same project on a Mac, for example. You seem to have to render out of AE first to an intermediate codec, and then it encodes to ProRes separately. It’s not the type of workflow I’m looking for although… Read more »

Soren Johnstone
Soren Johnstone

The Miraizon site works and it does have 10 bit ProRes (as all ProRes is 10bit):
Very easy it use — straight out of Premiere you get ProRes up to 444 10bit on Windows.

Paul Gale
Paul Gale

For me, the biggest thing you’ve not addressed here is speed of rendering. I had the Miraizon codecs and they were VERY slow in my tests.
Obviously your mac and windows machine probably have very different specs but it would be interesting to get a view on the performance aspect of this codec.
Thanks for your otherwise detailed review though 🙂
Mind you, I’ve never actually needed prores outside of a cross-platform project.


Just to clear up a popular misconception that a lot of people have, as they don’t read the Prores White Paper. Both 4444 and 4444XQ do 12bit colour channels and 16bit alpha. Not 16bit colour.

All other flavours of Prores are 10bit, just with more and more compression (Apple Prores white paper, p9). There are no 8bit restrictions on Prores like some DNx flavours. It’ll only be 8bit if you feed it 8bit data.

Tristan Summers

There have been many ways to convert to pro res using ffmpeg variants, cliptoolz being the most stable and professional, and Scratch is a great, fast grading product with the only official, and therefore acceptable to iTunes Windows pro res solution. Can i suggest you simply learn to use scopes properly to check for bit depth encoding, as an 8 bit render of a gradient is stunningly jagged compared to a10bit one. But this does seem a solution for direct from after effects. I suspect it still uses ffmpeg. I experience similar single frame crashes with cinemartin, using time lapse,… Read more »

Tristan Summers

As a side note i have worked for major channels who refuse to accept any form of pro res. Wood be keen to know why

Tristan Summers

Early ffmpeg solutions were 8 bit only, but since the broadcast version has been combined with the standard one, about three years ago now, most encoders now work in 10 bit. Miraizon, cinemartin etc are very old. Many newer products produce much better versions of pro res that are fine.


Your LT and 422 has internal QT engine dithering, that’s why they are bigger and also look different than HQ. This is problem with uncontrolled/unwanted QT engine feature on Windows. It was described by David from Cineform.

smarty pants
smarty pants

You should try DNxHR instead of DNxHD and then re-think your opening sentiments 😉

Lee MJ Daley

I was using using ffmpeg for about a year to deliver my work to post houses in the UK with no issues but switched to a monthly subscription of Scratch which works flawlessly.

Francois Turcotte
Francois Turcotte

Well, after playing around with this plugin, I decided to use it “in productions” this weekend, and it performed marvellously! The plugin rendered, without any fuss, everything I thrown at it. After Effects, Media Encore, Premier Pro, all of it. Even renders that stretch out to 9h came out perfect. And the multi-generation lossless feature also seam to be part of the package. Very impressed and very happy with this Mac workaround. There is 1 bug that kept appearing randomly though. Some times, at the end of a Render, a error message appears and the software was unable to save… Read more »

Jenny Everywhere
Jenny Everywhere

There’s a lot that can happen in two months. I found your article this evening, and checked the “ProRes Codec for Windows” site. I had to sigh…

I guess it simply was not meant to be…

comment image

Mrjj Syzygy Masters
Mrjj Syzygy Masters

hahah unauthorized… Means that if Apple dont see an option to milk it, it will be banned 🙂


I wish woz took over Apple and opened it up. They are the worst at sharing tech. I hope final cut just fails. It’s much more responsible to support os agnostic software companies in the long run, other wise they have you by the balls.

Ben S
Ben S

Apparently isn’t accepting new orders anymore. I’ve emailed their support address, but no response yet. Chris, maybe you could ping your contact Arnold for some info on the current situation and update the article here with any new developments?

Bill Weldon
Bill Weldon

If you go to the website, they are not selling it anymore. Apple’s legal team strikes again!

march 2018 calendar

I agree with you.


Have you tried scratch play pro? While it costs $ 20 per month, they say they export native prores in windows. If it fulfills what was promised it would be worth those $ 20 if or if. I hope you try it and you can give us an interesting conclusion like you did with windows prores.

Federico Ondarts
Federico Ondarts

Now you have Prores on windows out of the box with the adobe suite!

Farhan Thakur

Very impressed and very happy with this Mac workaround. There is 1 bug that kept appearing randomly though.