[Gavin Stokes]

Here we are three years later, and I’m having the same problem on the latest version.

[Gavin Stokes]

“Regarding the 4:2:0, I’m wondering what XDCAM HD shooters/editors (335, 355) are doing as far as editing codec used for compositing, keying, color correction.”

It doesn’t matter; the color information is missing from the original acquisition format.

[Gavin Stokes]

My intent is to make a progressive DVD to test the “film look” of deinterlaced 50i footage. I set the rate at 23.98 and then put the stuff into a 29.97 FCP timeline with some regular 60i stuff. The result looked a little stroby. FCP should’ve just done 2:3 pulldown, but knowing FCP, there’s no telling what it actually did.

I just made a 23.98 timeline, plopped the stuff in, and now I’m running it through Compressor to put on DVD. We’ll see what that looks like.

I seem to have found a bug in FCP during the process. When placed in a 29.97 timeline, the “conformed-to-23.98” footage and its audio lined up fine (except for the drift caused by the 25-to-24 slowdown). When the same clips are placed in a 23.98 timeline, the video ends at a different point and can’t be dragged out to show the whole clip, and the audio is way out of sync.

Gavin

[Gavin Stokes]

I’ll give that a shot.

[Gavin Stokes]

If there’s a discernible cadence (every Xth frame is darker, for example), you could quickly write a Shake expression to adjust the brightness on those frames.

Of course, you have to have access to Shake…

[Gavin Stokes]

The “bias” wasn’t even sly; remember year after year of using Photoshop 4 Gaussian blur to prove PowerPC superiority?

BUT

in this case it’s not total BS. Shake does a lot of different types of processing, but we saw a legitimate 30- to 40-percent speed-up with it (don’t know about FCP). As the last gasp for the PowerPC line, this could buy you a couple of extra years of usefulness.

[Gavin Stokes]

QT 7 for Windows will NOT include the DV50 codec.

Meaning that unless Panasonic does something about it, there’s essentially no way for most computer users to ingest the higher-quality material from their cameras. There is a codec out there from MainConcept, but it’s a pay-extra situation and most users are not going to know how to track it down. I haven’t tried that one either, and it doesn’t solve your problem because it isn’t QuickTime.

After several years now, this situation is ridiculous.

[Gavin Stokes]

I just noticed that you mentioned they got the proc-amp functions working. That’s a major addition. Good info.

Damn, if they just had switches on the front I’d have no complaints. Except, of course, no Windows drivers…

[Gavin Stokes]

Thanks Gary. I did get a beta of this before NAB. I didn’t see anything about it there, so I wasn’t sure if they had ever finished it.

It’s a welcome step, but unfortunately it doesn’t solve the main problem: Having to use a computer just to select the inputs.

[Gavin Stokes]

Hey Gary,

I’m not sure you’re interpreting my posts correctly. If you have DVCPro material on tape and you bring it into the computer, it doesn’t matter how it gets in there as long as it stays digital and you don’t recompress. Decompressing it before it gets into the computer is pointless because it can’t possibly increase the quality. At best, it will be an exact duplicate of the already compressed images on the tape. Which is exactly what you get when you bring in the data over FireWire, at greatly reduced storage cost.

When you open the native DVCPro files in your compositing or editing app, they are decompressed at that instant and promoted to whatever the native, uncompressed workspace is for that app. From then on, they’re uncompressed, unless the software is crap.

Consider this scenario: You open a DVCPro HD QuickTime file in Shake, do a bunch of effects on it, and then write it out to an uncompressed QuickTime file. Alternatively, you play out your DVCPro HD tape over SDI and capture it to uncompressed QuickTime, process it with Shake, and then write it out to uncompressed QuickTime. The results are the same. All you’ve done with the SDI step is unnecessarily bloat the ingested data.

You mentioned uprezing, but I didn’t. I’m not talking about changing resolution. I’m just talking about getting the data into the machine. Doing it over FireWire and decompressing in software at the beginning of your pipeline is just as good decompressing outside the computer and sending the data over SDI. Why decompress the data before you’re using the images? Save yourself the time and storage space by decompressing only the necessary footage and doing it IN SOFTWARE.

Regards,
Gavin