Need your help with first anamorphic encode

[DigitalDivide]

Hi,

I'm encoding my first movie using anamorphic resizing. Howver after reading everything on the forum, I think I'm more confused than ever. So I'm looking for someone to help me out to endode the following movie. I have Red Eye, it's 2:40 Anamorphic, NTSC. I'm using MeGUI, to mkv.

So step 1 go to Tools, AviSynth Script Creator, select my project file.
For Input DAR, I select Custom and do I enter in 2:35?
Check REtain anamorphic resolution and set SAR in Encoder.
AVS Profile just keep at Default?
Click Autocrop, which gives me 60 off the top and 66 off the bottom and 2 off the right.
Go to Output Resolution and select ?? 720?
Resize Filter, not sure what to select here but how about Bicubic Neatrual?
Leave Deinterlace and Noise Filter unchecked.
Mpeg2 Deblocking unchecked.
Do I need Colour Correction checked?

Is that it? I noticed that when I select the Edit tab, it says to "# Set SAR in encoder to 720 : 627"
So now I go to Video and select the AviSynth script, set the output file, set it to mkv.
For Codec set to AVC and here's where I select config and enter in 720:627 for SAR in the Advanced Tab? Is the 627 right?

FYI I usually encode all my movies to about 2GB for a full 2hr movie with the AC3 track.

So do I have this right?

[berrinam]

2:40 Anamorphic, NTSC.
...
For Input DAR, I select Custom and do I enter in 2:35?
Do you mean 1:2.35? You aren't allowed to enter : in the custom section.

Check REtain anamorphic resolution and set SAR in Encoder.
AVS Profile just keep at Default?
Click Autocrop, which gives me 60 off the top and 66 off the bottom and 2 off the right.
Go to Output Resolution and select ?? 720?
Resize Filter, not sure what to select here but how about Bicubic Neatrual?
Leave Deinterlace and Noise Filter unchecked.
Mpeg2 Deblocking unchecked.
Do I need Colour Correction checked?
A general rule which will get you through quite well: If you don't know whether you should use somethng, leave it at its default value. Anyway, your settings seem fine.

So now I go to Video and select the AviSynth script, set the output file, set it to mkv.
For Codec set to AVC and here's where I select config and enter in 720:627 for SAR in the Advanced Tab? Is the 627 right?Well, if you had checked 'On Save Close and Load to be encoded' in the AviSynth window, you shouldn't have needed to do this. But yes, your settings are right here, as well.

So do I have this right?Yes. But just to make sure, why don't you encode a small sample and see whether it is right. To encode just a little bit, add
trim(0,5000)
to the end of your AviSynth script. You can change the numbers to whatever you want, of course, but the first number is the starting frame number, and the second number is the finishing number.

[DigitalDivide]

Thanks good to know I have the process down. When I select custom, the 2:35 shows in the box automically. So I guess that's right.

Just curious can I trust the Edit page where it suggests to use
"# Set SAR in encoder to 720 : 627"? Is it usually right?

Also if my movie is 1:85:1 aspect ratio what do I select in the Input DAR, simply 16:9?

[berrinam]

Just curious can I trust the Edit page where it suggests to use
"# Set SAR in encoder to 720 : 627"? Is it usually right?Would it be in MeGUI if it wasn't usually right?:sly:

[DigitalDivide]

Would it be in MeGUI if it wasn't usually right?

lol just checking...the reason I ask is because I read so many posts about what to select which seemed kinda odd to me to worry about it if MeGUI already suggests the size.

Anyhow thanks for the input! Much appreciated.

[berrinam]

lol just checking...the reason I ask is because I read so many posts about what to select which seemed kinda odd to me to worry about it if MeGUI already suggests the size.Yes, it is odd.:D

Anyhow thanks for the input! Much appreciated.It's ok. Maybe you could even give something back by writing a guide based on your findings:sly:

[DigitalDivide]

Well I'm not there yet, I'm getting the following error when trying to encode

avis[error]: unsupported input format(DIB)
could not open input file d:\projects\Red Eye\Red Eye.avs.

I used the Avisynth Script Creator in MeGUI. It contains the following info.

LoadPlugin("C:\Program Files\GordianKnot\DGMPGDec\dgdecode.dll")
mpeg2source("D:\red.d2v")
ColorMatrix()
#deinterlace
crop(0,60,-2,-66)
LanczosResize(720,352)
Undot()

# Set SAR in encoder to 720 : 627

I usually use Gordian Knot to create my avisynth script then open it up with MeGUI. I've never had any problem. This is the first time I tried creating one using MeGUI. I checked the settings and the path is correct.

Edit: I get the following ouput using Gordia Knot. I noticed that the cropping and resizing are different.
# Created with Gordian Knot
#
# http://gknot.doom9.org

# PLUGINS
LoadPlugin("C:\Program Files\GordianKnot\DGMPGDec\DGDecode.dll")
LoadPlugin("C:\Program Files\GordianKnot\AviSynthPlugins\UnDot.dll")

# SOURCE
mpeg2source("D:\Projects\Red Eye.d2v")

# TRIM
#trim(startframe,endframe)

# IVTC
#Telecide(order=1,guide=1).Decimate()
# or use
#IVTC(44,11,95)
#GreedyHMA(1,0,4,0,0,0,0,0)

# DEINTERLACING (1)
#FieldDeinterlace()
#FieldDeinterlace(blend=false)
#TomsMoComp(1,5,1)

# DEINTERLACING (2)
#KernelDeInt(order=1,sharp=true)
# or maybe
#DGBob(order=1,mode=0)

# DEINTERLACING (3) - special requests
#GreedyHMA(1,0,0,0,0,0,0,0)
#Telecide()
#SeparateFields()

# CROPPING
crop(8,64,704,348)

# SUBTITLES
#VobSub("FileName")

# RESIZING
LanczosResize(672,272)

# DENOISING: choose one combination (or none)
Undot()

[berrinam]

Well I'm not there yet, I'm getting the following error when trying to encode

avis[error]: unsupported input format(DIB)
could not open input file d:\projects\Red Eye\Red Eye.avs.
It sounds like you are missing Undot.dll in your AviSynth plugins directory. You should take Undot.dll (located in C:\program files\gordianknot\avisynthplugins\undot.dll) and put it in the avisynth plugins dir (normally c:\program files\avisynth\plugins\)

Edit: I get the following ouput using Gordia Knot. I noticed that the cropping and resizing are different.Cropping is surprising, but resizing is expected: firstly, you are going to a different resolution, and secondly, you are doing anamorphic encoding.

[Daodan]

DigitalDivide, try using the following script (based on the crop settings you got from megui):

# PLUGINS
LoadPlugin("C:\Program Files\GordianKnot\DGMPGDec\DGDecode.dll")

# SOURCE
mpeg2source("D:\Projects\Red Eye.d2v")

# CROPPING
crop(0,60,-2,-66)

Encode this in megui (of course you can add other filters for denoising or smoothing like undot if you want) and save as mkv or mp4. Than after the encoding is finished open the file with mkvmergeGUI, select the video stream and at display width/height put 850/354 and remux under a different name.
I usually use this method because I get confused with those settings in megui. In case you don't understand how I got that aspect ratio, I explain it here: you take the resolution after cropping (in your case 718/354 (2.028)), you take the DAR of 1.77 of the original and the AR (1.5) and make the following calculus:
718/354(2.028).........x
720/480(1.5).....1.7777
and you get x. You multiply x with the height resolution and get 850/354 wich keeps the DAR and doesn't lose res by resizing. I hope I was clear (when I read it it confuses me). The resize settings in megui have no importance since you don't resize, that's the point of anamorphic display.
And one last advice: after the autocrop in megui or gknot you should crop a bit yourself to make the resulting height/width both multiples of 16. It helps compression (but don't leave any black borders).

[Benedikt]

-> I think it's important to note that you can (and you should) deactivate any resizing filters, because they may affect quality and speed. With anamorphic rips resizing is generally not necessary.

-> Also important is a little bit of "playing" with MeGUIs crop and resizing sliders, because there's some kind of bug in MeGUI: MeGUI only calculates the correct SAR if you adjust the resizing values at least once. Sometimes gives me rather odd results, if I don't change the resizing or cropping values a bit.

[DigitalDivide]

Hey all, thanks for the help. I will give this another try when I get home from work tonight.

[lenouch]

A "simple" question :

What is the difference between "Sample Aspect Ratio" set in x264 encoding and "Aspect ratio" set in MKV ?


Instead of applying 2 successives resize (one at encode and one at decode), why not setting encoding SAR is 1:1, and calculate the AR for display (stored in MKV container) ?

Example :
1) for a PAL DVD, native resolution (anamorphic) is 720x576
2) I perform a crop to remove black border : reso is 720x560

In this case, how should I set SAR in x264 and AspectRatio in Matroska ?
SAR=1:1 ?
AR=16/9 ?

Help, I'm very confuse about this ...:confused:

[Benedikt]

A "simple" question :

What is the difference between "Sample Aspect Ratio" set in x264 encoding and "Aspect ratio" set in MKV ?


Instead of applying 2 successives resize (one at encode and one at decode), why not setting encoding SAR is 1:1, and calculate the AR for display (stored in MKV container) ?

Example :
1) for a PAL DVD, native resolution (anamorphic) is 720x576
2) I perform a crop to remove black border : reso is 720x560

In this case, how should I set SAR in x264 and AspectRatio in Matroska ?
SAR=1:1 ?
AR=16/9 ?

Help, I'm very confuse about this ...:confused:
The SAR would be, I think 2.28571429 (=DAR*height/width)
The relevant SAR parameters for x264* would be 8960:6480. Or, some nicer values to fill in: 112:81.
Put that in the corresponding input boxes and you're fine.


*calculation: 720*16:560*9=1,382716...

[DigitalDivide]

I explain it here: you take the resolution after cropping (in your case 718/354 (2.028)), you take the DAR of 1.77 of the original and the AR (1.5) and make the following calculus:
718/354(2.028).........x
720/480(1.5).....1.7777
and you get x. You multiply x with the height resolution and get 850/354 wich keeps the DAR and doesn't lose res by resizing.

Okay you lost me here. I can see 718/354 = 2.028 and 720/480 = 1.5. The 1.777 I understand but when you say I get X and I should mulitply it with the height resolution and get 850/354 you lost me. As far as I can see I don't know what X... and I don't know what I'm muliplying it with to get 850/354....I feel dumb but honestly I don't see it...

[DigitalDivide]

It sounds like you are missing Undot.dll in your AviSynth plugins directory. You should take Undot.dll (located in C:\program files\gordianknot\avisynthplugins\undot.dll) and put it in the avisynth plugins dir (normally c:\program files\avisynth\plugins\)

Tried that but it gave me the same error. The only way I was able to get it was to create an AVS file from Gordian Knot, then modify the file. That works.

However I noticed the following locations for the file.
C:\Program Files\X264
C:\program files\avisynth 2.5\plugins
C:\program files\gordianknot\avisynthplugins
c:\program files\godianknot\dgmpgdec
Not really sure which I should be using but I tried putting the settings to c:\program files\avisynth 2.5\plugins and it still didn't work.

[berrinam]

Ok, here's the standard thing you do when an avisynth script doesn't load: open it with VirtualDubMod. It will tell you what the error is (almost all of the time), and then you can go about remedying it. I was just making a guess, but it seems it didn't work.

[DigitalDivide]

Okay figured out the error. I had two project files and it was looking for the wrong one.

I fnished encoding a small test. To be honest I don't see any difference between it using the SAR and the same movie I encoded without the SAR. Should I be able to see a difference?

[lenouch]

The SAR would be, I think 2.28571429 (=DAR*height/width)
The relevant SAR parameters for x264* would be 8960:6480. Or, some nicer values to fill in: 112:81.
Put that in the corresponding input boxes and you're fine.


*calculation: 720*16:560*9=1,382716...

Ok. So, I have to enter SAR=8960:6480 in meGui.

1) From a technical point-of-view, is SAR just a flag in the encoded stream or is there an internal resize in x264 before encoding ?

2) In this case (SAR=8960:6480), what is the value I have to enter as DAR ? 16:9 again, or 1:1 because AR is "managed" in x264 stream ?

This is definitly confuse for me :(

[Daodan]

Okay you lost me here. I can see 718/354 = 2.028 and 720/480 = 1.5. The 1.777 I understand but when you say I get X and I should mulitply it with the height resolution and get 850/354 you lost me. As far as I can see I don't know what X... and I don't know what I'm muliplying it with to get 850/354....I feel dumb but honestly I don't see it...

That X is the display aspect ratio of your encoded movie (2.4 in your case). You should be able to see an increase in the image quality (if you use a high enough bitrate, otherwise that extra resolution will only lead to blocking). At least in PAL dvds the difference is very clear (but here the loss of height resolution is much bigger at resizing than in the case of NTSC). Of course this anamorphic thing was made mostly for widescreens but in the case of monitors the resolution is big enough to take advantege of this even if they aren't widescreen.

Ok. So, I have to enter SAR=8960:6480 in meGui.

1) From a technical point-of-view, is SAR just a flag in the encoded stream or is there an internal resize in x264 before encoding ?

2) In this case (SAR=8960:6480), what is the value I have to enter as DAR ? 16:9 again, or 1:1 because AR is "managed" in x264 stream ?

Yes, it's just a flag, otherwise this hole anamorphic thing would be almost pointless. Let's say you have a PAL dvd with no borders in 16:9. To keep the hole details you should resize to the enourmous size of 1020/576 wich would take a lot to encode and a lot to decode. In case of anamorphic the decoded resolution is 720/576.
For question number 2 I'm not sure what you mean, you use either SAR OR DAR because they are related (height/width=SAR/DAR). (As I said before, it's less confusing if you just enter the DAR in matroska muxer after making an encode without resizing).

[lenouch]

Thanks, it's more clear for me :)

In my case, anamorphic resolution is 720x576 => DAR is (576x16)/(720x9) = 9216/6480 = 64/45 = 1.422

Then, according to your last sentence, it's not necessary to modify SAR in x264 encoding (keep 1:1), but I have to set 64/45 (in mkvmerge. Fine ?

In this case, decoder will decode my movie as 720x576, but will stretch it to display as (720*1.422) x 576 = 1024 x 576. Is that right ?

[Daodan]

Hmm, it looks right but it's somehow wrong. Let's try and keep it simple, lets' forget about SAR and use only DAR.
So you don't have any cropping so in your case is simple, you know that your final image should be 16:9 (1.77). Just multiply this to the height res and you get 1020. So put 1024/576 in mkvmerge and that's it. If you put that 1.42 the image will be too vertically stretched. (1.42 is multiplied with the vertical resolution not the horizontal one).

[lenouch]

I made an attempt. That works:)

Your last explanation was clear and simple. Thanks

[Benedikt]

Hmm, it looks right but it's somehow wrong. Let's try and keep it simple, lets' forget about SAR and use only DAR.
So you don't have any cropping so in your case is simple, you know that your final image should be 16:9 (1.77). Just multiply this to the height res and you get 1020. So put 1024/576 in mkvmerge and that's it. If you put that 1.42 the image will be too vertically stretched. (1.42 is multiplied with the vertical resolution not the horizontal one).
What about just setting an aspect ratio of 16/9 in Matroska (mkvmerge)? At least that's what I'm doing and it works just fine! Isn't that easier?

[Daodan]

Well, now that you mention it, it is. I guess it's just a habit, since usually one has also to crop you have to recalculate the new resolution, so in that case it's easier to use the resolution.

[DigitalDivide]

I was able to encode Red Eye using the SAR of MeGUI and the suggested settings in MeGUI's Avisynth Script Creator and suggest SAR values. However when I used the same process to encode Reservoir Dogs the final output is ...not sure how to describe it...noisy/busy..very unwatchable. So I removed the SAR values from the config and tried again. This time it came out nice and clean. Not sure why?? Here's what I did.
Reservoir Dogs 2:35 anamorphic NTSC DVD.
- Input the d2v project
- Input DAR - Custom - 2:35
- Retain Anamorphic check box is ticked
- Auto Crop, which resulted in 56 off the top, 60 off the bottom, 2 both left and right.
- Output Resolution back to 720.

These are the values on the Edit tab
crop(2,56,-2,-60)
LanczosResize(720,368)
#denoise

# Set SAR in encoder to 720 : 599

I set the SAR in the AVC config to 720 and 599 and encoded the movie which as stated above came out horrible.

Any help would be appreciated as I have no idea why this didn't work.

[DigitalDivide]

DigitalDivide, try using the following script (based on the crop settings you got from megui):

# PLUGINS
LoadPlugin("C:\Program Files\GordianKnot\DGMPGDec\DGDecode.dll")

# SOURCE
mpeg2source("D:\Projects\Red Eye.d2v")

# CROPPING
crop(0,60,-2,-66)

Encode this in megui (of course you can add other filters for denoising or smoothing like undot if you want) and save as mkv or mp4. Than after the encoding is finished open the file with mkvmergeGUI, select the video stream and at display width/height put 850/354 and remux under a different name.
I usually use this method because I get confused with those settings in megui. In case you don't understand how I got that aspect ratio, I explain it here: you take the resolution after cropping (in your case 718/354 (2.028)), you take the DAR of 1.77 of the original and the AR (1.5) and make the following calculus:
718/354(2.028).........x
720/480(1.5).....1.7777
and you get x. You multiply x with the height resolution and get 850/354 wich keeps the DAR and doesn't lose res by resizing. I hope I was clear (when I read it it confuses me). The resize settings in megui have no importance since you don't resize, that's the point of anamorphic display.
And one last advice: after the autocrop in megui or gknot you should crop a bit yourself to make the resulting height/width both multiples of 16. It helps compression (but don't leave any black borders).
__________________

I also tried the method above but obviously using different numbers for the new movie. Same problem I don't get a clear picture. So what am I doing wrong?

[Daodan]

Hard to say what the problem is. Use ChopperXp to cut a little part of your vob and use the following script:

LoadPlugin("C:\Program Files\GordianKnot\DGMPGDec\dgdecode.dll")
LoadPlugin("C:\Program Files\GordianKnot\DGMPGDec\Undot.dll")mpeg2source("D:\something.d2v")
Undot()
# CROPPING
crop(8,64,-8,-64)

Without anything else (like resize). And than remux in mkvmerge using for video : 830/352. As I said before, it's best to have after cropping res that multiply by 16, but not that big. Anyway, try this and in case it turns bad also, upload somewhere the test vob and also the encoded results. (www.savefile.com lets you upload files smaller than 50 mb).

[iceborne]

Hard to say what the problem is. Use ChopperXp to cut a little part of your vob and use the following script:

LoadPlugin("C:\Program Files\GordianKnot\DGMPGDec\dgdecode.dll")
LoadPlugin("C:\Program Files\GordianKnot\DGMPGDec\Undot.dll")mpeg2source("D:\something.d2v")
Undot()
# CROPPING
crop(8,64,-8,-64)

Without anything else (like resize). And than remux in mkvmerge using for video : 830/352. As I said before, it's best to have after cropping res that multiply by 16, but not that big. Anyway, try this and in case it turns bad also, upload somewhere the test vob and also the encoded results. (www.savefile.com lets you upload files smaller than 50 mb).

so basically you're saying encode the video source in 1:1 dar then tell mkvmerge to output the file at 16:9?

[DigitalDivide]

I see it mentioned that resizing is not needed when doing anamorphic encodes, and yet when using MeGUI to create an avi script for anamorphic encodes, it does put in a LancosResize(x,y). Should this be removed or does MeGUI just ignore this?

I'm a little confused which DAR to select in MeGUI for the following
1.85 anamorphic - I'm assuming I should just select 16:9?
2:35 anamorphic - select custom and enter in 2:35
2:40 anamorphic - select custom and enter in 2:40
1.78 anamorphic - select custom and enter in 1:78
Fullscreen 4:3 movie ??

[MetalPhreak]

@DigitalDivide
I think you should remove the LanczosResize part and just crop to a mod16 resolution, although I don't think mod16 is a must - just better. Resizing might be prefferable if you cannot just crop without cropping away too much of the actual movie itself. (This is personal taste, you have to do it the way you prefer).
Now the SAR settings - you're making it too complicated. You don't have to worry about 1.85 vs 2:35 etc. (I think, don't trust me too much, wait for someone else to confirm before doing it). Just use the following and you should be set:
PAL 4:3 DAR = 16:15
PAL 16:9 DAR = 64:45
NTSC 4:3 DAR = 8:9
NTSC 16:9 DAR = 32:27
Note, I don't think these values are going to be accurate if you resize(difference should be negligible though)
(Just read that you're talking about DAR, but I assume since it's in MeGUI you meant SAR setting of x264?)

[Daodan]

so basically you're saying encode the video source in 1:1 dar then tell mkvmerge to output the file at 16:9?
Yes, that's almost what I'm saying, only in his case is not 16/9 anymore because he needed to crop the black borders, so 2.35.
DigitalDivide, the input DAR should be 16:9 in your case (so what the original dvd looks like, what dgindex tells you). So if you really don't want to use my method with mkvmerge but want to use SAR in x264, fine, this is what you should do: delete the resize from that avs, I'm not sure that megui afterwards will ignore it, I don't see any reason why, that resize will already give you the normal aspect ratio, so if you change also the SAR, it will look too flattened. So after you cut that line, load the avs, in x264 config put in sample aspect ratio 1.175:1. Now encode. Unfortunately I'm not able at the moment to test this (I never used this sar thing in x264, but always dar in mmg) but it should work.

[DigitalDivide]

Originally Posted by MetalPhreak
@DigitalDivide
I think you should remove the LanczosResize part and just crop to a mod16 resolution, although I don't think mod16 is a must - just better. Resizing might be prefferable if you cannot just crop without cropping away too much of the actual movie itself. (This is personal taste, you have to do it the way you prefer).
Now the SAR settings - you're making it too complicated. You don't have to worry about 1.85 vs 2:35 etc. (I think, don't trust me too much, wait for someone else to confirm before doing it). Just use the following and you should be set:
PAL 4:3 DAR = 16:15
PAL 16:9 DAR = 64:45
NTSC 4:3 DAR = 8:9
NTSC 16:9 DAR = 32:27
Note, I don't think these values are going to be accurate if you resize(difference should be negligible though)
(Just read that you're talking about DAR, but I assume since it's in MeGUI you meant SAR setting of x264?)

Actually I was referring to the DAR selection box in MeGUI which needs to be set when you use the avisynth script creator. You have to select an option from the drop down box. The choices in the box are 4:3, 16:9, 1:1, and Custom.
So when I have a DVD and use the avisynth script creator which DAR do I select for the following options?
1.85 anamorphic DVD- I'm assuming I should just select 16:9?
2:35 anamorphic DVD- select custom and enter in 2:35?
2:40 anamorphic DVD- select custom and enter in 2:40?
1.78 anamorphic DVD- select custom and enter in 1:78?

[Daodan]

If you read more carefully you should see right at the beginning:
"DigitalDivide, the input DAR should be 16:9 in your case (so what the original dvd looks like, what dgindex tells you when you preview the vob)"

[DigitalDivide]

If you read more carefully you should see right at the beginning:
"DigitalDivide, the input DAR should be 16:9 in your case (so what the original dvd looks like, what dgindex tells you when you preview the vob)"

So you are saying no matter what 1.85, 2.35, 2.40 if 16:9 then always select 16:9 DAR? Sorry if i need this spelled out but I just want to make sure.

Also the only reason I'm not really into using your method is really only because I want to configure this all in one shot, let it run overnight so when I come home it's all done. To be honest I'm still not exactly sure how to correctly work out the SAR. I've read a number of threads and still am totally confused. MeGUI makes it simple since it tells me what to input for SAR.

[Daodan]

First of all, yes, you put 16/9 no matter what (or 4/3 of course), I never saw an original DVD that wasn't either 16/9 or 4/3. (in case is not clear is about the DAR of INPUT so the original vob, before cropping, encoding or whatever)Second, I am unable to test the automatic creation of avs in the latest megui (the one using .net 2.0), because for some reason it crashes no matter what I do (when I try to make a d2v, when i try to load a d2v, etc). I have all the necessary things, and the megui using .net 1.1 works just fine, but that doesn't have the SAR settings and all.

[DigitalDivide]

Bond, can you confirm to me whether or not I need to include the resizelanzos(x,y) in the avisynth script when doing an anamorphic encode? It was mentioned that you don't need it however I noticed that the avisynth creator in MeGUI includes it when creating an anamorphic encode. So I'm not sure does MeGUI just ignore it, does it actually require it, or should I remove it?

[Daodan]

Ok, so i got it working finally. Here are my results: you were right about using 2.35 in that case, not 16/9 as I said. I think this part of megui still needs improvement, since this automatic sar stuff doesn't help much since you already have to calculate the dar yourself (what's one extra calculation?). The input dar should logically be 16/9, and based on the cropping you make it should calculate the SAR.
But it is not the case. So you still have to calculate the DAR you want for the final encode, put that in 'input dar', check 'retain anamorphic...', it SUGGESTS a resolution (usually something with horizontal res of 640), and after cropping and all that it sais in the avs what should you put in the SAR field in megui (the x264 config). You should note that somewhere, delete the resize line in the final avs, and use that resolution in the SAR field as said before (it doesn't matter if you changed the resolution, that SAR resolution it's an aspect ratio, not an actual resolution, so you can use it no matter if you resize or not). Now, you don't actually have to delete the resize, only if you WANT to, but usually the purpose of anamorphic is to keep the original resolution for maximum quality. If you use low bitrates it's still better to use nonanamorphic, resized. I hope it's now pretty clear.
As for the way that sar calculation is implemented I think I should write about it in the megui thread, it only confuses people and is not of real help either.

[mgh]

see
http://www.mir.com/DMG/aspect.html

[DigitalDivide]

Daodan,

I'm telling you this is getting more and more confusing. Here's what I did from the first page.
DVD 2.35 (maybe actually be 2.40 but not sure at the moment) NTSC
Went to Tools, AviSynth Script Creator, select my project file.
For Input DAR, I select Custom and entered in 2:35.
Checked "Retain anamorphic resolution and set SAR in Encoder."
AVS Profile kept at Default.
Click Autocrop, which gives me 60 off the top and 66 off the bottom and 2 off the right.
Then went to Output Resolution and bumped up the width back to 720 and it automatically sets the height to 354.

It then suggests to "# Set SAR in encoder to 720 : 627"

So my avisynth script I have
Lanzosresize(720,354)

And in the AVC config I set SAR to 720:627.

According to Berrinam, this was correct. I just want to confirm if this is correct? If not is there not a simple straight forward way to determine what the SAR should be if a movie is 2.35 or 1.85? I’m getting so confused I think I may forget about anamorphic encodes.

The other issue is if I have a movie that is 1:85 A/R, instead of selecting Custom 2.35 for DAR, do I instead select 16/9?

[berrinam]

DVD 2.35 (maybe actually be 2.40 but not sure at the moment) NTSC
Went to Tools, AviSynth Script Creator, select my project file.
For Input DAR, I select Custom and entered in 2:35.Ok, sorry that I might have given you incorrect instructions originally. I think Daodan may be right about this -- although your DVD plays as 2.35, the actual aspect ratio of it is 16:9, and it reaches 2.35:1 by adding black borders. So, in the AviSynth script creator, you should select 16:9, not custom.
Click Autocrop, which gives me 60 off the top and 66 off the bottom and 2 off the right.
Then went to Output Resolution and bumped up the width back to 720 and it automatically sets the height to 354.Doing the calculations by hand, this seems right:
Your video: 720x480
Cropping 60+66=126 from the height gives 480-126=354, which happens to already be mod16
Cropping 2 of the width gives 718, which is rounded to the nearest multiple of 16.

This is the bit which may have been affected by selecting the wrong input DAR:
It then suggests to "# Set SAR in encoder to 720 : 627"
Never worry, we can redo the calculations here, just so that everyone can see them and verify them:
Your video height is 354, so when you are displaying the video, you will want the width to be 2.35 times that (if you are convinced it is 2.40, do the same calculations just replacing 2.35 with 2.40)
So, display height = 354*2.35 = 831.9 = 832 (close enough)
So, when displaying it, we want to stretch the 720 pixels of width we currently have to fill the size of 832 pixels. This is where the SAR signalling comes in. Basically, you can look at SAR as the amount to stretch the pixels horizontally. So, the SAR should be 832 / 720, or 832 : 720
Disclaimer: this is just theory. Please check with a small sample before doing the whole encode, to see if I am right

So my avisynth script I have
Lanzosresize(720,354)So that's right

According to Berrinam, this was correct. I just want to confirm if this is correct?The best way to confirm is to make a short sample and see if it is.
If not is there not a simple straight forward way to determine what the SAR should be if a movie is 2.35 or 1.85? I’m getting so confused I think I may forget about anamorphic encodes.Yes, it is especially confusing because of all the different standards there are for signalling.

[DigitalDivide]

Your video height is 354, so when you are displaying the video, you will want the width to be 2.35 times that (if you are convinced it is 2.40, do the same calculations just replacing 2.35 with 2.40)
So, display height = 354*2.35 = 831.9 = 832 (close enough)

Shouldn't this read Display Width = 354*2.35 =832 not Display Height?

So, when displaying it, we want to stretch the 720 pixels of width we currently have to fill the size of 832 pixels. This is where the SAR signalling comes in. Basically, you can look at SAR as the amount to stretch the pixels horizontally. So, the SAR should be 832 / 720, or 832 : 720

Shouldn't this read 832:354? 720 was the original width not the height? Whenver I use MeGUI I've never had a SAR suggested where the width is greater than 720. When I Autocrop and then put the Width back to 720, MeGUI always has the SAR as 720:xx

Also I checked the log file and found the following in it.
Track 1 of 'D:\Projects\Red Eye\Red Eye.mkv': Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 844/352.

[berrinam]

Shouldn't this read Display Width = 354*2.35 =832 not Display Height?Yep, my bad.

Shouldn't this read 832:354?Nu-uh. Here's the simplest explanation as I see it, for SAR (which is DIFFERENT from DAR, PAR): SAR is really a fraction: SarX / SarY. The way the player treats this fraction is by multiplying it by the width (720) to get the display width. It leaves the height the same. If you think of it that way, you should see that my calculations are correct.

720 was the original width not the height? Whenver I use MeGUI I've never had a SAR suggested where the width is greater than 720. When I Autocrop and then put the Width back to 720, MeGUI always has the SAR as 720:xxYeah, I've started looking at MeGUI's AR handling again, and it seems to be quite wrong. It is perfect when there is no cropping, but it has some quite serious bugs when there is cropping, which messes it all up. I've rewritten its algorithm, and I am testing it at the moment. It seems to be giving the same results as my manual calculations, so I'm testing now to see whether they look right when they play back.

Also I checked the log file and found the following in it.
Track 1 of 'D:\Projects\Red Eye\Red Eye.mkv': Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 844/352.I'm not sure where that is a log from, but it seems correct, by the sound of it.

[DigitalDivide]

I'm not sure where that is a log from, but it seems correct, by the sound of it.

That was the MeGUI log file which resulted from my encode using the parameters on the first page. So even though I entered in the SAR on the first page as indicated, the log file indicates the Aspect Ratio as per above.

[berrinam]

That was the MeGUI log file which resulted from my encode using the parameters on the first page. So even though I entered in the SAR on the first page as indicated, the log file indicates the Aspect Ratio as per above.Of course, the important question is 'does it work'? But other than that, I'll just say -- wow, magic; it works when I didn't expect it to. Most bugs tend to be the other way round:D

[iceborne]

digitaldivide,
why is there a discrepancy between which display height you set. 354 or 352.
if its 352, then the sar given by megui (720/627) is the same ratio as 827*:720.

*calc -->352 height X 2.35 =827.

so i'm thinking there is nothing wrong with megui's sar suggestion. i've never ran into any ar bugs in all my encoding days

[Daodan]

As I already said, megui calculation of sar is (almost) useless since:
1.it confuses people with the input DAR (which should be 16/9 or 4/3 but instead it actually wants the output DAR (in DigitalDivide's case 2.35)), since rarely will be no cropping.
2.it doesn't actually help much since you already have to calculate DAR yourself so knowing the final resolution you have one extra calculation to make for the SAR (this is what actually megui does).
3.you're better off calculating the SAR or DAR yourself (SAR for input in the x264 config or DAR in mkvmerge).

[Wilbert]

I guess i need to install MeGui to see what it is doing, and tell doom9 to correct his gui. The reason is that the way you talk about DAR and SAR in this thread doesn't make any sense. For DAR you should have the choice between 1x1, 4x3 and 16x9. Other choices shouldn't exist. SAR or 'Sample Aspect Ratio' means PAR (at least when talking about AVC streams). Thus a selecting a SAR of 720xsomething when your final encoding should have a PAR of 1:1 doesn't make any sense.

[Daodan]

I guess i need to install MeGui to see what it is doing, and tell doom9 to correct his gui. The reason is that the way you talk about DAR and SAR in this thread doesn't make any sense. For DAR you should have the choice between 1x1, 4x3 and 16x9. Other choices shouldn't exist. SAR or 'Sample Aspect Ratio' means PAR (at least when talking about AVC streams). Thus a selecting a SAR of 720xsomething when your final encoding should have a PAR of 1:1 doesn't make any sense.
Fisrt of all I'm gonna ulpoad a bit of an anamorphic encode of mine that has a DAR of 1.88 (1.88:1) so different than 16/9, 4/3, 1:1 (to playback correctly you must have enabled overlay mixer in both ffdshow and your player (mpc recommended)). The link:http://www.savefile.com/files/5028954
I don't understand why you say only those are possible dars? (it's about output not input, in case of input you are perfectly right). And who said that final PAR has to be 1:1? That's the whole point, no, of anamorphic, that the PAR is not 1:1.

[Doom9]

Fisrt of all I'm gonna ulpoad a bit of an anamorphic encode of mine that has a DAR of 1.88 (1.88:1) so different than 16/9, 4/3, 1:1Uh.. that does make no sense. DVD, DVB, ATSC and ISDB all know 4 DARs, the 3 Wilbert listed and another one nobody uses. What you're refering to is the aspect ratio of the movie.. there's no standard for that. DAR gives the aspect ratio of the playback device.. not the aspect ratio of the actual video.
The ITU people created a real mess with all these terms though. Basically if we had a horizontal stretch factor and that's it, things would be so much simpler. Leave it up to telephony people to create a mess in an area they should've never touched..

[Daodan]

Yes, you are perfectly right, that's what I've been struggling to say here. There is input (the original dvd) and output (the encoded movie). So the problem in your megui is that for input aspect ratio it actually wants the output one, and from here all the trouble people have understanding how it works. In my opinion this is how megui should work: you put input dar (usually 16/9), you use autocrop (or manual crop), and from that cropping megui should calculate that sar thing. However, megui leaves the same thing for sar no matter what you crop (because basically it requires from the beginning the desired dar). Ouf, I hope I made myself understood this time.

[Doom9]

it of course comes down to the question of how a playback device handles the DAR flag if the container has one. Is it h_res = v_res * dar ? If so, we need a formula that given the input resolution and dar, and output resolution, calculates the SAR. berrinam wrote the code so I'm not sure how that is being handled, and I have yet to come across a formula anywhere in this forum that would do just that (once again, I never looked at that particular code).

[Daodan]

Stupid me! I finally understood what was wrong and what needs to be changed in megui. Actually the SAR doesn't change however you crop, only the DAR is. So why my samples got wrong is because megui doesn't ask what dvd you have: PAL or NTSC, which is crucial. In case of NTSC it always is SAR 1.184 (so one should always put 118:100 in x264) and in case of PAL is always 142:100. That in case of aspect ratio of 16/9. In case of 4/3 is 107:100 for PAL and 88:100 for NTSC. I hope I didn't do any errors in my calculations.
So megui should ask for input DAR (olny 16/9 and 4/3 since I don't think there are original dvd's otherwise), type (PAL or NTSC) and suggest one of the values from above.

[Wilbert]

@Doom9,
it of course comes down to the question of how a playback device handles the DAR flag if the container has one. Is it h_res = v_res * dar ? If so, we need a formula that given the input resolution and dar, and output resolution, calculates the SAR.
The formulas for the PAR of pal/ntsc dvd:
http://www.doom9.org/index.html?/capture/par.html (16.2 examples 2 and 3). See also below:

@Daodan,
And who said that final PAR has to be 1:1? That's the whole point, no, of anamorphic, that the PAR is not 1:1.
Correct, when the resulting encoding is anamorphic the output PAR (or SAR) is 1.778.

Actually the SAR doesn't change however you crop
True!

, only the DAR is.
No. You are still confused about DAR. DAR is only defined in certain containers like mpeg-2 (and not mpeg-4). MeGui should ask you whether your input is anamorphic or not, because that specifies the DAR of the input. If the stream is anamorphic the input DAR is 16x9, else it is 4x3. Whether it is PAL or NTSC can be read of from the input size (like 720x480), so you don't need to worry about that as a user. Given the input DAR and the source, the input PAR can be determined, thus for PAL (width: 720, height 576, DAR 4x3):

53.333 µs = 720 pixels /13.5 MHz
PAR = 576/720 * (4 / 3) * (53.333/52) = 1.094

PAL (width: 704, height 576, DAR 4x3):

52.148 = 704/13.5
PAR = 576/704 * (4 / 3) * (52.148/52) = 1.094

NTSC (width: 720 or 704; height 480, DAR 4x3):

PAR = 480/720 * (4 / 3) * (53.3333/52.6555) / (480/486) = 0.9116

NTSC (width: 704, height 480):
PAR = ... = 0.9116

etc ...

[Daodan]

Well, the results are almost the same as mine (only I didn't take in consideration those µs). The only thing I didn't quite get is what is the deffinition of DAR, in my idea it was display aspect ratio so what I see, so in that case it doesn't matter if it's mpeg 2 or 4 or whatever. Thanks for the link of the guide, I missed that one.

[Doom9]

@Wilbert: what I cannot find is how given a horizontal and vertical resolution and a PAR I get the playback resolution.. because in the end that's all the player has (especially a PC based player). And software DVD players work the same way... v_res * DAR = h_res.

[SeeMoreDigital]

Personally I prefer using the following equations: -


If you require your PAL encode to displayed at 1.33:1 (4:3), use: -
4 576 2304 16
- x --- = ---- lowest dominator -- or 16:15 (or 1.0666666)
3 720 2160 15


If you require your PAL encode to displayed at 1.77:1 (16:9), use: -
16 576 9216 64
-- x --- = ---- lowest dominator -- or 64:45 (or 1.4222222)
9 720 6480 45


If you require your PAL encode to displayed at 1.85:1 (37:20), use: -
37 576 21312 37
-- x --- = ----- lowest dominator -- or 37:25 (or 1.48)
20 720 14400 25


If you require your PAL encode to displayed at 2.35:1 (47:20), use: -
47 576 27072 47
-- x --- = ----- lowest dominator -- or 47:25 (or 1.88)
20 720 14400 25


If you require your PAL encode to displayed at 2.40:1 (12:5), use: -
12 576 6912 48
-- x --- = ---- lowest dominator -- or 48:25 (or 1.92)
5 720 3600 25


The same principle can be applied to any MPEG-4 source by simply substituting the relevant horizontal and vertical resolution values


Cheers

[DigitalDivide]

3 simple words..."I give up on anamorphic encodes"...

[Daodan]

3 simple words..."I give up on anamorphic encodes"...
Wise words, but not really 3. Ok, in an attempt to rescue you, i'll give you this method: when using 16/9 ntsc (usually your case, right?), delete any resizing in the avs and use 118:100 in the sar settings in x264 config in megui. Try samples from different movies and see if you are happy with this one. It should always work (in case the ntsc resolution is 720/480, not 704/480, which i think is rare).

[DigitalDivide]

Wise words, but not really 3. Ok, in an attempt to rescue you, i'll give you this method: when using 16/9 ntsc (usually your case, right?), delete any resizing in the avs and use 118:100 in the sar settings in x264 config in megui. Try samples from different movies and see if you are happy with this one. It should always work (in case the ntsc resolution is 720/480, not 704/480, which i think is rare).

I'll give it a try tonight.

[SeeMoreDigital]

when using 16/9 ntsc (usually your case, right?), delete any resizing in the avs and use 118:100 in the sar settings in x264 config in megui. Try samples from different movies and see if you are happy with this one. It should always work (in case the ntsc resolution is 720/480, not 704/480, which i think is rare).118:100 can be simplified to 59:50 (which decimates to 1.18).

But you might want to give 32:27 (which decimates to 1.1851) a try too ;)

[Wilbert]

@Wilbert: what I cannot find is how given a horizontal and vertical resolution and a PAR I get the playback resolution.. because in the end that's all the player has (especially a PC based player). And software DVD players work the same way... v_res * DAR = h_res.
h_play_res = h_res * PAR (vertical size doesn't change during playback - that's the case for all players I think ...)

example: 720x576 PAR: 1.094

playback: "720*1.094 = 788" x 576

[SeeMoreDigital]

h_play_res = h_res * PAR (vertical size doesn't change during playback - that's the case for all players I think ...)

example: 720x576 PAR: 1.094

playback: "720*1.094 = 788" x 576You would like to think so.... but it's not necessarily the case!

An 720x576 MPEG-4 encode with a decimate PAR of 1.094 (or 547:500) is reported in WMP10 and Media Player Classic as being like this: -

http://img494.imageshack.us/img494/8854/mpeg4withparof10945475009sq.png.


By contrast, an 720x576 MPEG-2 source with 4:3 DAR would be reported in WMP10 and Media Player Classic as being like this: -

http://img203.imageshack.us/img203/8342/mpeg2withparof106616157hg.png


Cheers

[Doom9]

playback: "720*1.094 = 788" x 576But the playback resolution of a PAL 4:3 stream is 768x576.. that's 20 pixels off. Is that an effect of logic (hres = vres * DAR) versus ITU (y*z/x * pi / e )?

[SeeMoreDigital]

But the playback resolution of a PAL 4:3 stream is 768x576.. that's 20 pixels off. Is that an effect of logic (hres = vres * DAR) versus ITU (y*z/x * pi / e )?Yep... I hear what you are saying but I'm only reporting what WMP10 and Media Player Classic are reporting about the MPEG-2 source!

At the end of the day, when we generate our MPEG-4 encodes (whether they be SP, ASP or AVC) are we not trying to emulate the aspect ratio (PAR) statistics of the MPEG-2 source?

By-the-way, here is the MPEG-2 source (http://81.98.148.105/Uploaded_Files/Doom9_Forum_files/MPEG-2_720x576.7z).


Cheers

[Wilbert]

But the playback resolution of a PAL 4:3 stream is 768x576.. that's 20 pixels off. Is that an effect of logic (hres = vres * DAR) versus ITU (y*z/x * pi / e )?
Yup, that conversion is specified in the mpeg-2 specs. So, that's how it must be done by software players.

@SMD,
Regarding the mpeg-4. So the displayed 1.37:1 part is good. What does that "actual 5:4" mean, and why this 786x576 instead of 788x576?

[SeeMoreDigital]

@SMD,
Regarding the mpeg-4. So the displayed 1.37:1 part is good. What does that "actual 5:4" mean, and why this 786x576 instead of 788x576?720 divided by 576 equals 1.25. Similarly, 5 divided by 4 equals 1.25


@Yes, i guess that's what most (if not all) software players/filters do.It seems to be what most hardware stand-alone players do as well. Especially those with offering MPEG-4 decoding too!


Cheers

[Wilbert]

720 divided by 576 equals 1.25. Similarly, 5 divided by 4 equals 1.25
I turned my pc on again to edit my post, but i was too late :)

It seems to be what most hardware stand-alone players do as well. Especially those with offering MPEG-4 decoding too!
That's interesting. Do they calculate the DAR from the PAR (assuming they support any PAR), and calculate the playback size from that?

[SeeMoreDigital]

That's interesting. Do they calculate the DAR from the PAR (assuming they support any PAR), and calculate the playback size from that?When playing back MPEG-2 that would be difficult to say. As I've not generated any MPEG-2 encodes not conforming to either 4:3 or 16:9 DAR (that said I guess I could use re-stream to generate an MPEG-2 at 2.21:1 (which would equate to a PAR 221:100)

When playing back MPEG-4 in hardware, it's all about PAR calculations. If an MPEG-4 encode just happens to have a PAR that conforms to a known DAR, it seems to just carry on regardless!


Cheers

[berrinam]

Ok, guys, I've made some changes to MeGUI which I hope have fixed all the problems with it.

Also, everything can now be entered the same way. I'm not sure of the name (I've been calling it PAR -- Picture Aspect Ratio, but I don't know), but what it does is it says that, when displaying it, displaywidth/displayheight must equal parx/pary. Call it whatever you want, but that's what it does, which should mean that if you have a 4:3 source you can just enter 4:3. Likewise for all other sources. MeGUI handles the conversions required for each encoder to reach the end result I described.

I've done all of this in 0.2.3.2059, so I guess you'll just have to wait until that is released.

[SeeMoreDigital]

Also, everything can now be entered the same way. I'm not sure of the name (I've been calling it PAR -- Picture Aspect Ratio, but I don't know), but what it does is it says that, when displaying it, displaywidth/displayheight must equal parx/pary. Call it whatever you want, but that's what it does, which should mean that if you have a 4:3 source you can just enter 4:3.PAR, SAR, DAR... at the end of the day it's all a form of "Aspect Ratio Signalling"..... So I propose we call it "ARS" from now on ;)


Cheers

[Wilbert]

When playing back MPEG-4 in hardware, it's all about PAR calculations. If an MPEG-4 encode just happens to have a PAR that conforms to a known DAR, it seems to just carry on regardless!
How can that be? If they consider the PAR, playback should be at 788x576 and not 768x576 (the latter done used by mpeg-4 players if i understand you correctly). Apperently they must be doing something else?

[SeeMoreDigital]

How can that be? If they consider the PAR, playback should be at 788x576 and not 768x576 (the latter done used by mpeg-4 players if i understand you correctly). Apperently they must be doing something else?I presume it's because, like most of our software players, not all of our hardware players follow the ITU specs either!

A dedicated MPEG-2 DVD player, only has to detect and display 4No values of aspect ratio signalling from commercially produced DVD's (two for 720x480 NTSC disc's and two for 720x576 PAL disc's). So I guess they are more likely to follow the ITU specifications.

A combination MPEG-2/MPEG-4 player is able to detect and display many different values of aspect ratio signalling. So I guess they are less likely to follow the ITU specifications.

As a side issue, I'm tending not to use expressions such PAR, SAR and DAR as many of us have pre-defined ideas as to what they represent.

EDIT: Here are some 704x576 and 720x576 MPEG-2 Test Files with 4:3 and 16:9 AR Signalling (http://81.98.148.105/Uploaded_Files/Doom9_Forum_files/MPEG-2_Test Files_with_AR_Signalling.7z). When you play them in a software player their AR properties should be correctly stated as being either 4:3 or 16:9.

To me, logic should dictate that when you convert the MPEG-2 sources to MPEG-4, after you add the appropriate level of AR signalling and then play the encodes in a software player, their AR properties should be correctly stated as being either 4:3 or 16:9 too!


Cheers

[DigitalDivide]

I seem to be having a strange problem. It was indicated that I shouldn't do a resize in my avisynth script when doing an anamorphic encode, however if I don't include a resize in my script, the movie will not encode. I get an error. As soon as I include the resize, I am able to encode the movie.
For instance, I am encoding FlightPlan, I crop 0 from the left, 2 from the right, 56 off the top and 62 off the bottom. If I only use the crop(x,x,x,x) and removegrain parameters MeGUI gives me an
"avis [error]: unsupported input format (DIB )
could not open input file 'D:\Projects\FlightPlan\Flightplan.avs' error"
But it doesn't do that with the resize.

So how do I not resize in my script?

[foxyshadis]

DIB = Avisynth error, open it in vdub. Sometime soon there should be a message informing you to do just that when it shows up. ^.~ If I had to guess it's probably that removegrain requires mod 4/8/16 width video.

[DigitalDivide]

Ok, guys, I've made some changes to MeGUI which I hope have fixed all the problems with it.

Also, everything can now be entered the same way. I'm not sure of the name (I've been calling it PAR -- Picture Aspect Ratio, but I don't know), but what it does is it says that, when displaying it, displaywidth/displayheight must equal parx/pary. Call it whatever you want, but that's what it does, which should mean that if you have a 4:3 source you can just enter 4:3. Likewise for all other sources. MeGUI handles the conversions required for each encoder to reach the end result I described.

I've done all of this in 0.2.3.2059, so I guess you'll just have to wait until that is released.

I don't think I'll be able to use this version. I can't install net2 which I believe the newest versions of MeGUI use. I'm stuck for the time being with .net 1.1

[DigitalDivide]

Okay if I'm cropping in my avisynth script as per above, what should I be resizing to since it appears you must have a resize in the script? 720x368? Then enter in the SAR of 32:27?

[Wilbert]

(1) Post your script. (2) Post the DAR of your source (16x9 i presume). (3) Post the amount of black borders.

[SeeMoreDigital]

You might find some information in this thread useful: -

http://forum.doom9.org/showthread.php?p=772428#post772428


Cheers

[DigitalDivide]

(1) Post your script. (2) Post the DAR of your source (16x9 i presume). (3) Post the amount of black borders.

From above "I am encoding FlightPlan, I crop 0 from the left, 2 from the right, 56 off the top and 62 off the bottom"

NTSC 16:9 DVD
My AVI script has currently

Crop(the numbers above)
Right now LanzcosResize (720,368)
Removegrain(mode=1)

The only reason I am asking about the resize is because I thought when doing anamorphic encodes you don't need to resize. But as per my above error, it appears I must have resize in my script.

SMD, I'll check the link. Thanks

[nm]

The only reason I am asking about the resize is because I thought when doing anamorphic encodes you don't need to resize. But as per my above error, it appears I must have resize in my script.
No, you don't need to resize. Just crop so that the resulting image has a mod-16 resolution (both width and height can be evenly divided by 16) or don't crop at all, which is bad if there are black borders.

[SeeMoreDigital]

No, you don't need to resize. Just crop so that the resulting image has a mod-16 resolution (both width and height can be evenly divided by 16) or don't crop at all, which is bad if there are black borders.Indeed....

Providing that is when you crop, its smack on the "matte-to-image" boundary and you get a nice clean edge!

[DigitalDivide]

Okay maybe I'm not stating this clearly. If I don't put resize into my avi script, when I try to encode I get an error as soon as I click start. See a few posts above to see the error. As soon as I put resize everything works. So I can't figure out why everyone is saying don't resize and yet MeGUI gives me an error when I leave resize out of the script??

Here's a sample script which I've tried with and without the resize. Without doesn't work.

# Created with Gordian Knot
#
# http://gknot.doom9.org

# PLUGINS
LoadPlugin("C:\Program Files\GordianKnot\DGMPGDec\DGDecode.dll")
#LoadPlugin("C:\Program Files\GordianKnot\AviSynthPlugins\UnDot.dll")
LoadPlugin("C:\Program Files\GordianKnot\AviSynthPlugins\Removegrainsse2.dll")

# SOURCE
mpeg2source("G:\flightplan.d2v")


# CROPPING
#crop(0,56,718,362)
crop(0,56,-2,-62)

# RESIZING
LanczosResize(720,368)

# DENOISING: choose one combination (or none)
#Undot()
Removegrain(mode=1)

[nm]

Read the answers you got through again. The problem is likely bad resolution after cropping, which you fix by resizing to a mod 16 resolution. However, by resizing you also lose quality, so it is better to crop to a good resolution directly.
Remove the resizing filter and try this: crop(8, 64, 704, 352)

Resolution 704x352 is good because 704/16=44 and the division has remainder 0
(that is, 704 modulo 16 = 0), and 352 has the same property. For example, also 720x368 would be good.

Mod 16 resolutions can be encoded more optimally by x264, and as you seem to have just experienced, non-mod 16 (or 8 or 4) can cause other problems with filters.

[DigitalDivide]

Read the answers you got through again. The problem is likely bad resolution after cropping, which you fix by resizing to a mod 16 resolution. However, by resizing you also lose quality, so it is better to crop to a good resolution directly.
Remove the resizing filter and try this: crop(8, 64, 704, 352)

Resolution 704x352 is good because 704/16=44 and the division has remainder 0
(that is, 704 modulo 16 = 0), and 352 has the same property. For example, also 720x368 would be good.

Mod 16 resolutions can be encoded more optimally by x264, and as you seem to have just experienced, non-mod 16 (or 8 or 4) can cause other problems with filters.

Okay so what you are saying is if I have a proper crop, then it should work without resize. It's the fact that I didn't have a proper crop that was causing the error. ONe thing is I notice that if I use MeGUI to creat the avi script it shows crop as the following crop(0,56,-2,-62) however GK shows it as crop(8, 64, 704, 352). I'm assuming second one is the correct method? Also I understand the 704 and 352, but what is the 8 (does this mean crop 8 from the left or right) and 64 (does this mean crop 64 from the top or bottom)

[DigitalDivide]

Now I see what the problem was with the crop. MeGUI's crop of crop(0,56,-2,-62) is what was causing the problem. When I use the crop of crop(8, 64, 704, 352) I don't get the error. Gee took me long enough...:D

[SeeMoreDigital]

If your movie source has an aspect ratio of 2.40:1, try adding the following PAR/SAR: -


12 352 4224 6
-- x --- = ---- lowest dominator - giving a PAR/SAR of 6:5
5 704 3520 5


Or if your movie source has an aspect ratio of 2.35:1, try adding the following PAR/SAR: -


47 352 16544 47
-- x --- = ----- lowest dominator -- giving a PAR/SAR of 47:40
20 704 14080 40



Cheers

[foxyshadis]

Heh, if that's the case, update your avisynth. I think crop (pos,pos,neg,neg) was introduced in 2.5.5 or 2.5.6. Along with so many bugfixes you just have to.

[berrinam]

There seems to be a lot of differing opinions about handling AR, and using anamorphic signalling.

I think that this is one of the reasons why some people find MeGUI's AR handling wrong or useless, because the way MeGUI handles it is how we devs decided to do it, and other people may choose a different way.

The issues, as I see it are this:
When someone wants to do an anamorphic encode, there is almost always cropping. Now, the chance that this cropping is exactly mod16 in both axes is 1/64 (2/16 * 2/16), which means that it is quite low. Now, there are three things that can be done in this situation:
ignore the mod16 constraint, since x264 can now handle non-mod16 resolutions
Resize the video so as to make it mod16.
Increase cropping so that it is cropped to a mod16 resolution.

Each of these three methods has its own proponents. I would like it if this conflict could somehow be resolved with some level of unanimity, so that people end up agreeing with MeGUI's solution (not that I'm saying MeGUI's current solution is right; what I'm saying is we change MeGUI's solution to agree with what the majority says, ONCE the majority is agreed). I have come up with an objective way of comparing methods 1 and 2, to see which gives a higher quality. As to method 3, that should probably give the best quality metric-wise, as it has neither a loss in quality due to resizing or due to non-mod16, but the loss is in the image area being reduced. I cannot see any way to evaluate the importance of this loss, so I will look at only the first two methods:

My comparison between methods 1. and 2.:
Objective: See whether method 1. or method 2. will give a better final quality (with a given metric -- I would say PSNR and SSIM), taking into account factors such as quality loss by resizing, compressibility loss due to non-mod16. Also, compare the quality of these approaches to a non-anamorphic encode, to attempt to find the crossover point at which anamorphic encoding is useful.

Method:
We take some source (perhaps an apple HD trailer, so that (a) the quality is high when downsized to SD and (b) it is accessible to everyone, for reproducibility of the tests), and we downsize it to SD resolution. Let's call this downsized clip sd_original. We then find some cropping values for sd_original (these must be non-mod16, or else it will defeat the purpose of this test), and encode this to x264 using method 1. and 2. These two clips will be at different resolutions, yet they will both have been cropped with the same values, so we can simply compare them to the (cropped) original or sd_original source. Then, using SSIM and PSNR, we can see which is closer to the original, which is the aim of anamorphic encoding.
As an extension to this test, we also try encoding it non-anamorphically, to see how the quality turns out for this, and to evaluate the importance of encoding anamorphically.

So, what do you think?

[SeeMoreDigital]

The "mod16" benchmark is a useful one to adopt because "all" codecs conform to it.

As far as I know it's technically possible to generate MPEG-4 SP/ASP at "mod8" and MPEG-4 AVC at "mod4" but I don't know what kind of modifications (if any) have to be incorporated into "front end" encoding applcations to make use of them.


Cheers

[Daodan]

berrinam, this is how I see things. Let's say one wants to do anamorphic encode and has enough bitrate to do it (let's say 1.4 gb for 2 hours dvd). He wants anamorphic because he wants highest possible quality. So the first things that should be changed in megui is that when you check 'anamorphic' the resize would be automaticly off (no matter if the cropping is or not mod16). If you don't have ebough bitrate for that resolution, it's better to just resize nonanmorphic. (these are my conclusions after a few tests). As for your test proposal,i'll make a few tests this weekend on some hdtv material I have,using x264, to see how much this affects quality.

[DigitalDivide]

oh Boy, nothing but problems. Oka so the movie encoded perfectly fine...EXCEPT for the sound. My AC3 track seems to be off by a sec. Sound comes first then the scene. Not sure why? First time this has ever happened to me.

Is there any way to extract the video from the mkv file. I still have my ripped ac3 track so I would like to try to use MKMerge Gui to remege it again. Should I be using the delay as per the stream.txt info from ripping my dvd?

[foxyshadis]

No need to extract anything. Just drag both files into mmg, uncheck the audio from the video file, set a delay on the other, and you should be set. The delay should be set according to its filename (if from dvddecryptor) or stream.txt, definitely.

[berrinam]

berrinam, this is how I see things. Let's say one wants to do anamorphic encode and has enough bitrate to do it (let's say 1.4 gb for 2 hours dvd). He wants anamorphic because he wants highest possible quality. So the first things that should be changed in megui is that when you check 'anamorphic' the resize would be automaticly off (no matter if the cropping is or not mod16).I don't think you got the point of what I am saying. I described in my previous post that, for non-mod16 cropping resolutions, you can deal with this in three ways. I also described the merits of each in comparison to the others. But now you are just saying that you can ignore the fact it isn't mod16 (listed in my post as the first option), without providing any reason.

I did also say that there seems to be a large variety of opinions on this topic, and some people seem to back each method. You clearly back method 1, and there's nothing wrong with that, per se. However, each of these three methods involves some form of quality loss, and the goal of the tests I described was to find some way of quantifying this objectively, instead of the theoretical arguments that people have. Too many people just make assertions without backing them, so I wanted to find a way to do some tests that people agree with.

As it is, method 1 may be the best, but I won't feel safe just because someone tells me it is -- I want to see some evidence.

Hence, the proposed test.

Opinions from anyone else?

[Daodan]

Ok, I finally finished the tests (I understood you wanted metrics proof). I did this on a dvd sample, because after all, when you work with anamorphic you work with dvd. The sample was a 5 min PAL DVD sample. No filters used (like denoisers, etc). The commandline in x264 was ref 5 --mixed-refs --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter -1,-1 --subme 6 --analyse all --8x8dct , at 2000 kbps, 2-pass, no fast first pass. I post the results for the second pass.
The first test was cropping at 720x544 (mod 16), no resizing.

PSNR Mean Y:41.734 U:46.162 V:48.908 Avg:42.907 Global:42.493

The second test was cropping non-mod 16, I tried to crop so the total number of pixels per frame was the same. (391680 in the first case, and 391272 in the second). So the resolution in this case was 714x548.

PSNR Mean Y:41.512 U:46.076 V:48.712 Avg:42.697 Global:42.300

The thirs was the same as the same res as the second but brought at mod 16 (720x544) by lanczos resizing.

PSNR Mean Y:41.589 U:46.120 V:48.768 Avg:42.771 Global:42.394

Also, about the speed of the encoding, the second was 2.5% slower then the first, and the third 3.2% slower then the first.

Now, for the interpretation, some help is needed, since I'm not used to metrics tests, are these differences in PSNR noticeable or can they be ignored?

berrinam, as for the fact that I say that anamorphic should be left without resizing, it's hard to verify here, since you can't compare PSNR made at such different resolutions, I was saying that from my own 'visual' comparisons.

[SeeMoreDigital]

Hence, the proposed test.

Opinions from anyone else?I totally agree with you ;)

[nm]

The thirs was the same as the same res as the second but brought at mod 16 (720x544) by lanczos resizing.

PSNR Mean Y:41.589 U:46.120 V:48.768 Avg:42.771 Global:42.394
Did you get the PSNR values directly from x264, or did you calculate them separately? I'm not exactly sure, but I'd think x264 doesn't calculate the PSNR against the original source, but the filtered one when you are using Avisynth, and in this test you would want to take the losses from resizing into account too.

[SeeMoreDigital]

All I see are two 720x544 encodes, which conforms to a "mod16" output pixel frame size :confused:

[nm]

Daodan did three tests, first with cropped 720x544 source, second with non-mod16 714x584 and the third with 714x584 resized to 720x544.

PSNR comparison between these encodes is a bit difficult though because the source (after cropping) is not the same (between tests 1 and 2) or has different pixel dimensions (between tests 2 and 3). The PSNR differences Daodan got can as well come from that as from the non-mod16 encoding and resizing (which wasn't even measured in the PSNR, as I noted).

[Daodan]

Damn, so the resizing doesn't count in that case? I used the PSNR from x264, I didn't know that it didn't compare with the source, but now that I think of it, it's quite logical. I should make another set of tests then, these don't mean much.

[SeeMoreDigital]

Sorry... my mistake. I missed the non-mod16 714x584 bit :(

[nm]

It would be best to get someone more experienced in metric testing to figure out a good test. I can't think of any good way to include resizing in the PSNR calculations where the values are supposed to be compared with PSNR values from a non-resized encode.

Perhaps visual comparison with a low resolution (< 320x240) and very low bitrate (100-200 kbps) would be better. Still, resizing would be hard to do without affecting the judgement because of scale differences. You could do the resize twice, first to a higher resolution and then back to the original, but that wouldn't be fair.

[SeeMoreDigital]

With the help of generous friend, here is the first version of the ARS Calculator (http://homepage.ntlworld.com/seemoredigital/Applications/ARS_Calculator_v1.0.0.7z). I hope some of you guys will find it useful and enjoy using it :)

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


At the time of writing it requires version 2 of Micro$oft's .NET Framework in order to run.

My profound thanks goes to Moitah. Who was able to turn my design concept into a working reality. Many, many thanks....


Cheers

[Backflip]

Excellent work :)