Resize calculator PHP [Archive]

smok3

8th January 2008, 20:31

Running at
http://resizecalc.sourceforge.net

sourceforge summary page
https://sourceforge.net/projects/resizecalc/

important note
- before posting bugs, please use alternative calculation method (preferably manual) and do mention which one was it, mkay? :) (nothing will get fixed without that)

licence
- unlicensed

php source
http://resizecalc.sourceforge.net/source/?C=M;O=D

-------------------------------

windows exe (not mantained)
http://sourceforge.net/projects/osx264/files/resizeCalcWapache/resizeCalc11aExe.7z/download

some reading
http://forum.doom9.org/showthread.php?t=145197
http://forum.doom9.org/showthread.php?p=1100187#post1100187

done
- php get method, so you can 'bookmark' your calcs
- 'any' pixel aspect to 'any' other one
- the usual pad or crop to
- echo a simple crop/resize avisynth
- crop source suggestions to minimize dar error (monte-carlo)
- new PAR recalc to fix error made with modN rounding
- blowup warning (check both output x and y if they are bigger than input (with croping) and color that result values in red or something)
- echo aftercrop resolution in avisynth part (before resizing)
- echo N up/down modN resolutions for onclick recalculations
- check also if calculated resolution is mod32 - nope, just enter custom mod into mod field instead
- change html to show some numbers with the options for AR correction
- crop suggestion for the aftercrop resolution to be modN
- echo mplayer command line (for playback)
- mplayer compatible crop input (704:416:6:80 = width, height, leftcrop, topcrop)

todo
- echo mencoder command line (for encoding), example from man;
Encode DVD title #2, resizing to 512xHHH (keep aspect ratio):
mencoder dvd://2 −vf scale −zoom −xy 512 −o title2.avi −oac copy −ovc lavc −lavcopts vcodec=mpeg4
- styling (css) and display type (show: more|less <- to be added) should not be part of the url, since this is user/browser specific, make cookie based preferences for that)
- write a little doc about how the math is handled (and simplified), with examples and how this may affect some of the calcs ('PAL' to 'NTSC' conversions may be a good example)
- add target height or no. of pixels
- change the avisynth display as a 2nd option, to be mod(1) friendly as described here (should i?):
http://forum.doom9.org/showthread.php?s=&threadid=91630

LoRd_MuldeR

11th January 2008, 02:06

1st try:
http://somestuff.org/resizeCalc.php
bookmark example; PAL to SQUARE:
http://somestuff.org/resizeCalc.php?ssmw=720&ssmh=576&sar=1.094&CL=8&CR=8&CT=0&CB=0&dar=1&trw=576&doit=true

That looks very useful. Thanks!
But the interface could be designed a little bit more eye-friendly :p

Painkiller

11th January 2008, 10:50

Looks Good :thanks:

smok3

11th January 2008, 11:10

But the interface could be designed a little bit more eye-friendly
color-wise or position wise? (for default browser look try http://somestuff.org/resizeCalc.php?css=false)
(interface will be redesigned anyway (when the source is released, it will be simply the matter of changing some css tags), but i need to implement all the features first, the priority now is to check all the math, so it is of 'reference' quality)

LoRd_MuldeR

13th January 2008, 01:21

color-wise or position wise?
Color-wise. Gray text on black background isn't too nice ^^
The "No CSS" version is completely "unstyled", but a lot better to use.

About the layout:

Maybe you can re-think the idea to place the input form on the very left side.
For example you can put the form into a box and place that box in the center of the screen...

About the calculation:

It would also be nice to calculate the new PAR for cropping only, but no resize.

1. Enter original resolution and original PAR
2. Enter what has been cropped (top, bottom, left, right)
3. Get the new (corrected) PAR value

This is needed to keep anamorphic video anamorphic, but crop the black borders away.
Without resizing!

smok3

13th January 2008, 10:09

so you are saying that PAR changes with cropping? (i would say no), example:
http://somestuff.org/resizeCalc.php?ssmw=704&ssmh=576&sar=1.459&CL=16&CR=16&CT=16&CB=16&trw=672&dar=1.459&css=false&doit=true
(manualy calculated requsted width=width-32 (based on cropping) and same for height=height-32, dar error=0 :))
or different crop:
http://somestuff.org/resizeCalc.php?ssmw=704&ssmh=576&sar=1.459&CL=16&CR=16&CT=72&CB=72&trw=672&dar=1.459&css=false&doit=true

anyway PAR is PAR and it will change only with resizing.

LoRd_MuldeR

13th January 2008, 13:29

I think this isn't the case or I'm doing something wrong ;)

For example my input captured from analog PAL TV is:

[Video]
Resolution: 720 x 576
Aspect ratio: 1.3333
Format: 0x10000002
Bitrate: 15000 kbps
Frames per second: 25.000
Selected codec: mpeg12

Now I crop away borders (-16 on left/right side, -8 on top/bottom).
Then I encode without resizing it. And I encode with PAR of "16:15" (PAL 4:3).
So I'm using the same PAR as the original/input was.

But the result is this:
[Video]
Resolution: 688 x 560
Aspect ratio: 1.3105
Format: H264
Bitrate: 1332 kbps
Frames per second: 25.000
Selected codec: ffh264

Obviously the Aspect Ratio isn't correct, the PAR needs to be re-calculated!

According to "ARS Calculator" I get:
688 x 560 and 4:3 Display AR => 140:129 PAR (not 16:15)

Using a "custom" PAR of 140:129 I get:

[Video]
Resolution: 688 x 560
Aspect ratio: 1.3333
Format: H264
Bitrate: 1332 kbps
Frames per second: 25.000
Selected codec: ffh264

So it's fine again, though it requires a non-standard PAR value....

All encoding done with Avidemux/x264. Video info/details taken from MPlayer.

smok3

13th January 2008, 14:40

Thats ok if DAR is different, since DAR may change with cropping (but PAR is the same), so there is nothing to recalculate (i think you are doing it wrong, no need to fix the PAR).

edit: i think you should use 128/117 for PAL PAR and keep in mind that usually active area is only 704 pixels wide.

edit2: this would be the 'correct' calc for your example (just happens that DAR error=0, since we crop mod16):
http://somestuff.org/resizeCalc.php?ssmw=704&ssmh=576&sar=1.094&CL=16&CR=16&CT=0&CB=0&trw=672&dar=1.094&css=false&doit=true
or this
http://somestuff.org/resizeCalc.php?ssmw=720&ssmh=576&sar=1.094&CL=24&CR=24&CT=0&CB=0&trw=672&dar=1.094&css=false&doit=true
(you have to take those 8 pixels into consideration)

edit3: or if you are sure that full 720 pixels are active area
http://somestuff.org/resizeCalc.php?ssmw=720&ssmh=576&sar=1.094&CL=16&CR=16&CT=8&CB=8&trw=688&dar=1.094&css=false&doit=true

edit4: honestly i don't even understand what 'ARS Calculator' does (it will fix the PAR for resizing mod16 error?).

p.s. this calc may eventually get some sort of:
- add autocrop left-right to minimize DAR error
- add autocrop all to minimize DAR error
(since i have no clue what the formula should look like, it will be some sort of monte-carlo calculation, time to start checking the speed of the script also...)

LoRd_MuldeR

13th January 2008, 19:09

Well, the facts are:

* My original (PAL) video is 720x576, the Display Aspect Ratio is 4:3
* If I encode that with a PAR of 16:15 ("as input"), the result plays with proper 4:3 aspect.
* There are black bars I want to crop away. The cropped video is 688x560.
* If I encode that cropped video with the "old" value of 16:15, the resulting video doesn't play at 4:3 any more!
* The "corrected" PAR value from ARS Calculator apparently does exactly what I need.
* The 688x560 video encoded with a PAR of 140:129 plays at proper 4:3 aspect.

smok3

13th January 2008, 19:53

well, interesting, i'am confused now :)

LoRd_MuldeR

13th January 2008, 20:07

Hmm, I guess I was thinking in the wrong direction:
"Improper" cropping might destroy the aspect ratio of the video, right?
Then re-calculating the PAR with ARS Calc will "stretch" it back to the original aspect.
So I get a video that has the same Display AR as the original, but the AR of the video is (slightly) wrong.
Do you understand what I mean?

smok3

13th January 2008, 20:16

yes i understand, however what i think the ARS calc does is fix the wrong resizing, since only with cropping you can't change PAR... (but i'am guessing)

The 688x560 video encoded with a PAR of 140:129 plays at proper 4:3 aspect
how can you tell?

anyway i realized that target PAR will usually be changed with mod16 or mod32 targeted resolutions, so new PAR could be calculated here... (however that is not the case in your example).

LoRd_MuldeR

13th January 2008, 20:43

how can you tell?

Well, the player displays my original 720x576 video with a Display Aspect Ratio (DAR) of 4:3. It's Pixel Aspect Ratio (PAR) is 16:15.
The cropped 688x560 video is not displayed with a DAR of 4:3, if I encode it with a PAR of 16:15.
But I now think that is "correct", because cropping parts away changes the DAR (if not cropped for the same percentage in both dimensions).
Using the 140:129 PAR will cause the 688x560 video to be displayed with a DAR of 4:3 again, but I think it's actually "stretched" then.

smok3

13th January 2008, 21:03

But I now think that is "correct", because cropping parts away changes the DAR (if not cropped for the same percentage in both dimensions).
Using the 140:129 PAR will cause the 688x560 video to be displayed with a DAR of 4:3 again, but I think it's actually "stretched" then.
yes, thats right,

- there is new version which will calc also a new PAR value based on mod16 error - but i guess this is more confusing than useful?

- also ugly php source is up there (check 1st post)

smok3

19th January 2008, 20:26

.added 'pad or crop to'.

buzzqw

19th January 2008, 20:32

well done smok3

very usefull thanks!

BHH

smok3

20th January 2008, 13:51

buzzqw: tnx, hopefully someone (else than me) will find this usefull :)

.added 'custom target mod' - if undefined defaults to 16.

.added 'suggest crop height or width or width&height to minimize DAR error - that pretty much equals/supersedes autocrop-all and autocrop left-right' -monte carlo calculus - user will have to be aware of the color-space limitations with avisynth cropping, but that seems still better than mod2 limitation.

smok3

12th February 2008, 00:00

08
.added blowup warning
.some html changes
.removed all javascript
08b
.echo aftercrop resolution

krosswindz

13th March 2008, 16:44

Its really useful I use it quite often. It would be really nice if you can have an option to generate multiple resolution along with the associated errors.

Given the crop value generate multiple resolutions if the user doesnt request a width.

608x?
624x?
640x?
656x?
672x?
688x?

Something like this so that user might choose the resolution depending on this.

smok3

14th March 2008, 10:12

krosswindz: are you saying that one would choose encoding resolution based on DAR error? - i don't really understand the request (calculating dar error for lot of them would take time, since the implementation is monte-carlo).
(echo N up and N down will be implemented thought)

krosswindz

19th March 2008, 19:33

^ yeah one can choose the encoding resolution based on keeping the DAR error to a minimum.

how about having something like a default resolution (currently 640) and buttons to change the width, then the user can choose the one that he prefers.

smok3

20th March 2008, 10:53

08c
.added : 'on click recalc with new width' thingy, which is simply 'width + mod' or 'width - mod' (will work with js disabled as well, one will just have to travel for another click on submit)

krosswindz

20th March 2008, 22:35

^ awesome

krosswindz

23rd March 2008, 22:53

I have been reading up a bit on calculating the suitable resolution when trying to encode movies from DVD9. I was trying to figure out how once actually calculates the different aspect ratios.

There are different aspect ratios like

DAR (display aspect ratio)
PAR (pixel aspect ratio)

I read this http://www.doom9.org/capture/par.html to figure out the different PAR values.

I know that cropping doesnt affect PAR but resizing does affect PAR. The question I have is whats the relation between the change between source resolution and target resolution when one resizes.

Which aspect ratio error do you want to minimize when you resize?

How is DAR related to PAR etc. If someone could point me to some resources it would be much appreciated. I did some reading I am confused as some links they use things like 2.35 as DAR other places use it PAR.

smok3

23rd March 2008, 23:15

internaly calc uses PAR, but DAR error is used (only for presentation and for croping suggestions) for better compatibility with other calcs out there, this is basically a representation of source (cropped) resolution vs target mod-resolution (i think, irc).

Which aspect ratio error do you want to minimize when you resize?
you want to minimize target DAR error introduced by (usually mod16) rounding basically, but in some cases you would want all the pixels to go into resizing, in other you would use smaller mod, or maybe just use new PAR, etc, it is a case by case 'problem'.

example:
pal to square;
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.094&sar2=&ssmh=576&CT=0&CL=8&CR=8&CB=0&trw=576&dar=1&dar2=&mod=&padw=&padh=&css=&doit=true
i could fix the error by using custom PAR;
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.094&sar2=&ssmh=576&CT=0&CL=8&CR=8&CB=0&trw=576&dar=1&dar2=1.003&mod=&padw=&padh=&css=&doit=true
or maybe with some additional cropping, since my encoding method does not support custom PARs;
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.094&sar2=&ssmh=576&CT=0&CL=8&CR=10&CB=0&trw=576&dar=1&dar2=&mod=&padw=&padh=&css=&doit=true

PAR and DAR, basic formula is

DAR width
--- = ------
PAR height

Ranguvar

23rd March 2008, 23:52

Your calculator has a problem. Not sure exactly what, but as you can see, when one types in an input res of 1280x528 square pixels, and attempts to resize to NTSC wide, the calculator outputs resolutions like 688x352, 672x336, and 640x320. Which are, obviously, close to a 2:1 AR rather than the targeted 2.35:1.

The calculator reports the number of pixels in the modified resolution correctly, but thinks its erroneous output resolutions are ~2.35:1, with a very small error.

Example: http://somestuff.org/resizeCalc.php?ssmw=1280&sar=1&sar2=&ssmh=528&CT=0&CL=0&CR=0&CB=0&trw=640&dar=1.215&dar2=&mod=&padw=&padh=&css=&doit=true

Note how the calculator thinks "640x320" is 2.43:1...

smok3

24th March 2008, 00:10

Ranguvar: no, i don't see? 1*1280/528 = 2.42 no? (and 640*1.215/320 = 2.43)

please do some proper (manual maybe) calcs and then post a bug...

edit: since you didn't consider PAR, maybe start readin here
http://www.doom9.org/index.html?/capture/par.html

krosswindz

24th March 2008, 02:40

internaly calc uses PAR, but DAR error is used (only for presentation and for croping suggestions) for better compatibility with other calcs out there, this is basically a representation of source (cropped) resolution vs target mod-resolution (i think, irc).

you want to minimize target DAR error introduced by (usually mod16) rounding basically, but in some cases you would want all the pixels to go into resizing, in other you would use smaller mod, or maybe just use new PAR, etc, it is a case by case 'problem'.

example:
pal to square;
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.094&sar2=&ssmh=576&CT=0&CL=8&CR=8&CB=0&trw=576&dar=1&dar2=&mod=&padw=&padh=&css=&doit=true
i could fix the error by using custom PAR;
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.094&sar2=&ssmh=576&CT=0&CL=8&CR=8&CB=0&trw=576&dar=1&dar2=1.003&mod=&padw=&padh=&css=&doit=true
or maybe with some additional cropping, since my encoding method does not support custom PARs;
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.094&sar2=&ssmh=576&CT=0&CL=8&CR=10&CB=0&trw=576&dar=1&dar2=&mod=&padw=&padh=&css=&doit=true

PAR and DAR, basic formula is

DAR width
--- = ------
PAR height

Since the idea is to minimize the DAR error, how does one calculate the DAR from the source frame size. Would cropping affect the DAR? If so how would one calculate the actual DAR from the values.

smok3

24th March 2008, 10:21

source DAR is basically = sourcePAR * (width-widthCROP) / (height-heightCROP)

yes, cropping affects DAR.

Since the idea is to minimize the DAR error
the idea is different on a case by case basis... (or better on user by user basis), or with different words: this calc is just a tool, don't get any ideas from it :)

krosswindz

24th March 2008, 15:56

the idea is different on a case by case basis... (or better on user by user basis), or with different words: this calc is just a tool, don't get any ideas from it :)

when you are converting from source to target, assuming that PAR values cant be change, then the aim is to reduce the DAR maintaining the standards?

Like if we are converting say from NTSC Wide to PAL Wide, the PAR values are constant. If you want use minimal cropping then there would be a certain amount of error always associated. If you want to minimize this error then you would have to change the cropping right?

edit: For resizing (ignoring cropping)

source_DAR target_DAR
------------- = -------------
source_PAR target_PAR

smok3

24th March 2008, 18:10

yes, i guess that would be the case.

krosswindz

24th March 2008, 18:27

I wonder what the problem here is. If you read this article

http://forum.videohelp.com/topic174200.html

entering the crop values based on that gives a different DAR and resolutions too?

http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.215&sar2=&ssmh=480&CT=60&CL=0&CR=0&CB=60&trw=640&dar=1&dar2=&mod=16&padw=&padh=&css=&doit=true

edit: basically from the article the DAR is supposed to be 2.35 but using the resizecalc we get a DAR of 2.43 is there something I am missing?

smok3

24th March 2008, 19:36

if you think it is a bug, then suggest some numbers, so i can fix.
(p.s. i have compared the results with two different calcs, and they both spit out 640x256)

edit: example;
http://somestuff.org/example.png

quote from http://forum.videohelp.com/topic174200.html
if you have a theatrical movie that has an aspect ratio of 2.35:1 and you want to encode your AVI for playback on a PC, then you would simply resize it using a 2.35:1 aspect ratio
and one would know that by looking at what excatly?

krosswindz

24th March 2008, 19:57

if you think it is a bug, then suggest some numbers, so i can fix.
(p.s. i have compared the results with two different calcs, and they both spit out 640x256)

The output depends on the calculated DAR if I am not wrong. I tried another calculator with the crop values its spits out 640x256. But the question is what was the DVDs flagged DAR

I have a DVD9 with me, is it possible to find out what the flagged DAR would be. I guess once the image is cropped the calculated DAR should be somewhat close to flagged DAR.

edit: What is the video calculator used in the screen?

krosswindz

24th March 2008, 20:00

quote from http://forum.videohelp.com/topic174200.html

and one would know that by looking at what excatly?

I guess one way to figure out would be looking at the aspect ratio listed on IMDb. I am not sure if it lists the aspect ratio for every movie.

smok3

24th March 2008, 20:03

no, no, no, the DVD have no flaged DARs, there are basically only two common PARs, most of the commercial titles should be either using (i will use my calc terminology here)
a. ntsc wide PAR or
b. pal wide PAR

different DARs are then made by using padding with black borders.

p.s. the 'idea' to 'determine what DAR is used' is silly, as you allready know what PAR your DVD uses, so there is nothing to determine....

krosswindz

24th March 2008, 20:08

no, no, no, the DVD have no flaged DARs, there are basically only two common PARs, most of the commercial titles should be either using (i will use my calc terminology here)
a. ntsc wide or
b. pal wide

different DARs are then made by using padding with black borders.

The padding is done to convert them to one of the common PARs (NTSC wide/PAL wide). If you crop of the black borders then you should get the actual DAR of the source, I hope I am right about this. This DAR should be as close as possible to the theatrical DAR, if I am right.

smok3

24th March 2008, 20:14

SeeMoreDigital

24th March 2008, 20:16

If you crop of the black borders then you should get the actual DAR of the source, I hope I am right about this. This DAR should be as close as possible to the theatrical DAR, if I am right.True...

I prefer to refer to this as being the Movie Aspect Ratio (MAR). Others refer to it as being the Theatrical Aspect Ratio.

smok3

24th March 2008, 20:29

hmm, well, imho there is enough confusion allready about this 3 letter beasts, how about not inventing new ones?
(MAR actually stands for Modified aspect ratio)

krosswindz

24th March 2008, 20:29

yes, but one can't really know if the theatrical DAR is really what was transfered to DVD (there could be some cropping in the process, ect) when on the other hand PAR is always known to the end user.

Very true, during the transfer if they cropped the picture then you would be loosing the theatrical DAR. It would be nice if there was some way of determining the DAR that DVD was authored in. Would be really helpful when you re-encode.

smok3

24th March 2008, 20:35

uhmm, yes, you crop the blacks, use the correct PAR and there you have your correct source DAR (unless the production company f*** up in conversion somehow, but you can't really be sure about that, unless you know the movie really really well...)

---

anyway, lets go the other way, for example i have done some renderings in my favorite 3d package, this are 2048x866 frames (35mm Full Screen Super 4k cineon - preset) with PAR 1:1, and for some reason i would like to do wide PAL dvd out of the animation;
http://somestuff.org/resizeCalc.php?ssmw=2048&sar=1&sar2=&ssmh=866&CT=0&CL=0&CR=0&CB=4&trw=704&dar=1.459&dar2=&mod=&padw=720&padh=576&css=&doit=true
(i would crop some pixels in the bottom, so i get less error and there goes away my original DAR...)

krosswindz

24th March 2008, 20:55

Not only do you loose the original DAR, you also loose some part of the image. Wish things were so much easier with encoding. I think the only way one can really not have problems would be when creating the images based on what the final product would be.

SeeMoreDigital

24th March 2008, 20:55

hmm, well, imho there is enough confusion allready about this 3 letter beasts, how about not inventing new ones?
(MAR actually stands for Modified aspect ratio)As of December 2007!!!

I wonder who decided to place that new acronym on Wikipedia

smok3

24th March 2008, 21:03

oh, it wasn't me :)

I think the only way one can really not have problems would be when creating the images based on what the final product would be.

in this days it is quite usual that one must produce video for different aspect ratios/different media systems as well (well known example from tv world is 14:9, where you can shoot in 16:9 with 14:9 picture in mind or with 4:3 with 14:9 picture in mind..., cough), sometimes i do 4:3 version for TV and 16:9 version for web, ect.

(using loose conversation-purpose numbers here)

krosswindz

25th March 2008, 05:49

is the math for PAL <-> NTSC right. Because video frame height are different for both.

smok3

25th March 2008, 09:05

i think for D1 pal to D1 ntsc this should be simply good enough
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.094&sar2=&ssmh=576&CT=&CL=&CR=&CB=&trw=720&dar=0.911&dar2=&mod=&padw=&padh=&css=&doit=true (sampling matrix width in µs =53.33333 µs)
or maybe
http://somestuff.org/resizeCalc.php?ssmw=704&sar=1.094&sar2=&ssmh=576&CT=&CL=&CR=&CB=&trw=704&dar=0.911&dar2=&mod=&padw=&padh=&css=&doit=true (sampling matrix width in µs=52.14815 µs)
(makes sense that there is minimum DAR error, which needs not to be fixed, although as you may figure out the active area wont match perfectly in some cases, for this kind of conversions i would recommend a manual calc method which must start with collecting all the needed data - and you have to do it correctly just once anyway)

krosswindz

25th March 2008, 15:28

Quoting http://lipas.uwasa.fi/~f76998/video/conversion

If vertical_conversion_factor is anything other than 0.5, 1 or 2, you are probably trying to do a standards conversion between a 625/50 system and a 525/59.94 system. Standards conversion (when done right) is a highly demanding process and outside the scope of this document.

Here the vertical conversion factor would not be 1. Since the active picture heights vary. Would the resized image be fine?

smok3

27th March 2008, 22:45

i'am not sure what he meant with 'demanding' process? (maybe that one shouldn' do it at all...)

krosswindz

28th March 2008, 03:53

i'am not sure what he meant with 'demanding' process? (maybe that one shouldn' do it at all...)

I am not sure how demanding the process is but I have seen a lot of Indian movie DVDs which are PAL to NTSC transfers and are such pain to deinterlace. Apart from being a bad transfer they all have bad aspect ratio too.

krosswindz

2nd April 2008, 17:53

Is there any link for the math if the source is BluRay/HD DVD?

smok3

2nd April 2008, 18:22

the hi-defs are mostly with square PAR i imagine (no i haven't seen the complete standard for either of this yet).

krosswindz

2nd April 2008, 18:41

^ I assume that they should be square, havent found any mention of them of not being square AFAIK.

SeeMoreDigital

2nd April 2008, 18:43

There are quite a lot of 1440x1080 sources knocking around, complete with 4:3 (PAR) aspect ratio signalling, creating a displayed shape of 1920x1080 pixels...

smok3

3rd April 2008, 09:33

some numbers are here;
http://developer.apple.com/documentation/QuickTime/QTFF/QTFFChap3/chapter_4_section_2.html
http://www.surrealroad.com/research/archives/2005/standard-data-resolutions/

DVCPRO HD (as i recall from hvx200) is either, using smaller res:
------------------------------------------------------
960x720 (square should be 1280x720), PAR is around 1.333 (so you can use hdv preset);
http://somestuff.org/resizeCalc.php?ssmw=960&sar=1&sar2=1.333&ssmh=720&CT=&CL=&CR=&CB=&trw=1280&dar=1&dar2=&mod=&padw=&padh=&css=&doit=true
or bigger res:
1280x1080 (square should be 1920x1080), PAR is around 1.5
http://somestuff.org/resizeCalc.php?ssmw=1280&sar=1&sar2=1.5&ssmh=1080&CT=&CL=&CR=&CB=&trw=1920&dar=1&dar2=&mod=&padw=&padh=&css=&doit=true
------------------------------------------------------
this needs to be confirmed (or denied).

p.s. hvx200 960x720 scaled to square 960x544 example (seems correct or very close):
http://somestuff.org/flashAVC/flvplayer_alt.php?moviename=movies/hvx200_raw_0013EO_mute-x960y544.mp4

08d
.added some examples and links (no math changes)

krosswindz

28th April 2008, 03:21

I am not sure but I am kind of revisiting the problem we had talked earlier. Now this was something that I see personally.

The movie DVD has been marked in the packaging with "aspect ratio 2.40:1"

With the cropping resize calc displays the DAR as 2.49

http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.215&sar2=&ssmh=480&CT=62&CL=2&CR=0&CB=68&trw=&dar=1&dar2=&mod=&padw=&padh=&css=&doit=true

DVD has been authored by Sony, its probably one of the first sony dvd that I am backing up ever. My question would be why is there this difference?

smok3

28th April 2008, 07:51

various reasons:
1. sony is wrong
2. you are wrong by choosing wrong method somehow
3. my calc is wrong
did you try any alternative calc? or manual calc maybe?

SeeMoreDigital

28th April 2008, 09:20

I am not sure but I am kind of revisiting the problem we had talked earlier. Now this was something that I see personally.

The movie DVD has been marked in the packaging with "aspect ratio 2.40:1"

With the cropping resize calc displays the DAR as 2.49

DVD has been authored by Sony, its probably one of the first sony dvd that I am backing up ever. My question would be why is there this difference?Can you try this please: -

Play the DVD in a software player
Find a light scene where the black mattes are clearly visible.
Take a snapshot
Upload the snapshot to the forum

From the snapshot I should be able to tell you the movies aspect ratio...

smok3

28th April 2008, 11:08

08e
.internal release (last source code stays 08d), just some php fixes, lets see how it behaves before releasing the code.
08f
.added primitive unique visitors counter, some html fixes, sources are out

krosswindz

28th April 2008, 19:04

various reasons:
1. sony is wrong
2. you are wrong by choosing wrong method somehow
3. my calc is wrong
did you try any alternative calc? or manual calc maybe?

I normally use one of the two calculators, one is yours the other one being http://www.animemusicvideos.org/guides/avtech/resizecalc.html both spit out similar values, the difference being how the ar error is calculated.

Can you try this please: -

Play the DVD in a software player
Find a light scene where the black mattes are clearly visible.
Take a snapshot
Upload the snapshot to the forum

From the snapshot I should be able to tell you the movies aspect ratio...

Used vlc to grab these scenes, the movie is really dark so this is the best I could do. As you can see there is this white line on the top and bottom in many frames of this movie, I crop them off also along with the black border on the side before I back up.

http://img294.imageshack.us/img294/2069/vlcsnap5158296kp3.png

http://img293.imageshack.us/img293/9906/vlcsnap5157238tn8.png

http://img329.imageshack.us/img329/1601/vlcsnap5157467vh8.png

http://img152.imageshack.us/img152/2282/vlcsnap5157746tb7.png

http://img410.imageshack.us/img410/3081/vlcsnap46489bv3.png

http://img395.imageshack.us/img395/9950/vlcsnap46977sv1.png

http://img236.imageshack.us/img236/3937/vlcsnap47519rl3.png

http://img395.imageshack.us/img395/2095/vlcsnap47642bn4.png

http://img236.imageshack.us/img236/1571/vlcsnap47982fw8.png

http://img236.imageshack.us/img236/6792/vlcsnap48084cw1.png

SeeMoreDigital

28th April 2008, 19:46

Hi krosswindz,

Thanks for all the captures. After hard cropping the black mattes, green lines and image roll, your movie has an aspect ratio of 2.40:1 - as near as makes no difference.

Cheers

krosswindz

28th April 2008, 20:48

Hi krosswindz,

Thanks for all the captures. After hard cropping the black mattes, green lines and image roll, your movie has an aspect ratio of 2.40:1 - as near as makes no difference.

Cheers

Can you tell me what were the crop values.

Now the question is what went wrong with the math :confused:

krosswindz

28th April 2008, 22:00

EuropeanMan

28th April 2008, 22:38

^ as we discussed in PM kross...i was right. no offence...

my calculations were correct...your "backup" @ 2.50 was wrong...or rather AH's
-farooq

EuropeanMan

28th April 2008, 22:40

This is one of the similar frame at 720x480 frame size

http://img209.imageshack.us/img209/7663/snapshot20080428224747lf0.jpg

basically I work on the cropping on this frame before resizing, now the question I have is the cropping that gets applied to this frame is it the same cropping that gets applied to the anamorphic frame size of 853x480.

The cropping I used was (2, 62, 0, -68)

you can NOT apply the same A/R specifications on a 4:3 frame with one made on a 16:9 frame. those are two different specs. this movie was anamorphic and thus 16:9...you will have to use 853x480...as the pixels that are 'available'

in your 720x480 frame above...don't you see her face is vertically stretched? you can't do a proper a/r from this frame...

from MY understanding you must always calculate the source A/R from DAR frames...like ones shown on previous page.

krosswindz

28th April 2008, 22:56

^ as we discussed in PM kross...i was right. no offence...

my calculations were correct...your "backup" @ 2.50 was wrong...or rather AH's
-farooq

As for who is right or wrong I am not bothered. I am more interested in the math. That is what I care about.

you can NOT apply the same A/R specifications on a 4:3 frame with one made on a 16:9 frame. those are two different specs. this movie was anamorphic and thus 16:9...you will have to use 853x480...as the pixels that are 'available'

in your 720x480 frame above...don't you see her face is vertically stretched? you can't do a proper a/r from this frame...

from MY understanding you must always calculate the source A/R from DAR frames...like ones shown on previous page.

I believe using the source par it is possible to calculate the dar from the source video frame. I am sure there are other who would agree with this.

EuropeanMan

28th April 2008, 23:13

^ source DAR in this case from the source is the same as DVD packaging info.

on some bolly-titles, the .vobs have incorrect A/R on them inherently & are fixed in the .IFO files when they are played as a DVD...and even IF they are resized to a new A/R...then, many times it's wrong anyway as Bollywood DVD Authorors don't know how to properly do it :(

that's the sad part...we just got lucky with Sony here.

krosswindz

29th April 2008, 03:59

Are these PAR values correct, these are different from what is used in resizeCalc

PAL: 128:117
NTSC: 10:11
PAL Wide: 118:81
NTSC Wide: 40:33

smok3

29th April 2008, 07:25

as EuropeanMan said, visualy this appears as 2:40, however there is no much wrong watching it at 2:50 (dunno) - it seems you would never get correct numbers by using the calc or screenshot method.

40:33 = 1.21212 = 16/9*480/704 wont give much different results as it seems, calc still says that DAR is 2.48 something.

a. this seems correct:
http://somestuff.org/resizeCalc.php?ssmw=704&sar=1.215&sar2=&ssmh=480&CT=62&CL=2&CR=0&CB=68&trw=851&dar=1&dar2=&mod=1&padw=&padh=&css=&doit=true
(imagine that 704 is actually 720, which means they are using the fullscreen 'standard')
or with some clicking (converting 704 to 720) you would get 1.189 PAR for the fullscreen NTSC 'standard'.
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.215&sar2=1.189&ssmh=480&CT=62&CL=2&CR=0&CB=68&trw=851&dar=1&dar2=&mod=1&padw=&padh=&css=&doit=true
(but that number is not mentioned anywhere else as i remember)

b. or adobe seems to use 1.2 for ntsc wide (16/9*486/720), which again is close
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.215&sar2=1.2&ssmh=480&CT=62&CL=2&CR=0&CB=68&trw=851&dar=1&dar2=&mod=1&padw=&padh=&css=&doit=true
what a mess...

btw: the calc got incredible 22 unique visitors since yesterday :P

SeeMoreDigital

29th April 2008, 08:59

The following sample was "hard cropped" to 850x352 pixels and then encoded to an 720x352 frame with 32:27 aspect ratio signalling added: -

http://www.sendspace.com/file/ytnm9y

See what you think?

smok3

29th April 2008, 09:43

SMD: The connection to the server was reset while the page was loading.

08g - nothing new with resizing, i'am playing with the counter...
.faster and even simpler ('unique' visitors) counter, behaves like: store last (and only last) ip and use session (cookie) as well, (can be faked by killing the cookies and waiting for another guy to hit the page before you or by changing the ip as well - so with two machines on different ips one could play the ping-pong and increase the count).

smok3

29th April 2008, 11:17

krosswindz: could you post a small vob sample? (if you need some ftp let me know.)

krosswindz

29th April 2008, 13:32

The following sample was "hard cropped" to 850x352 pixels and then encoded to an 720x352 frame with 32:27 aspect ratio signalling added: -

http://www.sendspace.com/file/ytnm9y

See what you think?

It seems fine.

as EuropeanMan said, visualy this appears as 2:40, however there is no much wrong watching it at 2:50 (dunno) - it seems you would never get correct numbers by using the calc or screenshot method.

40:33 = 1.21212 = 16/9*480/704 wont give much different results as it seems, calc still says that DAR is 2.48 something.

a. this seems correct:
http://somestuff.org/resizeCalc.php?ssmw=704&sar=1.215&sar2=&ssmh=480&CT=62&CL=2&CR=0&CB=68&trw=851&dar=1&dar2=&mod=1&padw=&padh=&css=&doit=true
(imagine that 704 is actually 720, which means they are using the fullscreen 'standard')
or with some clicking (converting 704 to 720) you would get 1.189 PAR for the fullscreen NTSC 'standard'.
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.215&sar2=1.189&ssmh=480&CT=62&CL=2&CR=0&CB=68&trw=851&dar=1&dar2=&mod=1&padw=&padh=&css=&doit=true
(but that number is not mentioned anywhere else as i remember)

b. or adobe seems to use 1.2 for ntsc wide (16/9*486/720), which again is close
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.215&sar2=1.2&ssmh=480&CT=62&CL=2&CR=0&CB=68&trw=851&dar=1&dar2=&mod=1&padw=&padh=&css=&doit=true
what a mess...

btw: the calc got incredible 22 unique visitors since yesterday :P

Assuming that we have full frame (NTSC Wide) anamorphic video when we convert to square pixel we should get 853x480 if we use mod1.

using NTSC Wide PAR
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.215&sar2=&ssmh=480&CT=0&CL=0&CR=0&CB=0&trw=853&dar=1&dar2=&mod=1&padw=&padh=&css=&doit=true

Using 1.189 as PAR
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.215&sar2=1.189&ssmh=480&CT=0&CL=0&CR=0&CB=0&trw=853&dar=1&dar2=&mod=1&padw=&padh=&css=&doit=true

Using 1.2 as PAR
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.215&sar2=1.2&ssmh=480&CT=0&CL=0&CR=0&CB=0&trw=853&dar=1&dar2=&mod=1&padw=&padh=&css=&doit=true

But 1.189 doesnt seem to be a PAR for NTSC Wide mentioned any where

http://en.wikipedia.org/wiki/Pixel_aspect_ratio

IMO if we have the right PAR value we should be able to get to right anamorphic width.

krosswindz: could you post a small vob sample? (if you need some ftp let me know.)

http://www.mediafire.com/?3dmyzdfcvj4

smok3

29th April 2008, 14:08

yes, but check the square numbers, the ones i use for PAL are
1024x576 square
http://somestuff.org/resizeCalc.php?ssmw=1024&sar=1&sar2=&ssmh=576&CT=0&CL=0&CR=0&CB=0&trw=704&dar=1.459&dar2=&mod=1&padw=&padh=&css=&doit=true

and
1050x576 square
http://somestuff.org/resizeCalc.php?ssmw=1050&sar=1&sar2=&ssmh=576&CT=0&CL=0&CR=0&CB=0&trw=720&dar=1.459&dar2=&mod=1&padw=&padh=&css=&doit=true

krosswindz

29th April 2008, 14:59

I dont have much idea about PAL but it seems right, I am sure that NTSC would be the same way around too. Looking at the standards it seems that this should be the way it should be done.

To further confuse oneself NTSC Wide is displayed as 853x480 and PAL Wide 1024x576. This is what it is displayed as. Do we have to account for PAR in this case?

smok3

29th April 2008, 15:03

edit: nm, my mistake

back to your sample, this seems to be one way of getting the 'on the box' DAR
http://somestuff.org/resizeCalc.php?ssmw=704&sar=1.215&sar2=&ssmh=480&CT=60&CL=2&CR=0&CB=66&trw=&dar=1&dar2=&mod=1&padw=&padh=&css=&doit=true or
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.215&sar2=&ssmh=480&CT=60&CL=10&CR=8&CB=66&trw=&dar=1&dar2=&mod=1&padw=&padh=&css=&doit=true
however i don't think it is correct for this specific sample, now what is puzzling me is that the player seems to get it right...., is it because the software player is wrong or... -> and we are back at the start.

krosswindz

29th April 2008, 15:35

The only thing I can think of is probably what something sony did. They probably authored it at 704x480 and then stretched to 720x480. Software players guess only check if it is either 4:3 or 16:9. If this is the case then it is a violation of standards IMO.

smok3

29th April 2008, 15:41

yes, it appears so, but iam afraid to claim anything really :)

for example, if i use my 'out of the air' number i get close as well (with DAR)
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1&sar2=1.189&ssmh=480&CT=60&CL=2&CR=0&CB=66&trw=&dar=1.215&dar2=&mod=1&padw=&padh=&css=&doit=true

krosswindz

29th April 2008, 16:34

I am not making any claims either but this seems to be the only logical explanation to it. The "out of the air" number isnt a valid PAR IMO. It would be interesting if this can be checked with some PAL DVDs or other NTSC DVDs.

edit: Will try it with the few DVDs that I have.

smok3

29th April 2008, 17:02

maybe better check the entire cycle;
http://somestuff.org/downloads/resizeCalc_php/test_pat/
(i think all you need is this simple test pat picture, the circle should be circle at the end of its path)

krosswindz

29th April 2008, 17:23

The test pattern seems to be 4:3 only, a few more test pattern that can be used to test the math.

http://img139.imageshack.us/img139/2696/nbc640x480bw8.gif

http://img149.imageshack.us/img149/930/indianhead640x480lx0.gif

http://img301.imageshack.us/img301/7177/bbcgts4.jpg

http://img291.imageshack.us/img291/2672/bbcf1997hl9.jpg

http://img292.imageshack.us/img292/3994/bbcaxo7.gif

http://img329.imageshack.us/img329/6969/aspectratiocircles1024xrp9.jpg

Not sure if there are any 16:9 test pattern. There should be since now there are 16:9 TVs.

krosswindz

29th April 2008, 17:28

found 16:9 test pattern this should be interesting to see how it works.

http://img216.imageshack.us/img216/3075/16x9testpatternpa3.gif

smok3

29th April 2008, 18:08

you can/should make it wide, example;

pal704wide
imageSource("philips_test_pat.png")
assumefps(25)
Subtitle("pal704Wide", font="arial", size=50, text_color=$ffffff, align=5)

# resizeCalc
# pixels = 304128, DAR error = -0.042
# Crop(Left, top, -right, -Bottom)
Crop(0,2,-0,-0) # 768,574
LanczosResize(528,576) # mod16
AddBorders(88,0,88,0) # pad width 704

#http://somestuff.org/resizeCalc.php?ssmw=768&sar=1&sar2=&ssmh=576&CT=2&CL=&CR=&CB=&trw=528&dar=1.459&dar2=&mod=&padw=704&padh=576&css=&doit=true

edited

krosswindz

29th April 2008, 18:46

http://img166.imageshack.us/img166/3076/pal704widerx3.png

this is the output screen of the script.

will try to encode into mkv and see how it works.

smok3

29th April 2008, 18:50

i guess, now the idea is to measure the circle in pixels before and after dvd has happened, if i force preview in virtualdub to 16:9, this will be correct.

krosswindz

29th April 2008, 18:56

It seems perfect when I force it to 16:9 now the question is what would be a similar test for NTSC

http://img410.imageshack.us/img410/1180/testkg8.jpg

smok3

29th April 2008, 19:00

for ntsc704wide version, and change assumefps to whatever you need for the ntsc, 29.something?

#http://somestuff.org/resizeCalc.php?ssmw=768&sar=1&sar2=&ssmh=576&CT=2&CL=&CR=&CB=&trw=528&dar=1.215&dar2=&mod=&padw=704&padh=480&css=&doit=true

krosswindz

29th April 2008, 19:26

Seems to me like that it works fine, for some reason 40:33 aspect ratio for NTSC seemed better visually to me than 16:9. I am not sure if you notice the same.

smok3

29th April 2008, 19:36

what/how exactly did you test?

krosswindz

29th April 2008, 19:41

I opened the avs file in virtualdub and changed the aspect ratio in that from free adjust to 16:9 or 40:33.

krosswindz

29th April 2008, 20:04

@smok3 that was my bad, 704 looks perfect with both 16:9 and 40:33, I tried another one with padding it to 720 and that also seems better for 16:9, 40:33 makes it horizontally stretched.

The conclusion we have from this is that the PAR values are correct IMO. The question comes what went wrong with that DVD. I have a couple of other DVDs which I am gonna check.

smok3

29th April 2008, 20:09

here is one thread, that should be interesting
http://forum.doom9.org/showthread.php?t=132378

SeeMoreDigital

29th April 2008, 20:11

Seems to me like that it works fine, for some reason 40:33 aspect ratio for NTSC seemed better visually to me than 16:9. I am not sure if you notice the same.Yep... That's because 704 x 40/33 = 853.3333.

If you had elected to encode a 720x480 resolution frame, you would need to add aspect ratio signalling of 32:27. As 720 x 32/27 = 853.3333.

Cheers

krosswindz

29th April 2008, 20:28

SeeMoreDigital

29th April 2008, 20:46

coming back to the point, what would be the right value that one should pick up when one is doing a mpeg-4 encode from DVD. What would be the right way to calculate the actual DAR.

One would surely start of by cropping the black borders on the top & bottom, and the sides. And depending on if the source is 720x or 704 would we choose the 40:33 or 32:27 to calculate the DAR?For NTSC sources. If you crop/re-size to 704 wide use 40:33. Or if you crop/re-size to 720 wide use 32:27. Both will give you a "playback" width of 853.3333 pixels.

krosswindz

29th April 2008, 21:19

For NTSC sources. If you crop/re-size to 704 wide use 40:33. Or if you crop/re-size to 720 wide use 32:27. Both will give you a "playback" width of 853.3333 pixels.

The point is that if the DVD source is 704 pixels width-wise or 720 pixels width-wise when resizing after cropping what would one choose as the PAR to calculate the DAR. This would be the DAR to be used for the mpeg4 encode.

going with the formula for DAR.

DAR height
------ = ----------
PAR width

SeeMoreDigital

29th April 2008, 22:03

The point is that if the DVD source is 704 pixels width-wise or 720 pixels width-wise when resizing after cropping what would one choose as the PAR to calculate the DAR. This would be the DAR to be used for the mpeg4 encode.

going with the formula for DAR.

DAR height
------ = ----------
PAR width
At the end of the day, DAR, PAR and SAR are only different abbreviations that use the same maths to calculate a required "aspect ratio signalling" value!

Don't get caught up in the abbreviations... Just do the maths ;)

krosswindz

29th April 2008, 22:29

At the end of the day, DAR, PAR and SAR are only different abbreviations that use the same maths to calculate a required "aspect ratio signalling" value!

Don't get caught up in the abbreviations... Just do the maths ;)

What would you propose would be the math to do calculate "aspect ratio signalling" value?

Given that the source could be a DVD either NTSC/NTSC Wide/PAL/PAL Wide with video frame size as 704x480/720x480/704x576/720x576.

SeeMoreDigital

29th April 2008, 22:40

Have a look at the following thread: -

http://www.ziova.com/forum/index.php?showtopic=3800

Together with the ARS Calculator...

http://img233.imageshack.us/img233/9139/arscalculator9va.png

Cheers

krosswindz

29th April 2008, 23:00

Have a look at the following thread: -

http://www.ziova.com/forum/index.php?showtopic=3800

Together with the ARS Calculator...

http://img233.imageshack.us/img233/9139/arscalculator9va.png

Cheers

I did read that the, one relation ship I didnt understand just by looking at is the relation between PFS, MAR and ARS?

edit:
What I am trying is to have one shot calculator so that I really dont have to worry about multiple calculators.

edit2:
The reason being I normally encode to square PAR.

smok3

30th April 2008, 08:43

ok, so i can add those numbers at the pulldown if you wish:
32/27 = 'ntsc 720 wide' - naming ok?
40/33 = 'ntsc 704 wide' - naming ok?
or will this just add to the confusion?

SeeMoreDigital

30th April 2008, 08:58

edit2:
The reason being I normally encode to square PAR.In that case...

Do what you did in post #60 (using VLC player).
Hard crop the black mattes, green lines and image roll away.
Using the remaining cropped image. Divide the image width by the height height which will give you the movies aspect ratio

Cheers

smok3

30th April 2008, 10:30

lol, ok i rest my case :)

krosswindz

30th April 2008, 13:45

In that case...

Do what you did in post #60 (using VLC player).
Hard crop the black mattes, green lines and image roll away.
Using the remaining cropped image. Divide the image width by the height height which will give you the movies aspect ratio

Cheers

Thanks.

ok, so i can add those numbers at the pulldown if you wish:
32/27 = 'ntsc 720 wide' - naming ok?
40/33 = 'ntsc 704 wide' - naming ok?
or will this just add to the confusion?

Wouldnt the same apply for PAL as
pal 704 wide = 16/11
pal 720 wide = 64/45

Similarly things would change for normal NTSC/PAL?

smok3

30th April 2008, 15:57

yeah, we need 4x PAL and 4x NTSC with
a. proper numbers?
b. proper names for the presets?
c. proper and short general explanation how they are mapped to each other?
suggestions?

maybe like:
---------------------
pal aa/bb
pal fullscan aa/bb
pal wide aa/bb
pal wide fullscan aa/bb
ntsc aa/bb
ntsc fullscan aa/bb
ntsc wide aa/bb
ntsc wide fullscan aa/bb
---------------------
?

the word instead 'fullscan' could be 'digital' but sounds kinda cheesy?

krosswindz

30th April 2008, 16:43

my 2 cents

The PAR values need to be rechecked however. If someone can confirm these values.

NTSC (704/480) = 10:11
NTSC (720/480) = 8:9
NTSC Wide (704/480) = 40:33
NTSC Wide (720/480) = 32:27

PAL (704/576) = 12:11
PAL (720/576) = 16:15
PAL Wide (704/576) = 16:11
PAL Wide (720/576) = 64:45

The standards are the same the only difference that source video frame size is different.

SeeMoreDigital

30th April 2008, 17:38

Hi krosswindz,

I'm getting quite confused by your posts now :eek:

If you normally generate encodes with "square" pixels. Why are you so interested in "non-square" pixel PAR values?

Cheers

unskinnyboy

30th April 2008, 17:52

SMD, My thoughts exactly.

krosswindz, I quickly skimmed through this thread now, but can't really understand what you are on about. What's your confusion about aspect ratios exactly? You seem to be making it harder than it has to be.

krosswindz

30th April 2008, 17:52

Hi krosswindz,

I'm getting quite confused by your posts now :eek:

If you normally generate encodes with "square" pixels. Why are you so interested in "non-square" pixel PAR values?

Cheers

my question was more like are those PAR values the correct ones for the videos of those source. I always encode with square PAR.

SMD, My thoughts exactly.

krosswindz, I quickly skimmed through this thread now, but can't really understand what you are on about. What's your confusion about aspect ratios exactly? You seem to be making it harder than it has to be.

If those PAR values are correct IMO

source PAR * cropped width
source DAR = ------------------------------
cropped height

Since the aim is to keep the target DAR as close to the source DAR as possible then choose a mod16 res which fits the target DAR with the lease amount of error.

edit: In this case cropped width and cropped height are with regards to the source frame size of being either 720/704 x 480/576

edit2: this DAR would be close the MAR (movie aspect ratio), which SMD uses in aspect ratio signaling calculator.

smok3

30th April 2008, 18:08

unskinnyboy, this thread has actually lead (some of us) to some conclusions,
a. that are no complete calcs out there, even if the theory behind it is really simple,
b. there is also a thread started by 2bdecided that never got exact answers - which means that no one really knows how exactly the theory patches to practice, check it out.

unskinnyboy

30th April 2008, 18:23

Since the aim is to keep the target DAR as close to the source DAR as possible then choose a mod16 res which fits the target DAR with the lease amount of error.A DVD can have only two DARs, 16:9 or 4:3, period. Your aim should be to get as close to the theatrical AR as possible. In the rare event that the DVD AR (I am referring to the AR of the DVD image here, after cropping away all black, NOT the DVD DAR) is different from the theatrical AR, then that's what you should get close to.

You shouldn't be hung up on the DVD PAR values. Yes, your ratios are right AFAICS, but when you encode to AVI, how do you plan to use those DVD PAR values?

P.S: Can you please stop editing your posts once you've submitted them? Twice I had to revise my replies because you changed your post.

SeeMoreDigital

30th April 2008, 18:41

I'm in total agreement with unskinnyboy's comments....

krosswindz

30th April 2008, 19:15

A DVD can have only two DARs, 16:9 or 4:3, period. Your aim should be to get as close to the theatrical AR as possible. In the rare event that the DVD AR (I am referring to the AR of the DVD image here, after cropping away all black, NOT the DVD DAR) is different from the theatrical AR, then that's what you should get close to.

You shouldn't be hung up on the DVD PAR values. Yes, your ratios are right AFAICS, but when you encode to AVI, how do you plan to use those DVD PAR values?

P.S: Can you please stop editing your posts once you've submitted them? Twice I had to revise my replies because you changed your post.

This I suppose is because of my incorrect terminology. There are two many 3 letter acronyms floating around which refer to different things.

Let me define my terminologies before I go into

PAR = Pixel Aspect Ratio. Whose values are mentioned in #106 (http://forum.doom9.org/showpost.php?p=1130663&postcount=106) along with the respective video frame size.

After cropping that image (i.e removing the black borders) I would get the cropped width.

I calculate my sources aspect ratio (calling it source AR) to prevent any confusion.

source PAR * cropped width
source AR = ------------------------------------
cropped height

This source AR in my opinion should be as close as possible to the DVD AR that you have mentioned. When you encode with square pixels you would want the output resolution as close as possible to this. Please correct me if I am wrong.

I'm in total agreement with unskinnyboy's comments....

I hope this clarifies any of the confusions I have caused using incorrect terminology.

SeeMoreDigital

30th April 2008, 19:22

As I said in post 97 (http://forum.doom9.org/showthread.php?p=1130397#post1130397).

"At the end of the day, DAR, PAR and SAR are only different abbreviations that use the same maths to calculate a required "aspect ratio signalling" value - Don't get caught up in the abbreviations... Just do the maths" ;)

krosswindz

30th April 2008, 19:26

unskinnyboy

30th April 2008, 19:31

source PAR * cropped width
source AR = ------------------------------------
cropped height

This source AR in my opinion should be as close as possible to the DVD AR that you have mentioned. When you encode with square pixels you would want the output resolution as close as possible to this. Please correct me if I am wrong.Your formula is right, as long as you aren't mixing the values for DVDs and the values for MPEG-4.

Regardless of whatever your previous DVD PAR values were, when you encode to AVI, your PAR is now 1. If you put this in your formula, then source AR = cropped width / cropped height. Which means, how you resize the image will determine your final AR. Is it clear so far?

krosswindz

30th April 2008, 19:42

Your formula is right, as long as you aren't mixing the values for DVDs and the values for MPEG-4.

Regardless of whatever your previous DVD PAR values were, when you encode to AVI, your PAR is now 1. If you put this in your formula, then source AR = cropped width / cropped height. Which means, how you resize the image will determine your final AR. Is it clear so far?

Probably an example might be better for me to explain what I am trying to say.

Lets take this 720x480 frame (my cropping is using this frame size).

http://img209.imageshack.us/img209/7663/snapshot20080428224747lf0.jpg

The crop values I had were crop (2, 62, 0, -68) IIRC.

so using this

32 * 718
source AR = ----------- = 2.431322
27 * 350

IIRC the cropped frame of this image was 850x352

http://img294.imageshack.us/img294/2069/vlcsnap5158296kp3.png

this gives DVD aspect ratio which you are taking about as 2.414773

I tend to be conservative in cropping and do over crop a bit at times.

I hope that the math I proposed is correct. And better explains what I am trying to do here.

smok3

30th April 2008, 19:50

08h
.has 'notes' link to fullscan numbers as proposed above, so you can copy/paste those when needed (into custom PAR field) - on the 2nd thought there are reasons to not include those into presets.

SeeMoreDigital

30th April 2008, 19:58

To confuse you even more: -

The unfortunate thing with NTSC DVD sources is that they're more difficult to convert to "square pixel" encodes than PAL DVD sources.

Upon playback, PAL DVD sources are displayed at either 768 pixels wide (for 4:3 sources) or 1024 pixels wide (for 16:9 sources).

By contrast, NTSC DVD sources are displayed at either 640 pixels wide (for 4:3 sources) or 853.33 pixels wide (for 16:9 sources).

Sadly, 853.33 pixels does not conform to a "mod-16" width (ie: 853.33 does not divide by 16). Meaning the closest mod-16 pixel width to 853.33 is either 848 or 864 pixels

krosswindz

30th April 2008, 20:09

unskinnyboy

30th April 2008, 20:53

krosswindz, let's see if the way you are doing it is universally applicable, OK?

This is a screencap from my NTSC R1 4:3 DVD of Cyrano de Bergerac (1990) (http://www.imdb.com/title/tt0099334/) which has a PAR of 8:9:

http://img301.imageshack.us/img301/9360/vlcsnap3244586ru4.th.png (http://img301.imageshack.us/my.php?image=vlcsnap3244586ru4.png)

To get rid of all the black, I need to use crop(4,42,-2,-48). My resultant image is now 634x390:
http://img238.imageshack.us/img238/6244/cyranocroppedlf9.th.png (http://img238.imageshack.us/my.php?image=cyranocroppedlf9.png)

If I plug the values into your formula, I get:

8 * 634
source AR = ----------- = 1.4450
9 * 390

Are you suggesting that 1.44:1 is the AR of this movie?

SeeMoreDigital

30th April 2008, 21:06

That does not confuse me as much as the number of 3 letter acronyms. I would really appreciate it if you could confirm that the math I suggested is right?Well this bit of maths you did works: -

32 * 718
source AR = ----------- = 2.431322
27 * 350

However, if you know your NTSC DVD source is 16:9, you could also calculate the movie aspect ratio like this: -

16÷9 x ((718÷720) ÷ (350÷480)) = 2.431322751

Cheers

smok3

30th April 2008, 21:18

krosswindz

30th April 2008, 21:28

smok3

30th April 2008, 21:34

appears as this is the 4320/4739 case - 704 active area stretched to 720 (but you can't be sure)
http://somestuff.org/resizeCalc.php?ssmw=720&sar=0.911&sar2=&ssmh=480&CT=90&CL=6&CR=&CB=&trw=&dar=1&dar2=&mod=&padw=&padh=&css=&doit=true
spits DAR as 1.668

krosswindz

30th April 2008, 21:35

appears as this is the 4320/4739 case (but you can't be sure)
http://somestuff.org/resizeCalc.php?ssmw=720&sar=0.911&sar2=&ssmh=480&CT=90&CL=6&CR=&CB=&trw=&dar=1&dar2=&mod=&padw=&padh=&css=&doit=true
spits DAR as 1.668

Very true because the source is assumed as 720x480. If you do the similar work using my math it seems to come to a similar number.

krosswindz

30th April 2008, 21:37

May be to make point clearer all the cropping I do is on the actual source frame viz. 720x480/704/480 (NTSC), 720x576/704x576 (PAL).

unskinnyboy

30th April 2008, 22:15

you got me wrong... I said that this work using the source video frame. If I assume that the source video frame is 720x480...I understood you now. Earlier, I assumed you were saying something else. But, in fact, we may have been trying to say the same thing.

So, yes, your math is right. :)

smok3, I'll check out the other thread.

EuropeanMan

1st May 2008, 05:05

I'm in total agreement with unskinnyboy's comments....

I agree with USB here...it was SO simple just to cut away all black and you have the DAR of the source. When encoding to AVI/MKV or whatever...one should get a resolution as close to the original DAR as possible...WITH also keeping mod16 in mind.

Also, the formulae here in many instances do hold validity as well...but will THIS lead to a calculator for A/R that is universal? and what would be the +/- error %?

SeeMoreDigital

1st May 2008, 08:55

Hi unskinnyboy,

When you do the maths, a loss of just "one" cropped pixel in width, can make quite a difference to your calculations: -

4÷3 x ((715÷720) ÷ (390÷480)) = 1.629629296
4÷3 x ((714÷720) ÷ (390÷480)) = 1.627350427
4÷3 x ((713÷720) ÷ (390÷480)) = 1.625071225
4÷3 x ((712÷720) ÷ (390÷480)) = 1.622792023

Cheers

smok3

1st May 2008, 10:22

but will THIS lead to a calculator for A/R that is universal? and what would be the +/- error %?
from a DVD-ripper-person point of view, certainly no, from a video-person perspective it is universal enough just now as it seems.

unskinnyboy

1st May 2008, 14:32

I agree with USB here...it was SO simple just to cut away all black and you have the DAR of the source. When encoding to AVI/MKV or whatever...one should get a resolution as close to the original DAR as possible...WITH also keeping mod16 in mind.Wait! No, not "original DAR" again! When you say "original DAR", it means the DAR of the DVD, which can only be 4:3 or 16:9, and that's not what you want to get close to (if your source is just MPEG-2, then it can have 1:1, 4:3, 16:9 or 2.21:1). You want to get close to the AR of the movie. Perhaps this is indeed what you meant to say, but let's be sure of using the absolute correct terms here. Part of the reason why the AR concept seems so confusing is because of loosely using these terms. This is why we were trying to explain this 4 years ago, and we are still trying to explain this now.

Also, the formulae here in many instances do hold validity as well...but will THIS lead to a calculator for A/R that is universal?Nope.

When you do the maths, a loss of just "one" cropped pixel in width, can make quite a difference to your calculations: -

4÷3 x ((715÷720) ÷ (390÷480)) = 1.629629296
4÷3 x ((714÷720) ÷ (390÷480)) = 1.627350427
4÷3 x ((713÷720) ÷ (390÷480)) = 1.625071225
4÷3 x ((712÷720) ÷ (390÷480)) = 1.622792023
Yes, agree. Cropping is very crucial here. If you have have overcropped or undercropped by even 1 pixel, that will have a butterfly effect on the final AR. That plus, the MoD-16 restriction, will mean that you'll never be able to get the proposed AR down to the last point. It'll always be an approximation.

And we haven't even touched on ITU-R BT.601, capture windows (say if you were capturing your source) etc.

krosswindz

1st May 2008, 15:11

Yes, agree. Cropping is very crucial here. If you have have overcropped or undercropped by even 1 pixel, that will have a butterfly effect on the final AR. That plus, the MoD-16 restriction, will mean that you'll never be able to get the proposed AR down to the last point. It'll always be an approximation.

And we haven't even touched on ITU-R BT.601, capture windows (say if you were capturing your source) etc.

IMO cropping a source definitely changes the source AR, and not the source PAR. Plus taking into consideration source whose AR varies at different parts of it. If we crop keeping that in mind it will definitely affect the final AR.

It would be nice if we have more hard ware vendors implementing non mod16 macro blocks in hardware. There have been many implementations floating around for implementing them efficiently on hardware. IIRC I have only seen probably one vendors chip that probably implements at least mod8 macroblock. Most chips I have seen break on anything other than mod16.

These two links provide a nice explanation, but if you use those numbers we end up not getting the right AR quite a few times. Is this because the source was violating something :confused:

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

http://lipas.uwasa.fi/~f76998/video/conversion/

smok3

1st May 2008, 16:07

just a note /maybe to myself/: agreeing or disagreeing without the numbers is not the purpose of this thread.

unskinnyboy

1st May 2008, 16:12

IMO cropping a source definitely changes the source AR, and not the source PAR. Of course. However you crop, PAR won't be affected. I never said otherwise. Did you get that impression from anything I said? When I say final AR, I mean the final DAR of the AVI file, obtained after resizing.

Plus taking into consideration source whose AR varies at different parts of it. If we crop keeping that in mind it will definitely affect the final AR.For floating frames, I try to strike a balance wherein I might overcrop some parts and undercrop some parts, the aim being to keep as much of the picture as possible, and try to resize to compensate for this. You might end up with a wrong final DAR, but that's OK.

It would be nice if we have more hard ware vendors implementing non mod16 macro blocks in hardware. There have been many implementations floating around for implementing them efficiently on hardware. IIRC I have only seen probably one vendors chip that probably implements at least mod8 macroblock. Most chips I have seen break on anything other than mod16.I am not sure what you mean by "non mod16 macro blocks in hardware". The MoD16 restriction (well, not really a restriction, but rather a recommendation) is more for aiding the codec to compress the input video optimally, and to ensure that it works across the board for all filters, some of which may process the image using the same 8x8-DCTs-grouped-into-a-macroblock way. EDIT: Yes, some standalones do have a problem with non-MoD16.

These two links provide a nice explanation, but if you use those numbers we end up not getting the right AR quite a few times. Is this because the source was violating something :confused:

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

http://lipas.uwasa.fi/~f76998/video/conversion/
Example? Could be the ITU-R BT.601 black magic.

krosswindz

1st May 2008, 16:35

Of course. However you crop, PAR won't be affected. I never said otherwise. Did you get that impression from anything I said? When I say final AR, I mean the final DAR of the AVI file, obtained after resizing.

For floating frames, I try to strike a balance wherein I might overcrop some parts and undercrop some parts, the aim being to keep as much of the picture as possible, and try to resize to compensate for this. You might end up with a wrong final DAR, but that's OK.

I am not sure what you mean by "non mod16 macro blocks in hardware". The MoD16 restriction (well, not really a restriction, but rather a recommendation) is more for aiding the codec to compress the input video optimally, and to ensure that it works across the board for all filters, some of which may process the image using the same 8x8-DCTs-grouped-into-a-macroblock way. EDIT: Yes, some standalones do have a problem with non-MoD16.

Example? Could be the ITU-R BT.601 black magic.

my bad... i just woke up and wasnt reading properly.

mod16 is not a restriction but most hardware vendors choose not implement grouping 8x8 or 4x4 or 2x2 into a macroblock. These days you have efficient algorithms to do this which can be verified in hardware. If you want I can pm you some papers.

Lets no digress from the topic at hand of calculating an AR withing allowable error range.

Lets take the previous example used in post #117 (http://forum.doom9.org/showpost.php?p=1130708&postcount=117)

Source video frame is 720x480.

From these articles one can get the source PAR of NTSC Wide would be 1.215446 (one can easily calculate this) unless I am in correct.

I am just giving the final source AR (one can easily calculate it) as 2.493401. Agreed this is within 5% error.

Now if we assume the frame size is 704x480

source AR comes out to be 2.437837 which is closer to what we have calculated.

I am not saying that I am right, I am probably wrong in interpreting it and getting an incorrect PAR.

SeeMoreDigital

1st May 2008, 18:25

And we haven't even touched on ITU-R BT.601, capture windows (say if you were capturing your source) etc.Indeed....

However, for all those who insist on accomodating for the ITU spec. Here's how it can be worked into a typical calculation: -

For a PAL movie (Cropped: Top = 70, Bottom = 70, Left = 0, Right = 0. Disc AR = 16/9. PAL ITU = 1.025640385)

With PAL ITU = 16÷9 x ((720 ÷ 720) ÷ (436 ÷ 576)) x 1.025640385 = 2.408843473
Without ITU = 16÷9 x ((720 ÷ 720) ÷ (436 ÷ 576)) = 2.348623853

For a NTSC movie (Cropped: Top = 58, Bottom = 59, Left = 0, Right = 0. Disc AR = 16/9. NTSC ITU = 1.02536086)

With NTSC ITU = 16÷9 x ((720 ÷ 720) ÷ (363 ÷ 480)) x 1.02536086 = 2.410398349
Without ITU = 16÷9 x ((720 ÷ 720) ÷ (363 ÷ 480)) = 2.350780533

Cheers

krosswindz

1st May 2008, 18:40

SMD, can you provide any link for the PAL/NTSC ITU numbers. I just want to understand them better.

krosswindz

1st May 2008, 18:44

Looking at this link http://trac.handbrake.fr/wiki/AnamorphicGuide#itu

I am not sure about this but I am just wondering shouldnt the NTSC/PAL PAR which I wrote up in post #106 (http://forum.doom9.org/showpost.php?p=1130663&postcount=106) account for these.

Apologies if I am being stupid, ignorant and hence incorrect.

unskinnyboy

1st May 2008, 20:05

mod16 is not a restriction but most hardware vendors choose not implement grouping 8x8 or 4x4 or 2x2 into a macroblock. These days you have efficient algorithms to do this which can be verified in hardware. If you want I can pm you some papers.I don't really understand what you are trying to say, so please yes, PM me the papers and point out which are the relevant sections I should look at.

Looking at this link http://trac.handbrake.fr/wiki/AnamorphicGuide#itu

I am not sure about this but I am just wondering shouldnt the NTSC/PAL PAR which I wrote up in post #106 (http://forum.doom9.org/showpost.php?p=1130663&postcount=106) account for these.

Apologies if I am being stupid, ignorant and hence incorrect.
You have already accounted for those. The PARs for all the 704x??? ones correspond to ITU-R BT.601 compliant PARs. As per the specs, 704x480 for NTSC and 704x576 are the active pixel areas (it's actually 702x???, but we won't go there, so as not to confuse you further). It's only valid for DVDs authored with ITU-R BT.601 or for captures done with ITU-R BT.601 compliant cards, though. But, just because a DVD is 704x??? doesn't mean that it's ITU-R BT.601 compliant nor does a 720x??? DVD means that it isn't. There's no rule of thumb there.

Like I've implied before, don't always depend on your formula to get the AR right, though - you could have a WS image letterboxed into a 4:3 DVD, authored with a 4:3 DAR and 8:9 PAR.

krosswindz

1st May 2008, 21:06

I don't really understand what you are trying to say, so please yes, PM me the papers and point out which are the relevant sections I should look at.

You have already accounted for those. The PARs for all the 704x??? ones correspond to ITU-R BT.601 compliant PARs. As per the specs, 704x480 for NTSC and 704x576 are the active pixel areas (it's actually 702x???, but we won't go there, so as not to confuse you further). It's only valid for DVDs authored with ITU-R BT.601 or for captures done with ITU-R BT.601 compliant cards, though. But, just because a DVD is 704x??? doesn't mean that it's ITU-R BT.601 compliant nor does a 720x??? DVD means that it isn't. There's no rule of thumb there.

Like I've implied before, don't always depend on your formula to get the AR right, though - you could have a WS image letterboxed into a 4:3 DVD, authored with a 4:3 DAR and 8:9 PAR.

I have sent you one... a really short one.

Just that this formula could be used as tool to aid a ripper. To make his decision process easier. Its not for the ripper to depend on them.

smok3

2nd May 2008, 10:43

to simplify, the real problem is (with DVDs at least):
1. was dvd authoring path ITU-R BT.601 compliant
2. what software/hardware players are ITU-R BT.601 compliant
which seems unsolvable.
p.s. personally i don't care about unknown sources thought, i do manipulate my own material - mostly.
-----------------------
p.s.2 for other lost souls, this seems to be the simplest explanation i have found so far (no, i do not say or claim that it is perfecly correct, but should be more than good enough for illustration):

from http://www.afterdawn.com/glossary/terms/itu-r_bt_601.cfm
ITU-R BT.601 is the designation for an entire set of standards that defines rules for converting analog (PAL or NTSC) television signals to digital and back. The standard was formalized by the International Telecommunications Union (ITU) and has since been used as a guideline for nearly all digital consumer video formats. This standard is also commonly referred to as simply Rec.601, or even by its older name of CCIR 601.

Resolution
The most commonly used portion of ITU-R BT.601 is the Resolution of 720x576 for PAL video and 720x480 for NTSC. This Resolution is achieved by sampling at a Frequency of 13.5MHz (13,500,000 samples per second) across horizontal lines 53.333µs (.000053333 seconds) long. Since the actual line length for PAL and NTSC TVs is 52µs and 52.666µs respectively. That means a standard ITU-R BT.601 Frame includes either PAL video with an Active Area (the part of the Frame containing visible pixels) of 702x576 or NTSC video with an active area of 711x480. In reality many real-world implementations of this conversion use either a different resolution, such as 640x480/576, or a slighly different line length, resulting in the active area of the picture to use all 720 Pixels.

DVD
The best known application of ITU-R BT.601 is probably DVD-Video, where frame sizes of 720x480 and 720x576 are standard. However, like all implementations, the actual conversion back to an analog signal is dependent on the player, and may not follow the ITU specification. Likewise, video encoding for video often uses all 720 Pixels for a standard 4:3 image. For either Widescreen (Anamorphic) or 4:3 Letterbox DVDs it may be necessary using the additional pixels to maintain the source's Aspect ratio.

DV
DV, used in most Standard Definition (SD) digital camcorders, uses the recommended resolution of 720x480/576, but uses the entire width of the frame for the picture. When using DV as a source for other formats that respect the ITU-R BT.601 specifications with regard to line length it may be desirable to resize to match the active area of your TV's picture and add borders to the sides.

-----------------------
08j
.very primitive crop-only mode (wip), not very usefull right now, only thing it really does is;
$target_requested_width = $source_sampling_matrix_width
- $crop_L - $crop_R;
$destination_aspect_ratio = $source_aspect_ratio;
.AR suggestions are now displayed as numbered list

smok3

8th May 2008, 23:43

09
.aftercrop resolution (in avisynth display textarea) now includes the number in pixels which suggest how much would a crop need to be modified to be modN friendly (previous idea about crop-only mode was rejected) - trying to keep things simple.

example, if you get something like this:
Crop(0,0,-0,-0) # 1280x1080(-8px)
that would mean that you need to crop height for additional 8 pixels (if you need modN cropping that is...)

.different behaviour: if requested width is undefined, then it equals sampling matrix width

(not tested very much)

Adub

10th May 2008, 00:58

Okay, so I am new to the whole anamorphic encoding thing.

I am in the process of backing up my Pirates of the Caribbean: Dead Man's Chest NTSC DVD.

I noticed that there were black bars on the top and bottom. If I cropped 62 pixels off of both the top and bottom, I got rid of all remnants of black bars.

Now, I want to store this on my computer for archival purposes and viewing. So, I assume, I want my new PAR to be square, or 1:1.

So, I went to your calculator, smok3, and punched in my res and crop settings. It recommended this:

# resizeCalc
# pixels = 207360, DAR error = 0.023
# Crop(Left, top, -right, -Bottom)
Crop(0,65,-0,-65) # 720x350(-2px)
LanczosResize(720,288) # (mod16)

Now, this looks funny to me, but if I understand anamorphic encoding correctly, it is supposed to. So, my question is, if I add those settings to my script, encode, and then mux with mkvmerge, I should set the AR flag to be 16:9?

krosswindz

10th May 2008, 04:25

Adub

10th May 2008, 05:17

Wait a sec. Aren't you just talking about the PAR? I am pretty sure that the flag that I set in MKVMerge is supposed to be the DAR, which I sure as hell don't want to be 1:1.

SeeMoreDigital

10th May 2008, 08:31

Hi Merlin7777,

By my calculations the movie aspect ratio of your (Pirates of the Caribbean: Dead Man's Chest NTSC DVD) source, after cropping is: -

16÷9 x ((720÷720) ÷ (356÷480)) = 2.397003745

If you want to generate a "non-square" (aka: anamorphic) pixel encode, your nearest mod-16 pixel frame size height would be 352

352 x 2.397003745 gives you a "square pixel" frame width of 843.7453182
843.7453182 ÷ 720 gives you a "non-square" aspect ratio signalling value of 1.171868498 or 75:64

So you need to generate your "non-square" encode at 720x352 pixels with aspect ratio signalling value 75:64

Easy in it....

EDIT: For "quickly" working out calculations such as: 16÷9 x ((720÷720) ÷ (356÷480)), just feed them into Google's "seach box". Like this (http://www.google.com/search?hl=en&q=16%C3%B79+x+%28%28720%C3%B7720%29+%C3%B7+%28356%C3%B7480%29%29&btnG=Google+Search). Then, to convert the "decimal" into a "fraction" use this web site: http://www.mindspring.com/~alanh/fracs.html

Adub

10th May 2008, 09:19

Okay, so let me get this straight. When I am dealing with anamorphic material, I should only crop to get rid of the black bars, and resize to reach the closest mod-16 resolution.

Then, I perform the math that SeeMoreDigital just did, and this should tell me what I should place into the MKVMerge "Aspect Ratio" box.

Is that correct?

So, first I find my MAR. I then multiply this by the closest mod-16 height value to get my "square pixel" frame width. If I divide this width by my "old" width, I get my ARS value.

I am slowly starting to get it. So you basically encode the main video content, removing all black bars, and modifying your source as little as possible. Then, in order to achieve a "square pixel" final output, you just enter the ARS into MKVMerge, and you are good to go.

I think I have it know. If I am wrong tell me. This is very interesting stuff. In addition, is there a proper guide to the math as stated above by SeeMoreDigital?

SeeMoreDigital

10th May 2008, 09:55

Sounds about right to me...

Personally I don't generate MKV muxes, so I'm not sure at what stage MKVMerge detects and places the aspect ratio signalling within the MKV container.

It looks as though you can either manually enter the "width/height" of your output encode. Or MKVMerge can pull-in the aspect ratio signalling information from within the MPEG-4 (in .AVI or .MP4) stream.

Here's and example: -

http://www.mediafire.com/?ndzyeegi1jw

smok3

10th May 2008, 13:00

if you need to just crop to mod16, then
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.215&sar2=1.18519&ssmh=480&CT=64&CL=&CR=&CB=64&trw=720&dar=1&dar2=&mod=&padw=&padh=&css=&doit=true
(adding 4px to the height to get out with mod16 resolution after crop, ignoring the resizer and like smd said, you would flag your video accordingly, in my example DAR=2.424)

Crop(0,64,-0,-64) # 720x352

krosswindz

10th May 2008, 15:26

I noticed that there were black bars on the top and bottom. If I cropped 62 pixels off of both the top and bottom, I got rid of all remnants of black bars.

# resizeCalc
# pixels = 207360, DAR error = 0.023
# Crop(Left, top, -right, -Bottom)
Crop(0,65,-0,-65) # 720x350(-2px)
LanczosResize(720,288) # (mod16)

What I quite dont understand is what is your final crop value? is it 62 or 65 (which could be mean either 64/66 for mod2).

Adub

10th May 2008, 18:17

Okay, so that script that I posted above was calculated by smok3's resize calculator.

I entered in that I cropped off 62 pixels from the top and the bottom. I set my source to NTSC Wide and my desired to Square. I then clicked calculate. By reading the comments on the bottom of the calculator, below the script, I arrived at the script I posted.

You can do it yourself if you are still confused.

Edit: Okay, so I looked at the MKVMerge documentation, and it looks like I will be putting in the MAR into the gui box. Or I could specify the exact dimensions if I wanted to. In the cli version there are 3 flags dealing with aspect ratio:

−−display−dimensions <TID:widthxheight>

Matroska files contain two values that set the display properties that a player should scale the image on playback to: display width and display height. These values can be set with this option, e.g. ’1:640x480’.
Another way to specify the values is to use the −−aspect−ratio or the −−aspect−ratio−factor option (see below). These options are mutually exclusive.

−−aspect−ratio <TID:ar|w/h>

Matroska files contain two values that set the display properties that a player should scale the image on playback to: display width and display height. With this option mkvmerge will automatically calculate the display width and display height based on the image’s original width and height and the aspect ratio given with this option. The ratio can be given either as a floating point number or as ´width/height’, e.g. 16/9.

−−aspect−ratio−factor <TID:ar|w/h>

Another way to set the aspect ratio is to specify a factor. The original aspect ratio is first multiplied with this factor and used as the target aspect ratio afterwards.
Another way to specify the values is to use the −−aspect−ratio option (see above). These options are mutually exclusive.

It looks like I would put in my ARS into the aspect ratio factor, or my MAR (or is it DAR?) into the aspect ratio, or my desired hight and width into the display dimensions.

Is this right?

Edit2: Also, SeeMoreDigital, your encodes kept saying a "non-square" pixel width of "foo". But I thought I wanted square pixels. Don't I encode using non-square pixels and then set the display size in mkvmerge so that I actually have square pixels. I thought that was the whole point in the beginning.

smok3

10th May 2008, 20:53

square pixels and anamorphic encoding are two different poles: you need non-square pixels for something to be called anamorphic (so what you end up, hopefully is something with correct display aspect ratio, but with non-square pixels).

MAR is something invented by SeeMoreDigital as it seems :)

p.s. the calc is linkable, so instead of providing what was printed out, just paste the url next time.

Adub

10th May 2008, 21:46

Oh, okay. And I will post a link to the calc next time.

krosswindz

10th May 2008, 22:40

MAR is something invented by SeeMoreDigital as it seems :)

Are'nt we back to who edited Wikipedia to change it :p

SeeMoreDigital

11th May 2008, 11:04

Are'nt we back to who edited Wikipedia to change it :pLol...

This is why hate three-letter acronyms. And why I especially don't like using the terms DAR, PAR and SAR and prefer to use the phrase Aspect Ratio Signalling instead.

When I concieved my own little application (ie: Aspect Ratio Signalling Calculator, way back in Xmas 2005) I did indeed elect to use the following terms: -

MAR = Movie Aspect Ratio - Refers to the aspect ratio of the movie. After cropping away all the black mattes. Which (as we all know) often does not match the aspect ratio of the movie stated on the back of the DVD cover.

PFS = Pixel Frame Size - Refers to the resolution of your encode in width pixels and height pixels.

ARS = Aspect Ratio Signalling - Refers to the aspect ratio signalling level that's needed to change (or distort) the shape of a "square pixel" to a "non-square" pixel.

unskinnyboy

11th May 2008, 15:32

MAR = Movie Aspect Ratio - Refers to the aspect ratio of the movie. After cropping away all the black mattes. Which (as we all know) often does not match the aspect ratio of the movie stated on the back of the DVD cover.I think we do need a term called MAR, because in between all the SAR-PAR-DAR malarkey, we never actually defined a term which would refer to the actual AR of the movie on the DVD! Which, like you said, can sometimes differ from what's on the box and what's on Amazon.com. In the olden days, due to the lack of a better word, I've tried to refer to MAR by using words like theatrical AR, source AR etc., but I've realized that they could cause confusion and because strictly speaking, they are probably incorrect. Theatrical AR is X.YY:1 doesn't mean that the MAR would be the same, thanks to the not-so-uncommon DVD transfer flaws. Not to mention that the MAR of the theatrical version of the movie could be different from the MAR of the DC, which in turn could be different from the Ultimate Edition DVD release, and so on :rolleyes:. Source AR could cause confusion in that it sounds like I am referring to the DVD DAR.

SMD, since I concur with you on MAR, if we could go and throw it around in the future AR related threads (there will be many more, I'm sure), sooner or later, we can make this part of the standard encoder's lexicon. :p

PFS = Pixel Frame Size - Refers to the resolution of your encode in width pixels and height pixels.This, I don't think we need. Storage Aspect Ratio (SAR) sounds just fine to me, although, deep inside, I've always wished it had been called FAR (Frame Aspect Ratio) instead. Oh well...

ARS = Aspect Ratio Signalling - Refers to the aspect ratio signalling level that's needed to change (or distort) the shape of a "square pixel" to a "non-square" pixel.Hmm, you referring to DAR here? See, how confusing this can be? If you insist on using the word anyway, I demand that it be changed to "Aspect Ratio Signaling" instead - the American way.

J/K :devil:

krosswindz

11th May 2008, 16:15

MAR = Modified Aspect Ratio as defined here http://en.wikipedia.org/wiki/Aspect_ratio_(image)

now what do we call this as :p

We should probably have some form of terminology that we should come up with and sticky it somewhere.

unskinnyboy

11th May 2008, 16:34

From an encoder's perspective, the term Modified Aspect Ratio (MAR) has little or no bearing. If a WS movie was modified by Pan & Scan to FS, I wouldn't buy the DVD, let alone attempt to encode it. Open Matte DVDs aren't that common, and if available would take preference over a WS DVD of the same movie, for me.

smok3

12th May 2008, 07:59

instead of MAR, how about MORDAR? (movie original release DAR)? :p (at least it will be clear that the aspect ratio type is DAR), anyway, fix the wikipedia first.
p.s. anyway, since there seem to be no interest in simplifying and unifying the acronyms, i will invent few of mine as well, just to add to the confusion.

-----------------------
09a
.more PAR presets, changed the naming scheme to be more exact (and to add to the naming confusion)
.the result textarea is now editable
.small fixes here and there
.examples removed since they didn't follow the new naming scheme
.this version may break URL compatibility with older ones
.in IE it does look pretty damn borken, can't be bothered...

krosswindz

13th May 2008, 03:46

09a
.more PAR presets, changed the naming scheme to be more exact (and to add to the naming confusion)
.the result textarea is now editable
.small fixes here and there
.examples removed since they didn't follow the new naming scheme
.this version may break URL compatibility with older ones
.in IE it does look pretty damn borken, can't be bothered...

Probably a typo, I am not sure shouldnt PAL be 704 instead of 702 :confused:

krosswindz

13th May 2008, 03:57

@smok3 a suggestion, if we choose PAL (704/720) or PAL Wide (704/720), cant the source matrix size be fixed to 704x576 or 720x576. Similarly for NTSC too.

smok3

13th May 2008, 08:16

702 is a bit closer to the truth, but one can easily use 704 (basically 704 is the closest mod16 number) with very small error for the same standard.

edit2: at least, thats what i figured yesterday, not so sure today :)

edit: note that the math done by the calc is a bit simplified.

---
edit3:
cant the source matrix size be fixed
what if you have cropped anamorphic encode as input? (but yes, i see that some other calcs are doing it that way for some reason..., here you would just do some bookmarks for the numbers you use often instead.)
p.s. actually crappy flexibility displayed in other calcs is the main reason i started this 'project'.

example: say you encoded something from PAL source and croped off the black borders; 576-64-64 = 448 (mod16) and now you would want to recode that into square pixels, then you would just start thinkering with something like;
http://somestuff.org/resizeCalc.php?ssmw=702&sar=1.094&sar2=&ssmh=448&CT=0&CL=0&CR=0&CB=0&trw=640&dar=1&dar2=&mod=16&padw=&padh=&css=&doit=true

example bookmark for PAL 702;
http://somestuff.org/resizeCalc.php?ssmw=702&sar=1.094&sar2=&ssmh=576&CT=0&CL=0&CR=0&CB=0&trw=&dar=1&dar2=&mod=&padw=&padh=&css=&doit=false
(change doit=true to doit=false in the url, and you would have just the input field defined)

SeeMoreDigital

13th May 2008, 08:19

702 is a bit closer to the truth, but one can easily use 704 with very small error for the same standard.Agreed :)

smok3

13th May 2008, 15:04

@smok3 a suggestion, if we choose PAL (704/720) or PAL Wide (704/720), cant the source matrix size be fixed to 704x576 or 720x576. Similarly for NTSC too.

on the 2nd thought, presets system could be implemented as (similar thing as presets in adobe after FX):
1st. select input preset which will populate PAR, width, height
2nd. let the user decide which part to keep by allowing to change each individual

but that would just blow up the GUI.

krosswindz

14th May 2008, 00:33

702 is a bit closer to the truth, but one can easily use 704 (basically 704 is the closest mod16 number) with very small error for the same standard.

edit2: at least, thats what i figured yesterday, not so sure today :)

does this mean for NTSC it is 710/711 or whatever it is :confused:

edit: links would be useful to educate the uneducated like myself.

smok3

14th May 2008, 07:40

no, you would take the 'sampling matrix width';
http://lipas.uwasa.fi/~f76998/video/conversion/#conversion_table
(link is also on the calc)
---
edit:
demos for new versions will be @
http://resizecalc.somestuff.org
(edit2: redirection from old to new url is now active)
---
edit3:
cunning plan for a preset system without gui blowup (javascript-ish)
SOURCE
- If width&height are both empty when the PAR preset is choosen in pulldown, then javascript will fill in the width&height
- if only one of them is allready filled, then no changes are done
TARGET
- same, only applies to width, mod is independant anyway

comments?

krosswindz

15th May 2008, 01:57

no, you would take the 'sampling matrix width';
http://lipas.uwasa.fi/~f76998/video/conversion/#conversion_table
(link is also on the calc)

Reading the table we have the following.

NTSC : 704x480 or 720x480 actual picture is 711x486
PAL: 704x576 or 720x576 actual picture is 702x576

Now the question is we want to use the source sampling matrix and not the actual active picture matrix in the calculation, am I right about this?

smok3

15th May 2008, 08:47

krosswindz

15th May 2008, 14:43

i meant this one for PAL
702 576 13.5 128/117 52.00000 702 576 Y Active picture frame for 625/50 systems in ITU-R BT.601-4 pixels.

however there is only small difference if you take the 704 version (remember i'am trying to keep things simple, to actually implement entire ITU crap, there would be a lot more of this input fields - which no-one would know how to fill up anyway (including me)).

This one is for NTSC

711 486 13.5 4320/4739 52.66667 710.85 486 Y Active picture frame for 525/59.94 systems in ITU-R BT.601-4 pixels.

Does this mean for NTSC we should use 711x486 instead of 704/720x480. Unlike PAL, NTSC is neither here nor there.

Everything seems to get more confusing the more I read :(

smok3

15th May 2008, 19:59

krosswindz

16th May 2008, 05:30

just take (start with) sampling matrix width and PAR that goes with that, everything else is in 'analog' domain, at least that way you will have things simplified (you can safely ignore my naming convention if it is confusing, or suggest a better one....).

I just use what the frame size of the source, I have seen only NTSC source, not PAL

for NTSC I just use NTSC (704), NTSC (720), NTSC Wide (704) and NTSC Wide (720), I guess it would be similar for PAL to as PAL (704), PAL (720), PAL Wide (704) and PAL Wide (720).

These are what one sees in softwares like dgindex etc.

smok3

16th May 2008, 08:51

and the calc got 500 'unique' hits just now, seems to be quite usefull :)

smok3

16th May 2008, 10:55

These are what one sees in softwares like dgindex etc
really? from dgindex docs;

MPEG2:
(1:1)
(4:3)
(16:9)
(2.21:1)
http://neuron2.net/dgmpgdec/DGIndexManual.html

krosswindz

16th May 2008, 23:45

really? from dgindex docs;

http://neuron2.net/dgmpgdec/DGIndexManual.html

http://neuron2.net/dgmpgdec/DGIndexManual.html#InformationPanel

Frame size is displayed here which is either 704x480/720x480/704x576/720x576

Aspect ratio tells you if it is 4:3/16:9

This is when using a DVD vob files.

Video type shows you if its NTSC/PAL

smok3

19th May 2008, 09:50

krosswindz; will go thought it (again) when i find some time...

edit: 704x480 and 711x486 are pretty close thought, so you can pick any as your starting point
http://resizecalc.somestuff.org/index.php?ssmw=704&sar=0.911&sar2=&ssmh=480&CT=&CL=&CR=&CB=&trw=712&dar=0.911&dar2=&mod=2&padw=&padh=&css=&doit=true

edit2: again, 704 is popular, since it is mod16 and in ntsc case seems to be very close to the truth.

krosswindz

20th May 2008, 22:28

smok3

31st May 2008, 12:52

1000 unique hits and no beer? wow, hard life as OS 'developer' :p

09b
.changed default.css to overcome new ff3 behavior where input boxes don't have priority anymore when overlapped with textual elements

mikeytown2

6th June 2008, 21:52

todo
- change the avisynth display as a 2nd option, to be mod(1) friendly as described here (should i?):
http://forum.doom9.org/showthread.php?s=&threadid=91630

I have a function that uses sub pixel accurate resize, as is described in that thread (V2), with the added benefit of setting the Source DAR & target DAR, and choosing to crop or add borders.
http://forum.doom9.org/showthread.php?p=1111789#post1111789.

Thought you guys would be interested in this.

Edit:
Example

a = AVISource("dvNTSC.avi").SeparateFields().SelectEven() #Load DV, Fast Deinterlace

ZoomBox(a, 720,480, SourceDAR=720.0/528.0, TargetDAR=16.0/9.0, Align=-5)#add borders
last + ZoomBox(a, 720,480, SourceDAR=720.0/528.0, TargetDAR=16.0/9.0, Align=5)#crop

NTSC DV source 15/11, going to anamorphic widescreen DVD 16/9

smok3

7th June 2008, 11:48

mikeytown2, interesting yes, what are the pros/cons as compared to non-subpixel method? (speed?, complexity?, ect)

mikeytown2

7th June 2008, 12:18

Short answer
Speed: slightly slower then doing it "by hand". (very minor)
Complexity: less complex then doing it "by hand".
Quality: when adding borders to a clip, there will no be hard edges, on the other hand there is no AR error. When cropping, this is the best way to go.
Interlaced: haven't played around with this since my projects so far have been for the web.

Long Answer
There is a slight speed hit, since it does a lot of arithmetic. When Cropping to fit, only a single resize function touches the clip. When adding borders I have to use AddBorders() and then do the single resize function. In both cases the resizer is dealing with more pixels then doing it "by hand", thus the resize is slightly slower.
I'm assuming complexity is referring to the scripts complexity, and the math involved. My code makes it much easier to change input sizes and output sizes. In the above example we are dealing with 4 different AR ratios. I changed the PixelAR of the DV clip without having to change the ZoomBox code, which is nice. If I want the target to be 4/3 DVD all i need to do is set TargetDAR=4.0/3.0. If the Source/Target DAR is not set then it assumes square pixels, so in this case 3/2 (720x480).

smok3

7th June 2008, 19:00

do 'we' have an autocrop (removal of black borders) feature hidden somewhere as well?

mikeytown2

7th June 2008, 19:06

do 'we' have an autocrop (removal of black borders) feature hidden somewhere as well?

no, there is no edge detection, but if you know the clips original dimension, it will act like it knows. So yeah you could say it's a hidden feature...

a = ColorBars().Trim(0,-1).AddBorders(100, 0, 100, 0)
ZoomBox(a, 640,480, align=5)
b = ColorBars().Trim(0,-1).AddBorders(0, 100, 0, 100)
last + ZoomBox(b, 640,480, align=5)
last + ColorBars().Trim(0,-1)

smok3

23rd July 2008, 22:16

09f
.slight default.css changes
(looks almost good in IE now as well, remaining IE-only problems:
- pulldown selectors are still cliped
- resolution labels are non-responsive, sometimes double-clicking will work, sometimes not, this could be fixed with some better js i guess) fixed!, (thanks to people on dalnet/#javascript)

Other browsers retested
- FF 3
- opera
- safari
- lynx nix
- lynx win

Analog browser pie for jul08
http://blog.somestuff.org/images/browsers_resizecalc.png
(obviously msnbot should not be there)

----------

10
.echo mplayer command line

10b
.mplayer style cropping (width:height:left:top) - This is pretty dumb right now, will need some better input checking. Also if Left and Top are undefined then it should center the crop automagically.

10c
.favicon.png

smok3

6th September 2008, 16:47

4000 hits and i'am still thirsty :)

krosswindz

9th September 2008, 03:52

^ does the thirst ever end :p

smok3

5th October 2008, 11:31

i guess not, still thirsty with 5000 hits :P

krosswindz

17th December 2008, 16:48

@smok3 just a suggestion, how about having different mod values for width and height. Both defaulting to 16 if nothing is specified.

smok3

22nd December 2008, 12:54

i'am totally bad with time, can you do it?

krosswindz

23rd December 2008, 20:45

i'am totally bad with time, can you do it?

I made some modifications to index.php with what I think should work. You might want to code review it before updating it. You would have to look at the aesthetics as well :p

I am attaching a patch file with the differences. Hope the changes I did are the correct one.

smok3

25th December 2008, 19:21

i think this patch is reverse of what it should be?

-$modw = $_GET['modw'];
-$modh = $_GET['modh'];
+$mod = $_GET['mod'];

just post the new index.php.

krosswindz

26th December 2008, 17:32

i think this patch is reverse of what it should be?

-$modw = $_GET['modw'];
-$modh = $_GET['modh'];
+$mod = $_GET['mod'];

just post the new index.php.

I used diff to create the patch file, basically gives the differences between the two files - ->lines in new file and + -> lines in old file. I should created the diff file swapping the. I am attaching the index.php itself.

You might have to work a bit on the aesthetics of the page ;) I am sure my modification breaks it.

smok3

27th December 2008, 11:17

what i think is missing is:

- compatibility with old mod system (old urls must still work, so there need to be some sort of patching from old mod to modw and modh), like

if mod = somevalueotherthanNull then
modw = mod
modh = mod

here is a diff right now:

http://resizecalc.pastebin.com/pastebin.php?diff=f7779fc5b

alpha demo: current state, krosswindz edition, for testing only;
http://resizecalc.somestuff.org/alpha/
(I will fix html later when all the logic is ok)

krosswindz

28th December 2008, 17:30

^ very true, I do understand the compatibility with previous urls.

I think the following changes should help. Not sure about the php syntax though

replace lines 311-312 with

if (!empty($mod)) { $modw = $mod; $modh = $mod; }
if (empty($modw)) { $modw = 16; }
if (empty($modh)) { $modh = 16; }

I updated the pastebin (which I figured after making a new post :o). I also added a line to ask people to update their bookmarks (if mod = somevalueotherthanNULL)

the diff is here: http://resizecalc.pastebin.com/pastebin.php?diff=f50b678e4

smok3

29th December 2008, 11:54

ok, pastebin is giving me some problems, so next alpha sources are here;
http://somestuff.org/downloads/resizeCalc_php/alpha/
demo, same link
http://resizecalc.somestuff.org/alpha/

changes:
- urls should be backward compatible (hopefully) - also this should be transparent for the user, no need to echo warnings imho.
- some html for the new modh, modw

krosswindz

29th December 2008, 16:21

^ I just clicked on the example on PAL (702) to square mod(1) resizing it seems to work without any problems :). There is only one issue being that we need to get 1 printed for mod w & h like before.

smok3

29th December 2008, 16:59

yes, i will change the example (if you mean that?), any other issues?

krosswindz

30th December 2008, 00:47

yes, i will change the example (if you mean that?), any other issues?

I wasnt suggesting changing the example. It was more like when you click on the link which only suppors mod and now mod w & mod h you can see the value of mod being displayed. It would be nice if we could some thing similar to it is what I meant to display the values of modw and modh which we have taken from the value of mod.

smok3

30th December 2008, 16:40

that would mean the rewrite of the whole 1st part, so no.
New 'release' is now on the default url.

11
.krosswindz's modh, modw
.fixed the example and add one more :P

11a
.changelog will be from now on included with sources as neat little - changelog.txt

p.s. i never use the mplayer code, so this will be removed in next release (complain here if you do mind).

krosswindz

30th December 2008, 17:20

:thanks: html does look much better.

smok3

10th February 2009, 23:59

windows standalone version (wapache stuff)
request it
(only tested with win xp)

install/run
1. unpack to some dir
2. run resizeCalc.exe

krosswindz

11th February 2009, 18:17

^ :thanks: wicked :p

smok3

9th April 2009, 11:58

10000 hits! :P

krosswindz

10th April 2009, 15:28

^ congrats :p

b66pak

12th May 2010, 22:49

windows standalone version (wapache stuff)
request it
(only tested with win xp)

install/run
1. unpack to some dir
2. run resizeCalc.exe

is this still available?...i don't find the link (on the first page)...
_

smok3

21st May 2010, 20:06

b66pak: link is in your pm.

b66pak

21st May 2010, 20:20

thanks a lot...
_

Nightshiver

22nd May 2010, 02:03

Could I have the link as well? The old hasn't been working for me for months, and I didn't know if you were still working on it or if the site had just gone done for some other reason.

Guest

22nd May 2010, 02:10

Could it be this:

http://smok3.t35.com/resize/

smok3, if you didn't want that public let me know and I will nuke my post.

smok3

24th May 2010, 06:14

the two working mirrors are in the 1st post (the section named 'running at').
edit: wapache = windows.exe version also reuploaded, see 1st post.

smok3

7th April 2011, 09:38

have managed to get it running at sourceforge, hopefully this will be a bit more faster/permanent, see 1st post for url :)

smok3

2nd August 2011, 17:04

beta15 now online (reports "human DAR"), see 1st post for url.

b66pak

4th August 2011, 20:40

thanks a lot...
_

smok3

5th August 2011, 15:26

thanks a lot...
_

your welcome ...

btw,
the new human DAR display is now 'fully' integrated.
One usable feature would be to display that DAR after pad/crop as well, but i haven't found time yet to do that. Meantime any bug reports are welcome (for this beta). Source code is also there (link in the 1st post + usual ugliness warning).

asteri

18th March 2014, 19:06

Hello,

I need help with correct settings for ResizeCalc. I am confused about set proper option in Source - PAR.

In what cases should i use PAL(702) vs. PAL(720) and PAL wide (702) vs. PAL wide (720) ?

I encoding mainly HD content where is simple calculate corect resolution but with this old staff I am not sure.

Thanks to anyone for explanation

smok3

20th March 2014, 12:22

@asteri, some good reading;
http://lipas.uwasa.fi/~f76998/video/conversion

asteri

2nd April 2014, 11:00

@asteri, some good reading;
http://lipas.uwasa.fi/~f76998/video/conversion

Hi, I have read it but I am not sure. If I have source PAL 720x576 should I always choose PAR 720 or sometimes 702? Can you please check these few examples (7 pictures) and tell me correct source PAR setting?

Thank you

http://s30.postimg.org/y8v1bmxct/image.png (http://postimg.org/image/y8v1bmxct/)http://s30.postimg.org/3xxh0x8il/image.png (http://postimg.org/image/3xxh0x8il/)http://s30.postimg.org/cl6316wyl/image.png (http://postimg.org/image/cl6316wyl/)http://s30.postimg.org/nol3t1sv1/image.png (http://postimg.org/image/nol3t1sv1/)http://s30.postimg.org/kggmg06l9/image.png (http://postimg.org/image/kggmg06l9/)http://s30.postimg.org/nei6ng3ml/image.png (http://postimg.org/image/nei6ng3ml/)http://s30.postimg.org/os5850di5/image.png (http://postimg.org/image/os5850di5/)

smok3

2nd April 2014, 11:26

asteri; Seriously in this point in time I would consider SD something not really worth wasting a lot of time with, i'd just use something like

http://resizecalc.sourceforge.net/index.php?ssmw=720&sar=1.459&sar2=&ssmh=576&CT=2&CL=8&CR=8&CB=2&mplayCrop=&trw=&dar=1&dar2=&modw=&modh=&padw=&padh=&css=&doit=true

for everything and be done with it.

Actually I wouldn't scale it at all, just use 16:9 DAR or PAR while transcoding.

Btw; how did you get national geo / discovery to be so stupidly interlaced?

asteri

2nd April 2014, 13:27

I know SD is dead, but some old movies still need do from SD source, so I would welcome to know how to choose PAR properly. Just for the info, the first example is not WS so use 16:9 generally is not good choice.
So should I choose 702 (PAL/PAL wide) instead of 720? Why? Because of cropping a lot pixels of the borders? So if I am cropping for example more then 8 8 (L R) then should I use 702 for calculation instead of 720?

About interlacing NatGeo and Discovery. It is not question for me. My TV broadcast provider use this method. NatGeoHD and Discovery HD are ok, but there are another tv shows so I cant capture from HD :/