[Dennis Couzin]

I used Ra-ey Saleh’s suggestion of ALT+2 to step through fields. Amazingly, all three viewable QuickTimes exhibited screwed-up field order. That is, time goes 1 step backward, 2 steps forward, 1 step backward, 2 steps forward, etc., field to field. Can the field dominance really be wrong in every case? The original interlaced video was DV-PAL and one of the FCP exports to QT was straight DV-PAL. Did FCP even screw up that one, or is Avid misreading the QT?

Concerning the missing 10-bit codecs, I will either need to install QT Pro on my PC (where I’ve installed Avid), or else install Avid on my Mac (where the codecs definitely reside).

I’m aghast that the field order problem already shows on the 8-bit QTs.

[Dennis Couzin]

Thanks Andy for both suggestions.
Voilà, Avid Media Composer 3.5 is in my Thinkpad now.

Problem 1: The 8-bit QTs import fine, but the 10-bit uncompressed QTs import as all white. I can step through the frames, so the clips are there, but I just see white. I installed Avid Codecs PE to no avail.

Problem 2: I can only step through frames. How does one step through fields in this application?

[Dennis Couzin]

Rafael, I’m not sure that method can be trusted. The FCP viewer shows two fields interleaved into a frame. How do we know which of these fields will be shown first when the video is displayed interlaced? For example, suppose the camera took fields in this temporal order: …I,J,K,L,M,N,… and suppose the viewer shows a frame consisting of I&J, then a frame of K&L, then a frame of M&N, etc. These frames will look OK, with minimal zigzag. But if somehow the field order had become screwed up in the file, like …J,I,L,K,N,M… then the viewer could have shown those same decent frames, while an interlaced display of fields in the order …J,I,L,K,N,M… will have terrible jitter. I think that this can happen with some codec conversions if they are not properly applied (or not properly written). I managed to make the jitters once, and want to be sure I don’t again.

In fact, if anyone’s interested, I’ve posted 5 conversions of a 16 frame interlaced clip at https://www.mediafire.com/download.php?dnytvummgld. I don’t know if any of them have screwed up field order, but I did calculate that the fall-none.mov file contains exactly 16½ frames worth of data. The other three uncompressed files contain exactly 16 frames worth. How did that extra ½ frame (= 1 field?) get into that file — thank you, FCP — and what does it imply for the field sequence in fall-none.mov?

[Dennis Couzin]

Thanks David for showing a sleaker solution.
Hiding in the corners of Apple’s cobbled code are great tricks and also legacy garbage. My general preference for entering numbers over trusting jargon, such as “Conform aperture to production”, is not the best approach to QuickTime.
The “proper” solution is one that completely avoids what Rafael refers to as “unpredictable results”. Maybe David’s is one.

[Dennis Couzin]

My experience is all with PAL’s rectangular pixels, but I think you have no problem.

I leave my timeline with its usual rectangular pixels and go straight to Compressor for the mpeg2 conversion. DVD Studio Pro imports this file to make the DVD files. The resulting DVD plays with the correct aspect ratio.

I can make a QuickTime file straight from the same timeline. It initially plays with the wrong aspect ratio, but this is easily fixed in the QuickTime file playback data as follows:
(1) Open the file with QuickTime.
(2) Go to Window>Show Movie Properties.
(3) Select the Video Track
(4) Deselect Preserve Aspect Ratio
(5) Change the scaled size to give the aspect ratio you want. Do this by increasing one number while leaving the other number fixed.
(6) Press the Enter key
(7) Quit QuickTime Player
(8) Save changes.

The QuickTime file, with or without the playback modification, could also be used in Compressor to make the mpeg2 to make a DVD which plays with the correct aspect ratio.

[Dennis Couzin]

Field dominance is pretty well explained in https://lurkertech.com/lg/fields/. I’m no expert, and don’t know if your settings were right and if FCP honored them. Let the experts on this forum weigh in.
If you have access to a CRT monitor, field dominance error is easy to see on that. FCP can’t step through fields as a decent editor should.
I once made a big Quicktime (DV-PAL converted to 10-bit uncompressed 4:2:2) with reversed fields, so I’m nervous about repeating the error. Now I’ll check Quicktimes I make on a friend’s Avid system.

[Dennis Couzin]

Jitters sounds like field reversal.
Were you careful in chosing the field dominance at each step? (Was the camera even set at 50i or perhaps 25p?)
(FCP has been accused of blowing field dominance with European formats.)

[Dennis Couzin]

Thank you Noah and George for this information. Obviously I must find a new authorer.

[Dennis Couzin]

[Gary Adcock]: “YUV video is more analogous to the ICE-LAB colorspace than the RGB space, and if you did actually know these color spaces you would understand that RGB info is indicating how many colors as Chroma that can be recorded while YUV bit depth is determined by levels of Luma that can be captured.”

It was in response to this erroneous statement that I wrote “Do not confuse ‘chroma’ with color.”

RGB does NOT indicate “how many colors AS CHROMA can be recorded”. Chroma is 2-dimensional, and RGB gives a 3-dimensional indication. Indeed RGB contains the (1-dimensional) luminance information as well as the (2-dimensional) chroma information. When there are 8 bits for each of R,G,B there are 2^24 COLORS represented. There are not 2^24 CHROMA represented. I can only repeat: do not confuse ‘chroma’ with color.

[Dennis Couzin]

Rafael, that was exactly what I meant.