Pixel Aspect Ratio, how am I meant to deal with it?

[PRAGMA]

So. I'm using VapourSynth and loading MPEG-2 DVD videos with d2v_source.

Here's the thing. Let's say I have Family Guy S01E01 from the USA R1 NTSC DVD then:

SAR: 720x480
DAR: 4:3

That means the PAR of this would be 8/9 right?

# following check I got from somewhere when researching a long time ago
# the base idea is just test the width/height on the dar, then gcd it to a ratio rather than int
def calculate_par(pic_w: int, pic_h: int, display_w: int, display_h: int):
    """Calculate the PAR (pixel-aspect-ratio) from SAR (picture-aspect-ratio) against DAR (display-aspect-ratio)"""
    par_w = pic_h * display_w
    par_h = pic_w * display_h
    par_gcd = gcd(par_w, par_h)
    par_w = int(par_w / par_gcd)
    par_h = int(par_h / par_gcd)
    return [par_w, par_h]

calculate_par(720, 480, 4, 3)
>>> [8, 9]

Ok, let's say its 8:9, wouldn't that mean that every (8/9) [0.8888888889~] columns is a duplicate column? Since, 720 * (8/9) == 640 (the expected width)?

And ok, if I'm correct so far, why don't I notice any duplication in the columns width or height wise on any of my raw 720x480 frame exports? Am I missing something?

If I zoom in (nearest-neighbour scaling) on a 720x480 export (no resizing has taken place) it doesn't show any visible signs.



And, when is it supposed to be resized height wise? 720x576 (PAL) DAR of 4:3 content would be 768x576 if resized width, or 720x576 if resized by height, which should be used?


----


Take this frame for example:


- The left and right have freezing/stretching to fit the full 720 pixels width
- Every pixel returned by VapourSynth seems to be a 1:1 (square) pixel, though that can't be right? Right??
- Can this even return 640 pixels width without losing details, I assume not right? I know some NTSC content would use a 10:11 PAR to return 704x480, or SMPTE RP 187's 177:160 to return 708x480
- Is it programmatically possible to calculate the PAR used, or is it the case of looking at it and seeing?

[Cornucopia]

DVDs can only have a DAR of 4:3 (aka 1.3333333) or 16:9 (aka 1.77777777).
Now, you say your dvd has a DAR of 4:3, but IMDB says the original production of the master was in 16:9 HD, so it could be you have a 4:3 Pan&Scan copy. Sorry to hear.

The universal formula for aspect ratios is:

Horiz rez / Vertical rez * PAR = DAR

, where PAR = Pixel or Sample AR, and DAR = Display or Frame AR.

For NTSC Hrez=720, Vrez=480. Thus 720 / 480 * X = 1.333333 (or to be more exact, 4/3).
Put another way to solve for X, X = 480 / 720 * 4 / 3 = 8 / 9 or 0.88888888.

That part is correct.

What it doesn't mean is about column number or column width. BECAUSE, Those are point samples. These are merely plain quantities at a certain point along a sampling line.
What it means is that you can view these quantities in one of a few ways:
1. Viewing natively using a device and acompanying support system that honors the PAR and does a point-for-point exact match of the pixels. IOW, since the PAR is 8/9 and you could view this on a CRT that also shows those pixels with 8/9 widths, it is a match and doesn't require any further resizing, interpolation or adjustment. You would have a 4/3 DAR.
2. Viewing natively using a device that doesn't honor the AR. This would show an image that doesn't properly follow the AR and so appears "stretched" or "squeezed" (depending on the AR difference). For example, a 720 x 480 shown using native sizing on a (now normal) 1:1 PAR screen, would show 720 / 480 * 1 / 1 = 3/2 or 1.5 DAR.
3. Viewing resized, on a 1:1 screen, manipulating either the H dimension or the V dimension, or both. For example, "viewing in a window" on a computer will often adjust the horizontal but not the vertical dimension (for a number of valid reasons**). In this instance, the equivalent H resolution in this scenario would be 640 (leaving the 480 alone). How it interpolates to 640 would vary, but it could often be using bicubic, bspline, etc. Notice that much of those algorithms will interpolate EACH pixel along the sample line, so the idea of only modifying a few out of most pixels ("columns" as you stated) - being added/dropped - is interesting, but pretty unlikely. So the result looks like 640x480 on a 1:1 display device.
4. Viewing resized on a 1:1 screen in "full screen" mode, where likely both dimensions are adjusted but the ultimate DAR is remembered and honored and if the full screen isn't able to be fully and exactly utilized and rendered to, you will see letterboxing or pillarboxing.

A nearest neighbor zoom would likely ignore the AR, and so would show like scenario #2, and would have inaccurate AR. However, since you are zooming in, it often isn't easy to tell.

**: DVDs are interlaced. Interlaced footage may be resized but the discreet and non-coinciding nature of interlacing requires that much more complex operations be done when resizing vertically. So in general, it isn't a good idea.

Scott

[Cornucopia]

AVISynth, Vapoursynth, etc., do not work with ARs at all, so AFA they are concerned, all pixels are square. What's more true is that AR (PAR or DAR) really only comes into play when either capturing or displaying, and when encoding & decoding stored files & transmitted streams.

The fact that you are viewing the pixels means you are using one of those scenarios. Which one depends on your choice of device, algorithm, etc. If the visual AR appears correct, it is likely you are doing scenario #3.

Scott

[PRAGMA]

AVISynth, Vapoursynth, etc., do not work with ARs at all, so AFA they are concerned, all pixels are square. What's more true is that AR (PAR or DAR) really only comes into play when either capturing or displaying, and when encoding & decoding stored files & transmitted streams.

The fact that you are viewing the pixels means you are using one of those scenarios. Which one depends on your choice of device, algorithm, etc. If the visual AR appears correct, it is likely you are doing scenario #3.

Scott

Hello Scott, thanks for the answers. I want to ask you if I understand it correctly now.

1. the frames of an MPEG-2 video (no matter how they are stored or who stored it) will be 1:1 PAR (square pixels)
2. this means if for ex VapourSynth loads a DVD, it will be 720x480 (for NTSC) all of them would be square pixels
3. it's the actual hardware/monitor/crt that actually displays as non-square pixels
4. however, some DVD's may have a baked-in PAR, even though each pixel is itself 1:1 square in the file. For example if the PAR of the video content was 2:1 (rectangular, 2x the width same height of a square pixel) then what happens is every 2 pixels horizontally would actually be 1 pixel of the video content. but if it's something funky like 8:9 (aka 1.125:1) then that means 1 pixel will be most of the original video content pixel, and then .125 of the next square pixel of the MPEG file, finishes the first pixel of the original video content, and also does a bit of the next original video content pixel (so basically there's a small bit of horizontal, in this case, detail loss).
5. In the case of 2:1 you could nearest-neighbour it, because its divisible by 2. If it's not divisible by 2, you would need to use a resizing algorithm that checks every sample point per pixel like Spline64 or Bilinear, meaning no matter what, some kind of interpolation on the width (or height if you are resizing height instead) will occur.

I also still don't quite understand when I should resize the width or the height. You said because of interlacing which I totally understand, but I assumed you would think I would be doing this operation AFTER deinterlacing. I should note in my tests, the actual bits per frame and general display dimensions of the video were larger when I resized by height (even on PAL) compared to width, even though the actual data didn't add any extra resolution or data. The larger display window makes sense of course because larger height (e.g. 540 on NTSC, would be 720x540, which is obviously larger than 640x480). So I presume for NTSC, just always do width, but for PAL, I think it might be wise to do height so that it's like NTSC and instead of increasing the resolution pointlessly (adding more data), it instead "downscales" (technically I guess) reducing file size and pointless display resolution when it wouldn't help.

[PRAGMA]

I'm also not sure if this video file is 8:9 PAR. I've seen so far, 3 different PAR's for a 720x480. 8:9 (calculated by the SAR and DAR), 10:11 (Rec.601 recommended for NTSC 480i, according to Wikipedia, but doesn't mean it definitely uses it), and SMPTE RP 187's 177:160

[Cornucopia]

No, that's not what I was saying.

ALL bitmap-type video or photos, of any file or stream format, has:
1. Explicit horizontal resolution
2. Explicit vertical resolution
3. Either an explicit or an implicit (derived) PAR
4. Either an explicit or an implicit (derived) DAR

And if 3 is explicit, then 4 is implicit. Or vice-versa.

MPEG1 video syntax uses explicit PAR (with DAR being implicit/derived).
MPEG2 video syntax uses explicit DAR (with PAR being implicit/derived).

DVD is a subset of MPEG2 video, and so follows the same syntax. This subset makes 4:3 or 16:9 the only legit options. This means that 1:1 DAR is not allowed (nor is 2.21:1, etc). By formula solving, it can be derived that DVD video PAR will NEVER be 1:1 either.

As mentioned, Vapoursynth et al, has NO understanding of AR. Because it shouldn't need to. It only works with sample points. They are points, IOW without dimension. It is how it is interpreted and mapped upon display that will determine what its AR looks like. Since those apps DO NOT ENCODE, nor do they DISPLAY, it is not their job to decide how to interpret AR, it is the job of the encoders & display processors (usually based on AR flagging).

So when VS loads a DVD video, all of the pixels are considered just pixels without dimension. An NTSC dvd would have 720x480 pixels, and a PAL dvd would have 720x576 pixels. For you to VIEW (or encode) those pixels, your VS has to pass those pixels along to another app. THAT app is the app that applies whatever AR it is supposed to have.
It is one of the common things that trip up those new to VS, etc, is that it ignores the AR (whether DAR or PAR) and it is the job of the user to remember what it should be and supply it to the subsequent app(s) downstream.

It is the actual viewing app+video driver+display system which determines the screen size & resolution & AR expectation. The display itself, being HARDWARE, has a fixed AR to its displayed pixels (phosphor dots, etc). In general, CRTs are non-square (aka NOT 1:1), but that is actually more due to its analog scanning frequencies than it is due to phosphor placement. Digital displays such as plasma, LCD, OLED, LED, are in general 1:1 (aka square pixel) display devices.
So, at some point non-square AR files/streams are likely gonna have to be mapped to 1:1 displays, since those are now the vast majority of displays.

As it was mentioned above, there are NO dvds that have baked in PAR of any kind.

You mention about resizing of the dimensions, deinterlacing notwithstanding. But deinterlacing is NOT a lossless operation, and not without consequences. Yes, after Deint, you could choose to resize whichever dimensions you choose, I guess.

I could go on for a VERY LONG time (and I have) about vertical vs. horizontal resizing options. Suffice it to say, it is professional best practice to do these resizes on the horizontal (whether up or down) and not the vertical. Most of what I would say would have more appropriateness to analog-originated material than digital, and these days there are combinations of both analog and digital, so the recommendation is less strict.


8/9 = 0.8888888888888 (MPEG)
10/11 = 0.9090909090909 (ITU-601)
177/160 (which was using reverse dimensions, so should read 160/177) = 0.90395080 (SMPTE 187)
There is less than a 2% difference between any of these. So there is very little difference to fight over. I know what I would recommend - 8/9 for MPEG-specific stuff, or 10/11 for (704-based) ITU-601 analog-based stuff. That subsequent SMPTE document didn't have much influence.

Scott

[hello_hello]

So. I'm using VapourSynth and loading MPEG-2 DVD videos with d2v_source.

Here's the thing. Let's say I have Family Guy S01E01 from the USA R1 NTSC DVD then:

SAR: 720x480
DAR: 4:3

That means the PAR of this would be 8/9 right?

Every 4:3 NTSC DVD on the planet has a 10:11 PAR/SAR. Well.... the great majority of them do.
Use an mpeg4 SAR/PAR for 4:3 DVDs and you'll almost never go wrong. For 16:9, newer DVDs are mostly generic but look out for substantial black down the sides as a hint they're mpeg4. There's no way to know for certain, short of trying to find shots with round objects in the picture, taking screenshots and drawing circles over them to verify they're round.
How to set aspect properly?

Technically.... cropping and using the original PAR for encoding leaves you with maximum quality, second place would be cropping and only resizing the width for the correct DAR, while full resizing comes in third, but I prefer related encodes to be properly cropped and resized to the same resolution/aspect ratio, so I usually go with method three. More often than not there's other filtering involved such as noise removal, so a little resizing is easily the least of it. One TV here has a media player that doesn't understand anamorphic video, so I've resized to square pixel dimensions for years as part of the process.

VapourSynth can load lots of Avisynth stuff these days can't it? I ask because....
https://forum.videohelp.com/threads/393752-CropResize-Cropping-resizing-script
Play around and Info=true should give any info you need. If nothing else you can open scripts while specifying different input SARs, let CropResize resize to square pixel dimensions as a player would, and compare the video that way to decide which input SAR to use.

All you need is:

CropResize(InSAR=10.0/11.0, ResizeWO=true)

To do the same while cropping, you can specify zero for the output width and height.

CropResize(0,0, -8,4,10,-6, InDAR=4.0/3.0, ResizeWWO=true)

With appropriate filtering, animation will usually look at least a little better upscaled. It's about the only time I upscale although I don't get any more carried away than 720p.