-
Prores422 vs. DVCPRO50 SD Smackdown preliminary results
Quick extract: Prores is very, very, very slightly better than DVCPRO50 in a fair fight, but is 20% bigger, and supports 10-bit, which won’t help with most if not all SD formats via capture (maybe digibeta– maybe.) And as a colorist, I do appreciate finer control in 10 bits.
Ramble on:
After making an offhanded comment about my preference of DVCPRO50 to Prores in another thread, I decided to get scientific on Prores’s Ass. For the purpose of this article “Prores” = Prores HQ.
I hope to publish a detailed article with pictures, movies etc at some point on my new website, http://www.AppleIsRotten.com. [basically I hope to make a reality-distorion backlash Mac user weblog, eventually, but that’s later] I thought I’d share the summary results with a few very interesting discoveries, in case I never get around to writing the article or starting the website…
First, I have an apology to make. I have misrepresented Prores earlier. The problems I was experience had to do with another apple issue– The horrifficly bad software DV50 implementation, but Prores is itself a fine codec. Not earthshattering, but not inferior to DV50– in fact, It’s about a tie.
First some backstory: My love affair with DV50 is a forced arrangent. When I was primary Avid, I drove myself nearly insane mixing resolutions– 1:1/486 lines + DV25/480 footage= Avid export explosions. The solution, which saved me much heartache was to bring all my SP footage and graphics in VIA DV50– plus, in the Avid implementation, it’s nearly indistinguishable from 1:1, and you get the matched resolution and 6MB/sec bitrate to boot. After some extensive tests, DV50 was nearly indistinguishable from uncompressed.
When I came over to the ‘dark side’ it was pre-prores, and my Kona did a fine job capturing DV50, so the workflow stuck.
When Prores came out, I tried some footage out, and found it okay, but when I’d drop it on my timelines, it looked (and played back) visibly softer than the DV50 stuff. I didn’t go into great detail, but it was slightly bigger, and didn’t look as good to me, so I pretty much dismissed (and dissed) it. As it turns out, the entire blame lies with Apple’s piss-poor DV50 software encoder. It’s utter crap. And the problem was that when you have a DV50 timeline, it runs it through the RT software encoder before display– the result? Soft video. If you have a Prores timeline, it looks fine. (Same w/ uncompressed video in a DV50 timeline) DV50 video in a DV50 timeline looks great, and rendered Prores footage in a DV50 timeline looks fine. (My guess is rendering uses the Kona hardware) This even happens when playback settings are set to High/Full..
And yes, I checked my scale/distortion/offset, and when reset to 100%, -1 center, it still has this problem.. again, rendered looks great..
My guess on this is that it’s using the same [broken-ass] DV50 encoder that quicktime uses. If you capture a video uncompressed and then use quicktime or compressor to convert it to DV50 (or export a n uncompressed timeline using quicktime conversion) it looks like utter crap, compared to the same source through the Kona capture. I did not have this problem in the Avid world. The AVID DV50 codec is superb, and again, nearly indistinguishable from uncompressed.
I tried a bunch of different settings on sequences (8bit, rgb etc etc) and in the menus, with the same results every time. This was the same behavior I experienced in Tiger, and I have a virgin install in Leopard, so I am pretty certain it’s not a configuration thing.
I exported an uncompressed clip using QT Conversion to the standard QT DV50, and then again using the [freely downloadable] Avid DV50 codec, and the avid codec mopped the floor with the QT DV50 codec [@ precisely the same file size] — so much so, that it’s disgraceful, and I can only conclude that Apple never intended to actually make a quality DV50 codec and intentionally sunk it. Maybe to make prores look better, who knows..
So in Summary, Apple software DV50 encoder = garbage.
Now, on to the good stuff:
I encoded some factory auto footage from Beta SP, setup to bars in Uncompressed 8, Uncompressed 10, Prores422 and DVCPRO50. I discovered a bug in the gamma metadata for the kona capture– it gives inconsistent gamma info to uncompressed vs compressed sources.. You can check the FCP compatibility option in Quicktime>preferences on and off, and also check the Project settings in After Effects and turn on the ‘Legacy QT Gamma adjustments’ to work around this bug.
First of all, I acknowledge that Prores is a 10 bit codec, and DVCPRO50 is 8 bit. I will go over this in the final wrap.
I did many tests in FCP and AE, and here’s the summary:
CPU:
An SD uncompressed stream pushed FCP to a whopping 9% utilization (of 400% of my quad core 3.0 Mac Pro).
A single Prores Stream hit 28%.
A single DVCPRO 50 Stream hit 32%.Now this is interesting: DVCPRO50 scales better, performance wise. 2 streams of video, each scaled 2 half size hit 55% on DVCPRO50, and 60% on Prores. 4 streams (50% size, same clip, 4 corners of the screen) hit only 102% on DVCPRO50 and 120% on Prores.. I didn’t go beyond that, but it seems that Prores is a linear progression, while the more streams of DV50 you add, the less CPU-per-stream it uses.
Note that each of these were in their native format sequences. My theory is that the DVCPRO50 encoder is more efficient at re-encoding DV50 streams. Or it could have to do with the bit depth, although I did change the rendering settings in the Prores sequence, and there was no effect on CPU utilization.
But mostly, a wash….
The gamma bug is not apparent in FCP (which is why I assume nobody’s caught it) but the difference compositor is not as exacting, and I have more robust tools in AE, so I took the clips there to evaluate.
I evaluated both chroma+luma and also luma alone by putting the compressed clips above the uncompressed clip and using the “difference” compositor. I additionally added a set-scale “levels” effect to scale the difference to make it more apparent.
It should be noted that both codecs produce excellent results, with almost undetectable artifacts.
On closer examination, it’s clear that prores is more selective in the location that it puts more pronounced compression, whereas DVCPRO50 has more of a “hide the compression in the noise” philosophy. On the one hand, I could actually more easily see specific compression differences in ProRES, but on the other, the DV50 was ever so slightly “noisier” than the prores. Furthermore, the noise pattern itself was more “generic” in DV50, which I found to be less noticeable than the prores. I must stress, however, that these are extremely fine hairs I’m splitting, and that without using a ‘levels’ filter, the differences were almost completely indistinguishable.
It’s hard to interpret the differences in chroma because at their initial levels, there’s almost no chroma difference detectable, but when scaled dramatically, prores shows slightly less variation in chroma, which leads me to believe that the philosophy for luma noise is evident in chroma– there’s a very fine “wash” of chroma noise in dv50 vs prores.
Additionally, the DV50 details showed occasional more pronounced differences than the prores– This could also be a 10-bit vs 8 bit thing, which would make sense, because the compression isn’t moving further afield.
Here’s the final whammy: As a comparison, I put the 8 bit uncompressed over the 10 bit uncompressed (and vice versa) and did a diff check on that as a “control” And I found that the majority of noise was STILL THERE. That’s right. Just the built-in noise of beta SP analogue tape is dramatically more evident than either the noise added by DV50 or Prores… when you take that out of the equation… Well, it’s not worth even thinking about.
So what does this all mean? First of all, Prores HQ is 20% larger, filewise than DV50, and 10 bit uncompressed is 25% bigger than 8 bit.
Essentially, apple rewrote a marginally improved DVCPRO50 codec, 5 years later.
https://www.apple.com/pr/library/2002/apr/07panasonic.html
I wouldn’t be surprised if the same team that ‘collaborated’ with Panasonic wrote Prores422. 🙂
All kidding aside, I have no idea about the mechanics of Prores vs. DVCPRO50, and there clerly is a “smart” mechanism for choosing where to hide the compression, and of course, it adds 2 more bits, and HD support…
What’s my point? Good question. I forgot. No wait. I set out on this adventure to find out which codec I should use for my autmotive work– I use a lot of SD factory footage, and I’m doing a new model year, so it’s time to batch batch digitize..
My result? I’m forced to go to Prores, not because it’s superior, but because the Quicktime software codec for DV50 is so badly executed, that although the footage captured through the kona is fine, and I would save 20% disk space, Exporting graphics from mac applications in DV50 to keep it “naitive” would sabotage my quality.. and in ‘animation’ would slow me down and eat disk space.. so that means ProRES or bust.
Furthermore, it won’t let me use Avid DV50 as a RT codec, dontcha know (love the ‘unrendered’ screen) even though it would work just fine in RT.. I actually play dubs from my Avid directly from the network in DV50, unrendered on the FCP timeline without dropping frames, and it works great…. I just can’t do multiple tracks, because they artificially limit the RT.
And I wouldn’t care, 20% of diskspace isn’t that important, except for the fact that Apple’s reality distortion BS and worse-than-Microsoft draconian protectionism limit ProRES to the Mac platform, and restricted further to just machines with FCP. WTF? Avid is giving away DnXhd & their DV50 codec for free to anyone on any platform who wants it… And that’s just reason #5324 that Apple Is Rotten (dot com) 🙂
As a final (positive?) note, I can see how prores would probably do really well with Red-camera type acquisition.. It’s a very noiseless compression, so the old “hide the compression in the noise/film grain” trick won’t be so cute. At this point, ProRes (or more likely ProRES2 or whatever) will probably finally start to see some real benefits, once we leave this super-lossy/noisy acquisition behind.
Seriously though, they do some things so right, I just don’t understand why they get caught up in this kind of BS over and over and over again… Because they’re apple.
-
22 Replies
-
Cory,
Now that you have written the longest post in recent memory, please go back and fix every instance where you have written Prores. As Tim Wilson, Associate Publisher of the Cow, pointed out to all of us in very detailed explanation of the codecs when they were new and just out of the box from our friends at Apple, the proper name for the codec is “Pro Res 422,” not Prores 422, not ProRes 422, but “Pro Res 422.”
Okay, now stand in front of the class and write Pro Res 422 on the blackboard 10,000 times please…
Thank you,
DavidDavid Roth Weiss
Director/Editor
David Weiss Productions, Inc.
Los AngelesPOST-PRODUCTION WITHOUT THE USUAL INSANITY ™
A forum host of Creative COW’s Business & Marketing, and Indie Film & Documentary forums.
-
That’s what you got out of his post? And your only comment is
he didn’t say Pro Res correctly? Wow.The guy did some great sloothing.
His tests will help me determine why I’ve been having some issues with the
DVCPRO50 codec vs my work in uncompressed and DVCPROHD.Thanks Cory.
Dan -
[Dan Riley] “That’s what you got out of his post?”
Sorry Dan, my attention span is evidently shorter than your own. Even after two readings I was unable to determine the point of much of the post.
David Roth Weiss
Director/Editor
David Weiss Productions, Inc.
Los AngelesPOST-PRODUCTION WITHOUT THE USUAL INSANITY ™
A forum host of Creative COW’s Business & Marketing, and Indie Film & Documentary forums.
-
Actually, it’s ProRes 422
https://library.creativecow.net/articles/wilson_tim/ProRes01.php
“Finally, ProRes is not two words. Just one word, with an intercap: ProRes. Remarkably enough, I only found 3 people and 1 company in the past 2 weeks who wrote it as two words. In fairness, all but one also used it as one word other times. So overall, class, very well done! ”
Also, a further litmus test would be Uncompressed 10bit HD vs ProResHQ to see where ProRes shines. What’s SD again?
Just kidding.
Also, if using ProRes an acquisition codec as gets done with dv50 (ie recording straight out of the camera), there’s no doubt that ProRes wins in SD or HD.
I did an informal test of DVCPro HD that was captured to an HVX200. One was to the cards (dvcproHD) one was to an ioHD (ProRes HQ) and one was Uncompressed 10bit (via Kona 3) all simultaneous. There was obvious differences between dvcpro hd and prores and uncompressed. Big huge glaring differences, and they way that FCP scales up 960×720 footage to get to 1280×720 is totally effed up and I really couldn’t believe that it was done that way, despite all the cool stuff that FCP does. But ProRes wins, hands down with it’s edge going to file size and real time versus uncompressed 10bit HD and as an acquisition codec, it’s totally great.
Jeremy
PS. Cory, thanks for taking the trouble to do all of this.
-
[Jeremy Garchow] “Actually, it’s ProRes 422”
Like I said, ProRes 422…
Actually, it was a test to see if someone would catch my mistake… I kinda knew it would be you Jeremy.
-
Good to know about DVCPRO HD v ProRes. Thanks for sharing the results. I suspected they would not be comparable, but it exceeded the scope, as I have no ability to to test that with uncompressed HD. Considering the bitrate for DVCPRO HD is about 1/2 that of ProRes HQ, and the resolution is 1.5 anamporphic, I’m not surpised there are big differences.
In my practical experience,most of us are still going to be dealing with primarily SD and pre-compressed 8-bit HD acquisition for a few years, as not many productions are conducive to lugging around a Mac & an IOHD.. 🙂
My point to all this was that I did the comparison specifically in SD, took extra pains to make sure I was testing accurately, and shared my results if anybody else was interested. I tried not to make assumptions or “interpret” the results when it comes to HD.
“Also, if using ProRes an acquisition codec as gets done with dv50 (ie recording straight out of the camera), there’s no doubt that ProRes wins in SD or HD.”
Keep in mind that DVCPRO 50 and DVCPROHD are very different animals… Their bitrates are almost identical (, but DVCPRO HD is crunching exactly 2x as much raw information into that space. (720×480)x(2) = (960×720) = 7MB/sec.
My test wasn’t perfect, but I think that it indicates there’s not much difference between ProRes & DVCPRO50 in the SD performance bitrate-for bitrate. I mean, if you have a modified 4:4:4 HVX200, go for it, but as stock HVX’s shoot 4:2:2 8-bit anyway, why go through the extra steps?? Or is there an SD test somewhere I haven’t seen?
And I defintely think ProRes is a great finishing codec for DVCPRO50 sourced stuff.. If you need your final SD output to be 10 bit.. AFAIK, color is 10+ bit internal, so it would actually work in 10 bit space, and even if you saved it ‘same as source’ you probably wouldn’t be able to detect any difference in the 8-bit world (DVD, qt file, Beta Sp, etc..) right?
My obviously opinionated stuff is obviously..well, obviously opinionated. 🙂
PS. Sorry about the rambles. After all of the testing and typing, I had no energy to go back and edit, and it clearly shows.
-
[Cory Caplan] ” mean, if you have a modified 4:4:4 HVX200, go for it, but as stock HVX’s shoot 4:2:2 8-bit anyway, why go through the extra steps??”
I don’t, but capturing straight out the component outputs will definitely skip Dv, dv50 or dvcpro hd compression as that signal is essentially coming off the chip after it’s been resized and interlaced or whatever. Also, an ioHd and a laptop with one of these is hardly lugging. It’s a backpack and briefcase. Totally doable.
[Cory Caplan] “AFAIK, color is 10+ bit internal, so it would actually work in 10 bit space, and even if you saved it ‘same as source'”
I think it process in float (32bit) and then gets rendered to whatever. Same as source doesn’t work all the time, so you are forced to render ProRes or UC.
[Cory Caplan] “even if you saved it ‘same as source’ you probably wouldn’t be able to detect any difference in the 8-bit world (DVD, qt file, Beta Sp, etc..) right? “
When you work with higher quality formats, that translates down to whatever format you end up with. So if your graphics, cc, and gradients all start in 10bit, that quality will carry through no matter how much your image gets beatup along the way (within reason). That’s why film footage transferred to dv will knock the socks off of dv shot on tape.
Jeremy
-
[Cory Caplan] “Sorry about the rambles. After all of the testing and typing, I had no energy to go back and edit, and it clearly shows.”
I wasn’t being serious Cory, but I hate putting those smiley faces 🙂 all over…
David Roth Weiss
Director/Editor
David Weiss Productions, Inc.
Los AngelesPOST-PRODUCTION WITHOUT THE USUAL INSANITY ™
A forum host of Creative COW’s Business & Marketing, and Indie Film & Documentary forums.
-
So Jeremy, are you saying that if I plug the HVX200 component out thru the AJa ioHD into my Mac Book Pro I can record 1080 in the “better” looking format “ProRes HD” vs DVCpro HD.
Does it make for better Chroma Keys?
And this process of recording does not work when you use the HVX200 firewire out to the MacBook Pro and record in ProRes HD… vs Dvcpro HD..
Am I translating this correctly…?
-
“with one of these is hardly lugging”
That’s one of these, is one pricey 320 gigs of location mirrored raid.
Me thinks I will stick with the “Micro Center” solution… 2.5″sata enclosures $30, 160gig sata drive $100 total $260 for 2 sata drives 160gig mirrored location recording… Buss powered via USB – I use a USB powered USB Hub..
Reply to this Discussion! Login or Sign Up