ProRes Export Size

I'm trying to export a sequence with the ProRes 422 codec from a 720 x 480 timeline. When I do the QT export with the ProRes 422 codec, the resulting file shows up in QT as 640 x 480....yet the QT inspector says the format is "Apple ProRes 422 720 x 486 (640 x 480)" and the Current Size is "640 x 480 (actual)".
Why does the size of the video change?
When I tried doing the "Export Using QT Conversion" option and change the codec to ProRes 422, I do get sizing options but the resulting video has jagged edges on the text whereas the first method doesn't.

I've upgraded to OS 10.6.2 and FCP 7.0.1....In FCP 6 the ProRes 422 export option did not do this.

Quote

Why does the size of the video change?

It doesn't. Exporting from the Final Cut timeline gives you a Quicktime movie in the same format as your timeline. As long as you don't have "recompress all frames" checked, all it does is copy the frames from your various clips and render files and write them to a new Quicktime movie file.

Quicktime Player is notoriously bad at reporting encoded and displayed raster sizes for non-square-pixel formats. If you ever have a question about raster size, just drop your Quicktime movie into a bin in Final Cut and examine the resulting clip's item properties. Those values are always accurate. (Well, at least they always have been in my experience. There's probably an exception to be found out there somewhere.)

I just did a little more searching and found this thread from this forum:

[www.lafcpug.org]

I did what it suggests and opened the file in MPEG Streamclip and it shows the file being 720 x 486 so I guess there isn't really a problem....just confusing QT reporting!

I think it's that the *window* that QT is displaying in is at 640x480. So it reports that the current size is 640x480 - but then lets you know that the original file is 720x486. Certainly whenever you bring these files into a broadcast workflow they are accurate.

Huh. It turns out I might have been mistaken all these years.

The reason I said Quicktime Player is notoriously bad at reporting raster sizes is because sometimes it reports the "actual size" of HD material as being 1888x1062, instead of 1920x1080. I always just assumed this was a bug, because the numbers seemed to make no sense.

But I've gone back and done some reading, and found that this can be traced to QuickTime 7.1's implementation of an informational annex to an SMPTE spec. Seriously.

SMPTE 274M, which defined the "1920 x 1080 Image Sample Structure Digital Representation and Digital Timing Reference Sequences for Multiple Picture Rates," included an informational annex that defined what they call the "clean" aperture. It's disgustingly technical, but the short version is that cramming 1920x1080 into a 6 MHz analog broadcast channel could introduce some artifacts around the edges of the raster. They went on to say that the worst-case scenario says that sixteen samples on the left and right side, and nine scan lines on the top and bottom, can have artifacts. So the "clean aperture" is the part of the raster that's inside that limit, or 1888 samples by 1062 lines.

It further turns out that QuickTime 7.1 implemented that, even though it's an FYI and not an actual part of the specification. Some HD Quicktime movies open as clean aperture by default. Others don't; I'm not sure why. But that's why Quicktime Player reports the "actual size" as being 1888x1062. That's because the actual size really is 1888x1062 when clean aperture is turned on. I never even noticed that the image was cropped.

Final Cut doesn't pay attention to the clean aperture, for obvious reasons. But Quicktime Player does. I guess it's good that Quicktime Player complies so strenuously with SMPTE specs ? even parts of specifications that nobody's ever heard of before.

So when Quicktime Player says 640x480, what I guess it's doing is correcting for non-square pixels (as it should; this is correct behavior) and then reporting the actual pixel dimensions of the corrected raster. One could argue whether this is the right thing to do or not. It's certainly confused and annoyed me in the past, because what I wanted to know was what the actual samples-by-lines dimensions were, not what the computer was correcting them to for on-screen display.

Oh well. At least now that I understand what Quicktime is doing, I can stop ignoring that feature and work with it.

EDIT: In case anybody wants more detail, it's all documented here. The relevant part is this:

Quote

? Classic. Content appears as it did in QuickTime 7. The existing track dimensions are respected. A DV NTSC (4:3 or 16:9) track appears as 720 x 480.


? Clean. Content may appear different than in QuickTime 7. Conformed tracks are cropped to the clean aperture mode and scaled according to the pixel aspect ratio. The resulting movie composition may be different, as may the movie box. This is the new default for consumer applications. A 4:3 DV NTSC track appears as 640 x 480; a 16:9 DV NTSC track appears as 853 x 480.

? Production. Content may appear different than in QuickTime 7. Conformed tracks are not cropped to the clean aperture mode, but they are scaled according to the pixel aspect ratio. The resulting movie composition may be different, as may the movie box. This would be typically used for professional applications wanting to see all the pixels, but with the correct aspect ratio. A 4:3 DV NTSC track appears as 654 x 480; a 16:9 DV NTSC track appears as 873 x 480.

? Encoded pixels. Content typically appears the same as QuickTime 7. Conformed tracks are not cropped to the clean aperture mode, and are not scaled according to the pixel aspect ratio. The encoded dimensions of the image description are displayed. This would be typically used to preview rendering (where you want all pixels) in a professional application. A DV NTSC (4:3 or 16:9) track appears as 720 x 480.

So basically, you want to use either the "Production" or "Encoded pixels" setting, most likely. Production corrects for pixel aspect ratio, while encoded pixels shows you one pixel per sample, and one row of pixels per scan line.