[Jason J rodriguez]

Thanks Graeme.

I’ll actually be at NAB, so maybe we might bump into each other at the LAFCPUG or something.

But if you do find out anything more on this, I’d be very interested in hearing, especially if there is a compositing/color-correction/effects package out there that can deal with DVCProHD natively.

Thanks again,

Jason Rodriguez
Virginia Beach, VA

[Jason J rodriguez]

See, that’s very unfortuate that Panasonic must do things that way with the constant bit-rate rather than maximizing the bit rate of 100Mb/s for each frame-rate, like Sony does. HDCAM, for example, is 6Mbits/frame (@24p), yielding much less compression artifacting, especially at 1920×1080, than DVCProHD.

Jason Rodriguez
Virginia Beach, VA

[Jason J rodriguez]

All these cameras have a light low-pass filter in front of the CCD’s, even the 100K Cinealta, in order to prevent aliasing. They then use detail circuitry to overcome the “blurring” from the filter, although the filter is very light (in comparsion to a bayer camera), only enough to prevent horrible aliasing beyond Nyquist. Depending on the manufacturer, they’ll allow more aliasing than others to get a “sharper” image or higher perceived MTF, while others will filter the image further in DSP to prevent aliasing (I believe that Sony does allow some aliasing to occur, while Panasonic tries to filter as much as possible).

Jason Rodriguez
Virginia Beach, VA

[Jason J rodriguez]

[Graeme Nattress] Ofcourse, this means that if you do effects in FCP, then no scaling occurs until playback, and all is ok. I think this is also why people hate AIC so much, as when you convert AIC to uncompressed you see all these scaling artifacts.

Now, if I was compositing in Shake, I’d set it so that all the compositing goes on with the unscaled footage, but with the viewer so that I can see it all at it’s proper aspect ratio. Can you do this in AE, or is it square pixels only for everything??

BINGO!

Actually, once you convert the footage to working in RGB, you can’t undo the scaling, you are stuck with the poor decoding of the Apple Quicktime DVCProHD decoder, and you have hit precisely on my argument. This happens in Shake, After Effects, Quicktime player, Combustion, etc. Anything outside of FCP that is not YUV native, or that can process DVCProHD natively, is going to resort to the RGB scaler of the Quicktime codec with all of it’s faults. And then when you render to an uncompressed codec out of those applications, you have done irreversible damage to the footage, in that now the scaling and color artifacts are permanently “flattened” into the image-you can’t get rid of them, and they end up on whatever tape format or whatever you go back to for delivery or mastering.

Again, go look at Marco’s page on DVCProHD at onerivermedia.com. It doesn’t look that pretty, and that’s what you get in Shake, After Effecs, Combustion, or any other non-FCP application that uses the Quicktime DVCProHD-RGB decoder and can’t natively process DVCProHD.

BTW, since Shake is not DVCProHD native, even if you import the footage and scale it down to 960×720, and then re-scale it, it’s too late, because again, you’re now going through the Quicktime RGB decoder engine, and are basically taking the RAW 960×720, scaling it out to 1280×720 (on import into Shake), and then squshing the poorly scaled material back down to 960×720, and then adding a viewer control to “preview” back at 1280×720. Basically you’re not helping anything. Once you’re out of FCP-land and a native DVCProHD YUV timeline, you’re screwed because these other programs only know how to deal with RGB or floating point RGB data (in the case of Shake), and so any compressed footage that is imported is decompressed to full-raster 4:4:4 RGB. They do not do any of their operations in the native DVCProHD pre-filtered YUV color space. I know this for a fact (Shake included).

Jason Rodriguez
Virginia Beach, VA

[Jason J rodriguez]

the different decoders (software and hardware) have access to the same data information. That’s what I’m saying, not that the two are the same, cause obviously they’re not.

for instance, I prefer the look of AVID’s DV codec to Apple’s. It’s the same RAW data being decoded, but the actual software algorithms used to render a visible image on the screen are not the same, and one produces a more pleasing image to eye. THAT’s what I’m saying.

The hardware decoder in the panasonic deck looks better (and keys better, takes extreme color correction better, etc.) than the software decoder in Quicktime. The only way to get access to the hardware decoder is through HD-SDI. If you’re going to work with the HD-SDI signal, then good, visually lossless intermediate codecs are a very nice thing.

And Louis, with P2, you are not side-stepping the issue, since you are going to be using Apple Quicktime’s software decoder to decode the RAW information on the P2 card.

The DVCProHD encoder dumps data into a format, whether that’s a data stream on tape, or a MXF file on a P2 card. In order to see that footage on your computer screen, out your monitor, etc., it must be decoded. From the artifacting I’ve seen, I think that Apple’s implementation, whether it’s more “accurate” or not, doesn’t look that good, and is prone to banding, etc.

For instance if you have the demo DVCProHD footage, try to alter the color in those sunset shots and watch all the banding an noise appear in the sky. Or why don’t you try to raise the blacks on the “Presido” shot to make it less contrasty. Or why don’t you try saturating some of those shots, or bumping contrast, etc. You’re going to discover banding and other digital artifacts that I personally don’t think look good.

Again, it’s NOT the information that panasonic has encoded onto the P2 card that is at fault. It’s the way the file is being decoded.

Decoders CAN get better. Just look at the DV codec quality jump from QT 4.0 and 5.0. And if the DV codec’s decoder (not encoder) was so great right now, why was an “improved” DV codec one of the top feature requests on the LAFCPUG’s Final Cut requests list?

So again, I’m not pointing fault at DVCProHD itself, as in the RAW information held in the binary format after encoding. I’m pointing fault at the artifacts in Apple’s decoder that to me just don’t look good. For top-quality work out of the Varicam, I’d rather user the decoder present in the hardware decks of Panasonic, and digitize over HD-SDI, than use the software Quicktime DVCProHD decoder. The only downside with the HD-SDI route is that it requires big files and lots of bandwidth to move around, and nice, visually lossless intermediate codec would be nice thing to use with the HD-SDI route.

Maybe Apple will make a better decoder or should I say “better looking” decoder, an then this argument will be moot.

[Jason J rodriguez]

Suffice to say, when trying to push the Varicam to it’s maximum dyanmic range, or when trying to shoot a very “flat” image for post-correction DI that has no clipped highlights (sort of shoot a digital negative, or the equivalent of a film inter-positive from the original color-negative, but in order to protect the highlights, you have to underexpose), the software codec, the way that Apple chooses to decode it, exhibits artifacting that I DO NOT SEE in the HD-SDI ingest of the same footage. It’s typically a nasty, large, pixel blocking artifact. I’ve seen it, my DP has seen it, when pointed out to others they see it, it’s plainly there, and it’s impossible to get rid of UNLESS you digitize through HD-SDI.

I’m not saying that the hardware codec is better than the software codec, they’re the same codec. But there is a different decoder happening in the Apple sofware than in a Panasonic deck.

Now here’s one interesting thing. Like DV, IF you apply no effects to your footage, you ingest via firewire, and then write back to the tape via firewire, you basically have a clean digital copy of the footage. Now you can take that same tape, and digitize it via HD-SDI (but it’s now an edited program), and have a ‘cleaner’ copy to do effects with. Not as convenitent IMHO, but it does work.

But the point is, if you choose the DVCProHD software decoder from the start, that’s the problem. IMHO, the HD-SDI hardware decoder in the Pansonic decks makes a “cleaner” (not necessarily more accurate to the actual information on the tape) image than what I get off firewire.

BTW, one other thing you missed.

If you export DVCProHD to After Effects, render to a new “uncompressed” codec, and import back into Final Cut, and then want to go back to tape, you’re either going to have to render back to the DVCProHD codec (another generation loss), or you’re going to have to render out your whole timeline to some other codec (which can take some time).

I think in the end my argument has been pretty self-explanitory, and it’s that HD-SDI looks better than what’s coming off firewire, plain and simple. I don’t know EXACTLY why, but there’s a reason that the top post houses in America and around the world aren’t ditching all their gear for firewire ingest if it was so much better-because it’s not, and it has some definite trade-offs to the higher-quality input you get over HD-SDI. The footage looks cleaner, there’s less artifacting, the noise looks more “natural” rather than blocky, less banding in the gradients, etc. I’m sure there’s some form of dithering happening to create this phenomena that is not occuring with the Apple software decode so that Apple’s codec remains more faithful to the “original” data on the tape. But that dithering, or whatever is happening inside that deck over HD-SDI is making the footage look much “better”, or “cleaner”, or less “digital” and more “natural” (in the sense of less digital artifacting) than what I see from the same footage off firewire.

Jason Rodriguez
Virginia Beach, VA

[Jason J rodriguez]

I still think that you’re being a bit short-sighted about the benfits of a good intermediate codec, especially when there’s more to the world than keeping your entire project inside Final Cut Pro.

For instance the current digital cinema project I’m working on has been onlined in Final Cut, but was then exported for 16-bit color correction and effects inside of After Effects. Since I’m working with Uncompressed 10-bit Blackmagic stuff, the file sizes are huge, and it would be a nice feature to have the same image quality in a file-size 1/6th the size, like Cineform and DNxHD can do.

DVCProHD is not the ideal solution for these types of multi-platform, multi-program, multi-compression workflows. If all you’re doing is working inside of FCP, then that’s great, but for many of us, that just isn’t the case, and that is where a nice intermediate codec that withstands the tortures of repeated compression, passes, etc. with flying colors comes in very handy.

You call the tests that Cineform did as “not fair”, yet this is exactly what you have to deal with if you use the native DVCProHD codec outside of Final Cut, in Shake, After Effects, Combustion, etc. When that becomes the playing field, then I feel the results are very fair, because that is exactly what I’m going to have to deal with when I use DVCProHD outside of Final Cut’s native DVCProHD timeline.

So, I’m not saying that DVCProHD is no good, but I’m saying, it’s NOT a true intermediate codec, meaning that it’s not made to withstand repeated YUV-RGB conversions and be visually lossless, survive multiple passes between different programs for effects, color correction, etc.

Basically, it’s a crappy codec for Digital Intermediate work. Does everybody need to do a Digital Intermediate? No. There are many programs that do just fine adding their effects, graphics, color-correction, etc. all inside of Final Cut, and then drop back to tape. But there is another side of the industry, those people who are working on films, high-end commerical work, etc. where a visually lossless digital intermediate codec can come in very handy. Uncompressed is great, but like I was saying before, it has it’s problems when it comes to speed, bandwidth, etc. If you can do all your digital intermediate work and maintain visual perfection, but have a file size that’s 1/6th the size of uncompressed, I think there are some definite advantages to that workflow. And of course AVID and Cineform have seen the market potential in that mid-range to high-range area, and I hope that Final Cut doesn’t get left behind because they think that DVCProHD is good enough for that kind of work-cause it’s not.

Who knows, maybe core video will enable all sorts of real-time stunts on uncompressed HD footage, so this whole argument is moot.

Jason Rodriguez
Virginia Beach, VA

[Jason J rodriguez]

Yes, you must have Prospect HD and Premiere Pro 1.5.

You can now purchase Prospect HD stand-alone for $1,500, but it needs a 3.4Ghz P4, and that is without the ingest/output card (Aja XENA HD).

With HD-SDI card, you’re talking around $6,000 with the Adobe Video Bundle and Prospect HD. Also for ingest/export you’ll need a much beefier machine, basically a dual Operton 252. Since you don’t need a drive array, once you’re all done, figure under 10K for the whole package.

Go over to http://www.cineform.com and click on Prospect HD for the different choices you can make.

Jason Rodriguez
Virginia Beach, VA

[Jason J rodriguez]

Something’s different, because the files definitely do look different.

Try doing some green-screening sometime with DVCProHD over HD-SDI and then over the same footage on Firewire.

You will notice a difference, especially on challenging footage.

Seems as though the software DVCProHD codec can suffer horribly from macro-blocking in the shadows and saturated color gradients. I hate color-correcting DVCProHD footage for these reasons, there’s not much you can do before you see some pretty terrible-looking stuff, if you’ve under-exposed the camera a little too much. I’ve talked to Pana about the problem, and they acknowledge that much of it has to do with the 8-bit precision and compression on the codec not being able to really take advantage of the full dyanamic range that the FILM REC mode on the Varicam can deliver.

BTW, for a quick visual comparison between DVCProHD and CFHD, go over to one-river media and look at Pixlet 100% vs. DVCProHD. Ignore the white-count, because CFHD has a very, very low white-count (the gradients and other areas that Pixlet does bad in are perfectly preserved with CFHD). But they look about the same visually, with the edge going to Cineform. And again, their white-counts are completely different (the white count of CFHD is close or very comparable to Apple’s 10-bit 4:2:2 Uncompressed, so again, it’s a very high-precision codec, and way beyond the other 8-bit codecs that have very high white-counts).

Jason Rodriguez
Virginia Beach, VA

[Jason J rodriguez]

I think you’re missing the point Graeme.

I’ve used both DVCProHD from firewire (1200A deck), and footage ingest uncompressed to Blackmagic 10-bit.

There is a WORLD OF DIFFERENCE between the footage. You can argue all you want on the technicalities of this process, how you’re editing with that native codec, etc. but once you ingest via firwire the native DVCProHD codec signal, the damage IS done. Frankly, there’s something about ingesting a base-band signal that is much higher quality than the native DVCProHD codec. Maybe it’s the way that Apple decodes the codec compared to the hardware decoders in the Panasonic decks, but the footage is simply NOT THE SAME. This is the same concept behind the differences of working with firewire DV, and digitizing DVCAM off SDI via a high-end DSR deck to a 10-bit 4:2:2 format. There’s a big difference in quality with the SDI signal.

So, if you’re ingesting the HD-SDI stuff via blackmagic, etc. you’re now doing uncompressed 10-bit. Big files, and a lot of storage. That is where intemediate codecs come into play like Cineform or DNxHD. They allow you to work with the base-band HD-SDI signals with real-time effects, etc., not being constrained by the bandwidth and processing requirements that moving around multi-stream uncompressed HD would require. Furthermore these codecs are higher quality/more efficient than DVCProHD, they are full-raster, 10-bit precision, can survive multiple passes, etc.

Ingesting the native DVCProHD signal via firewire, adding effects, and then rendering out uncompressed does nothing for your quality in improving how the DVCProHD signal was decoded in the first place. When you do this, all you’re doing is preserving the artifacts of the original decode, whether that is banding, blocking, etc. I’ve tested and I’ve seen with my own two eyes that the software decode of these native DV codecs, whether it’s DV, DVCProHD, etc. is not as good visually as the hardware decoder required to output a base-band HD-SDI signal.

So, there is a big use for intermediate codecs, in that working with native DVCProHD is not that wonderful a solution for really high-quality work, especially post color-correction, etc. Digitizing off HD-SDI is, but there is a definite workflow bottleneck when you’re trying to move around uncompressed footage. Intermediate codecs allow you to re-definte the HD-SDI workflow by having the benefits of the HD-SDI stream decode process (and it’s quality improvements) and the flexibility that editing with the native codec allows, but now with visual quality that matches the uncompressed HD-SDI workflow.

For P2 this process is totally irrelevent, since there is no HD-SDI decode process. You already have the native codec on-disk ready to work with. But if you ever want to work with HD-SDI uncompressed for the highest quality possible, intermediate codecs are a huge boon.

BTW, when Qrez is released by AJA, that should make for a very nice intermediate codec in FCP compareable to CFHD or DNxHD.

Jason Rodriguez
Virginia Beach, VA