General: Aspect Ratio Clarification

[Krelmaneck]

I know these question may seem really dumb to ask, but as I go further into encoding videos, I need to make sure I have some simple basic AR understanding.


First dumb question for clarification: Is a Television's physical aspect ratio of 4:3 just the "television 525 line NTSC system" format? In other words, the televisions aspect ratio is NOT a FAR, DAR, SAR, or Par, correct? It is just the FOMAT, or as I like to call "525 line NTSC old school analog TV?" I just need clarification on that. I KNOW FOR SURE IT IS NOT A SAR since sar deals with the size of a pixel.



Next question: Now, if DGAVC says the display size as 853x480(DAR) and the Frame size(FAR?) is 640x480? Does that just mean that it naturally wants to play on a widescreen but is in a 4:3 frame; therefore, since 640x480 is a good NTSC frame rate, I can base my Lanzcos Resize on the FAR 640x480 assuming I add in some borders since DVD wants to be 720x 480? Or did I grasp the concept incorrectly or got it 1/2 correct meaning my case is not necessarily anamorphic and could be something else? So if a video had a DAR of 640x 480 and the FAR was 640x480 then that means it has no widescreen or is that impossible or less likely?

[edDV]

First dumb question for clarification: Is a Television's physical aspect ratio of 4:3 just the "television 525 line NTSC system" format?

I think you are over (uber) confused? Analog NTSC has a screen 4 arbitrary units wide and the same units 3 tall. 525 lines includes the unseen vertical interval. Active vertical area in analog NTSC is 486 lines which was later reduced to digital 480 lines in defference to our memory frugality back when memory was very expensive.

So, if you sample horizontal as square pixels vs. 480 lines at 4:3 aspect ratio you get 640 pixels x 480 lines. Nez pah?

All this fits nicely into memory, I won't burden you how.

Next concept is 16:9 wide screen. If you horizontally sample 480 lines at 16:9 aspect ratio, you get 853 plus a pinch hoizontal pixels. Try the math.

"PAL" equivalent is not as memory friendly 768x576 for 4:3 and 1024x576 for 16:9.

So, if all the world consisted of square pixels as you were taught by clueless professors in Comp Sci 101, FAR (frame aspect ratio) = DAR (display aspect ratio) = 640x480 or 853x480 and PAR (pixel aspect ratio) = SAR (storage aspect ratio) = 1.

So above we are in ~1979, think Apple ][ where most Comp Sci professors still live.

Absorb that while I write Chapter 2.

[edDV]

In a parallel universe broadcast engineers had already done the digital video thing as 3x fsc (frequency sub carrier) or ~ 560x480 in 1972 which wasn't quite good enough so they did 4x fsc or ~746x480 in 1976 which was hunky dory for NTSC but kinda sucked for PAL (too expensive).

So they all hit their HP45 calculators and found a magic sample rate of 13.5 Ms/s that could be horizontally common to NTSC 704x480/29.97 and PAL 704x576/25 and result in the same bit rate for both. For the first time dual standard NTSC/PAL digital equipment could be made bringing down the cost for all. All this became the CCIR-601 standard aka D1 in 1985 (later ITU-Rec-601).

704x480 and 704x576 both had non-square pixels hence the concept of PAR (pixel aspect ratio). While all this was going on, Japan's MITI and USA's MIT decided that HDTV should be 16:9 (long story) so the CCIR-601 standard was extended in ~1988 to allow both 4:3 and 16:9 PAR's for both NTSC and PAL (four different PAR's but all 704 pixels wide). For analog to digital sync issues (advanced topic) 8 extra pixels were added left and right to make a 720 wide production format with the same PAR's as 704. The idea was at the point of broadcast, 720 would be cropped back to 704 which it still is even for ATSC and DVB.

Later it was decided for all-digital DV and DVD formats, 720 would be used for release. Still correct PAR scaling would reference the center 704x480 or 704x576 frames and the extra pixels would represent additional width. A properly adjusted TV would lose these pixels to overscan.

[Krelmaneck]

First dumb question for clarification: Is a Television's physical aspect ratio of 4:3 just the "television 525 line NTSC system" format?

I think you are over (uber) confused? Analog NTSC has a screen 4 arbitrary units wide and the same units 3 tall. 525 lines includes the unseen vertical interval. Active vertical area in analog NTSC is 486 lines which was later reduced to digital 480 lines in defference to our memory frugality back when memory was very expensive.

So, if you sample horizontal as square pixels vs. 480 lines at 4:3 aspect ratio you get 640 pixels x 480 lines. Nez pah?

All this fits nicely into memory, I won't burden you how.

Next concept is 16:9 wide screen. If you horizontally sample 480 lines at 16:9 aspect ratio, you get 852 plus a pinch hoizontal pixels. Try the math.

"PAL" equivalent is not as memory friendly 768x576 for 4:3 and 1024x576 for 16:9.

So, if all the world consisted of square pixels as you were taught by clueless professors in Comp Sci 101, FAR (frame aspect ratio) = DAR (display aspect ratio) = 640x480 or 852x480 and PAR (pixel aspect ratio) = SAR (storage aspect ratio) = 1.

So above we are in ~1979, think Apple ][ where most Comp Sci professors still live.

Absorb that while I write Chapter 2.

I am still kind of a newbie or advanced newbie when it comes to encoding files. And I am a little slow to understand. I kind of knew that some lines on a tv system were not shown And I could see how the 480 lines could show up. But I am not understanding where 640 is coming from. Yes, I know that is just the arbitrarily the good choice to go with since it is NTSC. But how did you mathematically get 640? Or is something like: "you really do not need to know how it happens, you just need to know that is what it is?"

[edDV]

I am still kind of a newbie or advanced newbie when it comes to encoding files. And I am a little slow to understand. I kind of knew that some lines on a tv system were not shown And I could see how the 480 lines could show up. But I am not understanding where 640 is coming from. Yes, I know that is just the arbitrarily the good choice to go with since it is NTSC. But how did you mathematically get 640? Or is something like: "you really do not need to know how it happens, you just need to know that is what it is?"

Try this

480/3 * 4 = 640 or 640x480 square pixels.

Likewise

480/9 * 16 = 853.33 or 853x480 square pixels

853 is not digital friendly so often 852 is used, or 848 which is integer 8 friendly (106 x 8 = 848)

[Krelmaneck]

In a parallel universe broadcast engineers had already done the digital video thing as 3x fsc (frequency sub carrier) or ~ 560x480 in 1972 which wasn't quite good enough so they did 4x fsc or ~746x480 in 1976 which was hunky dory for NTSC but kinda sucked for PAL (too expensive).

So they all hit their HP45 calculators and found a magic sample rate of 13.5 Ms/s that could be horizontally common to NTSC 704x480/29.97 and PAL 704x576/25 and result in the same bit rate for both. For the first time dual standard NTSC/PAL digital equipment could be made bringing down the cost for all. All this became the CCIR-601 standard aka D1 in 1985 (later ITU-Rec-601).

704x480 and 704x576 both had non-square pixels hence the concept of PAR (pixel aspect ratio). While all this was going on, Japan's MITA and USA's MIT decided that HDTV should be 16:9 (long story) so the CCIR-601 standard was extended in ~1988 to allow both 4:3 and 16:9 PAR's for both NTSC and PAL (four different PAR's but all 704 pixels wide). For analog to digital sync issues (advanced topic) 8 extra pixels were added left and right to make a 720 wide production format with the same PAR's as 704. The idea was at the point of broadcast, 720 would be cropped back to 704 which it still is even for ATSC and DVB.

Later it was decided for all-digital DV and DVD formats, 720 would be used for release. Still correct PAR scaling would reference the center 704x480 or 704x576 frames and the extra pixels would represent additional width. A properly adjusted TV would lose these pixels to overscan.

But as we know, 704 x480 or 720 x 480 is the standard for DVD but is a "no-no" for a 4:3 system because NTSC 4:3 systems like 1.3333 . So my original question was: If I have a source that has the frame at 640x480 and I want to encode for DVD that is 4:3, would I have to add borders (avisynth command) so that I can then be at the DVD spec sampling matrix and keep the 4:3 ?

[Alex_ander]

But as we know, 704 x480 or 720 x 480 is the standard for DVD but is a "no-no" for a 4:3 system because NTSC 4:3 systems like 1.3333 . So my original question was: If I have a source that has the frame at 640x480 and I want to encode for DVD that is 4:3, would I have to add borders (avisynth command) so that I can then be at the DVD spec sampling matrix and keep the 4:3 ?

704 x480 or 720 x 480 is not related to aspect ratio (you see x symbol, not ':' ), those numbers are used to just store image data. In DVD an additional parameter is used to set displayed AR, it's either 4:3, or 16:9. In both cases, if you have a video shot/displayed as 4:3 or 16:9, resize it to 704 x480 or 720 x 480 and set 4:3 or 16:9 in encoder and authoring application.

[manono]

But as we know, 704 x480 or 720 x 480 is the standard for DVD but is a "no-no" for a 4:3 system because NTSC 4:3 systems like 1.3333 . So my original question was: If I have a source that has the frame at 640x480 and I want to encode for DVD that is 4:3, would I have to add borders (avisynth command) so that I can then be at the DVD spec sampling matrix and keep the 4:3 ?

To echo Alex_ander, you both resize and you add borders when converting a 640x480 video to NTSC DVD for 4:3 encoding (assuming you want a 720 width). The script might go:

LanczosResize(704,480)
AddBorders(8,0,8,0)

And, of course, 704x480 is perfectly acceptable. If you were thinking of only adding borders to that 640x480 video to bring it up to 720x480, something like:

AddBorders(40,0,40,0)

then you had better start reading up on DARs.

[edDV]

In a parallel universe broadcast engineers had already done the digital video thing as 3x fsc (frequency sub carrier) or ~ 560x480 in 1972 which wasn't quite good enough so they did 4x fsc or ~746x480 in 1976 which was hunky dory for NTSC but kinda sucked for PAL (too expensive).

So they all hit their HP45 calculators and found a magic sample rate of 13.5 Ms/s that could be horizontally common to NTSC 704x480/29.97 and PAL 704x576/25 and result in the same bit rate for both. For the first time dual standard NTSC/PAL digital equipment could be made bringing down the cost for all. All this became the CCIR-601 standard aka D1 in 1985 (later ITU-Rec-601).

704x480 and 704x576 both had non-square pixels hence the concept of PAR (pixel aspect ratio). While all this was going on, Japan's MITI and USA's MIT decided that HDTV should be 16:9 (long story) so the CCIR-601 standard was extended in ~1988 to allow both 4:3 and 16:9 PAR's for both NTSC and PAL (four different PAR's but all 704 pixels wide). For analog to digital sync issues (advanced topic) 8 extra pixels were added left and right to make a 720 wide production format with the same PAR's as 704. The idea was at the point of broadcast, 720 would be cropped back to 704 which it still is even for ATSC and DVB.

Later it was decided for all-digital DV and DVD formats, 720 would be used for release. Still correct PAR scaling would reference the center 704x480 or 704x576 frames and the extra pixels would represent additional width. A properly adjusted TV would lose these pixels to overscan.

But as we know, 704 x480 or 720 x 480 is the standard for DVD but is a "no-no" for a 4:3 system because NTSC 4:3 systems like 1.3333 . So my original question was: If I have a source that has the frame at 640x480 and I want to encode for DVD that is 4:3, would I have to add borders (avisynth command) so that I can then be at the DVD spec sampling matrix and keep the 4:3 ?

Alex_ander and Manono gave the answer but I still sense you aren't getting the idea of non-square pixels. 640x480 (square pixel) is represented as 704x480 (PAR = 0.9090) as stored on a DVD. The 720x480 version would have 8 pad pixels added both sides to be completely in spec. Broadcasters care about this but many DVD authors incorrectly stretch 640x480 out to 720x480 (PAR = 0.8888) or maintain PAR and crop the top and bottom which is also incorrect.

The DVD disc identifies itself to the player as 4:3 (default). The player then horizontally rescales the center 704x480 to square pixel for analog 4:3 output. DVD player digital outputs are passed to the display over HDMI as 704x480 or 720x480, then the display will rescale the center 704x480 to show as 4:3 (with side pillars on a 16:9 display).

While most video displays are square pixel (e.g. 4:3 1024x768, wide 1366x768, wide 1920x1080), not all are. Many plasma displays have 16:9 screens with a 1024x768 native display resolution. At that resolution, each pixel has an aspect ratio of 4:3. In that case DVD 704x480 gets scaled to 768x768 resulting in a 4:3 picture with side pillars on the plasma screen. If the display is correctly designed, a 4:3 720x480 input will be cropped to 704x480 before being scaled to 768x768.

Upscaling DVD players will scale 4:3 704x480 to 960x720p square pixel with sidebars or 1440x1080i square pixel with sidebars for HDMI output. The HDTV will then rescale again to native display resolution. I'm ignoring overscan but you get the idea.

[Krelmaneck]

In a parallel universe broadcast engineers had already done the digital video thing as 3x fsc (frequency sub carrier) or ~ 560x480 in 1972 which wasn't quite good enough so they did 4x fsc or ~746x480 in 1976 which was hunky dory for NTSC but kinda sucked for PAL (too expensive).

So they all hit their HP45 calculators and found a magic sample rate of 13.5 Ms/s that could be horizontally common to NTSC 704x480/29.97 and PAL 704x576/25 and result in the same bit rate for both. For the first time dual standard NTSC/PAL digital equipment could be made bringing down the cost for all. All this became the CCIR-601 standard aka D1 in 1985 (later ITU-Rec-601).

704x480 and 704x576 both had non-square pixels hence the concept of PAR (pixel aspect ratio). While all this was going on, Japan's MITI and USA's MIT decided that HDTV should be 16:9 (long story) so the CCIR-601 standard was extended in ~1988 to allow both 4:3 and 16:9 PAR's for both NTSC and PAL (four different PAR's but all 704 pixels wide). For analog to digital sync issues (advanced topic) 8 extra pixels were added left and right to make a 720 wide production format with the same PAR's as 704. The idea was at the point of broadcast, 720 would be cropped back to 704 which it still is even for ATSC and DVB.

Later it was decided for all-digital DV and DVD formats, 720 would be used for release. Still correct PAR scaling would reference the center 704x480 or 704x576 frames and the extra pixels would represent additional width. A properly adjusted TV would lose these pixels to overscan.

But as we know, 704 x480 or 720 x 480 is the standard for DVD but is a "no-no" for a 4:3 system because NTSC 4:3 systems like 1.3333 . So my original question was: If I have a source that has the frame at 640x480 and I want to encode for DVD that is 4:3, would I have to add borders (avisynth command) so that I can then be at the DVD spec sampling matrix and keep the 4:3 ?

Alex_ander and Manono gave the answer but I still sense you aren't getting the idea of non-square pixels. 640x480 (square pixel) is represented as 704x480 (PAR = 0.9090) as stored on a DVD. The 720x480 version would have 8 pad pixels added both sides to be completely in spec. Broadcasters care about this but many DVD authors incorrectly stretch 640x480 out to 720x480 (PAR = 0.8888) or maintain PAR and crop the top and bottom which is also incorrect.

The DVD disc identifies itself to the player as 4:3 (default). The player then horizontally rescales the center 704x480 to square pixel for analog 4:3 output. DVD player digital outputs are passed to the display over HDMI as 704x480 or 720x480, then the display will rescale the center 704x480 to show as 4:3 (with side pillars on a 16:9 display).

While most video displays are square pixel (e.g. 4:3 1024x768, wide 1366x768, wide 1920x1080), not all are. Many plasma displays have 16:9 screens with a 1024x768 native display resolution. At that resolution, each pixel has an aspect ratio of 4:3. In that case DVD 704x480 gets scaled to 768x768 resulting in a 4:3 picture with side pillars on the plasma screen. If the display is correctly designed, a 4:3 720x480 input will be cropped to 704x480 before being scaled to 768x768.

Upscaling DVD players will scale 4:3 704x480 to 960x720p square pixel with sidebars or 1440x1080i square pixel with sidebars for HDMI output. The HDTV will then rescale again to native display resolution. I'm ignoring overscan but you get the idea.

I'm sorry, I should have used the word "sampling matrix" when I was talking about the height and width of the DVD. Since I thought the DVD picture had a AR, I was calling it an AR. But I should have not called it that. Or maybe the term sampling is better?

So the DVD does the autoscaling of 640 x 480 picture to the correct 704 x 480 sampling area if I enter in the correct parameters in my script as the other poster suggested? That makes sense. And when I was referring to DAR in my original post, I was just referring to actual tv set AR., my emerson NTSC 4:3 analog tv.


And so, if I have a another video that has an aspect ratio of 480 x 480, since it already has 480 going one way, I would just need to resample the 480 to 704 and then set the encoder(quenc) to the dar of 4:3, correct?

For clarification, so even if I had a 352x480 mp4 encoding through avisynth, would be just fine to just LancozResize it to (704 x480) ? But maybe where I was getting confused was with DJ rumpy's guide where he or she was downscaling a widescreen and resampling it to 640x480 kind of deal. I don't know.


Where I was confused was between display aspect ratio in an MPEG and the video SAR. Now, the physical height on a mpeg is that the display size that would show up as the size in Gspot? That is what messed things up and got things a little confused here.

[lordsmurf]

Japan's MITI and USA's MIT decided that HDTV should be 16:9 (long story)

Are you sure it wasn't a wide story?

(ducks and runs)

[Alex_ander]

Or maybe the term sampling is better?

'Sample/sampling' is definitely better, since it is the only term used in the basic ITU 601 standard describing analog-to-digital video conversion. You will not find there terms like PAR, SAR, sar, FAR, OAR or even 'pixel' if you run search over the document. Nor ITU's mpeg2 standard (H.262) uses those words (it only uses unabbreviated 'sample aspect ratio' to explain how a device could set image proportions in case those are additionally defined with optional parameters for image sides). When establishing the standards, no one kept in mind 'pixels' and their form. The vertical numbers naturally came from the number of analog lines (for compatibility with analog displays without vertical resizing) and sample frequency came from bandwidth of video broadcasting signal; it was chosen of suitable value (13.5 MHz) for both PAL and NTSC scanning types. As a result, you get numbers like 704x480 which represent 4:3 (or 16:9) (displayed) AR which means that everything in that area must be stretched to one of those standard proportions. Numbers like 640x480 are often found in types of video file in which proportions are derived from those numbers only (that's when you hear 'square pixel'). So when you have a 640x480 avi file and know it has correct proportions when it fills the 4:3 screen, in DVD form it must be stored as 704x480 samples (resized in script before encoding). It is the task of a player to make 704x480 fill the 4:3 (or 16:9) screen, by restoration of standard analog or digital signal fed to displaying device.

And so, if I have a another video that has an aspect ratio of 480 x 480, since it already has 480 going one way, I would just need to resample the 480 to 704 and then set the encoder(quenc) to the dar of 4:3, correct?

Yes (if for DVD).

For clarification, so even if I had a 352x480 mp4 encoding through avisynth, would be just fine to just LancozResize it to (704 x480) ? But maybe where I was getting confused was with DJ rumpy's guide where he or she was downscaling a widescreen and resampling it to 640x480 kind of deal. I don't know.

If 352x480 are displayed with correct proportions as 4:3, then you could use 352 x480 for DVD, it is also supported by DVD standards in combination with 4:3 flag.

Where I was confused was between display aspect ratio in an MPEG and the video SAR. Now, the physical height on a mpeg is that the display size that would show up as the size in Gspot? That is what messed things up and got things a little confused here.

GSpot show both real numbers like 704x480 and 4:3 + it also directly calculates 'SAR' for those who feel unsafe without seeng that number (or can't calculate it him(her)self from existing numbers). The less you keep in mind PAR, SAR etc. imaginary things, the clearer you understand how it all works.

[edDV]

It is confusing and to make it more confusing programs like GSpot and Mediainfo report with inconsistent but useful terms.

I'm sorry, I should have used the word "sampling matrix" when I was talking about the height and width of the DVD. Since I thought the DVD picture had a AR, I was calling it an AR. But I should have not called it that. Or maybe the term sampling is better?
So the DVD does the autoscaling of 640 x 480 picture to the correct 704 x 480 sampling area if I enter in the correct parameters in my script as the other poster suggested? That makes sense. And when I was referring to DAR in my original post, I was just referring to actual tv set AR., my emerson NTSC 4:3 analog tv.

How to explain? Maybe if we start with the DVD disc resolutions and confine to NTSC resolutions for simplicity.

From "What is DVD?" https://www.videohelp.com/dvd the following resolutions are allowed for "NTSC" DVD

720 x 480 pixels MPEG2, 4:3 PAR = 0.9090 or 16:9 PAR =1.2121
704 x 480 pixels MPEG2, 4:3 PAR = 0.9090 or 16:9 PAR =1.2121*

Note that these resolutions can be 4:3 or 16:9. This is determined during MPeg2 encoding. The default case is 4:3. If the file is encoded 16:9, a wide flag bit is set to tell the DVD player to assume 16:9.

So, in the 4:3 case, the DVD player horizontally scales 704 x 0.9090 = 640, or 640x480 for square pixels.
If flagged as 16:9, the DVD player horizontally scales 704 x 1.2121 = 853.33 or 853x480 for square pixels.
In the 720 case, the player either crops to 704, or adds the 16 extra pixels as additional picture width (extending into blanking)

The concept of pixel aspect ratio is implemented with only horizontal scaling (stretching). That way the interlace line structure is not disturbed.

352 x 480 pixels MPEG2 (Called Half-D1, same as the CVD Standard) PAR= 2 x 0.9090 = 1.8182

Note that there is no 16:9 version of Half D1. The player horizontally scales 352 x 1.8182 = 640 or 640x480 for square pixels

352 x 240 pixels MPEG2
352 x 240 pixels MPEG1 (Same as the VCD Standard)

These are single field versions of 352 x 480. To get to 640x480, the 1.8182 PAR is used horizontally, and the second field is added vertically.

And so, if I have a another video that has an aspect ratio of 480 x 480, since it already has 480 going one way, I would just need to resample the 480 to 704 and then set the encoder(quenc) to the dar of 4:3, correct?

480 x 480i is a good example. This is what DirecTV originally used for standard def satellite TV. Most cable companies used 524x480i.

Even though 480 x 480i from DirecTV was encoded MPeg2, it was not a compliant resolution for DVD. It needed to be re-encoded to 704x480i (Full D1) or 352x480i (Half D1) to be placed on a DVD. Some people encoded these incorrectly to 720x480. The only consequence was the picture was stretched 2% wide when played on a DVD player. Most digital TV sets would crop off the extended pixels with side pillars.

For clarification, so even if I had a 352x480 mp4 encoding through avisynth, would be just fine to just LancozResize it to (704 x480) ? But maybe where I was getting confused was with DJ rumpy's guide where he or she was downscaling a widescreen and resampling it to 640x480 kind of deal. I don't know.

Under strict DVD definitions, 352x480 would represent 4:3 aspect ratio and wouldn't need resizing. Amamorphic wide is not allowed at that size, however letterbox inside 352x480 would not violate any rules. The DVD player would process letterbox as 4:3.

Since the DVD player would resize 352x480 to 640x480 for D/A output, there is no point to upscale 352x480 to 704x480. If you did, it would just get scaled again by the player back to 640x480.

Your mp4 example brings up another issue. To be DVD compliant, the video codec would need to be MPeg2 so a recode would be necessary but not a resolution change. If the mp4 file was progressive at 23.976 fps, it would need to be MPeg2 encoded with pulldown for DVD. Any other frame rate would need to be converted to 29.97 fps interlace.

Individual players may play formats other than strict DVD MPeg2 (e.g. divx, xvid or even h.264) but these would be player specific.

Where I was confused was between display aspect ratio in an MPEG and the video SAR. Now, the physical height on a mpeg is that the display size that would show up as the size in Gspot? That is what messed things up and got things a little confused here.

G-Spot and Mediainfo report these with inconsistent terminology. I need to review them.

NTSC DVD is limited to analog output at 4:3 aspect 480 lines or 16:9 (horizontally squeezed) 480 lines. Player setup menus determine whether anamorphic wide is output as letterbox in a 4:3 frame (4:3 TV setting) or as full height horizontally squeezed (16:9 TV setting). Normal output frame rate is 29.97 interlace. When set for progressive output, DVD players will deinterlace 29.97i to 59.94p. If a telecine pattern is detected, an inverse telecine is done to a 3:2:3:2 frame repeat sequence at 59.94 fps.

Digital output through HDMI is passed as 720x480 or 704x480, interlace or progressive, with or without anamorphic wide flags. When upscale is done, 1280x720p gets a progressive conversion to 59.94 (deinterlace or inverse telecine) while 1920x1080i is passed at 29.97 fps. Some players will output 1080p as 59.94 fps. I haven't seen one yet capable of 1080p at 23.976 fps (common for Blu-Ray players).



* This is in conflict with Baldrick's "What is DVD?" and I'm not sure which is correct for DVD. Digital broadcasting supports anamorphic wide screen at 704x480 but DVD may only support 720x480. Vegas and DVD Architect will allow an anamorphic 704x480 project and will encode without error notice.


Edit: fixed the 0.0909 typo to 0.9090

[Alex_ander]

...there is no point to upscale 352x480 to 704x480. If you did, it would just get scaled again by the player back to 640x480.

Of course, no point to upscale from 352, but... What do you mean by 'scaling back to 640x480' in DVD player? If that expresses AR, it's OK, but if you mean any player always does it to 704 literally, that would be a waste of storage memory and picture sharpness loss. There's no need to resample 704 to 640 for playback, it is quite enough for a DVD player to output 720 samples at the standard 13.5 sample frequency to further restore analog signal in its original sharpness. Those 711 (in case of 720x480) will lie back into active line interval. 704x480 of all those will exactly correspond to 4:3 area (5 analog lines are anyway lost). So if any digital output is intentionally done for resampling to 640, it's evident degrade compared to analog output.

In the 720 case, the player either crops to 704, or adds the 16 extra pixels as additional picture width...

Doesn't a DVD player comply with mpeg2 standards like ITU's H.262? The paper says that by default (no other area like 711x483 is explicitely defined in optional extention) all the stored samples must be displayed as 4:3 or 16:9. GSpot has a field to display that extension (sequence_display_extension), but you'll find it used not too often with VOBs from DVDs.
And it's a good question about 704 and 16:9. I've noticed that DVDRemake in case of 704/16:9 always writes 720x480 to that field, while in case 704/4:3 it writes 704x480 (but that might be simple coincidence, bug etc.).

[lordsmurf]

352x480 16x9 is not illegal, but it's not specified as legal either.
The bigger issue with it is that it simply looks like crap stretched out, so it's not suggested.

I don't know that I follow the 640x480 either, as the (for example) 720x480 is simply non-square pixels. I guess you could say that this non-square image is overlaid on a square pixel canvas that measures 640x480. That makes more sense.

[edDV]

...there is no point to upscale 352x480 to 704x480. If you did, it would just get scaled again by the player back to 640x480.

Of course, no point to upscale from 352, but... What do you mean by 'scaling back to 640x480' in DVD player? If that expresses AR, it's OK, but if you mean any player always does it to 704 literally, that would be a waste of storage memory and picture sharpness loss. There's no need to resample 704 to 640 for playback, it is quite enough for a DVD player to output 720 samples at the standard 13.5 sample frequency to further restore analog signal in its original sharpness. Those 711 (in case of 720x480) will lie back into active line interval. 704x480 of all those will exactly correspond to 4:3 area (5 analog lines are anyway lost). So if any digital output is intentionally done for resampling to 640, it's evident degrade compared to analog output.

That was an abstraction. A typical DVD player (non-upscaling) will pass the digital video "as is" over digital connections (HDMI, DVI-D, etc.) to the TV where the TV will perform the rescale.

For analog outputs, the DVD player does horizontal aspect corrections in the D/A process. NTSC or PAL analog video have a fixed active picture line width. For 4:3 TV mode, 704/720/352 pixel widths are D/A clocked to fill the analog line width. A second setting for a 4:3 TV set is letterbox or pan/scan for wide flagged source.

For 4:3 source, this results in a 4:3 aspect ratio analog frame (the analog equivalent of 640x480 square pixel). If this was done by an SD CRT digital TV from the HDMI input, 704/720/352 would actually be resampled into a 640x480 frame buffer before D/A to the screen. These TV sets can also rescale 1920x1080i or 1280x720p to 640x480 before D/A.

Example: http://www.mysears.com/RCA-27-in-Diagonal-Class-CRT-SDTV-with-ATSC-NTSC-QAM-Tuner-reviews
Digital

SDTV's are rapidly disappearing, replaced by 1366x720p LCD models.

For DVD player 16:9 TV mode, I need to hook up an analog TV to remember all the modes.

[edDV]

OK, now for 16:9 TV setting for analog out.

On my oldest Pioneer DVD player, 4:3 DVD source first plays full width (H stretched). The wide button on the SD analog TV seems to add the side bars and correct to 4:3 aspect ratio.

Anamorphic 16:9 (1.77 to 1 ) source shows full height and full 16:9 width.*

Anamorphic 2:35 to 1 source has mild letterbox. In this case letterbox is encoded into the VOB.


* on a 4:3 TV this appears full height and H squeezed.

[edDV]

In the 720 case, the player either crops to 704, or adds the 16 extra pixels as additional picture width...

Doesn't a DVD player comply with mpeg2 standards like ITU's H.262? The paper says that by default (no other area like 711x483 is explicitely defined in optional extention) all the stored samples must be displayed as 4:3 or 16:9.

GSpot has a field to display that extension (sequence_display_extension), but you'll find it used not too often with VOBs from DVDs.

And it's a good question about 704 and 16:9. I've noticed that DVDRemake in case of 704/16:9 always writes 720x480 to that field, while in case 704/4:3 it writes 704x480 (but that might be simple coincidence, bug etc.).

Overscan masks most of these issues on an actual display so it is hard to see the difference. The most obvious 704 vs 720 issue is with SD analog TV captures. ATSC and DVB broadcast 704 wide but most capture devices capture 720 extending into into blanking. I like this since it gives a 0 IRE reference from blanking. Downside is 8 pixel black stripes left and right.

Here is an example of the 8 side pixels. Note the H shift right. That happens during A/D capture due to sync issues. The error can build up with repeated A/D D/A. If that frame was 704x480, several columns of pixels would have been shaved off the right side. That was the reason for 720.

Maybe this wasn't the best example but it illustrates the point.

[Krelmaneck]

Thanks peoples for all the info. I am going to read over it later.


But to see if I have a small understanding, let me tell you what I learned. If I have any questions, i will post later.


It is better to use the words sampling, or even better, horizontal scaling. Screw the words far, par, sar, and dar. But I should remember the term PAR simply to know what flag target in the MPEG I want to set for. And Just for the sake of things try to grasp the concept of PAR= 0.0909 for ntsc 4:3. I do not know if I can remember an exact number. But that is the the size of the pixel in a 4:3 flag for an "ntsc system." And lastly, pixel aspect ratio is really for horizontal stretching.


last question for now: how does 704 x 0.0909= 640?. I am getting 63.9936. so the decimal needs to go over another place to the left. But 704 x 0.909= 640 rounded. so wouldn't the par be .909, or is the par still 0.0909 and you just move over the decimal point to the right?


i am not going to write any more questions or grasp the concept until tomorrow. That is all for now. I do not want to drive you guys crazy.

[edDV]

last question for now: how does 704 x 0.0909= 640?. I am getting 63.9936. so the decimal needs to go over another place to the left. But 704 x 0.909= 640 rounded. so wouldn't the par be .909, or is the par still 0.0909 and you just move over the decimal point to the right?

Sorry for my typo oops. Just below I had it right. I'll correct it now.

Best thing to take away from this is the SD frame is like a rubber sheet that can be stretched horizontally but remains fixed vertically.

[Krelmaneck]

edDV: sorry one more question, let's say you have a rare case where you need to vertically sample for dvd,. Let's use the video size of 576 x 240. I know this is a rare case, and a bit impratical, but AVi's could have any size they want.

Maybe there would not need to really be a vertical stretch for this one either because 240 may be ok. But can you show me an example of where I would need to vertically stretch something and the math to go with it?

[edDV]

edDV: sorry one more question, let's say you have a rare case where you need to vertically sample for dvd,. Let's use the video size of 576 x 240. I know this is a rare case, and a bit impratical, but AVi's could have any size they want.

Maybe there would not need to really be a vertical stretch for this one either because 240 may be ok. But can you show me an example of where I would need to vertically stretch something and the math to go with it?

To be DVD compatible, 576 would need to be lowered to 352 before a DVD authoring program would accept it. Frame rate would need to be 29.97. The player would replicate vertical pixels to interlace.

Alternate would be an H stretch to 352, 704 or 720 and an external conversion to 480i.

In the general case, any vertical resize would need a progressive conversion first (lossy), then a re-interlace at 480i. To get more sophisitcated, interlace (e.g. 1080i) can be spit into fields, then resized, then re-interlaced to 480i.

[manono]

Let's use the video size of 576 x 240. I know this is a rare case, and a bit impratical, but AVi's could have any size they want.

Maybe there would not need to really be a vertical stretch for this one either because 240 may be ok. But can you show me an example of where I would need to vertically stretch something and the math to go with it?

You can make life easier for yourself by letting FitCD do the work for you:

But better might be:

Lanczosresize(720,360)
AddBorders(0,60,0,60)

[Krelmaneck]

Let's use the video size of 576 x 240. I know this is a rare case, and a bit impratical, but AVi's could have any size they want.

Maybe there would not need to really be a vertical stretch for this one either because 240 may be ok. But can you show me an example of where I would need to vertically stretch something and the math to go with it?

You can make life easier for yourself by letting FitCD do the work for you:

But better might be:

Lanczosresize(720,360)
AddBorders(0,60,0,60)

True, but sometimes it helps that if I can actually know the theory of what calculations to make. I can take my time. But I guess FITcd would be GOOD to double check my work, once I learn the theory.

[Alex_ander]

Lanczosresize(720,360)
AddBorders(0,60,0,60)

True, but sometimes it helps that if I can actually know the theory of what calculations to make. I can take my time. But I guess FITcd would be GOOD to double check my work, once I learn the theory.

The theory behind conversions between AR's is quite simple. Let's assume that in your example 576 x 240 represent a film, shot with 2.21:1 AR (it is actually 2.4 from given numbers, but that's just for example) and you want to letterbox it in 16:9 anamorphic encoding. You know that 704x480 represent a 16:9 DVD image. Since 2.21:1 is 'wider' than 16:9, the width 704 will not change and you only want to find out the height of new image in # of samples. From global relationship between the two AR's 16:9/2.21:1=0.804 you get the wanted coefficient. For NTSC the new height will be 480x0.804=386 (576x0.804=~464 for PAL). Round it to a multiple of 16 (if possible, otherwise to a multiple of 8 or 4). Then you get 704x384 and complement it to 704x480 (or 720x480) by addition of borders, then encode with 16:9 setting. As you can see, no need in 'PAR's.
LanczosResize(704,384)
AddBorders(0,48,0,48)

[Krelmaneck]

edDV: I am kind of reading your explanation bit by bit to understand everything, and I have a question for you regarding PAR


In your example of 352x480 scaling to 640 x 480(the square pixels) I get PAR= 1.8181 You conclude par=1.8182

What I did was:

(640/480) / (352/480) = 1.333333333/0.733333333 = 1.8181 PAR


The earlier explanation of 704x480 scaling to 640 x 480(square pixels) to get Par= .9090 made sense and we BOTH agree on the the same answer:


(640/480) / (704/480) = 1.333333333/1.466666667 = .9090 Therefore PAR = .9090 And we both agree


But why isn't it working above ?

[Alex_ander]

704x480 and 352x480 displayed as 4:3 naturally have different PAR's. In geometrical interpretation of pixel idea a 4:3 image will be composed of vertically placed bricks (PAR<1) in first case and of horizontally lying bricks in second case (PAR>1). In case of other resolutions and other AR's the PARs are different. A good reason to give up the idea of remembering a table of numbers and using them for calculations. I gave an example showing you don't need them. However when you find PARs mentioned in an interface of some clever-looking program, you might need to understand which option its author suggests for which number, then you can take real numbers and calculate PAR for your video as you've correctly done just above (only use 4:3 or 16:9 instead of 640/480, it's easier).

[manono]

But why isn't it working above ?

Because 1.818181818... is closer to 1.82 than it is to 1.81. Why are you quibbling over less than one ten thousandth anyway?

[Krelmaneck]

704x480 and 352x480 displayed as 4:3 naturally have different PAR's. In geometrical interpretation of pixel idea a 4:3 image will be composed of vertically placed bricks (PAR<1) in first case and of horizontally lying bricks in second case (PAR>1). In case of other resolutions and other AR's the PARs are different. A good reason to give up the idea of remembering a table of numbers and using them for calculations. I gave an example showing you don't need them. However when you find PARs mentioned in an interface of some clever-looking program, you might need to understand which option its author suggests for which number, then you can take real numbers and calculate PAR for your video as you've correctly done just above (only use 4:3 or 16:9 instead of 640/480, it's easier).

I am not really in a rush to learn things. I am not really going to remember any exact number. I am just here to understand the concept. And I have printed out ths whole thread and reading little by little. And I kind of like doing math. Yeah, I barely passed intermediate algebra with a D, but that does not mean i have to give up using arithmetic or algegra in video applications.



I have noticed a certain trend on these boards which is not encouraging: people tend to say "don't bother or just give it up." That is a negative thing. I post questions because I want to learn. And it kind of irritates me when people just say "give it up."

[Krelmaneck]

But why isn't it working above ?

Because 1.818181818... is closer to 1.82 than it is to 1.81. Why are you quibbling over less than one ten thousandth anyway?

Because I want to understand horizontal scaling. Maybe I was thinking that not having an exact number might lead me to actually not understanding the whole concept. I thought things might have to be exact . But I thought PAR should be an exact number even though I will not even use PAR in a script, and just knowing about par is for for my 'knowledge database(my brain)." Maybe I thought rounding a number was an incorrect thing to do. I do not know. That is why it is a general newbie discussion. And advanced newbie discussion that has no board for itself like the doom one. Therefore, it cannot be a fussing over an exact number. It is an intriguing question for me to understand the concept. Therefore I ask you, is rounding is ok? Because if rounding is fine, then I can I round the PAR of .9090 to .9091? That is an honnest question of mine. I am not joking.