Home / Blog

First Look at Codecs: ProRes 422 vs DNxHD

I'm not a codec guy. I don't know the ins and outs of codecs the way engineers do. All I want to know is how how true to the original image the resulting file is when I use a codec, how much space I'm saving, and how much processing power it takes to compress and display it.

I just received Final Cut Studio 2 – quite an impressive package. Among the new features is the ProRes 422 video codec. It comes in two flavors – regular and HQ, and boasts file sizes 20% of uncompressed HD. Sounds a lot like Avid's DNxHD codecs.

So I came up with a little test. I generated six QuickTime video files in Adobe After Effects (neutral territory.) The test pattern was simple enough – an animated blue to white gradient background with a noise filter added to the lower half and a 16:9 box in the center with a waving silky texture. You can download the After Effects CS3 project that I used.

As a control, I used Apple's Uncompressed 10-bit 4:2:2 codec. I rendered the animation to the ProRes 422 (HQ), ProRes 422, Avid DNxHD 175, Avid DNxHD 115, and Avid DNxHD 36 codecs. (Note: The DNxHD flavors are specific to 1080/24p format video. The 30i versions would be DNxHD 220 and 145.)

After re-importing the results in After Effects, I placed each file in a composition along with the Uncompressed 10-bit 4:2:2 version and used the Difference transfer mode to illustrate where the compressed image varied from the uncompressed. The results were quite surprising.

The DNxHD 175 file's difference from the uncompressed was barely visible to the naked eye, but the ProRes 422 (HQ) codec showed significant differences. In fact, in my test, the DNxHD 115 codec also outperformed the ProRes (HQ).

The images below are scaled JPEGs, but they are fair representations of the files rendered in After Effects. The first image is a still frame from the fully rendered animation out of After Effects. Below it are the comparison images' difference mattes against the uncompressed animation.

Added 5/30/07:

Thanks to everyone for the comments and suggestions., especially Graeme Natress.

Inspired, I ran the following test. AJA Kona 3 uncompressed 1080i. Transcoded it to ProRes 422 (HQ) through compressor. Imported the ProRes material back into the FCP 6 project. Placed in a timeline on top of the orignal mater, changed the composite mode to Difference and <drum roll> … the frame was virtually black.

Using the ProRes 422 (HQ) codec as intended… it delivers as promised and a bit better than expected.

Have not had the time to test the Avid codecs under similar conditions within an Avid system, but there's no reason to suspect DNxHD won't perform as well in that test as it did in the more informal test.

Further, I have been able to determine that most of the difference spotted in the Difference mode tests in After Effects was due to some sort of a gamma shift.

The Avid codecs allow you to select the color space (709 or RGB) and I believe that is why the RGB-YUV conversions are apparently handled better by the Avid codecs. (Something to keep in mind when embarking on projects that may require material to meander into the RGB space.)

The big surprise for me was the performance of Avid's DNxHD 36 codec. 3.5% of the original file size… and look at how amazing it did. (Since it's a progressive-only codec, I couldn't run it on my second set of tests.)

I'll give Graeme's red on black test a try sometime in the future.

For the record: 4:4:4 filtering was on in all applicable ProRes renders.

initial animation

Uncompressed file size 15 sec. animation: 1.61 GB.

DNxHD 175 vs. Uncompressed

DNxHD 175 file size 15 sec. animation: 273 MB.

ProRes 422 (HQ) vs. Uncompressed

ProRes 422 (HQ) file size 15 sec. animation: 262.1 MB.

DNxHD 115 vs. Uncompressed

DNxHD 115 file size 15 sec. animation: 180.4 MB.

ProRes 422 vs. Uncompressed

ProRes 422 file size 15 sec. animation: 178.8 MB.

DNxHD 36 vs. Uncompressed

DNxHD 175 file size 15 sec. animation: 56.1 MB.

This test is not meant to be the definitive codec comparison. It's meant as a conversation starter. I only tested using one computer generated file. To the naked eye, all codecs delivered exceptionally well, but the difference mode comparisons show that the Avid codecs were truer to the original image. I'd love to hear from others testing different file types.


Categories: Blog
Tags: ,

  • http://www.scottsimmons.tv/blog editblog

    Great test. I think it’s important that people do these kinds of comparisons between these competing codecs.

  • Pingback: The Editblog » Blog post about DNxHD vs. ProRes422()

  • http://www.whaleofatale.net Jonah Lee Walker

    Does After Effects CS 3 actually export 10 Bit in ProRes422, or do you need to alter your setup text file as you need to do in After Effects 7?

  • http://finalcutpronews.com Jeff Greenberg

    Frank – looks really cool. I can’t see a difference at all in your difference/black JPEGs.

  • http://www.indieshd.com Gopal Balaji

    May i know how you encoded the image whether using final cut pro 6 or compressor. If possible could you do a test on compressor and post result.

    I cant do this since i am living in chennai, india and FCS2 is not yet available for our region.

  • Pingback: DNxHD spanks ProRes 422 in informal codec comparison at FreshDV()

  • http://aulich-adamski.de mactrix

    I didn’t test yet by myself but both the Avid DNxHD and the ProRes codecs operate in 4:2:2 Y’CbCr. Therefore you should test in Y’CbCr color mode, not in RGB like with After Effects. The differences could be caused by 4:2:2 to 4:4:4 chroma upsampling that is done by the DNxHD codecs for display. For the ProRes codec there is an option in the codec settings to do this also. However what you see is not what you get so you should really test in 4:2:2 Y’CbCr like with Shake.

  • http://www.xprove.com Frank Capria

    mactrix –

    Very good point. Here’s my thinking on this. Since everything was processed in After Effects the YUV/RGB conversion issues would be the same for all rendered files, including the Uncompressed 10-bit 4:2:2. I used a single render with multiple output modules in After Effects so all codecs were fed exactly the same data.

    It does appear that there’s a gamma shift going on with the ProRes codec — maybe it handles RGB to YUV encoding differently than the others.

    What do you think?

  • http://www.hdforindies.com Mike Curtis

    Hey Frank, some questions for codec testing:

    1.) Are you SURE you’re getting 10 bit output from your CS3? Often one has to edit text files to make sure the codec enables 10 bit output – see


    2.) If unsure, render a black to white gradient, left to right, on a 1024 pixel wide frame, to your ostensibly 10 bit codec. Bring it back into your AE project. Does each pixel moving right change one pixel in brightness? If they change in jumps every 4 pixels, you’ve got 8 bit output.

    3.) Just glancing at your test frames, are those HD video legal colors? Are you working in the Rec 709 color space?

    4.) Not having tested FCP 6 codecs enough to say, is there a possible gamma shift going on here? That’s been an issue in the past.

    5.) Since AFAIK AE uses RGB not Y’CbCr colorspace, might Final Cut be a better place to export from, since we’re talking video not RGB codecs.

    6.) There’s also a “Enable 4:4:4 chroma filtering” checkbox in the codec options for ProRes that I think it’d be interesting to test:


    While you do clearly state that this is just a conversation starter, respectfully, I think some more testing might be due before conclusive observations can be drawn.


  • http://www.nattress.com Graeme Nattress

    You’ve got to take into account how the codecs do their RGB to YCbCr and YCbCr to RGB conversions. You should do some red text on a black background and look to see how the chroma sampling is handled. If the chroma is smoothed, it will look better but have poorer generational performance. If it’s unsmoothed, it will look worse (although it’s holding the same data) and have superior generational performance.

    Perhaps if you make a graphic and take it into Avid and do a DNXHD test there, and do the differencing on the Avid timeline, and then, do a similar test inside FCP for the ProRes codec you might find that enlightening.

  • Hank den Drijver

    It’s not a gamma thing. The white point of the prores does not match the white point of the 10 bit yuv.
    Only this way you will get the difference signal you’re seeing.
    Looks like a 235 vs 255 issue. Has nothing to do with the quality of the codec.

  • http://elvisripley.com Elvis Ripley

    I did a test and found ProRes to do a great job. It must just be the export process.


  • http://www.digital-arts.net aderi

    This is clearly a YUV to RGB gamma issue and has nothing to do with the codec itself. The massive leftover of info on your difference key should have been a hint. This test to date does not reveal anything about the codec from what I gather here (as confirmed by others prior to me). What was your method for converting from avid to FC? (There are gamma issues there in most cases)

  • http://www.studiodaily.com/blog Frank Capria


    Why bother reading the entire post? Did you miss the half dozen paragraphs explaining what further tests revealed?

    Thanks so much for (re)stating the obvious.

  • http://www.nattress.com Graeme Nattress

    Investigating further, it looks to be how AE specifically is handling things.

    When AE renders the ProRes project, it passes RGB with a gamma of 2.199997 to the codec, which the codec converts directly to Y’CbCr using the Rec.709 matrix. Good so far. AE then tags the resulting render file with a ‘gama’ image description extension set to 2.199997. I don’t think that this should be done for a Y’CbCr format though.

    Things go awry when AE decodes the rendered ProRes file. AE requests a decode to RGB with a gamm of 2.199997. Since the codec is Y’CbCr-based, it decodes to 2vuy and QuickTime performs the 2vuy to RGB conversion. Apparently, this 2.199997 gamma request causes QT to invoke the Rec.601 conversion matrix rather than the Rec.709 matrix, resulting in a color shift.

    The same color shift does not occur with Uncompressed 10-bit 4:2:2 because AE uses its own built-in v210 to RGB conversion routine rather than going through QuickTime.


  • Olm

    Where is the comparison of number of RT streams? Isn’t good quality DNxHD one only stream and ProRes is 14? That makes as much difference in time and euro as a gamma change, right?

  • Prune

    Good article. Interesting :)

    I heard in Final Cut Studio presentation in Paris that the preview in FC is half the prores quality by default. Maybe you have to set it to ful quality ?
    Of course, this is not the case if you are just working on the final rendered files with compressor..

    Keep testing !

  • VideoEdit

    Oln –

    This is not a test about performance. It is about quality. Nevertheless, did you consider that ProRes performs rather poorly on PPC Macs when compared to ProRes on Intel Macs or DNxHD on either platform?

    Just something to think about.

  • Pingback: Capria.TV :: DNxHD vs. ProRes 422 redux()

  • andres serra


    I’ll be working with PRORES 422 codec very soon, and I have an after effects station, separate from final cut, is there a Quicktime codec ( freeware or buy ), that will work with after effects? or view a quicktime PRORES 422 as a stand alone. Do I need an specific video card?

    thank you

  • Pingback: after effects quicktime codec()

  • Pingback: Cognitive Zest » In Search of a Good HD Codec()

  • http://www.ipsupermarket.com codecs

    Hi! is this codec is better than H.264 or Divx?

  • Pingback: How The East Was Won » Blog Archive » Avid’s codecs are simply the best.()

  • Pingback: Blog » Blog Archive » DNxHD Settings (revisited)()

  • http://www.alacarte-paris-apartments.com Richard in Paris

    Very nice test. I think it’s important that people do these kinds of comparisons between these competing codecs and the relative issues that come from them.

  • ProRes follower

    ProRes 422 in the news. On 03/31/2011 two companies made annoucements related to ProRes.

    Telestream, the leading provider of video transcoding software solutions, today announced that its Vantage, FlipFactory, and Episode Engine transcoding software for Windows-based servers now allow encoding to the Apple ProRes video codec. Telestream is the first company to enable the creation of ProRes in Windows-based transcoding applications, for use in Final Cut Studio production environments, as well as in preparing content for distribution through iTunes.


    Civolution, the leading provider of technology and services for identifying, managing and monetizing media content, today announced two new additions to its NexGuard watermarking technologies that enables watermarking of pre-release content in the Apple ProRes 422 codec. The new NexGuard technologies are a software plug-in for Final Cut Studio and a standalone software solution to process ProRes .mov files.


  • Pingback: Sound Devices PIX 240 ????? | ???????()

  • Brian

    Awesome! Thanks for the comparison work. I’m using a SoundDevices Pixe240 recording 1080i and wanted to know the better codec to go with. I have been using Apple’s ProRes, however, want to keep the footage as compatible and clean as possible. All things considered, I will be recording DNxHD from this point forth.

  • http://twitter.com/robertstar20 Robert

    There doesn’t seem to be any fine detail in your test footage — apart from the noise part, presumably. Now note that the noise area is bright (i.e., shows a great difference) in the DNxHD footage. This strongly suggests that the image is getting softened as a side-effect of the compression; softening a soft wavy image or a solid color bar isn’t going to create much of a difference.

    Conversely, I can see the wavy texture in the difference file for the ProRes codecs. If I saw a horrible blocky pattern, I would be concerned — but subtracting a very dim wavy texture from another wavy texture just gives you a marginally different coloured wavy texture, hardly a worse outcome than softer footage.

    Overall, this comparison should be taken with a grain of salt, as you said. Try converting a sound recording to MP3 at a very high quality, and then subtracting the original sound away. You’ll get a lot of residual noise. Is this because the compression is bad? No — it’s because the human ear is very insensitive to the phase of signals, so the MP3 codec throws this away.

    This test is similarly flawed — consider if one codec was specially contrived to perform well in this test (an easy task and a naive trap to fall into as a codec designer), and a second was specifically designed to only throw away that which is invisible to the human senses. Then the former would win this test, and the latter would look better (indeed, perfect) to humans. What are we aiming for in the end?