Pixels in an ITU-R BT.601-4 digital video signal (also known as Rec. 601 and formerly CCIR 601) are non-square. A 100 pixel vertical line may be longer or shorter than a 100 pixel horizontal line on a video monitor, depending on the video standard. See below for details.
The term which describes this is pixel aspect ratio. In SGI libraries it is specified as a fraction of vertical (y) pixel size divided by (x) horizontal pixel size. The pixel aspect ratio for square pixels is 1/1.
This term is different than frame aspect ratio, which is a fraction of total vertical (y) frame size over total horizontal (x) frame size, for a given definition of "frame."
Any rendering of geometry-based graphics to an image must take the pixel aspect ratio into account.
An analog video signal consists of discrete video lines, each of which is a continuous analog signal that represents the luma and chroma for that line of the image. So an analog video signal has no "pixels." When a video board samples a video line, it can sample whatever part of the line it pleases, and it can sample the line at whatever interval it pleases. For a given video signal format (525/625), a board may choose to sample the line according to one of two rules: square sampling or non-square sampling.
A Rec. 601 digital video signal is non-square. Some SGI video boards have horizontal resampling hardware which will give you square pixels in memory even if you have a Rec. 601 signal.
Therefore, if you get a buffer of pixels from a video board or give one to a video board, you need to know whether your pixels are square or non-square. Among other things, this will determine the image dimensions of your buffer.
Images in the DM (dmIC, etc.), MV, or CL libraries may be square pixel or non-square pixel, depending on context. There is a DM parameter DM_IMAGE_PIXEL_ASPECT which specifies the pixel aspect ratio (y/x) in movie files and other situations. Be careful: some of the movie capture and conversion programs shipped with SGI systems even as recently as IRIX 6.3 create movies where this parameter is always 1.0, or is an x/y value instead of a y/x value. These are known problems that will get fixed, but movies may exist with the bogus pixel aspect ratios (see Motion JPEG on SGI Systems for more on that).
For our VL and compression devices,
Example dmParams calls to set the params:
525-line non-square (Rec. 601):
dmParamsSetFloat(userImgParams, DM_IMAGE_PIXEL_ASPECT, ((double) 11.0 / (double) 10.0));625-line non-square (Rec. 601):
dmParamsSetFloat(userImgParams, DM_IMAGE_PIXEL_ASPECT, ((double) 54.0 / (double) 59.0));Contrary to popular belief, the pixel aspect ratios are not 4:3, nor are they 720/640 and 768/720! The actual ratios are defined purely in terms of the pixel sampling frequency of each video standard:
When the diagram says "pad," this means you need to pad the image out to 720 non-square pixels. Usually this means that you start with a greater number of square pixels than 640 or 768. Sometimes those pixels are not available, and you have to improvise.
When the diagram says either "pad" or "crop," it is best to do the padding or cropping so that the image stays centered.
A video board which is encoding or decoding an analog signal will never need to pad or crop: it can measure or synthesize the continuous analog signal for each video line any way it wants. Each analog video line is long enough to accomodate either horizontal range.
As a result, the 768-pixel-wide images you get from mvp for video-to-memory operations will be horizontally compressed by 1 7/33 pixel, and the 768-pixel-wide images you provide to mvp for memory-to-video operations will be horizontally expanded by 1 5/59 pixel on the video signal (where one pixel is defined as a Rec.601 luminance sampling instant). This quirk only affects square-pixel 625-line data; square 525 and non-square 625 and 525 work correctly.
This problem may be fixed in a future release of the mvp video hardware or system software. Unless you really need to account for this quirk now, we recommend that you assume the mvp hardware implements the correct ratios.
In theory, we could derive the square pixel sampling frequencies from the frame aspect ratio and other statistics from each analog signal spec. Unfortunately, while both ANSI/SMPTE 170M-1994 and Rec. ITU-R BT.470-3 state that the active picture has a 4:3 frame aspect ratio, neither spec defines "active picture" well enough to use in deriving an accurate square pixel sampling frequency. So the square pixel sampling frequencies in use today are industry conventions, not stated in any spec.
In 1995, SMPTE created RP 187, "Center, Aspect Ratio, and Blanking of Video Images," to address exactly that problem. Unfortunately, instead of recommending the values above, which were de facto industry standards even in 1995, RP 187 recommended a pixel aspect ratio of 177/160 (y/x) for 525-line video and 1035/1132 (y/x) for 625-line video. In addition to conflicting with pretty much every piece of square-sampling equipment in existence, these numbers are highly impractical to implement. They result in a non-integral numbers of luma and chroma sampling instants per line, which makes hardware people jump out of high windows. At a time when the industry so badly needed to standardize pixel aspect ratio and sampling frequencies, it's really too bad that RP 187 chose such impractical values: RP 187 will probably create more problems than it solves. Strangely, RP 187's informative annex A.4 talks about square to non-square conversion of computer images, and suggests resampling the image by a factor of 11:10---thus using the industry standard values and contradicting itself!
In rev 2 of ISO/IEC DIS 2-11172, the committee changed the pixel aspect ratios in the table, but sadly they still were not 11/10 or 54/59. The committee only changed the made-up canonical image dimensions to other made-up canonical image dimensions.
Even more bizarrely, in both drafts, the committee decided to fill in the 12 open slots in the pixel aspect ratio table with linear interpolations and extrapolations of the 525- and 625-line values! They topped it off with this conundrum:
"It is evident that the specification does not allow all possible pel aspect ratios to be specified. We therefore presume that a certain degree of tolerance is allowable. Encoders will convert the actual pel aspect ratio to the nearest value in the table, and decoders will display the decoded values to the nearest pel aspect ratio of which they are capable."Hopefully from this data you have learned not to trust the pixel aspect ratio encoded in an MPEG I video bitstream.
The MPEG II committee discarded the MPEG I pixel aspect table. But unfortunately it retained the notion that pixel aspect ratio depends on encoded image size. Pixel aspect of an MPEG II video bitstream sequence can be 1.0, or it can be specified in terms of a frame aspect ratio times a ratio of the image height and width in pixels. The frame aspect ratio can be a fixed value (4:3 or 16:9) or it can be encoded in the bitstream as any two integers. Unlike MPEG I, it's possible to twist the MPEG II paramers around in order to make them say what they should originally have said: that the pixel aspect is 11/10 or 54/59. It's too bad that the committee didn't just offer these as constants.
So I would watch out for the pixel aspect ratios encoded in all kinds of MPEG. If you know that data came from non-square-sampled video, use your own judgement.