Welcome to...
MGCJerry's Personal Page
A small repository of things I've collected over the years including some of my own stuff. 3D graphics, RPGs, science, code, electronics, tweaks, & references (Est 2012)

Navigation Home
 - Login
 - Register
Contact Me
Site Map
3D Graphics
null- Poser 6
null- Carrara 6
Reference Material
null- MX12 Lumamod
null- Video Conversion
null- ISO8859-1 Table
Fun Stuff
null- Kerbal Names
Public Ban List

We received a total of
page views since
December 27, 2015

Video Conversion

4. Frequently Argued Questions

4.1 Isn't 720 the real width of a 4:3 image? If not, then why are 720 pixels sampled instead of 711 or 702 (or whatever)?

720 pixels are sampled to allow for little deviation from the ideal timing values for blanking and active line lenght in analog signal. In practice, analog video signal - especially if coming from a wobbly home video tape recorder - can never be that precise in timing. It is useful to have a little headroom for digitizing all of the signal even if it is of a bit shoddy quality or otherwise non-standard.

720 pixels are also sampled to make it sure that the signal-to-be-digitized has had the time to slope back to blanking level at the both ends. (This is to avoid nasty overshooting or ringing effects, comparable to the clicks and pops you can hear at the start and end of an audio sample.)

Last but not least, 720 pixels are sampled because a common sampling rate (13.5 MHz) and amount of samples per line (720) makes it easier for the hardware manufactures to design multi-standard digital video equipment.

4.2 What does this mean, considering ITU-R BT.601 compliant equipment?

It means that the sampled horizontal range of the signal is a bit wider than the actual active image frame:

  • On 625/50 systems, only the centermost 702×576 pixels (of 720×576) belong to the actual 4:3 (or anamorphic 16:9) frame.
  • On 525/59.94 systems, only the centermost 710.85×486 pixels (of 720×486) belong to the actual 4:3 (or anamorphic 16:9) frame. (For practical video applications, 710.85 will have to be rounded up to 711 pixels.)

Yes, you understood correctly. 720x576 is not exactly 4:3, and neither is 720x480. The real 4:3 frame (as defined in the analog video standards) is a bit narrower than the horizontal range of signal that actually gets digitized.

Yes, it is the same for all generally available digitizing equipment; tv tuner cards, digital video cameras and such. It is true even for all-digital systems; otherwise they would not be compatible with ITU-R BT.601.

4.3 You must be kidding! I am pretty sure there is a mistake in your calculations. It says everywhere that 720×576 or 720×480 really is 4:3. Please stop propagating this misinformation!

I admit that the figures presented on this web site are not very well-known facts even amongst professional videographers, not to mention hobbyists. Aspect ratio is one of the most misunderstood "black magic" issue in digital video. That is precisely why I constructed the web site in the first place - to share the knowledge.

As for my calculations; feel free to prove them wrong. For starters, you might want to read the documents in the Related Links section.

4.4 I have been doing digital video projects for the last 50 years. I know my stuff! If you were correct, everything I have done to process my precious video has always been wrong, aspect-ratio wise!

That may very well be the sad truth. Fortunately, even if you had used wrong methods for scaling/resampling the image, the difference between the correct aspect ratio and a wrong aspect ratio is often small enough to go unnoticed unless you really start looking for it.

4.5 It still does not make any sense. For starters, all the 525/59.94 equipment I have only works in 720×480, not in 720×486 (and definitely not in 711×486)! How do you explain that?

525/59.94 video signal has 486 active (image-carrying) scanlines, but modern digital video equipment usually crops 6 of them off. Why? To get the height of the image down to 480 pixels, which is neatly divisible by 16. See for yourself:

  • 486 / 16 = 30.375 whereas
  • 480 / 16 = exactly 30.

Also note that 720 / 16 equals exactly to 45 so the width of the image is divisible by 16, as well!

4.5.1 Why is it important to have the height and width of the raster image divisible by 16?

Modern digital video applications such as DV, DVD and digital television (DVB, ATSC) often use MPEG-1 or MPEG-2 formats (or their derivatives) which are all based on 16×16 pixel macroblocks. Having the height and width of the image readily divisible by 16 makes it easier and more efficient for an MPEG encoder to compress video.

4.5.2 Doesn't this mean that when capturing in 720×480, I will lose six scanlines worth of valuable information that was once present in the original video signal?

Correct, but the information might not have been that valuable in the first place. Most 525/59.94 video work is already done solely in the digital domain and in the 720×480 format, so there is usually nothing to digitize on those scanlines anymore. Moreover, in the good old days (when all of those 486 scanlines were still in active use) most of the time the edges only carried flickering VCR head noise.

The video image is masked by the overscan edges of a CRT based television, so you would not normally see the "missing" scanlines, anyway.

4.5.3 You keep saying the "real" 4:3 resolution is at about 711×486 for 525/59.94 systems. OK, maybe there really are 9 extra pixels on the sides, but how do I cope with the fact my equipment only records 480 active scanlines, not 486?

Think it this way:

  • First, you have a frame of 720×480 pixels.
  • There is another frame of 710.85×486 pixels, overlaid and centered on top of the first one. This frame represents the "real" 4:3 resolution in 525/59.94 systems. (In any practical real-world video application we would have to use 711 pixels, but 710.85 is the ideal, mathematically exact number.)
  • The parts of the first frame that go over the side edges of the second frame are excess space that is outside the actual active image area. You can put picture there in digital systems, but there is no guarantee it will survive on any analog system, or display on any CRT monitor, even in underscan mode.
  • The parts of the second frame that go over the top and bottom edges of the first frame are the cropped 6 scanlines. As you only have 480 scanlines at your disposal, you cannot put picture there, but aspect ratio wise this imaginary area counts as a part of the "real" 4:3 image.

There is also another way of thinking it:

  • Disregard the notion that 525/59.94 systems have traditionally had 486 active scanlines. Instead, think that the new standard is now 480 scanlines.
  • Now, your ideal 4:3 frame is 480 * (4/3) / (4320/4739) = 702 + 2/27 pixels. In real world, a minimum of 703 pixels would need to be sampled to convey all the information in the active part of the scanline.
  • 703 is a nasty uneven number for computers. 704 is much better since it is divisible by 16 (again!)
  • Now you have something like a frame of 704×480 pixels, inside which lives an-approximately-702×480-frame, which in turn represents the real 4:3 image area. But wait! 704×480 is a familiar number, isn't it? See the connection? It is used in VCD high-res still images and in ATSC digital television! How convenient!

The latter way of thinking will also lead to cropping off the side edges of the image to get it inside a 4:3 rectangle (albeit a bit smaller than the "real" one), but then again, if you are restricted to using 704×480, that decision has already pretty much been made for you.

4.6 What about standards conversion? Doesn't PAL 720×576 exactly equal to NTSC 720×480?

As can be seen from the example in section 3.2.2, the answer is no. If you simply resample from 720×576 to 720×480, the analog active areas of the source and target formats will not match. Fortunately, there is a bit fool-proofness built-in to the relationship of these two frame sizes. What you will actually get from the process is an image in which the original analog active area (702×576 centermost pixels of 720×576) has become 702×480 in the target format's pixels. This, in turn, almost represents a 4:3 area, albeit a bit smaller than what would be needed for a perfect conversion.

The area that 702×480 covers is not the same as the actual analog active image frame (which would be 710.85×486, or, in practical terms, 711×486). It is more like a smaller 4:3 frame inside it.

In other words, the result is that the active 4:3 image frame in the source format has shrunk a bit in the conversion: it has lost six (target) scanlines in vertical direction and the same relative amount of width. However, for all practical purposes, it has still retained its original aspect ratio. The easiest way to see this is converting 702×480 (in 13.5 MHz 525-line ITU-R BT.601 format) to "true" square pixels: 639 + 4419/4739 square pixels by 480 scanlines is a close enough match to 640×480, which is 4:3. Wonderful coincidence, isn't it? :)

The same peculiar relationship applies to all 525/625 "sister resolutions" derived from 13.5 MHz:

  • 704×576 vs 704×480
  • 480×576 vs 480×480
  • 352×288 vs 352×240
  • etc.

This holds true on two conditions:

  1. The source sampling matrix width (in microseconds) must be exactly the same as the target's.
  2. You can only convert between a full-height 625-line resolution and a cropped-height 525-line resolution (i.e. use only those formats that represent exactly 480 scanlines worth of 525/60 data, instead of full 486.)

As direct resampling involves shrinkage (or when going in another direction, enlargement), I cannot really recommend this method for any real standards conversion work. It is more like a quick hack, suitable for use e.g. if the software does not allow proper resizing and cropping.

Note: Many people use direct resampling for all the wrong reasons: 1) They think that a 720×480 frame directly equals to a 720×576 frame. 2) They also think that both aforementioned frame sizes represent exactly the active 4:3 (or 16:9) picture area, edge to edge. As you already know from Section 2.1, both of these assumptions are wrong. The fact that direct resampling works at all is mostly a quirky coincidence

4.7 What do you mean by saying it is better to avoid 720×540?

The problem with this resolution is that while you think you are editing in a format that is both 1) 4:3 square pixels and 2) easily convertable to a standard video resolution (either 720×576 or 720×480) just by vertical resampling, you are not. See the table. There is no real world video format that would use full 720 pixel horizontal range as the width of the active 4:3 frame.

In order to get to a standard video format from this one, you need to take in account the actual form of the sampling matrices. The 4:3 area in 625-line formats is 702×576, not 720×576. In 525-line formats it is 711×486, not 720×480. Resizing a 720 pixels wide 4:3 format directly to 720×576 or 720×480 simply won't work. You will either have to resample in both directions (unlike you originally thought, you do not get to keep the image width neatly as 720 pixels at all times), or to crop some top and bottom lines off.

If you need to construct an intermediary square-pixel resolution that is a) exactly 720 pixels wide and b) covers exactly the same area as 720x576 or 720x480 (thus only having to resample in vertical direction for conversions), you will end up with two separate resolutions, one for each video standard:

  • The 720 pixels wide square-pixel equivalent of 720×576 (ITU-R BT.601 pixels for 625-line systems) is 720×526.5 pixels
  • The 720 pixels wide square-pixel equivalent of 720×480 (ITU-R BT.601 pixels for 525-line 4739/9systems) is 720×526 + 5/9 pixels

Fortunately, the numbers will nicely round up to 720×527 for both standards.

Note that the original interlaced field structure (if any) will go haywire as you mess around scaling in the vertical direction.

4.8 Why does your table list two slightly different definitions for square pixels?

"Square pixels", as digitized by a TV tuner or an M-JPEG card, are not exactly square. The "industry standard" sampling rates used in square-pixel video equipment actually give out pixels that are almost square, but not exactly. As you can see for yourself in the table, the difference is very small - for all practical purposes meaningless - but it is still useful to know that sampled "video" square-pixels differ a bit from ideal "computer" square pixels.

Converting "computer" square pixels to "video" square pixels is usually a futile effort. You will not see the difference, anyway, and probably only lose some quality in the interpolation process.

4.9 This is really scary and nasty stuff. I thought digital video was simple! Now my head hurts!

But that's just the way video is. Fortunately, the conversions are not really that complicated once you practice them a little.

4.10 I think you're just nit-picking. No-one will ever notice if I consider all "4:3" video formats just 4:3, without doing any complicated aspect ratio or "active image area" calculations.

Feel free to process your video just the way you like it. But there are still many people who would like to get as close to the ideal aspect ratio correctness as possible, instead of only using rough "ballpark figures" in their video work.

4.11 Help! My capture card does not seem to do it this way!

You may be correct. The professional video gear is very strict about conforming to the ITU-R BT.601 standard, and you can also generally trust DV camcorders and DVD players/recorders using the correct sampling rates and pixel clocks. However, the PC hardware market is different: cheap mass-marketed tv tuner cards and "tv out" cards ofter seem to have these design flaws and inaccuracies in their drivers: sometimes they are using the common, industry-standard frame formats (such as 720×480) with sampling rates that are just plain wrong or sufficiently off the mark to create problems.

It is usually not the hardware that is the culprit here – the chips on the card may be perfectly capable of producing images (or digitizing them) using exactly the correct sampling rates and pixel clocks, but the programmer who designed the driver that controls the hardware may have taken some special liberties and shortcuts, leading to inaccuracies. (Possibly the drivers for these problematic devices were designed by someone who has not studied the relevant video standards.)

Fortunately, you can check out your devices and, if necessary, calibrate your capture workflow by following these instructions.  (The only way you can find out these flaws for sure is comparing test images as detailed in the above link, or using a test card generator and an oscilloscope.)

5. Related Links

This page is maintained by Jukka Aho. Last updated: 15-Jan-2008

Page 4 of 4

First Previous ... 1 2 3 4

Created: Dec 27, 2015 by 1
Edited: Dec 27, 2015 by 1

[ Home | Account | MX12 Lumamod | Kerbal Names | Contact Me | Poser 6 | Carrara 6 | Video Conversion ]
[ Site Map | ISO8859-1 Table | Public Ban List ]

This page was generated in 0.00667 seconds using 14 queries.
This page consumed 1.89 MiB of memory during its creation.

MGCMS Programming by MGCJerry
Copyright © 1992-2006, 2008-2012, 2015-2017 Jerry Meszaros (MGCJerry)
Best Viewed with any modern standards compliant browser.