The difference between DNxHR and ProRes codecs

The ultimate DNxHR and ProRes guide

 

T he Avid DNxHR and Apple Prores codec families are designed to meet the needs of modern, streamlined post-production workflows.

These days we capture source material on a variety of cameras- action cams, smart phones, drones and high-resolution cameras, and codecs makes it easy to work with any formats. With the growing demand for 4K deliveries, we need fast and reliable codecs that ensure reel-time playback while maintaining superior image quality. 

Both the DNxHR and ProRes families offer a variety of codecs for different compressions, data rates and file sizes. Some with just enough image information needed for editing, others for high-quality color grading and finishing, and lossless ones for mastering and archiving.

Below are the full list of codecs from both families.

Codec Color sampling Usage
DNxHR 444 4:4:4 Finishing
DNxHR HQX 4:2:2 Finishing
DNxHR HQ 4:2:2 Mezzanine*
DNxHR SQ 4:2:2 SQ Editorial
DNxHR LB 4:2:2 LQ Editorial
     
ProRes 4444 XQ 4:4:4 Finishing
ProRes 4444 4:4:4 Finishing
ProRes 422 HQ 4:2:2 Mezzanine*
ProRes 422 4:2:2 Mezzanine*
ProRes 422 LT 4:2:2 SQ Editorial
ProRes 422 Proxy 4:2:2 LQ Editorial


* In this case, Mezzanine means a compressed file that can be used to produce additional compressed files, but it is not necessarily useful for finishing work.

Codec facts:

  • DNxHR 444, ProRes 4444 and ProRes 4444 QC are the only codecs with embedded alpha channels.
  • DNxHR 444 and ProRes 4444 XQ are the only codecs that fully preserve the details needed in HDR- (high-dynamic-range) imagery.
  • Both codec families are resolution independent, but bitrate will vary depending on if you output a proxy file or a higher resolution file.
  • Both codec families can be wrapped inside MXF or MOV containers.

For more detailed specifications:
Full DNxHR codec list
Full ProRes codec list
 

Codec differences

DNxHR and ProRes was optimized to be visually lossless through many generations of decoding and re-encoding. Some claim to have noticed performance differences, but studies have shown that the quality and speed differences are negligible.

An important difference, however, is that most of the major editing and finishing systems available lacks support for ProRes encoding for Windows. This means Windows users can read a ProRes encoded file, but cannot export one. For this reason, many post-production facilites have abandoned ProRes and implemented a full DNxHR workflow.

There are systems that Apple fully supports such as Nuke and Scratch, but DNxHR is accessible universally.

Another important reason for the success of DNxHR is that Avid can read the files natively from its own MXF file structure. This eliminates the need to import clips and timeline rendering.

 

Lowepost

 

  • Like 2

User Feedback

Recommended Comments

Good write, it seems like DNxHR is definitely taking over the codec throne. Some seem to use the Cineform codec, any reason for that?

Share this comment


Link to comment
Share on other sites

It would be great to discuss if QT and DNX files are expected to be full range or legal range or both. There has been a long debate about proress 444 being full or legal or both. Also different systems render out prores differently. I was told by baselight team that all prores are expected to be legal. However, i heared davinci renders prores 4444  as full range.

Share this comment


Link to comment
Share on other sites
6 hours ago, Fady melek said:

It would be great to discuss if QT and DNX files are expected to be full range or legal range or both. There has been a long debate about proress 444 being full or legal or both. Also different systems render out prores differently. I was told by baselight team that all prores are expected to be legal. However, i heared davinci renders prores 4444  as full range.

Challenge accepted.

Share this comment


Link to comment
Share on other sites
Guest James Moore

I am puzzled why one would transcode to high res codecs for finishing as opposed to working with the original file format when finishing.  For real time work wouldn't you be working with low bandwidth codecs in both cases?  Why inject the extra step?

Share this comment


Link to comment
Share on other sites
8 minutes ago, Guest James Moore said:

I am puzzled why one would transcode to high res codecs for finishing as opposed to working with the original file format when finishing.  For real time work wouldn't you be working with low bandwidth codecs in both cases?  Why inject the extra step?

Because not all camera formats are optimized for real-time playback and enormous file sizes can slow things down.

Share this comment


Link to comment
Share on other sites


Create a free account or log in to comment

You need to be a member in order to leave a comment

Create an account

Register for a new account in our community.

Register a new account

Log In

Already have an account? Log in here.

Log In Now