[Thomas Worth]

Rec.601 is indeed SD, that is if you are following the rules. Canon aren’t. This doesn’t really matter since in order to do anything useful with the video you need to transcode it. You’ll get what’s expected (Rec.709, 16-235) after transcoding because the transcoder reads the 601 flag in the MOV and (hopefully) does a cross-conversion from one matrix to another.

>which a lot of people do and completely destroy their video because canon uses a special full 0-255 h.264

Not if you use 5DtoRGB!

[Thomas Worth]

That’s not really the right way to do it even though in practice you may not see any quality loss.

The correct way would be to render to uncompressed codecs. Example:

1. Transcode from H.264 to ProRes 4444 with 5DtoRGB. It’s preferable to export to 4:4:4 because we know we will be working with this footage in AE, which only works in RGB. You can get away with 4:2:2 if you don’t have the disk space.
2. Import into After Effects, do VFX. Export to uncompressed 4:2:2 to match the rest of your footage if it’s also 4:2:2.
3. Export the final program to uncompressed 4:2:2. You can then color correct this or use it as a source for HDCAM SR output, Blu-ray or DVD.

Some will say this is overkill, and perhaps it is considering your final delivery. However, if you are worried about generation loss, the only way to avoid it is to render to lossless codecs.

And yes, uncompressed 4:2:2 is technically lossy because it discards chroma info, but this type of “compression” does not produce the type of DCT / blocky compression artifacts you are probably worried about.

[Thomas Worth]

You can transcode a clip without audio in 5DtoRGB by selecting the “Disable Muxing” option. You will also lose timecode by doing this, but can easily add it back in Final Cut Pro.

[Thomas Worth]

Well, the quality difference is such that it is possible to detect on a non-calibrated display (the chroma aliasing, anyway). However, I agree 100% that any judgments about color should be made on a proper calibrated display being fed from hardware dedicated to this purpose (like a Blackmagic Intensity or DeckLink). Trying to judge color on the Mac’s primary display isn’t a good idea because there are several layers of graphics-related APIs that must be traversed before an image is displayed. With dedicated video hardware, the decompressed codec output is typically sent directly to the monitor without and meddling (unless you are applying LUTs, etc).

[Thomas Worth]

Importing H.264 directly into FCP means QuickTime must reconstruct frames from the H.264 decoder on the fly — hence the sluggish performance. Plus, it does not do a great job of this, since the QuickTime H.264 decoder seems to be optimized for speed and doesn’t differentiate between interlaced and progressive material when rebuilding chroma.

Transcoding to ProRes is preferable because each frame is discretely accounted for, whereas this is not the case with H.264 (only changes between I frames are stored, and so it is not an ideal format for editing).

H.264 is YCbCr with 4:2:0 sampling, not RGB. ProRes is YCbCr with 4:2:2 sampling. Both store luminance as full-raster.

5DtoRGB achieves superior chroma results because it does not rely on QuickTime’s flawed H.264 decoder like almost every other transcoder out there. Many independent tests have been done that show the difference this makes.

[Thomas Worth]

Yup, that’s exactly what I needed. This fixed the problem. Thanks!