Home | Our Services | Software - PRHelper for PC | Software - Project Tools for PC and Mac

Avid DNxHD vs. Apple ProRes vs. GoPro Cineform: Recompression Generation Loss

February 28th, 2013 / By Angelo Lorenzo / 11 Comments

If you have a properly tuned post production workflow then the amount of times you’ll recompress an intermediate video is zero or once; the most common case is recompressing assets like intros, bumpers, motion graphics, and others once they make their way into a final program.

I wanted to do an informal test between Avid DNxHD, Apple ProRes HQ, and GoPro Cineform to see how they stacked up through 5 rounds of recompression. To illustrate the differences, I took my original test video into Adobe Photoshop, added the compressed video to the layer above, set the compressed video layer’s blend mode to difference, and applied an exposure adjustment layer with gamma correction set to 2.0 to more clearly see the differences. This comparison should casually highlight the generation loss inherent in each format.

The Original Video

Recorded by the Canon 5DmkIII, h.264 all-I 1080p29.97. This was recorded for NBC as part of a web clip around the time of the 2012 Olympics.

01_original

Avid DNxHD 175 8-bit

First up is Avid DNxHD 175 8-bit. These were encoded by Adobe Media Encoder to the MOV container using Avid’s official Quicktime codec. If you ever wondered what the number in each DNxHD preset means, it’s the bitrate in megabits per second. 175 was chosen because it is similar to ProRes HQ’s bitrate of ~180Mbps. Below is the normal screenshot followed by a difference comparison to the original frame. You’ll see, quite easily, substantial blocking artifacts in both screenshots.

Avid DNxHD 175

Avid DNxHD 175 difference

Avid DNxHD 175x 10-bit

Terence Curren of Burbank, CA based Alpha Dogs aptly pointed out a flaw in that I was comparing an 8-bit format to ProRes HQ and GoPro Cineform which are 10-bit formats. Below are screenshots of Avid DNxHD 175x 10-bit produced by Adobe Media Encoder for a more fair comparison. As you can see, blocky artifacts are still pronounced.

Avid DNxHD 175x

AvidDNxHD 175x difference

FFMPEG/FFMBC DNxHD 175 8-bit

FFMPEG/FFMBC’s DNxHD 175 8-bit profile is processed through the command-line program FFMBC. Surprisingly, FFMPEG/FFMBC’s implementation of DNxHD produces less compression artifacts overall and less blocking artifacts. FFMPEG/FFMBC’s encoder, at time of writing, only supports 8-bit color.

FFMPEG/FFMBC DNxHD 175

FFMPEG/FFMBC DNxHD 175 difference

Apple ProRes HQ

This sample is from the official Apple ProRes codec controlled by Adobe Media Encoder on Mac OSX. You’ll see substantially less blocking artifacts in detailed areas in comparison to Avid DNxHD with some subtle blocking in areas of low detail.

Apple ProRes HQ

Apple ProRes HQ difference

FFMPEG/FFMBC ProRes HQ

This sample is from FFMPEG/FFMBC’s ProRes HQ profile processed through the command-line program FFMBC. Similar to Apple’s official codec, FFMPEG/FFMBC adds more compression artifacts overall but produces less blocking in areas of low detail.

FFMPEG/FFMBC ProRes HQ

FFMPEG/FFMBC ProRes HQ difference

GoPro Cineform

Last, but not least, is a sample of GoPro’s Cineform codec processed through Adobe Media Encoder. The one odd thing about this implementation is that there are no controls to set bitrate. The calculate bitrate is ~235Mbps which makes this a less fair comparison; it puts Cineform closer to Apple ProRes4444 and Avid DNxHD 220. With that said, I am still including it for comparison as it appears to have more compression artifacts overall, but suffers less from blocking than the other intermediate formats.

GoPro Cineform

GoPro Cineform difference

Conclusion

Again, I have to stress that the difference screenshots are brightened for better viewing and are not as severe as they initially appear. Almost all of these intermediate formats hold a decent amount of detail throughout rounds of recompression with the only, surprisingly, stand out failure being Avid’s implementation of their own DNxHD codec because of severe visible blocking. Apple’s official ProRes codec seems to perform the best in terms of introducing the least amount of artifacts after 5 generations.

So what exactly is the take away if you won’t see this level of compression “in the wild”? It seems that Avid’s DNxHD either has more aggressive compression or pre filtering/blurring than the other codecs which may lead it to being less suitable for a greenscreen intermediate than ProRes or Cineform. Cineform may be sacrificing color fidelity to keep sharpness and edge detail; because of its uncontrollable bitrate it may be a hard 1:1 comparison. ProRes may be striking some kind of balance between overall fidelity and sharpness. Different design philosophies from each codec.

11 Comments

  • Tom Daigon says:

    Wow, that all very depressing. All the more reason for Adobe to come out with its own codec. Thus will mean PC users dont have to rely on the old, slow qtserver.exe when exporting masters. And will allow PC users an alternate to Prores which is not supported on the PC.

  • David Newman says:

    You methods maybe in error when testing GoPro CineForm. There are quality controls for GoPro CineForm, just like most codecs. Failure to see these controls may mean you were accessed the codec in an usual manner. The quality control is not represented as bit-rate, just as ProRES offers Proxy, LT, 422, HQ and 4444, CineForm has 4:2:2 and 4:4:4:(4) modes with quality controls labled Low, Medium, High, Filmscan 1 and Filmscan 2. Bitrates aren’t useful for a constant quality codec with no resolution restrictions: 140Mb/s average is fine for 4:2:2 1080p24, not so much for 4K 4:4:4 60p, so when you set a quality, it will maintain that independent of resolution or pixel format, bitrates climb and fall as needed.

    In Adobe Media Encoder, you select Format as “CineForm MOV File”, you will see all the quality controls in the video tab under “Video Compression”. With Adobe tools make sure you set “Use Maximum Render Quality” to force 32-bit float processing over 8-bit.

    While all this is included with the free software on the PC, the Mac seems to be missing the CSx components. So if you having any trouble, try installing GoPro CineForm Studio Premium, the trial has all the components you need to do the above.

    David Newman | Sr. Director of Software Engineering, GoPro

    • David, you are right. I used Cineform as a simple codec under the MOV format rather than the specialized Cineform MOV format, as it appears you do indeed have more control. My apologizes, I will be revising with a Cineform quality level that provides a similar bitrate/filesize to ProRes HQ and Avid 175x.

      With Premiere, their documentation has lead me to believe that “Use Maximum Render Quality” uses 32-bit for internal color adustments/blending before feeding video to the codec. I’m not sure if this would have an impact on the final quality since I’m not doing anything else that MRQ improves (scaling, deinterlacing, frame blending). It would put it at odds with the FFMPEG results though, as they wouldn’t have that processing.

      Speaking of bitrate, while I understand that all these codecs are designed to work with constant quality rather than bitrate, I am testing these codecs on a single video file so, to me anyways, it makes sense to pick levels of quality that produce a similar file size across the board to see how effectively these bitrates are utilized; I’m trying to standardize as many attributes as I can despite the informal nature of this test. ProRes HQ and DNxHD 175 or DNxHD 185 seem to be the most chosen level of quality that production companies are using when burning out a 1080p30 show for long term storage on LTO or servers so it was all the more reason for me to center my test around the bitrates these codecs are delivering.

  • Steve says:

    Why don’t you try this with a real camera and real acquisition format like Alexa’s ProRes 4444 or RED’s R3D and get back to us.

    • David says:

      What does it matter regarding formats that are best case scenario? The guide is far more practical using a junk codec that might commonly be used with that much generational loss per the mentioned bumpers etc that often get re compressed.

      • Tim Kolb says:

        Starting with very clean, high color precision footage would give a different perspective as starting with a codec that is already so intensely lossy… Each compression type will likely function a bit differently with much cleaner source material.

        I would not say, however, that what you’ve already done here is “pointless” in any way…DSLR-to-Intermediate post workflow is very common and I think this is useful.

  • Tim Kolb says:

    As far as I know, DNxHD is specifically constant bitrate…not constant quality…ProRes is very high quality, but their bitrates are also hard-specified.

    The CineForm codec is variable bitrate, so analyzing the resulting filesize would have given you an average bitrate for comparison.

    CineForm’s use of a wavelet transform means that whatever artifacts you produce in pulling a difference like you did, are far less visible than rounding errors inherent in the typical DCT-block transforms…a visual comparison of image detail tells the rest of that story. CineForm was the first codec to do a completely compressed feature finish and have the edited CineForm master clip be the source for the exhibition film scan. When all else is equal, a DCT-based codec would reveal itself through visible compression artifacts before a wavelet based codec will.

    These are all very high-quality codecs, but a ‘runnability’ test would also be interesting as an installment in the overall comparison. Since QuickTime for Windows is still 32 bit, “MOV” wrapped files are disproportionately crippled on Windows when using a 64 bit editing application…which unfortunately takes ProRes out of the running for Windows users in any practical sense until Apple decides to upgrade the best computer media infrastructure that 1998 had to offer.

    • Thanks for the additional insight Tim. ProRes seems to be quasi-variable bitrate in implementation; it will scale bitrate based on quality level, frame size, frame rate, and frame complexity.

      From Apple’s documentation: “The Apple ProRes format has a target data size for every frame, regardless of complexity, but allows frames to fall short of that target if they are simple (if they cannot benefit in quality from using more bits). Such a shortfall is not reclaimed for other frames; instead, it just produces a smaller overall file.”

      Additional reading for others interested: http://documentation.apple.com/en/finalcutpro/professionalformatsandworkflows/index.html#chapter=10%26section=4%26tasks=true

      In regards to MOV… I’m counting down the days until better MXF support across the board.

      • Tim Kolb says:

        I guess what I’m saying is that when you choose a data rate (and ProRes does have different specified rates with frame size ands frame rate variations)…it won’t matter what the content is…it will simply be that data rate.

        “Constant quality” is really the codec using bitrate alteration based on content requirements. I was involved a bit with the CineForm guys in the days of the “Dust to Glory” project and I recall rather vividly how CineForm was actively involved in refining the codec due to the fact that the D5 transfers we had of the footage the filmmakers had shot on 16mm film had typical 16mm grain, which initially drove the data rates far higher than any of the 35mm transfers or the HD conversions when we used the same encode settings…the codec was reacting to what it saw as intense amounts of detail (grain) in the image. (CineForm refined the codec so that it would look at intensely grainy footage a bit differently and still preserve visual quality while creating a more manageable file size).

        As good as the other codecs are, in the same situation, DNxHD and ProRes would still be the data rate you selected regardless of whether or not it was adequate to faithfully preserve the content…therefore in the most basic terms, I believe that CineForm is the only codec of the three you could legitimately classify as “constant quality” vs the “constant bitrate” demonstrated by ProRes and DNxHD

        .

  • David says:

    I’d say the biggest error in this whole impromptu test is the initial video acquisition format. The Canon codec is horrid at compression and massive blocking and compression issues right off the bat! Low bit rate low color depth, Garbage in is always garbage out. Cineform is on par with R3d. Taking your highly compressed LGOP video and transcoding to a 10 bit, intraframe compressed format just helps prevent any further degeneration; it doesn’t fix the canon codec flaws. An that’s why they all practically looked the same!

    • The comparison was done with difference blending so the quality of the original content wouldn’t, in theory, disturb the result as all you’re seeing is the highlight of pixel difference through five rounds of compression. With that in mind you could argue that compression artifacts would exacerbate some issues in these intermediate codecs in terms of edge detection and other algorithms, but with a highly compressed piece of source material it’s a real world sample that a large audience of editors is going to see.

      I think once I have some time where I’m not on a film or TV show I’ll perform a more formal test.

Leave a Reply

css.php