autogk resizing vs megui

[donfrenchiano]

Ok my first question is why does autogk automatically resize your video (DVD to Xvid) and how does it determine the best size. Megui does not have this feature that i can tell. Im assuming people are going to answer this with you don't need to resize since ive seen that a lot on these forums. So my question to that is why does autogk think it needs to resize the video. Ive been using autogk for years and it creates various different sizes for my videos im guessing it has something to do with bits per pixel maybe but now i hear people say that that doesnt matter. I guess i dont have any problem leaving dvds at 720xXXX if it doesnt affect qualilty.

[hello_hello]

I assume when you encode you pick a target file size?

If you select "Advanced Settings" on the main AutoGK window you'll see options for output resolution such as auto, maximum width, fixed width etc. I assume AutoGK is set to Auto? You can only select options for the width. The height will be whatever it needs to be according to the width and the video's aspect ratio after the black bars have been cropped.

Leaving the width setting on auto is a good thing if you encode while picking a target file size, especially if you always use the same target file size. No one movie can be compressed in the same way as another (some are hard to compress while some are easy) so all else being equal, for a given quality relative to the original DVD the final file size will always be different. If you encode using the same file size each time then as it's a constant, other aspects of the conversion sometimes need to be changed in order to maintain a similar relative quality to the original DVD. One of them is resolution.

When you start an encode after picking a file size, AutoGK runs it's compression test and uses the result to make adjustments accordingly. It'll pick an appropriate resolution and decide on a sharper or softer resizer etc. AutoGK does it pretty well.

If you want to pick a fixed width each time then you probably need to be prepared to adjust the file size accordingly for each encode. Unless you're encoding for playback on a standalone device there's no real need to pick a file size and use two pass encoding. You can change the output file size setting to "target quality" instead. The default of 75% is probably the best to use. You can set your preferred width (I think if you leave it in auto mode AutoGK uses 640) and AutoGK will run a single pass encode. You don't lose quality running a single pass encode, only control over the file size, and single pass encoding is a fair bit faster.

I still use 2 pass encoding a fair bit as my encodes get played on a variety of standalone devices. Many standalone devices have a restriction on the maximum bitrate they can handle. XviD can control the maximum bitrate but only when encoding using the 2 pass method. If you haven't set one of the standalone device compatibility options (you'll find them in the hidden settings by pressing Ctrl+F9) then you're fine to use single pass encoding.
I encode by setting a fixed width. There's very little quality to be gained by going over 640, but I generally use 704 or 720 for movies to retain maximum detail, while I usually use 640 or 656 for episodes of TV shows. (640 if the aspect ratio is 4:3, otherwise I use 656). Anyway, that's just personal preference. I then take a guess as to what the file size should be and start the encode, making note of the compression test result. I usually aim for 70% to 75% (a higher % is better quality). If it's higher or lower than 70% to 75% I stop the encode, pick a more appropriate file size, then start again. It can be a bit frustrating as sometimes it takes a few goes to get it right, but that's life.

If you want the best of both worlds and aren't fussed about the encoding time, running a single pass encode to obtain the required file size and then running a 2 pass encode could be something to try. I do it a lot when encoding episodic DVDs as the file size required for each episode (at a given quality) can vary quite a bit.
So I set my desired fixed width and desired audio format. Usually it's 656 for TV shows and 720 for movies and I pretty much always use 128K CBR MP3 as the output audio. If file size isn't an issue for you, you can tell AutoGK to keep the original audio stream. Not re-encoding the audio can save a reasonable amount of time. I then set up all the encodes using the target quality setting of 75% and let AutoGK do it's thing. When it's done each episode/movie will have a different file size. I then set up all the encodes again using AutoGK's target file size option but change the target file size accordingly each time, using the file size obtained from the first encode. This will ensure the 2 pass encode will be of the same quality as the single pass encode without AutoGK needing to make any adjustments to the resolution or the resize method it uses etc. If the single pass encode was done using a target quality of 75% and the output file size was 800MB (for example) then running the same encode again using a target file size of 800MB should give you an encode with a quality of around 75%.

As I said, I only encode that way to ensure standalone device compatibility. If you're not fussed about it, or your standalone device happily plays whatever you throw at it, then you don't need to encode a second time like I sometimes do. Just run a single pass encode using a target quality setting of 75% and you're done.

Wow... that somehow turned into a bit of an essay while I wasn't looking....

PS In relation to MeGUI.... I think it's primarily aimed at running single pass quality based encoding using x264, so it doesn't have the ability to run a compression test. Some current GUIs still have the ability to do so. HDConvertToX for example.
Without a compression test it's often "hope for the best" when choosing an output file size, as you're effectively setting the final quality while having no idea what that quality will be. So when using most encoder GUIs it can be easy to produce poor quality encodes, or to waste lots of bitrate you didn't need to use. AutoGK is the only GUI I know of which makes it's own adjustments to maintain quality. When it's left entirely in Auto mode it does a pretty good job of it and of saving you from yourself. ;)

[donfrenchiano]

Thanks for your reply. That was very informative. I think I will just use MeGui when im encoding blu rays and stick to autogk for dvds. I was just curious because AutoGK uses some older versions of virtualdubmod and other things and was wondering if there was a different way with newer versions of codecs and tools

[hello_hello]

I know the version of VirtualDubMod isn't the last one available (it's not developed any more) but as far as AutoGK's encoding goes the new version won't make any difference. As I sometimes use VDM myself, I replaced the version AutoGK installs with the last available version. You can just overwrite the old VDM files with the newer ones.
AVISynth is still the current stable release (at least I think it is).
I replace Media Player Classic with Media Player Classic Home Cinema for previewing. Just download MPC-HC, rename it's exe to "mplayerc.exe" and replace the old version in the AutoGK/mpc folder.
I'm not sure about all the other tools in regard to whether they've been updated since the last version of AutoGK was released. I know XviD has but I don't know what the benefits of a newer version might be (if any), and whether they'd play nice with AutoGK is another thing....

Do you particularly require your DVD encodes to be AVIs? The only reason I still encode to AVI is so other people in the house can continue to live in the dark ages, watching AVIs using their DVD players. If not for them I'd probably retire from converting to AVI completely. For myself, I use MeGUI and x264 for DVD encodes too. MeGUI's anamorphic DVD encoding is the way to go. Because you're not resizing down to square pixel dimensions as you are with XviD encodes, the x264 encodes retain more detail (anamorphic encoding uses non square pixels like the DVD itself uses). I use single pass encoding (CRF 19) for DVDs and most of the time when running a DVD and the encode taken from it side by side, I can't see any quality difference between the two.

If you open a DVD using MPC-HC, then open an AVI encode taken from that DVD, even if you've used a width of 720 for the encode you'll notice the DVD video takes up more screen real estate than the encode. The difference in size is what you've lost through having to resixe down to square pixel dimensions.

[donfrenchiano]

I actually messed around with AutoGK and GordianKnot this morning. It seems Gordian Knot uses the last version of Vdubmod but a very old version of xvid and AutoGK uses an older version of VdubMod but a newer version of xvid. You can use newer versions of both in each program and the only difference i see is the file sizes are slightly off in the final encode. ie if you choose 700MB it will be around 705. I dont see much difference in just looking at it So i guess theres not much to be gained in doing this. I may start using megui its just that i have hundreds of avis ive encoded over the years and dont want to reencode them. Im OCD on certain things and dont really like my library of movies full of mixed file types and codecs. Thanks for all the info though.

[hello_hello]

Yeah, I tried different versions of XviD quite a while ago. Some gave me lots of problems regarding file size (way more than 5MB). The ability of XviD to limit the bitrate for standalone compatibility... apparently that's the cause, it's broken in some builds. The version of Xvid which comes with the last version of AutoGK has the VAQ patch so I went back to using it. What advantages any newer versions of Xvid might have over that one, I have no idea.

I do understand the OCD thing, I'm a bit like that. With me it's more being OCD when it comes to maximum quality, so now when I look at all my old AVI encodes and think about how I could have used x264 anamorphic encoding I get the urge to bang my head on the desk. ;)

[Chetwood]

Many standalone devices have a restriction on the maximum bitrate they can handle.
Well, since DVD standalones must be capable of handling the standard's total bitrate of 10.08 Mbps (10080 kbps), I'd say pretty much any SD encode is on the safe side.

There's very little quality to be gained by going over 640, but I generally use 704 or 720
Actually there is an awful lot of information dropped that just isn't there any more so why deliberately go below 720?

The only reason I still encode to AVI is so other people in the house can continue to live in the dark ages, watching AVIs using their DVD players.
As opposed to ditching their perfectly fine working hardware to buy a more expensive BD player to save space on the media (which is getting cheaper every day) by encoding to h.264 (which is overkill for SD material anyway)?

[hello_hello]

Well, since DVD standalones must be capable of handling the standard's total bitrate of 10.08 Mbps (10080 kbps), I'd say pretty much any SD encode is on the safe side.

As long as you don't take into account the varying difficulty when decoding video of different types. ;)

I probably didn't explain it properly. From AutoGK's help file, referring to the standalone compatibility options:
"For both XviD and DivX codecs this option also enables Home Theatre profile which is a part of DivX certification for hardware devices and which enables control over VBV buffer. Most standalones have issues with high bitrate spikes that cause internal memory of the player to be full and do not accept more data for a short period of time."

DivX profiles: http://en.wikipedia.org/wiki/DivX#DivX_profiles

Actually there is an awful lot of information dropped that just isn't there any more so why deliberately go below 720?

Aspect ratio. For example a width of 704 will give you a mod16 height that's closer to 16:9 than 720 will.
File size is of course the main motivation for reducing the resolution. If file size is a problem I much prefer to reduce the resolution than reducing the quality.
I'd also disagree with the statement there's an awful lot of information dropped when going below 720, or at least whether it's information you can see. I've got two identical monitors and I've run numerous 720x? and 656x? encodes full screen, side by side, and if I can see any difference at all it's very small. Even if a 16:9 video with a width of 656 might appear to have a 1% or 2% drop in quality when compared to a width of 720, for that you get around a 15% reduction in file size.

As opposed to ditching their perfectly fine working hardware to buy a more expensive BD player to save space on the media (which is getting cheaper every day) by encoding to h.264 (which is overkill for SD material anyway)?

No, as opposed to ditching their perfectly fine working hardware to buy a more expensive BD player so I don't have to encode everything twice.
I'm not sure why you'd think h.264 is overkill for SD material. Either it can encode to the same quality as XviD while reducing the file size or it can't. And even then it doesn't take into account the fact that most DVD players don't support anamorphic AVIs while an MKV capable BD player will support anamorphic MKVs.

And that's where I disagree with youre arguments. You say a lot of information is lost when going below 720 while converting to AVI, but it's small compared to what's lost when resizing down to square pixels, even at a width of 720. If I run a 720 pixel wide anamorphic x264 DVD encode side by side with a 720 square pixel wide AVI, the difference in the amount of detail retained is usually very obvious.

[Chetwood]

Any test files around the web that would support your last assertion? AVI vs anamorphic AVI vs x264?

[hello_hello]

Any test files around the web that would support your last assertion? AVI vs anamorphic AVI vs x264?

Most of them will be on the same pages containing the test files which refute yours. :)

I've never made an anamorphic AVI in my life. What's the point? My last assersion never mentioned anamorphic AVIs, just "anamorphic x264" v "720 pixel wide AVI" v "656 pixel wide AVI".
Theoretically though an anamorphic AVI should be fairly similar in quality to an anamorphic x264 encode assuming all else is equal. Likewise a 1024(ish) pixel wide DVD encode should look similar to an anamorphic encode because you're not resizing down, you're just using smaller (square) pixels when encoding. It's mainly the resizing which robs you of detail and my assertion is the resize down from anamorphic width to 720 square pixels generally produces a noticeable loss of fine detail. Resizing down from anamorphic width to 656 doesn't really loose you a noticeable amount more.

I was going to post some screen shots of 720 pixel wide AVI and a 720 pixel wide anamorphic MKV (same DVD), but when posting the links from photo-bucket I couldn't stop it resizing down the anamorphic screen shot, which kind of killed the ability to compare them properly.

[Chetwood]

I've never made an anamorphic AVI in my life. What's the point?
No quality loss due to resizing to square pixels but still running on older standalones that can't do x.264 material?

[hello_hello]

No quality loss due to resizing to square pixels but still running on older standalones that can't do x.264 material?

By far the majority of standalones either won't play anamorphic AVIs or they'll display them with the wrong aspect ratio.
I've never argued against the validity of anamorphic AVIs as such, just the fact when it comes to hardware compatibility they're basically useless.

As you asked for web links I stumbled upon this today. A quote from someone who's been responsible for several Xvid builds.
Post #8:
http://forum.doom9.org/showthread.php?t=161827
"But why use Matroska for MPEG-4 ASP? Standalone players always preferred the AVI container for ASP (some also support ASP in MP4). And if we don't care about old standalone DVD players, we may as well use x264 in MKV (it is supported by many Blu-Ray players). Encoding with x264 doesn't have to be slower - even “fast” settings can provide better quality than Xvid."

Doesn't sound like overkill to me. ;)

I have actually compared non-anamorphic 720 pixel wide encodes using both x264 and Xvid. There's no doubt x264 tends to retain more detail when all else is equal. I stick to Xvid for non-anamorphic AVIs simply for DVD player compatibility. The copies I make for myself use anamorphic x264 encoding, and I don't have to bother with 2 pass encoding, so x264 encoding isn't really any slower.

[donfrenchiano]

In case anyone was wondering I messed around with gordian knot and i was able to get correct file sizes by using vdubmod that came with gknot which is the latest, xvid codec 1.2.2 and i downloaded the latest version of DGMPGDec and just pointet gknot to dgindex. all my encodes so far have come out to around 700.x MB

[Chetwood]

we may as well use x264 in MKV (it is supported by many Blu-Ray players
Well, that was my idea but someone over at Doom9.de said there were very few that do this (he found 2). Anyway, I do care about old standalone compatibility, so I'm gonna stick with AVI for the time being.

[hello_hello]

Well, that was my idea but someone over at Doom9.de said there were very few that do this (he found 2).

Well I bought a Sony 380 Bluray player which supports MKV a few weeks ago. When I was enquiring about them, the sales guy pointed me to three different models in my price range which supported MKV. The others were LG and Samsung players. There didn't seem to be a shortage of more expensive models with MKV support either.

Anyway, I do care about old standalone compatibility, so I'm gonna stick with AVI for the time being.

Fair enough. I still have to care about old standalone compatibility too (for others in the house) which is why I often encode everything twice, whether it's DVD or Bluray source, but I do appreciate the fact not everyone could be bothered or has the time.

[donfrenchiano]

In my personal experience i dont really think x264 makes much of a difference unless you have a larger 1080p tv. I have a 32" 720p lcd in my bedroom and a 60" 1080i rear proejection tv in my living room, watching x264 vs xvid in my bedroom i can tell a very small difference since my tv isnt that big. In the living room my tv is huge but its still technically CRT so its not very sharp and i can tell almost no difference.

[hello_hello]

To be honest, there's been plenty of times I'll start to watch video and think to myself "that's fairly average quality" (regardless of the format etc) but by the time I'm a couple of minutes in I've forgotten about it and I'm just watching the video.

I guess as far as perceived quality goes, viewing distance in relation to screen size/resolution is also a big factor. I still watch a lot of stuff on 22" CRT monitors in my bedroom, often only several feet from the screen, and at that distance SD AVIs can look incredibly average. Yet if I played a 720p encode on one monitor and an AVI encode on the other and walked over to the other side of the room, I'd struggle to pick which is which.