720x544 vs 640x480

[gigantibyte]

I'm capturing full screen programs in MPEG-2 format off S-video, and converting them to XviD AVI's using AutoGK. Since the MPEG-2 files are 720x480, if I set a large enough size in AutoGK, say 1.45 for 90 minutes, AutoGK will stretch the vertical from 480 to 544 to maintain the 4:3 aspect ratio.

In strict terms of quality, and not compatibility with standalone players, is 720x544 better than 640x480 from an NTSC S-Video source?

[Midzuki]

In strict terms of quality, and not compatibility with standalone players, is 720x544 better than 640x480 from an NTSC S-Video source?

Only if the video source had been captured/created at 720x544.
Every resizing results in some loss of quality. BTW, 720x540 would
be a better choice than 720x544, and XviD should accept it without a complaint.

[aedipuss]

540 wouldn't be a good choice. it's not even divisible by 8, much less the more desirable 32.

[gigantibyte]

I didn't select 544 - AutoGK did. So compressing the Horizontal (640 from 720) is favorable to stretching the vertical.

What about widescreen within 720x480. Should I keep the 720 width x whatever the vertical is, or should that width also be brought down to 640?

[jagabo]

It's up to you which you prefer. Enlarging the frame will require a little more bitrate to encode at the same quality. You will retain a little more detail on the horizontal axis. Some standalone Divx/DVD players may have problems with 720x544 at 30 fps. Reducing the frame size to 640x480 will require less bitrate and be more compatible with stand alone players. You will lose a little detail on the horizontal axis. You could also leave the video at 720x480 and set the XVID DAR (display aspect ratio) flag to 4:3. This might give the best image quality but some players don't respect the DAR flag.

I usually encode 4:3 material at 640x480 and 16:9 material at 720x400, both with square pixels.

[FulciLives]

When you capture at the NTSC Full D1 resolution of 720x480 then using a MPEG-4 resolution of 640x480 makes more sense for 4:3 material than using the 720x544 resolution.

If you are using autoGK you can force it to use a width of 640 so you always get 640x480 with 4:3 Full Screen input videos.

- John "FulciLives" Coleman

[Midzuki]

aedipuss wrote:

540 wouldn't be a good choice. it's not even divisible by 8,
much less the more desirable 32.

AFAIK, the XviD specs are not the same as the MPEG ones.
But maybe you just meant the DVD-player designers are
even more stupid than I thought.

[jagabo]

aedipuss wrote:

540 wouldn't be a good choice. it's not even divisible by 8,
much less the more desirable 32.

AFAIK, the XviD specs are not the same as the MPEG ones.
But maybe you just meant the DVD-player designers are
even more stupid than I thought. :?

All MPEG family codecs are at their most efficient with frame sizes that are multiples of 32 or 16. This is because the first step of encoding the frame is to break it up into 16x16 blocks. And with YV12 encoding, where the color channels are at half the resolution of the intensity channel, to get a multiple of 16 in the U and V (color) channels you have to have a multiple of 32 in the Y (intensity) channel.

This is why AutoGK's default behavior is to use mod16 frame sizes.

[ronnylov]

Either 640x480 if the standalone player only accepts square pixels, otherwise 720x480 with PAR (pixel aspect ratio) or DAR (display aspect ratio) set accordingly for non-square pixels.

You wrote that you recorded from S-video. The horisontal resolution of the S-video signal is probably less then what you can store in 640 pixels resolution anyway. It may look the same as 720x480 even at 480x480 and a PAR of 4:3. For best compability I would make it 640x480 with square pixels. If the source video is interlaced then it may be better encoding to interlaced xvid rather than deinterlacing before encoding (not sure what AutoGK does).

[jagabo]

If the source video is interlaced then it may be better encoding to interlaced xvid rather than deinterlacing before encoding (not sure what AutoGK does).

In my experience, interlaced Xvid/Divx isn't handled well by most players.

[themaster1]

a little reminder, just in case:
The s-video defines the plug and type of signal (Y/C or luminance and chrominance), not the resolution of the signal.

Your source is 720x480 so i would keep 480 indeed and stretch the width to 640 (not 480x480) or even a bit less with deinterlaced frames.

[Midzuki]

jagabo wrote:

All MPEG family codecs are at their most efficient with frame sizes that are multiples of 32 or 16. This is because the first step of encoding the frame is to break it up into 16x16 blocks. And with YV12 encoding, where the color channels are at half the resolution of the intensity channel, to get a multiple of 16 in the U and V (color) channels you have to have a multiple of 32 in the Y (intensity) channel.

O-kay, I already knew that. BTW, TMPGEnc won't even start encoding if the user
chooses a frame size that is not mod(16). Now, should we conclude that the creators
of DivX and Xvid are as stupid as the DVD-player engineers?

[manono]

But the fact that it will accept Mod2 or Mod4 resolutions and encode at those resolutions doesn't mean the encoder can encode as efficiently or as well at those resolutions. Although I see more and more AVIs at Mod4 or even Mod2 resolutions, for best quality results use Mod16. And as jagabo and aedipuss said, a case can even be made for using Mod32, although that limits the heck out of the available resolutions. AutoGK uses Mod16, and the default for Gordian Knot is a Mod32 width and a Mod16 height. There are good reasons why those figures were chosen.

[jagabo]

And even though VirtualDub tells you there are "no known restrictions" with Xvid, Xvid has a mod2 requirement.

[Midzuki]

manono wrote:

AutoGK uses Mod16, and the default for Gordian Knot is a Mod32 width and a Mod16 height.
There are good reasons why those figures were chosen.

Again, I already was aware of that. What I have been trying to say is,
AutoGK and similar easy-using wonders should be "smarter" --- for example,
instead of simply resizing a true 4:3 clip to 720x544 and wanting the user to believe
everything is OK this way, it should resize to 720x540, then add a 2-pixel border
to the top and a 2-pixel border to the bottom. "We all" know that many/most players
keep ignoring the AR flags in AVI files, and the creator of AutoGK apparently has not
considered the fact very important. No more misunderstandings for today --- hopefully

[FulciLives]

When using autoGK just select a fixed width of 640 and all will be good

Maybe now we can argue over whether to use ITU resizing or not LOL :P

- John "FulciLives" Coleman

[Midzuki]

Call me nitpicker (or even troll) if you wish, but my eyes
really can tell the difference between a 16:9 640x352 image
and its 1:1 640x352 version --- or between 4:3 720x540 and
1:1 720x544, as the case seemed to be.

[FulciLives]

Call me nitpicker (or even troll) if you wish, but my eyes
really can tell the difference between a 16:9 640x352 image
and its 1:1 640x352 version --- or between 4:3 720x540 and
1:1 720x544, as the case seemed to be.

I took a 16x9 WS anamorphic DVD once and converted it "as is" meaning I left it at 720x480 (even though it was 2.35:1 I did no cropping what-so-ever ... actually I did crop the "old" black but replaced with "new" black) and set the aspect ratio flag using MPEG4Modifier and yes it played back properly in my Philips DVP5140 (a MPEG-4 capable DVD player) but you know what? ... it was a blocky mess at times (at times I note).

I took the same movie and did it again at 640x272 and it looked substantially better in terms of lack of "blockiness" etc.

Both times I used 1400MB as my size and it just wasn't enough for 720x480

As for the resolution difference ... I really couldn't see any noticeable difference on my 51" 16x9 WS HDTV ... I really don't think the difference was enough to make a difference. Of course I don't have two of everything so I couldn't do a true side-by-side but still I had both versions on one DVD-R and tried to switch back and forth between them and analyze several of the same scenes on both versions.

I guess I should point out that the scaler built-in to my HDTV seems to do a bang up job of things and perhaps that helped to lesson the difference in resolution between the sources.

- John "FulciLives" Coleman

[manono]

What I have been trying to say is,
AutoGK and similar easy-using wonders should be "smarter" --- for example,
instead of simply resizing a true 4:3 clip to 720x544 and wanting the user to believe
everything is OK this way, it should resize to 720x540, then add a 2-pixel border
to the top and a 2-pixel border to the bottom.

Everything is OK that way. What makes you think it isn't? If there's a great enough AR error, it'll cut into the video a very few pixels to lower the AR error. For me, purposely keeping black in an AVI is a big no-no. I would never even consider doing such a thing. When I see that in an AVI it tells me the encoder was incompetent. The edges between the black and the active video are very difficult to compress.

[Midzuki]

manono wrote:

Everything is OK that way. What makes you think it isn't?

Elementary Mathematics

For me, purposely keeping black in an AVI is a big no-no. I would never even consider doing such a thing. When I see that in an AVI it tells me the encoder was incompetent.

From this day on, my name is not on your black list anymore. Rejoice!
Seriously now, I have not yet used an application that thinks it is a good idea
to upsize a full-D1 4:3 NTSC source to 720x540/544. And I feel I never will.
Bad-bye, Automatic Gordian Knot! :P

[manono]

Elementary Mathematics

I don't understand. Are you saying because it's not exactly 1.33:1 there's something necessarily wrong with it? Didn't I say that AutoGK restores the proper AR with some small amount of cropping into the video if necessary? You can go into the Hidden Options to force AutoGK to do as you wish, keep some of the black, although you can't add any unless using one of the AutoGK add-ons that allow editing of the .avs. But if you know how to do that, then why use AutoGK at all?

Seriously now, I have not yet used an application that thinks it is a good idea
to upsize a full-D1 4:3 NTSC source to 720x540/544.

Well, you're only upsizing the height, and only if NTSC. The width is still the same. Anyway, I wouldn't do it either. Set a max width of 640 if you wish. And why have you still been using AutoGK anyway? You already know too much.

[Midzuki]

Just two more things:

1) When I said:

I have not yet used an application that thinks it is a good idea
to upsize a full-D1 4:3 NTSC source to 720x540/544.

, I meant "I have never used AutoGK, and I never will".

2) I am NOT the OP of this thread.

Have a very good night, Dear Master. =^.^=
Until tomorrow! ^_^

\\\

[manono]

Oh, sorry.

When you said, "Bad-bye, Automatic Gordian Knot!, I didn't realize you had never even said "Hello" to it.

[gigantibyte]

Wow. I didn't mean to spark such a lively debate.

I don't know AutoGK is doing with my TV captures, even when I force a 640 width. I cannot properly recreate the ecoding with GK.

I've been working with others online to encode a recent movie capture with GK. The capture was MPEG-2, NTSC, interlaced, and had a width of 720x480. However, there were black bars on the left, right, and bottom, respectively 6 - 8 - 8 pixels = a true resolution of 706x472. (All my TV rips have the same black bars.)

After trying various resolutions without much success, I had to crop 2 pixels from the top field for 706x470. The best resolution found after that, was 576x432; 0.1333 aspect ratio; 0.1% aspect error; 82% W-zoom and 92% H-zoom. If I tried 640x480, I ended up with a 102% H-Zoom error. Everything between 640 and 576 gave a higher aspect error than 0.1%.

[manono]

Hi-

I don't know AutoGK is doing with my TV captures, even when I force a 640 width. I cannot properly recreate the ecoding with GK.

Are you saying that you can't recreate with Gordian Knot what AutoGK does? Sure you can. You're saying that you get a satisfactorily low Aspect Error only with certain resolutions. But all the resolutions are open to you. All you have to do is continue to crop, into the video by a few pixels if necessary, in order to get a low Aspect Error. Also, AutoGK uses Mod16 for both the height and the Width, where Gordian Knot by default uses Mod32 for the width and Mod16 for the height. Change that W-Modul (Resolution Tab) to 16. Also, AutoGK doesn't use ITU resizing (unless you activate it in the Hidden Options). I can't remember if Gordian Knot still does by default or not, but you might check the Options Tab and see. I do use it, by the way.

I've been working with others online to encode a recent movie capture with GK. The capture was MPEG-2, NTSC, interlaced, and had a width of 720x480.

If it's a real movie (shot on film) then I hope you're applying an IVTC in the script, as would AutoGK, in order to make it 23.976fps when done.

I ended up with a 102% H-Zoom error.

So what?

Everything between 640 and 576 gave a higher aspect error than 0.1%

I try and end up with an Aspect Error of less than 0.5%. You can't tell an Aspect Error of less than about 2% (when round things begin to appear as slight ovals), so, in my opinion, you're being a little strict. But again, cropping a few pixels into the active video will allow you to lower the Aspect Error.

[Midzuki]

Wow. I didn't mean to spark such a lively debate.

Well... 706x472 is approximately equal to 628x472 square pixels.
628-4=624=39x16, and
472-8=464=29x16
{
OR:
472+8=480=30x16
--- just in case... you decide to be another incompetent AVI~encoder
}.


Hope this helps.

\\\\\\\\\\

[gigantibyte]

... Also, AutoGK uses Mod16 for both the height and the Width, where Gordian Knot by default uses Mod32 for the width and Mod16 for the height. Change that W-Modul (Resolution Tab) to 16. Also, AutoGK doesn't use ITU resizing (unless you activate it in the Hidden Options). I can't remember if Gordian Knot still does by default or not, but you might check the Options Tab and see. I do use it, by the way.

I used Mod16 for both in GK.

If it's a real movie (shot on film) then I hope you're applying an IVTC in the script, as would AutoGK, in order to make it 23.976fps when done.

Did that too.

I ended up with a 102% H-Zoom error.

So what?

It's not bad to stretch from 470 to 480?

Everything between 640 and 576 gave a higher aspect error than 0.1%

I try and end up with an Aspect Error of less than 0.5%. You can't tell an Aspect Error of less than about 2% (when round things begin to appear as slight ovals), so, in my opinion, you're being a little strict. But again, cropping a few pixels into the active video will allow you to lower the Aspect Error.

I'm not to experienced in such matters. Just following advice, and now I'm reading yours. Thanks for your comments - they are appreciated.

@ Midzuki: Those numbers look interesting. I'll definitely try them out.

[manono]

Hi-

It's not bad to stretch from 470 to 480?

I don't believe there's any difference between shrinking a height and increasing it. Both are equally "bad", I think. Since we shrink heights all the time, I don't see any problem in increasing it once in a while. Ideally, of course, we'd keep the height the same, but that's not usually possible. Lancos4Resize is said to be a better resizer when increasing the height or both the height and width.

And as I mentioned, it'll be easier to duplicate what AutoGK does by turning off ITU resizing in the Gordian Knot Options Tab. But this is one place where I disagree with AutoGK, as I keep the ITU box checked.

[gigantibyte]

Well... 706x472 is approximately equal to 628x472 square pixels.
628-4=624=39x16, and
472-8=464=29x16
{
OR:
472+8=480=30x16
--- just in case... you decide to be another incompetent AVI~encoder
}.


Hope this helps.

\\\\\\\\\\

Cropping to 464 for seems to be a great solution applied to my situation. To help me understand GK and AR a bit more, can anyone explain what is happening in the pics below? Why do I not get a 0.0% aspect error?

First of all, if I select 4:3, 624x464 is not an option.




I can only get the resolution if I enter 1.333 in 'Display AR' (or 1.33), but why 0.5% aspect error?

[ronnylov]

NTSC 4:3 aspect ratio of a DVD has the pixel aspect ratio of 4320/4739 = 0.9116

See this reference: http://www.iki.fi/znark/video/conversion/#conversion_table

So to convert 720x480 to square pixels you can multiply the width with the PAR: 720*4320/4739 = 656. This means 720x480 can be resized directly to 656x480 to get square pixels.

If you crop to 706x472 then this corresponds to 644x472 square pixels if you only resize horisontally. I would crop this further to 640x464. To avoid multiple cropping you can calculate backwards. You want 640x464 cropped square pixels. If you only resize horisontally (which I recommend because less resizing equqls better quality) then you can calculate how many rectangular pixels width with PAR of 4320:4739 is needed before resizing to 640 width?

640*4739/4320 = 702
You should first crop the width to 702x480 and then resize it to 640x480 if you need square pixels (a PAR of 1:1). If you do still have black bars you can crop them to a mod 16 resolution after resizing. Here's an avisynth script for you:

LoadPlugin("DGDecode.dll")
MPEG2Source("filename.d2v")
Crop(8,4,702,464) #crops 8 left, 4 top, 10 right, 12 bottom to 702x464
Spline36Resize(640,464)

This would give you a correct aspect ratio and the final resolution of 640x464. However to align MPEG blocks I try to crop the height in mod8 pixels. So instead of cropping 4 top and 12 bottom I would prefer cropping 8 top and 8 bottom if possible (if it is enough to remove all the black borders). So this is a little bit moe optimized:

LoadPlugin("DGDecode.dll")
MPEG2Source("filename.d2v")
Crop(8,8,702,464) #crops 8 left, 8 top, 10 right, 8 bottom to 702x464
Spline36Resize(640,464)

In your first screenshot you have cropped to 706x464 which would correspond to 644x464 square pixels. If the height is resized to 448 the width should then be resized to (706*4320*448)/(4739*464) = 621.39 pixels to maintain the aspect ratio. But to make it mod 16 Gordian Knot decided to resize it to 624x464 instead and this causes an aspect ratio error of 621.39/624 = 0.996 which it reports as -0.4 %. So Gordian Knot seems to get everything about the error right but it does not crop it very clever before the resizing. What happens if you select "Smart crop left-right" or "smart crop all"?

OK, heres a summary of how to resize 4:3 NTSC to square pixels:
Crop to 702x480
Resize to 640x480
Then crop more if needed to get rid of black borders, but keep final resolution mod 16.