Need your help with first anamorphic encode

[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 :(