The Problem

A QuickTime media has a 32-bit TimeScale. Each sample in a QuickTime media has a 32-bit duration. Together the duration and TimeScale let you specify the frame rate of your video data.

A QuickTime movie has a 32-bit TimeScale. Each item in a QuickTime track's edit list contains a 32-bit duration in the movie TimeScale and a 32-bit media time in the media TimeScale. Therefore, the precision of track edit boundaries is determined by the movie TimeScale. A QuickTime movie also has a 32-bit duration in the movie TimeScale.

All 32-bit quantities mentioned above are two's complement signed values.

Since the track's edit list item's media time (in media TimeScale) and the movie duration (in movie TimeScale) are 32-bit quantities, it is important to choose TimeScales which will not overflow these fields under normal use. This issue also arises at runtime. Although most of the QuickTime APIs for manipulating media and movie times use 64-bit quantities (e.g., TimeRecord, ICMFrameTime), some of QuickTime's internal time calculations use only 32 bits, and some QuickTime APIs (e.g., CallMeWhen()) have no 64-bit version.

Solutions

PAL and digital 625 video have exactly 25 frames per second. A media TimeScale of 25 and media sample durations of 1, along with a movie TimeScale of 25, provides 2 years of time in 32 bits. This works well for video-only movies.

NTSC and digital 525 video have exactly 30/1.001 frames per second. A media TimeScale of 30000 and media sample durations of 1001, along with a movie TimeScale of 30000, provide 19.9 hours of time in 32 bits.

The 30/1.001 rate of NTSC and digital 525 is sometimes approximated to (or mistaken to be) 29.97, which does not equal 30/1.001. The average rate of drop-frame timecode (e.g., LTC and VITC used in the video industry) over 24 hours is exactly 29.97, but the use of drop-frame timecode does not modify the video signal rate. Some existing movies have a media TimeScale of 2997, media sample durations of 100, and a movie TimeScale of 2997. This provides 8.2 days of time before 32-bit overflow, however after 4.6 hours, this representation deviates from the actual video timing by half a frame time. For tracks with a 2997 timescale which are longer than 4.6 hours, a frame-accurate representation of the video timing is only possible if the frames are allowed to have differing durations.

Most applications today only deal with material shorter than 4.6 hours. These applications should be able to read video movies with either 2997 or 30000 TimeScales. They may write either, but the 30000 TimeScale is preferred since it has a sufficient overflow time and precisely models the video signal.

Finally, some existing movies have a media TimeScale of 30, media sample durations of 1, and a movie TimeScale of 30. This provides 2 years of time in 32 bits, but the representation deviates from NTSC/digital 525 video timing by half a frame time after only 16 seconds! Any such movies intended for 30/1.001 frame/second video are mislabeled. Some such movies may be intended for graphics output devices whose rates are really 30 frames/second, but typically these are low-bitrate compressed movies where precise timing is not required. Therefore, a QuickTime reader which encounters a 30 frame per second movie with a compression type from this document but without the required ImageDescription extensions from this document should assume that the actual image rate is 30/1.001. All new movies with the compression types from this document should be created with the extensions from this document and should avoid image rate 30 for standard definition video.

The SMPTE HDTV formats (1920x1035, 1920x1080, 1280x720) have both a 30 (or 60) frame/second variety and a 30/1.001 (or 60/1.001) frame/second variety. Be careful to properly label HDTV data in QuickTime files.

Audio and Video

For movies with audio and video tracks, it is sometimes desirable to specify edits on the audio track at a finer granularity than a video frame. Since all edits (regardless of track) are specified on the movie TimeScale, you must choose a TimeScale which satisfies the needs of edits on both the audio and video tracks.

Ideally, you would choose a TimeScale which is the least common multiple of the audio and video media TimeScales. Audio tracks typically have a TimeScale equal to the number of audio frames per second (e.g., 22050, 44100, 48000). For some combinations of common audio and video media TimeScales, this will again result in 32-bit time overflow. This tradeoff must be made according to application needs.

Scheme A: 'Wide-Range' Mapping with Unsigned Y´, Two's Complement Cb, Cr

Scheme A transforms E_Y´, E_Cb, and E_Cr into n-bit Y´, Cb, and Cr (n >= 8) in this way:

Y´ = floor(0.5 + (2n-1) * EY´)

Cb = floor(0.5 + (2n-2) * ECb)

Cr = floor(0.5 + (2n-2) * ECr)

For n=8 bits, this yields:

Y´ = floor(0.5 + 255 * EY´)    Y´ = [0,255]     as EY´ = [0,1]

Cb = floor(0.5 + 254 * ECb)    Cb = [-127,+127] as ECb = [-0.5, +0.5]

Cr = floor(0.5 + 254 * ECr)    Cr = [-127,+127] as ECr = [-0.5, +0.5]

Y´ is an unsigned integer. Cb and Cr are two's complement signed integers.

The value -2^n-1 (-128 for n=8 bits) may appear in a buffer due to filter undershoot. The writer of a QuickTime image may use the value. The reader of a QuickTime image must expect the value.

Scheme B: 'Video-Range' Mapping with Unsigned Y´, Offset Binary Cb, Cr

Scheme B comes from digital video industry specifications such as Rec. ITU-R BT. 601-4. All standard digital video tape formats (e.g., SMPTE D-1, SMPTE D-5) and all standard digital video links (e.g., SMPTE 259M-1997 serial digital video) use this scheme. Professional video storage and processing equipment from vendors such as Abekas, Accom, and SGI also use this scheme. MPEG-2, DVC and many other codecs specify source Y´CbCr pixels using this scheme.

Scheme B transforms E_Y´, E_Cb, and E_Cr into n-bit Y´, Cb, and Cr (n >= 8) in this way:

Y´ = floor(0.5 + 2n-8*(219 * EY´ + 16))

Cb = floor(0.5 + 2n-8*(224 * ECb + 128))

Cr = floor(0.5 + 2n-8*(224 * ECr + 128))

For n=8 bits, this yields:

Y´ = floor(0.5 + 219 * EY´ +  16)    Y´ = [16,235] as EY´ = [0,1]

Cb = floor(0.5 + 224 * ECb + 128)    Cb = [16,240] as ECb = [-0.5, +0.5]

Cr = floor(0.5 + 224 * ECr + 128)    Cr = [16,240] as ECr = [-0.5, +0.5]

For n=10 bits, this yields:

Y´ = floor(0.5 + 876 * EY´ +  64)    Y´ = [64,940] as EY´ = [0,1]

Cb = floor(0.5 + 896 * ECb + 512)    Cb = [64,960] as ECb = [-0.5, +0.5]

Cr = floor(0.5 + 896 * ECr + 512)    Cr = [64,960] as ECr = [-0.5, +0.5]

Y´ is an unsigned integer. Cb and Cr are offset binary integers.

Certain Y´, Cb, and Cr component values v are reserved as synchronization signals and must not appear in a buffer:

0         <=  v  <  2n-8

2n - 2n-8  <=  v  <  2n

For n=8 bits, these are values 0 and 255. For n=10 bits, these are values 0, 1, 2, 3, 1020, 1021, 1022, and 1023. The writer of a QuickTime image is responsible for omitting these values. The reader of a QuickTime image may assume that they are not present.

The remaining component values (e.g., 1-15 and 241-254 for n=8 bits and 4-63 and 961-1019 for n=10 bits) accommodate occasional filter undershoot and overshoot in image processing. In some applications, these values are used to carry other information (e.g., transparency). The writer of a QuickTime image may use these values and the reader of a QuickTime image must expect these values.

Zero Bits

Some of the compression types below include zero bits which are not used to encode image data. The writer of a QuickTime image must place zero in these bits. Image processing operations must continue to place zero in these bits. The reader of a QuickTime image can assume the bits are zero.

'yuv2' vs. '2vuy'

We will define two 8-bit 4:2:2 compression types:

• '2vuy' is the format long used by professional video tape formats, transmission protocols, processing equipment (both computer-based and not), and compression schemes. It uses scheme B ("Video-Range" Mapping with Unsigned Y´, Offset Binary Cb, Cr) to get from from E_Y´, E_Cb, and E_Cr to 8-bit Y´, Cb, and Cr, so it discards no information from a digital video link. Its component order also matches that transmitted over a digital video link.

• 'yuv2' is a format used by PC-based display cards with Y´CbCr to E_R´, E_G´ E_B´ conversion hardware, which is typically used to accelerate MPEG decompression. Macintosh built-in video digitizers also use 'yuv2'.

'2vuy' is the preferred format for hardware and software development for which the choice is otherwise arbitrary.

'2vuy' 4:2:2 Compression Type

The ImageCompression.h token to use is k422YpCbCr8CodecType.

The codec name to use is "Component Y'CbCr 8-bit 4:2:2".

This compression type uses scheme B ("Video-Range" Mapping with Unsigned Y´, Offset Binary Cb, Cr) to get from E_Y´, E_Cb, and E_Cr to Y´, Cb, and Cr. bytes_per_luma_instant is 2. horiz_align_pixels is 2. depth is 24. Despite the name, this pixel format is not a simple byte-reversal of 'yuv2.'

There are '2vuy' files in the field with a version less than 2. If you want to support such files, see '2vuy'

'yuv2' 4:2:2 Compression Type

The ImageCompression.h token to use is kComponentVideoCodecType.

The codec name to use is "Component Video".

This compression type uses scheme A ("Wide-Range" Mapping with Unsigned Y´, Two's Complement Cb, Cr) to get from E_Y´, E_Cb, and E_Cr to Y´, Cb, and Cr. bytes_per_luma_instant is 2. horiz_align_pixels is 2. depth is 24. Despite the name, this pixel format is not a simple byte-reversal of '2vuy.'

As described in Technical Note "QuickTime Pixel Format FourCCs", the 'yuv2' file format is equivalent to the 'yuvu' pixel format.

There are 'yuv2' files in the field with a version less than 2. If you want to support such files, see 'yuv2' Backwards Compatibility.

v308' 4:4:4 Compression Type

The ImageCompression.h token to use is k444YpCbCr8CodecType.

The codec name to use is "Component Y'CbCr 8-bit 4:4:4".

This compression type uses scheme B ("Video-Range" Mapping with Unsigned Y´, Offset Binary Cb, Cr) to get from E_Y´, E_Cb, and E_Cr to Y´, Cb, and Cr. bytes_per_luma_instant is 3. horiz_align_pixels is 2. depth is 24

v408' 4:4:4:4 Compression Type

The ImageCompression.h token to use is k4444YpCbCrA8CodecType.

The codec name to use is "Component Y'CbCrA 8-bit 4:4:4:4".

This compression type uses scheme B ("Video-Range" Mapping with Unsigned Y´, Offset Binary Cb, Cr) to get from E_Y´, E_Cb, and E_Cr to Y´, Cb, and Cr. bytes_per_luma_instant is 4. horiz_align_pixels is 2. depth is 32.

In the absence of other information, assume the A (alpha) component behaves like Y´ as described in SMPTE RP 157-1995. 16 is completely transparent and 235 is completely opaque, and one is intended to linearly blend Y´, Cb, and Cr components based on the percentage between 16 and 235.

v216' 4:2:2 Compression Type

The ImageCompression.h token to use is k422YpCbCr16CodecType.

The codec name to use is "Component Y'CbCr 10,12,14,16-bit 4:2:2".

Each n-bit component is left justified in a 16 bit little-endian word. The 16-n least significant bits of the 16 bit word are zero bits (described above). This compression type uses scheme B ("Video-Range" Mapping with Unsigned Y´, Offset Binary Cb, Cr) to get from E_Y´, E_Cb, and E_Cr to Y´, Cb, and Cr. bytes_per_luma_instant is 4. horiz_align_pixels is 2. depth is 24.

n is determined by a required 'sgbt' extension:

'v410' 4:4:4 Compression Type

The ImageCompression.h token to use is k444YpCbCr10CodecType.

The codec name to use is "Component Y'CbCr 10-bit 4:4:4".

3 10-bit unsigned components are packed into a 32-bit little-endian word. Here are the bits of the 32-bit little-endian word in decreasing address order:

The 2 X bits are zero bits, described above. This compression type uses scheme B ("Video-Range" Mapping with Unsigned Y´, Offset Binary Cb, Cr) to get from E_Y´, E_Cb, and E_Cr to Y´, Cb, and Cr. bytes_per_luma_instant is 4. horiz_align_pixels is 2. depth is 24.

v210' 4:2:2 Compression Type

The ImageCompression.h token to use is k422YpCbCr10CodecType.

The codec name to use is "Component Y'CbCr 10-bit 4:2:2".

12 10-bit unsigned components are packed into four 32-bit little-endian words. Here are the four 32-bit words in increasing address order:

Here are the bits of the four 32-bit little-endian words in decreasing address order. We have numbered each component with its spatial order. As you move from left to right in the QuickTime image, Y´ goes from 0 to 5 and Cb and Cr go from 0 to 2. Y´ number 0 is a Y´0 sample as described in Y´CbCr Spatial Relationship.

The X bits are zero bits, described above. This compression type uses scheme B ("Video-Range" Mapping with Unsigned Y´, Offset Binary Cb, Cr) to get from E_Y´, E_Cb, and E_Cr to Y´, Cb, and Cr.

bytes_per_luma_instant is 8/3. horiz_align_pixels is 48. depth is 24.

As described in ImageDescription Structures and Image Buffers, the width field must be a multiple of horiz_align_pixels for all compression types in this document. As a special case that applies to the 'v210' compression type only, width may be a multiple of 2 that is not a multiple of horiz_align_pixels (48). Each line of video data in an image buffer is padded out to the nearest 48 pixel (128 byte) boundary. The bits used for Y´, Cb, and Cr components beyond pixel width are zero bits.

As an example, say width is 1280 (as it is for 1280x720 HDTV video, SMPTE 296M-1997). 1280 is not a multiple of 48. So each line in the file occupies 1296 pixels (3456 bytes) instead of 1280 pixels. Say width is 1920 (as it is for 1920x1080 HDTV video, SMPTE 274M-1995). 1920 is a multiple of 48. So each line in the file occupies exactly 1920 pixels (5120 bytes).

Primaries

Here are the values of primaries:

The following values, from Recommendation ITU-R BT.470-4 System M and the 1953 FCC NTSC spec, are obsolete and have never been used to code any digital image. If you are told your image is coded with these values, you almost definitely want the SMPTE C primaries (code 6 above) instead:

The following values, from Recommendation ITU-R BT.470-4 System B, G, have been superseded by EBU Tech. 3213 (code 5 above). EBU Tech. 3213 values are used for 625-line digital and composite PAL video:

Transfer Function

Here are the values of transferFunction (function f() in the diagram above). Transfer function is identical for red, green, and blue, and is shown as a mapping from W (e.g., R, G, B) to E_W´ (e.g., E_R´ E_G´ E_B´):

The MPEG-2 sequence display extension transfer_characteristics defines a code 6 whose transfer function is identical to that in code 1. QuickTime writers should map 6 to 1 when converting from transfer_characteristics to transferFunction.

Recommendation ITU-R BT.470-4 specified an "assumed gamma value of the receiver for which the primary signals are pre-corrected" as 2.2 for NTSC and 2.8 for PAL systems. This information is both incomplete and obsolete. Modern 525- and 625-line digital and NTSC/PAL systems use the transfer function with code 1 above.

The 'colr' extension supersedes the previously defined 'gama' ImageDescription extension. Writers of QuickTime files should never write both into an ImageDescription, and readers of QuickTime files should ignore 'gama' if 'colr' is present.

Some Macintosh-based video systems apply an additional transfer function to incoming Y´CbCr data at capture time so that when it is converted to nonlinear R´G´B´ for display on a Macintosh screen at playback time, it looks correct given the default Macintosh graphics backend transfer function. This operation is currently not representable or supported by the 'colr' parameters.

Matrix

Here are the values for matrix. We show a formula for E_Y´ in the range [0,1]. You can derive the formula for E_Cb and E_Cr by normalizing (E_Y´ - E_B´) and (E_Y´ - E_R´), respectively, to the range [-0.5,+0.5]. In other words, if the E_Y´ equation has the form:

Then the formulas for E_Cb and E_Cr are:

The MPEG-2 sequence display extension matrix_coefficients defines a code 5 whose matrix is identical to that in code 6. QuickTime writers should map 5 to 6 when converting from matrix_coefficients to matrix.

The following values, from the 1953 FCC NTSC spec, are obsolete. If you are told your image is coded with these values, you almost definitely want the SMPTE 170M-1994 values (code 6 above) instead:

The following values, from Recommendation ITU-R BT.709-1, have been superseded by Recommendation ITU-R BT.709-2 (code 1 above):

Sample 'colr' Settings

Unless you know better, here are the best values to use for some common video signal formats:

Some digital video signals can carry a video index (see SMPTE RP 186-1995) which explicitly labels the primaries, transferFunction, and matrix of the signal. If your video digitizing hardware can read video index, then use those values to fill in the 'colr' extension instead of the default values above. If your video output hardware can insert video index, consider doing so according to the 'colr' extension fields.

The 'fiel' ImageDescription Extension: Field/Frame Information

This extension is always required when using the compression types in this document. It defines the temporal and spatial relationship of each of the height lines of the data in an image buffer. This information is required to correctly display and process the video data (e.g., still frame, slow motion, CGI).

We give each line of the buffer, in order from lowest address to highest address, a number

The byte address of line n within the buffer is therefore rowBytes*n.

We give each line of the buffer, in spatial order from top to bottom, a number

Lines so numbered are called picture lines. On a display, picture lines are evenly spaced with no gaps. For interlaced images, a line in one field is vertically located exactly halfway between the next higher and lower lines in the other field. As you move from the top picture line to the bottom picture line of an interlaced buffer or display, you alternate between fields on each line.

We give each line of the buffer, in temporal order from earliest to latest, a number

For every setting of fields and detail, we will define S(n) and T(n), which map from address order to spatial and temporal order, respectively.

If fields is 1, then

• buffer contains a progressive scan image.

• detail is 0.

• S(n)=T(n)=n

If fields is 2, then

• buffer contains a 2:1 interlaced image. there are four possible address orderings:

• if (detail == 1), then

  • T(n)=n: buffer contains two fields in temporal order

  • case 1a: field with lower address contains topmost line

  • boundary = ceil(height/2)

  • if (n >= boundary), then S(n)= (n-boundary)*2+1 else S(n) = n*2

• if (detail == 6), then

  • T(n)=n: buffer contains two fields in temporal order

  • case 2a: field with higher address contains topmost line

  • boundary = floor(height/2)

  • if (n >= boundary), then S(n)= (n-boundary)*2 else S(n) = n*2+1

• if (detail == 9), then

  • S(n)=n: buffer contains two fields woven together in spatial order

  • case 1b: field containing line with lowest address is temporally earlier

  • if (n mod 2 == 0), then T(n)=n/2 else T(n)=floor(n/2)+ceil(height/2)

• if (detail == 14), then

  • S(n)=n: buffer contains two fields woven together in spatial order

  • case 2b: field containing line with lowest address is temporally later

  • f (n mod 2 == 0), then T(n)=n/2+floor(height/2) else T(n)=floor(n/2)

• None of the bits above directly imply a video signal field type (F1 or F2). The terms F1 and F2 refer to a characteristic of the electrical waveform of the video signal for a given field. In order to determine whether a field in a QuickTime file is F1 or F2, you must know the type of video signal and the intended position of the QuickTime buffer in the video raster. Given a video signal type, you can derive the raster position from the 'clap' ImageDescription extension described below.

• None of the bits above correspond to the often-misused term "field dominance." A piece of video footage acquires a field dominance when one commits to the frame boundaries on which the footage may be edited. Field dominance is either F1 dominant (edits fall between an F2 and a subsequent F1) or F2 dominant (edits fall between an F1 and a subsequent F2). Once video footage is placed in a QuickTime file, its fields have been grouped into frames, and edits are only possible on one boundary or the other. So to determine the field dominance of video footage in a QuickTime file, determine the field type (F1 or F2) of the temporally earlier field in each frame of the QuickTime file. The temporally earlier field of each QuickTime frame is a dominant field and the temporally later field of each QuickTime frame is a non-dominant field.

Standard Definition Pixel Aspect Ratios

There is widespread confusion about the pixel aspect ratio of standard definition video formats. If your device transfers one of these 4:3 picture aspect ratio video formats, these are the correct pixel aspect ratios:

The luma sampling frequencies shown above (13.5 MHz, (12+3/11) MHz, and 14.75 MHz) are ubiquitous in the video industry. Furthermore, all existing (and probably future) standard definition video equipment assumes that sampling a 525-line signal at (12+3/11) MHz, or a 625-line signal at 14.75 MHz, yields square pixels. Therefore, for the standard definition formats we derive the pixel aspect ratio of non-square pixels (13.5 MHz in both cases) by taking a ratio of 13.5 MHz and the square sampling frequency.

Typical applications manipulate 720 pixel wide images for non-square data and 640 (525-line) or 768 (625-line) pixel wide images for square data. Note that 640/720 does not equal 10/11, and 768/720 does not equal 59/54. If you want to convert images between square and non-square using the widths above, you will need to either crop the source image or pad the destination image: images with the widths above do not represent the same underlying region of the video signal. You should maintain the picture center when performing these padding or cropping operations.

In theory, the non-square pixel aspect ratios above, and therefore also the square luma sampling frequencies, are superseded by the new calculations in SMPTE RP 187-1995. However, because the standard definition pixel aspect ratios from that spec do not reflect the actual ratios used by any existing (and probably future) standard definition equipment, you should use the values above. For the same reason, the 13.5 MHz and 18 MHz clean aperture figures which we will present in Typical width, height, and 'clap' Settings differ from those in SMPTE RP 187-1995.

Here is a comparable chart for the existing standard definition formats with 16:9 picture aspect ratio. With the exception of the 18 MHz format, the formats below are electrically identical to the ones in the table above. Typically you use the 16:9 formats below by pushing a button labeled "16:9" on a standard 4:3 monitor; the monitor takes the same signal and displays it vertically compressed. The clean apertures of the 16:9 formats have the same number of pixels and lines as the 4:3 formats above. The difference is that 16:9 cameras will capture data 16 units wide by 9 units high into the clean aperture, and 16:9 monitors will display the clean aperture such that it is 16 units wide by 9 units high on the display surface, instead of 4 by 3. Since the clean aperture still has the same number of pixels and lines but now has a different picture aspect ratio, you can map 4:3 values above into 16:9 values below by simply multiplying by (16/9)/(4/3)=(4/3). The 18 MHz SMPTE 267M-1995 standard is exceptional in that its clean aperture has 4/3 as many pixels per line so that the pixels can retain the pixel aspect ratio of 525-line 4:3 digital video (10/11).

High Definition Pixel Aspect Ratios

Design of the HDTV formats had the benefit of hindsight. These formats define a clean aperture whose picture aspect ratio is exactly 16:9. Looking at the number of pixels and lines in the clean aperture, you can compute the pixel aspect ratio. One need not consider the luma sampling frequency.

For 1920x1035 HDTV (SMPTE 240M-1995, SMPTE 260M-1992), the clean aperture size is uncertain. SMPTE 240M-1995 and SMPTE 260M-1992 specify a clean aperture of 1888 pixels by 1017 lines. However, SMPTE RP 187-1995 specifies a clean aperture of 1888 pixels by 1018 lines. 1018 seems to be the more sensible value: since the picture center is located halfway between two lines, a clean aperture height which is 0 mod 2 puts the top and bottom of the clean aperture on lines instead of between lines. Industry practice will decide. Here are the values:

1920x1080 and 1280x720 HDTV are square-pixel:

Typical width, height, and 'clap' Settings

Typically, an application will manipulate QuickTime images whose width and height match the production aperture of a particular interface standard, whose 'clap' cleanApertureWidth and cleanApertureHeight match the clean aperture of that standard, and whose 'clap' horizOff and vertOff are zero.

The table below reproduces the picture center location, production aperture size, and clean aperture size for common video interface standards.

For the 525- and 625-line formats, the dimensions of the production and clean apertures depend on the luma sampling frequency. In the 'pasp' ImageDescription extension above, we explained how luma sampling frequency relates to pixel aspect ratio and picture aspect ratio. In that section, we also explained why the clean aperture dimensions below do not match those found in SMPTE RP 187-1995.

525-Line Example

Here are the most common settings for 525-line signals sampled at 13.5 MHz:

Here are the most common settings for 525-line signals sampled at (12+3/11) MHz:

This diagram shows the video lines of a 525-line signal interleaved in picture line order (spatial order from top to bottom). We have superimposed a 486-line image with the settings above. The vertical picture center of the QuickTime image is at (height-1)/2 since vertOff is 0. The vertical picture center of the video interface standard falls halfway between line 404 (field 2) and 142 (field 1). So the top and bottom lines of the QuickTime image are located

picture lines above and below the picture center:

The settings of width, height, and the 'clap' extension are closely related to those of the 'fiel' ImageDescription extension. Here are some example scenarios:

• Say you are using the settings shown above. The topmost line of your 486-line QuickTime image gets transmitted on a line of F2 (line 283).

  • Say each frame of your QuickTime file contains an F1 field temporally followed by an F2 field (this is called F1 dominance). Since the topmost line of your QuickTime image is in F2, it gets transmitted in the temporally later field. We would therefore expect to see case 2a or 2b as described in the 'fiel' extension.

  • Say instead that each frame of your QuickTime file contains an F2 field temporally followed by an F1 field (F2 dominance). Since the topmost line of your QuickTime image is in F2, it gets transmitted in the temporally earlier field. We would therefore expect to see case 1a or 1b in the 'fiel' extension.

• Now you switch to a different 486-line QuickTime image whose 'clap' extension has a vertOff of 1. Unlike the diagram above, the topmost line of your QuickTime image gets transmitted on a line of F1 (line 21).

  • Say each frame of your QuickTime file contains an F1 field temporally followed by an F2 field (F1 dominance). Since the topmost line of your QuickTime image is in F1, it gets transmitted in the temporally earlier field. We would therefore expect to see case 1a or 1b as described in the 'fiel' extension.

  • Say instead that each frame of your QuickTime file contains an F2 field temporally followed by an F1 field (F2 dominance). Since the topmost line of your QuickTime image is in F1, it gets transmitted in the temporally later field. We would therefore expect to see case 2a or 2b in the 'fiel' extension.

625-Line Example

Here are the most common settings for 625-line signals sampled at 13.5 MHz:

Here are the most common settings for 625-line signals sampled at 14.75 MHz:

This diagram shows a 625-line signal interleaved in picture line order. We have superimposed a 576-line image with the settings above. The vertical picture center of the QuickTime image is at (height-1)/2 since vertOff is 0. The vertical picture center of the interface standard falls halfway between line 479 (field 2) and 167 (field 1). So the top and bottom lines of the QuickTime image are located

picture lines above and below the picture center:

'2vuy' Backwards Compatibility

There are some existing '2vuy' files which have version 0 or version 1 and which lack the ImageDescription extensions described in this document. In general it is not possible to derive all the parameters. If you want to support such files, here are the best assumptions to use:

• if height is 486, file was recorded from the production aperture of a 525-line digital source, with F1 dominance and exactly the parameters described in The Production Level of Conformance. So:

  • 'pasp' extension: pixel aspect ratio is 10/11.

  • 'fiel' extension: fields is 2 and detail is 14.

  • 'clap' and 'colr' extension:

    • width: 720

    • height: 486

    • 'clap' cleanApertureWidth: (640*(11/10))

    • 'clap' cleanApertureHeight: 480

    • 'clap' horizOff: 0

    • 'clap' vertOff: 0

    • 'colr' colorParamType: 'nclc'

    • 'colr' primaries: 6

    • 'colr' transferFunction: 1

    • 'colr' matrix: 6

• if height is 576, file was recorded from the production aperture of a 625-line digital source, with F1 dominance and exactly the parameters described in The Production Level of Conformance. So:

  • 'pasp' extension: pixel aspect ratio is 59/54.

  • 'fiel' extension: fields is 2 and detail is 9.

  • 'clap' and 'colr' extension:

    • width: 720

    • height: 576

    • 'clap' cleanApertureWidth: (768*(54/59))

    • 'clap' cleanApertureHeight: 576

    • 'clap' horizOff: 0

    • 'clap' vertOff: 0

    • 'colr' colorParamType: 'nclc'

    • 'colr' primaries: 5

    • 'colr' transferFunction: 1

    • 'colr' matrix: 6

'yuv2' Backwards Compatibility

There are some existing 'yuv2' files which lack the required ImageDescription extensions. In some cases, these files may have a width which is not a multiple of horiz_align_pixels (see ImageDescription Structures and Image Buffers).

In general it is not possible to derive all the ImageDescription parameters. If you want to support such files, here are the best assumptions to use:

• 'pasp' extension: pixel aspect ratio is 1/1.

• 'fiel' extension: fields is 1 and detail is 0. Each buffer contains one of the two fields of each frame from a standard definition video signal, which thus looks like a progressive scan signal at half the vertical resolution of the video signal.

• 'clap' and 'colr' extension: if height is 240, file was recorded from a composite NTSC source with these parameters:

  • width: 320

  • height: 240

  • 'clap' cleanApertureWidth: 320

  • 'clap' cleanApertureHeight: 240

  • 'clap' horizOff: unpredictable (guess 0)

  • 'clap' vertOff: unpredictable (guess 0)

  • 'colr' colorParamType: 'nclc'

  • 'colr' primaries: 6

  • 'colr' transferFunction: 1

  • 'colr' matrix: 6

• If height is 288, file was recorded from a composite PAL source with these parameters:

  • width: 384

  • height: 288

  • 'clap' cleanApertureWidth: 384

  • 'clap' cleanApertureHeight: 288

  • 'clap' horizOff: unpredictable (guess 0)

  • 'clap' vertOff: unpredictable (guess 0)

  • 'colr' colorParamType: 'nclc'

  • 'colr' primaries: 5

  • 'colr' transferFunction: 1

  • 'colr' matrix: 6

'2vuy' is the preferred format for hardware and software development for which the choice is otherwise arbitrary. All new '2vuy' and 'yuv2' files should be created with the proper extensions and version 2.

Appendix: Issues Not Addressed

The compression types and ImageDescription extensions described in this document do not address:

• Separate alpha channels that tag along with the Y´CbCr data.

• Parameterization of alpha field so you can tell if it is a zero, don't care, or, if it is used, how it is to be interpreted.

• Using the 2 don't care bits of the 10:10:10:2 packings available as alpha.

• The meaning of the QuickTime video digitizer rectangles relative to the video standards.

• Use of these extensions outside uncompressed Y´CbCr (e.g., DV, M-JPEG, still JPEG, JFIF coordination). Many of the ImageDescription extensions can be applied with very little additional effort to other formats; we would appreciate any feedback on issues that arise.

• Labeling of uncompressed R´G´B´ pixels. In particular, R´G´B´ pixels derived from 525-line, 625-line, or HD video sources represent different primaries and cannot be interchanged without appropriate labeling and conversion.

• The three different 10-bit, 4:2:2 Y´CbCr formats used by:

  • Abekas A60 and Accom RTD

  • Accom WSD 2Xtreme

  • Sierra Design Labs QuickFrame

• Labeling of Y´CbCr pixels with non-standard primaries, transfer function, or matrix, such as

  • might occur with very-low-end consumer cameras or other devices.

  • might occur due to bugs in commonly available parts, e.g., Zoran JPEG chipsets.