lost in aspect ratios

[QQ]

Greetings,

sorry to bother you with what most likely is just a dumb question, but I seem to have a problem understanding how PAR/DAR works.

I have captured a tv show at resolution of 720x576. DVD2AVI shows that it has an aspect ratio of 4:3, and it most likely is right, because it takes up full screen. So, pixel aspect ratio must be 4/3/(720/576) = 1.067. But, when I select 720x576 res and PAL anamorphic (4:3) in GK, it shows that pixel aspect ratio is supposed to be 1.09?! And then it shows that final display aspect ratio is 1.3333 (just like it has to be), but with error of 2.6%. If I enter 1.067 as PAR manually, then error becomes 0%.

Question is, what exactly IS PAR of that capture, and why does my calculations differ from what GK suggests?

p.s. I tried reading, and read somewhere that 720x576 PAL isn't really an 4:3 image - is this because of that?

thank you!

[Wilbert]

I guess you are talking about a mpeg2 capture? Could you be more specific (capture card, chip)?

Btw, anamorphic means 16:9.

[QQ]

sorry, i meant non-anamorphic

yes, i captured video using leadtek winfast 2000xp tv card, captured to 720x576 PAL, mpeg2 compression. then i'm trying to convert it to xvid avi using Gordian Knot, and that's where I get lost. From my calculations i get one PAR, but GK suggests another..

[omion]

There are 8 pixels on either side of the frame that are used for "overscan", which means you aren't going to see them on a TV (usually). So the actual "display" size is 704x576. If you do your calculations with these numbers, it is exactly as GK says.

What I usually do (with NTSC DVDs, but it's the same thing) is crop 8 pixels off the left and right sides, then let GK do it's thing.

[QQ]

So GK just automatically assumes, that if resolution is 720x576, then 16 pixels are meant for overscan? or is it some other rule, how to decide that pixels are going to overscan? if so, then what other resolutions have this same effect?

and perhaps do you know a place where i could read more about these things? they are pretty interesting :)

[SeeMoreDigital]

Hi QQ

I wrote a quick explanation (http://SeeMoreDigital.net/03_Video_Only_Info/What_is_an_anamorphic_encode.html) about this very subject a few months ago.

Hopefully it will help you!


Cheers

[omion]

Originally posted by QQ
So GK just automatically assumes, that if resolution is 720x576, then 16 pixels are meant for overscan? or is it some other rule, how to decide that pixels are going to overscan? if so, then what other resolutions have this same effect?

and perhaps do you know a place where i could read more about these things? they are pretty interesting :)
There's a checkbox in the GK 'options' tab that says "Follow ITU ??? standard" (*) This controls the overscan settings. If you turn it off, you'll see that it will be exactly as you expected in your first post.
Don't leave it off, though. You won't notice the difference, but it's "more right" to trim off the edges than to bend the aspect ratio.

The "rules" for overscan are governed by the ITU standard mentioned in the settings tab. Not sure what else the standard says except that NTSC 720x480 is the same (16 pixels).

(*) Forgot the exact words. I actually uninstalled GK, as I do everything by hand now, but I remember having the same problem as you when I started.

[QQ]

allright, i'll definitely read that!

anyway, just to be quick now, what's the right way to overcome this - crop the 16 pixels, or enter 1.067 by hand?

[QQ]

actually, 704x576 still gives 0.3% error.. its as if it wouldnt be 8+8 pixels, but 8+10..

[trevlac]

Originally posted by QQ

sorry to bother you with what most likely is just a dumb question, but I seem to have a problem understanding how PAR/DAR works.

I have captured a tv show at resolution of 720x576. DVD2AVI shows that it has an aspect ratio of 4:3, and it most likely is right, because it takes up full screen. So, pixel aspect ratio must be 4/3/(720/576) = 1.067. But, when I select 720x576 res and PAL anamorphic (4:3) in GK, it shows that pixel aspect ratio is supposed to be 1.09?! And then it shows that final display aspect ratio is 1.3333 (just like it has to be), but with error of 2.6%. If I enter 1.067 as PAR manually, then error becomes 0%.

Question is, what exactly IS PAR of that capture, and why does my calculations differ from what GK suggests?

p.s. I tried reading, and read somewhere that 720x576 PAL isn't really an 4:3 image - is this because of that?



Clear your mind. :) I will try to make this brief. Forget about 16:9, we are only going to cover 4:3. Thats DAR. No need to say more on DAR.

PAR - Imagine a 4:3 picture on a piece of paper. Put rows and cols of dots on it. These are pixels. They measure the color at that spot. Erase the dots. Put more dots, this time closer together. Same picture. Different dots. As long as you put dots out to the edges, you are measuring the same picture. If you sometimes don't go to the edges, you are leaving out a bit. PAR is the spacing between the dots. The frame size in pixels (ie 720x576) does not tell you the PAR. This is because some sizes go to the edge and some do not. Some even go over the edge. You can make reasonable assumptions based upon standards, but then you are guessing.

Sounds like GK assumes you have a 702x576 pic inside of a 720x576 matrix of samples. This makes sense because a PAL standard picture is 702x576. BTW: 4/3 / 702/576 = 1.09

I have never seen GK ... but I'd guess the error% has to do with the fact that when it resizes there is a bit of an error due to rounding (you can only have whole pixels). If you enter 1.067, i'd guess it isnot going to resize. So 0% error.

If you really want a 'perfect' AR -- the rub is that your card/driver combo probably only samples a portion of the picture with more dots than are standard. The numbers, using the standard space between pixels as a measure (aka dvd pixels or 13.MHz) are:

702x576 - Original 4:3 picture
696x576 - The area of the picture that was sampled

This 696x576 area was actually sampled with more pixels than is standard ... so you got 720x576 pixels. I'd guess you'd want to tell GK that your PAR is 4/3 / 696/576 = 1.1

Or you could not worry about it and go with what it says. 6 pixels is not very many. :)


PS: This info is all in the doom9 capture guide. Said by other people in other ways. There are even some picture of dots grids in a writeup on par. :)

[QQ]

ok, i'm prolly too stupid, but i'm still not quite sure how it really is :)

why is it that 16 pixels are used for overscan, but calculations are only right when using 18 pixels (702x576)?

also, am i right about this:

if i select resolution of 720x576 (which is 1.25:1), and PAR of PAL 4:3 non-anamorphic, the crop 18 pixels, and resize to 384x288 (which is 1.33) will the result be identical to the one i get when i chose res of 720x576, PAR of 1.067 and disable cropping? In both scenarios the resulting error %age is 0, but i dont think the result itself will be the same..

then again, now that i've read some more information, i think i understand it.

if following standarts, the 720x576 PAL 4:3 capture has 702 active pixels in one scanline (704 is something.. well, i have no idea what it is, but it's still being mentioned - http://www.uwasa.fi/~f76998/video/conversion/#4.7). So now I need to somehow figure out if PAR of my capture is 1.067, or is it following standarts, and only calcing the active pixels, in which case PAR would be 1.091 or 1.094 (again, depending on the amount of active pixels).

Is there any program which can detect what PAR is stored inside mpeg file?

[QQ]

then again, to think - if the captured 720x576 video is perfectly 4:3, then PAR HAS to be 1.0667 (720*1.06667 = 768), no matter how many pixels were actually sampled. Now, i just need to make sure that the video is perfectly 4:3..

[trevlac]

You could read the doom9 capture guide or we could hash it out here :)


_________________ A
______________ B
. . . . . . . . . C
........... D


The space between the pixels. The space between the pixels.


A = The entire analog signal. This contains more than the active picture.

B = The active picture in the analog signal. This is 702x576. Standard PAL pixels.

C = If you sample more than the active picture you can get 720x576 standard PAL pixels, which contains a 702x576 standard PAL pixel picture. When you tell GK you have 720x576 at standard PAR of 1.094, it thinks this is what you have. This is the basis of all the crop stuff. You do not have this.

D = This is what your card most likely captured. How do I know? I'm assuming you have a BT878 or CX based card and are using the standard driver. The doom9 cap guide has this info. So you captured less than the std 4:3 pic and your PAR is 1.1 You have a smaller frame with non-standard pixels. So you think you have C. But you do not.


1st - Stop saying 720x576 is 1.25:1 It's like saying 720 inches x 576 cm is 1.25:1 This is what PAR is about. An adjustment because the 720 scale is not the same as the 576 scale.

2nd - You are not stupid. You have been trained to see this the wrong way. Once you see the light ... it's not too bad. :) I have read the guide. I have seen the light :D

[QQ]

lol!

is there any way to know how does my card (yep, it's 878 based one) captures stuff? eg, figure out what actual PAR that capture has..

[QQ]

ok, i was too quick to post that!;p

i read it, did it, and figured out stuff:

my PAR for this capture is: 1.0571

but 720 * 1.0571 and 576 doesn't give 4:3 DAR! it only gives 1.321..

im still missing something;p

[QQ]

so if scaled pixels is 720, and PAR is 1.05704, that comes to capture window of 695.68. clear so far. but how out of all this, the final result becomes 4:3 - that's what I don't understand..

[trevlac]

In the spirt of admiting i am just a novice ... I think i was a bit wrong on the 1.1 PAR calc. Sounds like you got the right answer and are working out the details.

What is your final output ? PC or TV? DVD, SVCD, Divx ? If it's TV DVD, the answer is easy. Resize to 696 and add borders to 704. I don't want to say much more because I don't use par. You have one and want to use it. See the guide for the steps for TV viewing. I think the answer is resize to 762 and pad to 768x576 for PC.

[omion]

Originally posted by QQ
actually, 704x576 still gives 0.3% error.. its as if it wouldnt be 8+8 pixels, but 8+10..
Yeah, I think the actual number is something like 402.07 pixels wide. I remember seeing an extremely complicated page that explained everything (*). The fraction was determined by where the picture ended in the analog signal, but you probably aren't too interested in pixel-fractions, so that number does you no good.
[edit: oops. I think that number was only for NTSC images. It looks like PAL is actually exactly 702]

704 is a good number because: 1) it's greater than 702.07, and 2) it's divisible by 64 ("mod-64").

702 is only "mod-2" (divisible by 2) and there are still 0.035 pixels on either side that are cut off (horrors! :D )

The division factors can be important for encoding. I think a lot of filters won't work on mod-2, and many encoders are less efficient at < mod-16. Less than mod-2 (ie. 703) tends not to work at all.

(*) Found at http://www.uwasa.fi/~f76998/video/conversion/. Don't look unless you want to be completely and hopelessly confused.

Of course, none of this matters if your capture chip does something weird to the picture, as trevlac pointed out.

[QQ]

yeah, i figured that all out already..

what i still don't understand is how 720x576 capture with PAR of 1.0571 turns out to have DAR of 4:3..

[QQ]

or can it perhaps be that the capture isn't exactly 4:3? but why would dvd2avi say so then..

[Wilbert]

or can it perhaps be that the capture isn't exactly 4:3?
The point is that indeed not the whole 4:3 image is captured.

Like you concluded correctly, knowing only the DAR (which is still 4:3 here, because it is intended for 4:3 display) is not enough to know how to resize your video correctly.

[QQ]

well yes, capture window isn't 4:3.. it's 1:1.3231. So does that mean that my capture doesn't actually fit whole screen, eg it really isn't 4:3?

I have a very important game to convert now, Lithuania vs USA olympics;p I dont wanna make a mistake, but i'm still lost, and can't seem to figure out correct way to proceed.

*IF* it indeed wasn't 4:3, then it would be pretty clear. But why would dvd2avi say it's 4:3 then? =/

[QQ]

or, if you're suggesting, that the whole image is 1:1.3333, but only 1:1.3213 of it is active (padded by black borders?), then that would kinda mean there are *two* PAR's - one showing active capture window, and one (720*1.05704 / 576 = 1.3213) and one showing the whole image (720*1.06666 / 576 = 1.3333). then which one should I use in GK? :(

sheesh, i'd have never thought this was so complicated..

[Wilbert]

So, your capture window is probably 51.56 µs (which equates 696 dvd pixels). You should really measure this yourself if you have time, see 10.3:

http://www.doom9.org/index.html?/capture/capture_window.html

You want to convert it to XviD. In 5.6 of

http://www.doom9.org/index.html?/capture/sizes_advanced.html

a bunch of examples are given. In your case:

-----
Say you want to make a DivX/XviD (PAL). Full PAL TV on a PC gives 52 µs * 14.7692 MHz = 768 pixels, ending with 768x576. Your "878" has a capture window of 51.56 µs. So, how many PC sized pixels fit in the capture window? 51.56 µs * 14.7692 MHz = 761.5 pixels.

So you have two options here (however, if you can't capture at arbitrary sizes you only have one option):

a) (...)

b) Capping at another resolution and resize to the correct pixel size afterwards. If you want that, cap high, say 720x576.
However, your card caps only 51.56 µs, so you need less pixels to make up the difference with the 52 µs a PC needs for correct AR. How many?
(52 / 51.56) * 720 = 726 in total.

So, add 6 black pixels to your 720x576 cap. You now have 52 µs of info in 726 pixels. Resize the resulting 726x576 to 768x576 or a scaling of it (640x480 for example).
-----

Now, if you don't want to enter the resize (and addborders) parameters manually in GKnot, you have to specify the source PAR: see 16.3 of

http://www.doom9.org/index.html?/capture/par.html

In your case

IAR = (4 / 3) * (51.56 µs / 52 µs) = 1.3221

Capture size is 720x576, this implies a PAR of

1.3221 * 576 / 720 = 1.0577

-----

About this DAR stuff. Knowing the DAR is not enough to know how to resize/play your video (you need DAR and PAR). DAR can be 4:3 (your monitor is 4:3), while PAR is something else (think about XviD where PAR = 1.0).


I hope this is clear a bit :)

[QQ]

Hmm, I actually used the calculator and BTTool, and yeah, I got:

capture window: 51.532
capture window: 695.68
capture window iar: 1.3213
par for this capture: 1.0571

i think you cleared up a bit about 52 vs my capture window, and that it needs more pixels. but im still not sure about the PAR thing.

so if my PAR for that capture is 1.0571, does that mean that my actual capture (720x576 one) isn't really 1.333, but instead 1.3213? if it is actually so, then if i enter that PAR into GKnot, and then resize to 384x288 (which is just a scale of 768x576), then I will get a bit of aspect error, since input is 1.3213 and output is 1.3333. Is this correct, and if so, then is the 0.3% aspect error acceptable, or is there something i should do about it?

I'm having all this confusion, cause all the apps i try (flaskmpeg for example), say that my capture is 1.3333 DAR, and NOT 1.3213 (which 720*1.0571 would give..)

sorry for being so sloppy at understanding this.. this is pretty complex, but somewhat very interesting subject :) now if only i could get myself to the bt8x8 tweaking stuff *grin*

[Wilbert]

so if my PAR for that capture is 1.0571, does that mean that my actual capture (720x576 one) isn't really 1.333
The DAR of your actual capture is still 4:3. Unless you take a hammer and squeeze your monitor a bit :)

This 1.3213 number is not the DAR (in the cap guide we call it the IAR).


then if i enter that PAR into GKnot, and then resize to 384x288 (which is just a scale of 768x576), then I will get a bit of aspect error, since input is 1.3213 and output is 1.3333. Is this correct, and if so, then is the 0.3% aspect error acceptable, or is there something i should do about it?
The difference is small, and hardly noticable. If you want to do something about it, you should enter 726x576 in "Input Resolution" -> other. Don't forget to manually change your avs script in that case (for adding those 6 pixel black borders).

[QQ]

ok, then how does it become 1.3333 if we have 720 pixels each 1.05704 wide? i only come to 761 instead of 768 there.. i feel like im missing something terribly obvious here *lol*

[trevlac]

Originally posted by trevlac

_________________ A
______________ B
. . . . . . . . . C
........... D



This is one of those subjects that is actually not as complex as it seems. We so much get muddled down in the math. If you take a step back ... maybe my picture will help .

A - Analog line
B - Active Picture. If you cap this, it will be 4:3. On a PC 4:3 is 768x576.

D - You captured this. So, you did not cap the entire 4:3 pic. 761 (or 762)x576. So you have to add borders for 768x576.


2 things fooled you. You did not cap the full width and your pixels are not a standard size.


**** On another note. This may add more confusion so read at your own risk. Once you size to 762x576 your image AR is 4:3. The frame is not 4:3. The frame and the image are different things. The display device is also a different thing. Your image at ~762x576 is 4:3 because you captured only part of the broadcast frame. A 768x576 frame is 4:3 on a PC. A 702x576 frame is 4:3 on a PAL TV.

[QQ]

well if only it would have black borders! but the capture doesn't have any borders, as if all 720 pixels were active. and if they are, then how come all the apps (and Wilbert;p) say it is 768 wide, when in fact its only 761 scaled pixel wide.. (720*1.05704)..

[trevlac]

Originally posted by QQ
well if only it would have black borders! but the capture doesn't have any borders, as if all 720 pixels were active. and if they are, then how come all the apps (and Wilbert;p) say it is 768 wide, when in fact its only 761 scaled pixel wide.. (720*1.05704)..

So we agree that the 720 are skinny and they only cover an portion of the active picture, namely 761(2) PC pixels? Hence no overscan (aka borders).

The apps don't know what's going on because your card caps a non-standard width. They assume standards. Wilbert does not think you have 768. He may think you need 768 for PC 4:3 ... but I'm sure he thinks you have less.

It might be easier if you did Arachnotron's test. It's in the appendix of the doom9 capture guide. 'How to determine the capture width of your card'. (Or something like that...) Seeing is beliving.

BTW: This is a bit of a strange thing. In the end ... you may not be able to tell the difference ... but it is sorta cool to know what is going on.

[QQ]

Well I did that test (I think) - i used specific tools for my video card, and came up with all these values.

As far as I understand, Wilbert suggested that my capture indeed IS 4:3, but I fail to understand how can it be such, if it only has 761 pixels (according to my calculations anyway), and no black borders whatsoever :(

[Wilbert]

As far as I understand, Wilbert suggested that my capture indeed IS 4:3
No, you are mixing up several Aspect Ratios. I said your cap was 4:3 DAR, because your monitor is 4:3.

In one of my posts above I already said once
The point is that indeed not the whole 4:3 image is captured.

The way I see it if programs are talking about DAR (like dvd2avi and GKnot), they are confusing you and me. The point is that DAR is not an intrinsic property of your video. It should be set in your player. For example, if you want to play XviD PAR 1:1 (size 640x272). Setting DAR 4:3 in your player, it will just add black borders to get 640x480 (or a scaling of it). Setting DAR 16:9, it won't add black borders, nor is it stretched/squeezed. This DAR value might be stored in the header of your video file, but imo unnecessary.

I'm sure that a lot of people will not agree with this view though :)

If you see a DAR of 4:3 in dvd2avi, it can mean several things (depending who you ask):
1) the video has a IAR of 1.333 (this is what doom assumes for dvd rips in his guides)
2) the video has a IAR of 1.3657 (this ITU compliant box) (this is why you can set this ITU checkbox in GKnot and FitCD)
3) the video has a different IAR (like you have: 1.3213)

[QQ]

so in fact if i'd physically (theoretically;p) measure the drawn on screen image, it wouldnt have 1.3333, but instead 1.3231?

edit: typo

[QQ]

i'll just assume that is correct then..

[trevlac]

Originally posted by QQ
so in fact if i'd physically (theoretically;p) measure the drawn on screen image, it wouldnt have 1.3333, but instead 1.3231?


Depends what you mean. If you measure 761x576 on a PC it will be 1.3231.

The original picture on a TV was 1.3333. You did not capture the entire active picture ... so I'm not sure what you are measuring on a TV. (If that's what you mean)

[QQ]

im just asking, if i play the 720x576 capture on screen, will it take up 761x576, or will it be 761x576 + 7 pixels of padding..

[SeeMoreDigital]

Originally posted by QQ
im just asking, if i play the 720x576 capture on screen, will it take up 761x576, or will it be 761x576 + 7 pixels of padding.. For an Mpeg2 stream. This will depend on the DAR setting you have allocated in the bitsteam!

By-the-way, you can use an tool such as DVDPatcher (http://mitglied.lycos.de/dvdpatcher/) to change various elements of an Mpeg2 stream...


Cheers

[trevlac]

Originally posted by QQ
im just asking, if i play the 720x576 capture on screen, will it take up 761x576, or will it be 761x576 + 7 pixels of padding..

Oh ... sorry ...

If you play the 720x576 file ... the player will scale it to be slightly wider than it should be. This is because your 720 pixels do not cover the full active picture and the players think it does.

This of course assumes the players do the right thing and format for PAL TV or PC depending on how you are playing it. If my answer is confusing ... tell me the file size (720x480?) how you play it (DVD player / WindowMedia Player) what format (mpeg2, avi) ... and I will be specific.

Frankly ... this can be much ado about nothing. It is nice to know what is happening, but you may never be able to tell the difference.