Letters & frequently asked questions

No. Most computer graphics modes (and, consequently, most computer graphics files) assume that pixels are perfect squares. In that situation, an image's aspect ratio can be inferred directly from its dimensions in pixels (ex., an image with 300x300 pixels will be square, whereas an image with 400x300 pixels will have an aspect ratio of 4:3). But most video formats do not use square pixels; they use rectangular pixels. Normal (4:3) video uses pixels that are almost (but not quite) square, whereas widescreen (16:9) video uses pixels that are much wider than they are tall. So the difference between 4:3 and 16:9 video images is not the number of pixels, but rather the pixels' aspect ratio.

When a video image is displayed on a computer screen (where the individual pixels are square), the software should have the option to resize the image so that it keeps its original proportions (typically labelled "preserve aspect ratio", or something along those lines). Without this correction, the image will look distorted. This applies to both PAL and NTSC, although the resolutions (and pixel aspect ratios) are slightly different (NTSC uses 720x480).

Note that the above applies only to standard-definition (SD) video. High definition (HD) video can use several different resolutions, but is always displayed with a 16:9 aspect ratio (never 4:3).

You probably have a Canopus card. The Canopus DV codec reports the wrong size for 16:9 files, in a (very misguided) attempt to force programs that don't support 16:9 to display the image correctly. A consequence of this is that 3rd party programs that try to process the file end up resizing it twice, causing a loss of quality. The file itself was captured correctly, though, and is 720 pixels wide, just as any other 16:9 DV file. You just need to find a way to trick the Canopus codec into reporting its real size.

If you're using Premiere, this thread in the forum explains how to work around this problem.

This is a long one. These different resolutions are a result of two things: the pixel aspect ratio and the limitations of (old) analog standards.

As described above, the video modes used by computer monitors (normally) use square pixels, whereas the modes used by video monitors use rectangular pixels. This creates a problem when it's necessary to display a video image on a computer screen (with the correct proportions). One solution is to resize the clips during playback. Another is to resize them during capture. Some capture cards automatically resize the image to 768x576 (for PAL) or 640x480 (for NTSC) before saving it to the disk. This makes the image look correct on the computer screen but makes it impossible to match the (original) video samples directly to the captured file's pixels, which causes a degradation in image quality. This is relatively common in analog cards (where it's impossible to get a perfect match, anyway), but video transferred using a digital connection (such as DV) is usually not resized, and keeps its original pixel coordinates and values.

The other issue (between 704 and 720 pixels) arises from limitations of early analog video equipment. As far as one can talk about "pixels" in analog video, the width of a frame is always 720 per line. However, due to the difficulty in maintaining a stable video signal, analog standards included in those 720 pixels an "overscan" area. This area was not supposed to be shown, and was used basically to act as a "cushion" for errors in the signal timing. The visible area of the image (sometimes called "active area") was considered to be 704 (or 702) pixels wide, leaving approximately 8 pixels on each side as a safety margin. As video equipment improved, it became possible to use this area for capturing and transmitting actual image. Most digital formats, that don't need to worry directly about signal timing issues, actually treat this area as part of the active image.

Now, this creates a new problem. Since the original standard determined that the active image area was 704 pixels wide, and had an aspect ratio of 4:3, that meant that an image that was 720 pixels wide would actually have a slightly different aspect ratio (approximately 2% wider). Since most modern digital formats actually support 720 active pixels per line, it's necessary to determine if this produces a 4:3 image or if it produces an image that is 2% wider. If it does produce an image that's 2% wider (thus conforming to the old analog standard), then those borders will not be visible in a regular TV, which means they are pretty much wasted (and this is why some digital cameras leave the edges of the image black; no sense in wasting bits to encode video that is never supposed to be shown). But if the standard is changed so that a 720-pixel wide image is 4:3 (allowing all pixels to be displayed), this will introduce compatibility problems with older (analog) equipment. Different manufacturers seem to adopt different solutions. Purely digital systems (including nearly all software and a large percentage of semi-professional hardware) tend to consider the 720-pixel wide images as being 4:3, while professional studio systems that mix digital and analog tend to consider that the real 4:3 area is just 704 pixels wide.

DVD supports both 704- and 720-pixel wide images, but both are tagged as having the same image aspect ratio. So, if your movie is 4:3, simply select 4:3 as the output aspect ratio, regardless of whether the source footage is 720 or 704. It will be up to the player to decide if it shows the whole image or just the 704-pixel wide area in the center.

Note that all the information above also applies to 16:9 modes; as described above, the actual number of pixels in 16:9 clips is the same as in 4:3, the only thing that changes is the shape of those pixels.

Just as they can talk about bits (binary digits) going through a cable (that transmits an analog electromagnetic wave). Bits (and pixels) are abstract concepts. Their physical representations are always approximate (at least until we move to quantum signals). When a computer transmits binary data over a wire, that data takes the shape of a high-frequency analog signal. In fact, even inside computer chips, "digital" data is represented using (analog) electric signals or charges.

Digital circuits are simply circuits that, instead of processing signals continuously, read the signal only at regular intervals (ex., once every millionth of a second), and decide what to do based on how similar that signal is to certain values. For example, if the signal is close to 0 volts, the chip does nothing. If the signal is close to 1.5 volts, the chip sends a signal to another chip. The signal itself does not jump from 0 to 1.5 volts instantaneously, though, and that's why everything must be in perfect sync. If the chip tried to read the signal at the wrong time, while it was still changing, the value could be ambiguous (ex., 0.75). So the interval between reads must be long enough to let the signal go from one value to the other. That's one of the reasons why it's so hard to make chips go faster (you get errors caused by the fact that the signal didn't change fast enough).

A similar thing happens with the "pixels" of analog video. The world "pixel" comes from "pic's el", or "picture's element". It's a concept, not a physical thing. Physical pixels (like the ones on a monitor's matrix or on printed media) are usually called "dots". The ability of a certain video format to resolve detail is directly linked to the frequency of the signal used to represent it. If you use a signal that can flip between 0% (ex., black) and 100% (ex., white) 50 times a second, then you can only really represent 50 pixels per second (in PAL, that would mean 2 pixels per frame - not exactly brilliant). If you try to "extract" more pixels from that video signal (by sampling it more often), then you get a series of intermediate gray pixels (as the signal rises from black to white). So, you're getting more "pixels" (the abstract thing), but not more detail (because the original signal simply can't change faster). The main professional analog video standards say that the video must be stored and transmitted with a bandwidth high enough to resolve 704 independent samples (pixels) per visible line (720 in total, including the edges). Digital formats (even if they are hard-coded to 720 pixels per line) use much higher bandwidths, because the signal must be accurate enough to distinguish several bits per pixel (some HD formats need to transmit over 2.4 gigabits per second).

So, although analog video doesn't have "delimited" pixels (where the coordinates and colour values are defined by precise numbers), it is possible to talk about the resolution of analog video formats in terms of pixels; it's simply the number of times that the signal can do a full amplitude variation per unit of time.

Televisions and video monitors typically crop 3% to 6% of the image on each edge. This ensures that things like sync signals, timecode, teletext and closed captioning (which are encoded at the top and bottom of the image) are not shown. The sides of the image are also cropped because they can reveal slight sync problems and some formats (and cameras) record them in black and white. So, if you need to add titles to your videos, make sure you leave a safety margin (ex., 40 pixels) from the edges. Some editing and post-production software has the option to display a "safe frame" that you can use as a rough guide to how much the average TV set will crop. Note that, in Adobe Premiere Pro, the safe frame has a pointless "shadow" effect; the shadow is on the right place; the frame itself is shifted to the top left)

Image aspect ratio (abbreviated as IAR), sometimes called simply aspect ratio (AR), refers to the ratio between the image's horizontal size and its vertical size (in physical units). For example, an image with a width of 30 cm and a height of 20 cm has an aspect ratio of 30:20, or 3:2 (or 1.5:1, or simply 1.5). If, instead, the image was 20 cm wide and 30 cm tall, it would have an aspect ratio of 2:3 (or 0.67). Pixel aspect ratio (abbreviated as PAR) refers to the width-to-height ratio of the individual pixels that form a bitmap (a digital image).

If an image is made up of square pixels (that is, pixels with a PAR of 1:1, or simply 1.0), then you can calculate its IAR directly from the image resolution (that is, the number of columns and rows of pixels in the file). An image with 1600x1200 pixels would therefore have an IAR of 4:3, while an image with 720x576 pixels would have an IAR of 5:4. However, if the pixels are not square (as happens with several video formats), the PAR must be known in order to display the image with the correct IAR. For example, an image with 1600x1200 pixels and a PAR of 2:1 (that is, formed by pixels whose width is twice their height) would have an IAR of 8:3. The same image, with a PAR of 3:4 would have an IAR of 1:1 (in other words, it would be square). Alternatively, the image file can omit the PAR but explicitly mention the IAR, which still allows the software to display the image correctly. In fact, as long as you have three of these four values (horizontal resolution, vertical resolution, PAR and IAR) you can calculate the missing one. Here are the formulas to calculate each variable based on the other three (X and Y are, respectively the horizontal and vertical resolution, in pixels):

PAR = Y / X x IAR
IAR = X / Y x PAR
X = Y / PAR x IAR
Y = X / IAR x PAR

If the file doesn't mention either the IAR or the PAR, some software will assume that the PAR is 1.0 (square pixels), which might be wrong and require manual correction. Virtually all current editing, compositing, animation and image editing applications let you set the PAR (and / or IAR) of the images you are working with, will often be able to guess the correct values for files with no AR information, and will handle any necessary conversions to make sure they appear correctly on your screen. In addition to letting you type in a value, most will also give you a list of common aspect ratios (such as those used by SD and HD video formats) to choose from, so you will rarely need to calculate the values manually.

Image aspect ratio is sometimes also called "display aspect ratio" (or DAR), but this can be confused with the aspect ratio of the actual display (i.e., the width-to-height ratio of the entire screen used to display the image), so it's only used when distinguishing between the aspect ratio of the "stored" image (known as storage aspect ratio, or SAR) and the aspect ratio of the displayed image. For all practical purposes, when talking about images (not monitors) DAR is the same as IAR, and SAR is simply X / Y .

To calculate the actual physical size of the image you would also need to know the physical resolution value, generally expressed in PPI (pixels per inch). This is rarely relevant for video, though, since screen sizes vary so much.

In most cases, video is interlaced. This means that the odd and even lines are supposed to be displayed alternately (each of these sets of lines is called a "field"). Television sets and video monitors are also interlaced, so they display the interlaced footage correctly. Computer monitors, on the other hand, are not interlaced, so they show all the lines at the same time. If an object has moved slightly between the two fields, its edges will appear jagged.

Some MPEG-2 software players have an option to "deinterlace" the image (usually by blending both fields into a single frame), which will make it look much better on computer screens. Programs without this feature will make the image look jagged. This is usually not an issue with commercial DVDs because most of those are made from film, which is not interlaced to begin with (some NTSC film DVDs are interlaced, though, and may also exhibit this problem).

When previewing an interlaced DVD or MPEG-2 file on your PC, you should always use a player that is capable of performing deinterlacing (also, see next question).

The most likely cause is an incorrect field order (interlacing) setting. Interlaced video works by displaying the odd and even fields alternately, but they are actually stored together, as a frame. This means that the player needs to know if it should show the odd lines first and then the even lines, or vice versa. Displaying them in the wrong order will cause noticeable flickering whenever the fields are significantly different (ex., during fast subject or camera movement).

Most software players deinterlace the image by blending both fields together, so regardless of the order, the image will never appear to flicker on the PC screen (because both fields are effectively shown at the same time). So the best way to determine if the field order is correct is to play the video back on an interlaced monitor (ex., a TV set).

If the field order is incorrect, you should reverse the field order setting in your MPEG compressor. As a general rule, you should use "lower field first" for DV and "upper field first" for analog video. If you are capturing analog video through a DV bridge, or DV video with an analog card, it's anyone's guess which setting you should use; you'll have to test it.

Note that this setting only affects a flag (on / off value) in the resulting file, it doesn't actually change the video. This flag is then used by the DVD players to decide the playback field order. The actual field order of the video was determined when the video was created or captured.

If the still was taken from a scene where the people, objects or camera were moving, then there is probably a difference between the fields (see above). As a result, when the image is repeated and displayed on an interlaced screen, it flips back and forth between the two positions, causing the flickering. This may not be noticeable on the PC screen (which is why you should always check your DVDs on a TV or video monitor).

To solve this problem, you must either take a still from a part of your video where there is no motion, or deinterlace the frame used for the still. Deinterlacing causes a loss of vertical resolution, though, so you should avoid deinterlacing areas that don't need it. The best course of action is to export the frame to an uncompressed still image file (ex., Targa or BMP format), load that file into an image editing program (such as Adobe Photoshop, Paint Shop Pro, etc.), select the areas that were flickering (they should be easy to identify, due to the jagged edges) and apply a deinterlace filter only to those areas. That way, the areas that did not flicker will preserve all the original detail. Then save the image, import it back into your video editing program, and extend its duration to the desired length.

When a DVD player is set to "bob", it will perform deinterlacing (usually by blending the fields, but some players use more advanced algorithms). When it's set to "weave" it will show two fields simultaneously.

If the source is interlaced video, you should always set your player to "bob", or the image will look jagged whenever there is fast motion. If the source is not interlaced (ex., film or progressive-scan video), deinterlacing will cause a loss of quality, so you should set the player to "weave". Most players also have an "auto" mode that will try to decide the best setting but doesn't always get it right

Because the manufacturers want to sell to ignorant people too. A digital medium's size is, naturally, defined in bits or bytes, not minutes. For media that uses a fixed bitrate (ex., DV tapes, audio CDs), there is a direct correspondence between the size (bits) and the duration (minutes), but for media that can use different bitrates (such as DVD), this doesn't make any sense.

The actual length of video that you'll be able to fit in a disc depends on the disc size and the bitrate used to encode the video. To determine the right bitrate to fit a certain amount of video in a disc, you can use a calculator such as the one found in the utilities section (in the menu on the left).

The problem here is that "GB" means different things to different people. Technically, the prefix "kilo" (k) means "multiplied by 1000", the prefix "mega" (M) means "multiplied by 1000000", the prefix "giga" (G) means "multiplied by 1000000000", and so on. In other words, one kilobyte (or kB) should be 1000 bytes, one megabyte (MB) should be 1000000 bytes, and so on. But, for practical reasons related to the fact that computers work with binary numbers, manufacturing and addressing a memory chip with 1024 bytes was no harder or more expensive than if the chip had only 1000 bytes. So, instead of having exactly 1000 bytes, "one kilobyte" chips had 1024 bytes. It was close enough and no one was going to complain if they got an extra 24 bytes, right?

Unfortunately, as memory and storage sizes grew, this approximation was not corrected. Worse; it was extrapolated to higher orders of magnitude. So, instead of defining one megabyte as 1000 x 1000 bytes, or even 1000 x 1024, most software decided it should be 1024 x 1024 (or 1048576) bytes (actually the 1024 x 1000 approximation was used for measuring the size of floppy disks).

This means that if you have a file that is 1048576 bytes long, your operating system reports its size as "1 MB". Unlike operating systems, DVD manufacturers (and almost everyone else) use the correct SI magnitude prefixes, so when a DVD is described as having "4.7 GB", that means it has (almost exactly) 4700000000 bytes. Unfortunately, your operating system divides this number by 1024 x 1024 x 1024, and reports it as having "4.377 GB" (but it does the same when measuring the size of files in your hard drive, so you can compare the two directly).

New prefixes were proposed by the IEC to describe the "binary magnitudes": kibi, mebi and gibi (instead of kilo, mega and giga), where the "bi" is for binary. These are abbreviated "ki" (or "Ki"), "Mi" and "Gi", respectively. Although some applications and some documentation already uses these prefixes, most mainstream software and operating systems continue to use the standard decimal prefixes to refer to the binary approximations.

So there you have it; your "4.7 GB" disc does have 4.7 GB. It just doesn't have 4.7 GiB, which is what your operating system is measuring.

If you really want to know, and are feeling brave (or having trouble falling asleep), read my explanation of the mysteries of the GOP structure here.

Although this is not directly related to DVD authoring or compression, a lot of people making DVDs use this software, so I've decided to answer this here (this information is - strangely - hard to find, although the problem is quite common).

This problem is caused by a bug in VirtualDub. When detecting the codecs installed in the system, VirtualDub will stop if it encounters a reference to a codec with an empty filename. The solution is to delete that reference from the registry (this won't make any difference, since a codec without a filename won't work anyway).

Start the registry editor (go to the Start Menu, then select Run..., type REGEDIT and press OK). Navigate to the following key:

[ HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Drivers32 ]

You will see a list of installed drivers, including the video codecs (lines starting with "vidc."). The left column shows the four-character name of the codec, and the column on the right shows the corresponding filename. One (or more) of the codecs probably has an empty filename:

"vidc.cvid" = "iccvid.dll"
"vidc.iv32" = "Ir32_32.dll"
"vidc.mrle" = "msrle32.dll"
"vidc.msvc" = "msvidc32.dll"
"vidc.iv50" = "ir50_32.dll"
"VIDC.UYVY" = "msyuv.dll"
"VIDC.YUY2" = "msyuv.dll"
"VIDC.YVYU" = "msyuv.dll"
"VIDC.MP43" = "mpg4c32.dll"
"vidc.DIVX" = "divx.dll"
"vidc.XVID" = "xvid.dll"
"vidc.3ivx" = ""
"vidc.3iv2" = "3ivxVfWCodec.dll"
"VIDC.HFYU" = "huffyuv.dll"
"VIDC.wmv3" = "wmv9vcm.dll"
"VIDC.IV41" = "Ir41_32.ax"
"VIDC.VP61" = "vp6vfw.dll"

In this example, the line for "vidc.3ivx" is missing the file name. This is what causes VirtualDub to ignore some of the next codecs. Select the codec with the empty filename and delete it. Next time you start VirtualDub, you should have access to all the codecs.

Hopefully, this will be fixed in a future version of VirtualDub.