MeGUI vs GK: AviSynth Script Creator [Archive]

berrinam

24th May 2006, 08:11

Despite the title, this is not a playoff or anything. It is simply a clarification thread, because several people have said that they prefer the GK AviSynth Script Creator to the MeGUI one. So that I don't pollute the thread that these claims came from, I am starting a new one here.

What does the Gordian Knot AviSynth script creator have that MeGUI's should have, but doesn't?
Resizing
Gordian Knot allows you to change the resolution and/or Aspect Ratio and immediately see what effect that has on the size/shape of the video. Why do people need this?
Choosing the resolution is a simple enough process: you always go for the highest resolution you can manage. If there are some constraints on that (processing power, size of screen, bitrate, whatever), these are going to be numerical constraints, so you won't gain anything by being able to see it.
Finding the right AR is the only theoretical use for previewing the resizing. However, MeGUI can autodetect the AR from the d2v file, whereas GK can't. This means that you mostly won't need to work out the AR, because MeGUI will do it correctly for you anyway, and it is most likely better than you at that, being a computer program, not a human.
Workflow
In Gordian Knot, you choose resizing and cropping while the preview window adjusts immediately at any changes, and then after that, you select your deinterlacing, resize algorithm and denoising in one screen with a preview you can see when you press a button. MeGUI immediately updates for cropping (this is a bit annoying, though, see * at the bottom), but not for resizing, which people seem to want, as discussed above. Other than this, the workflow is pretty similar, except there is a clash between the immediate updates of cropping(/resizing) and the delayed updates of other filters.
Compressibility check
Gordian Knot links the choosing of resolution to the results of the compressibility check. Since people often request a compressibility check in MeGUI, I suspect this may be one of the key issues. The main problem with a compressibility check in MeGUI is at what stage in the workflow it goes; you don't choose your video codec until after you have generated your avisynth script.

The first two of these issues are interface problems, and they are not too serious (IMHO) to pose any real problems. The compressibility check needs considerable research/experimentation in x264 in order to be a reliable measure, and it also needs more thought for integration into MeGUI. As such, I don't understand why (other than for the compressibility check) people go the extra mile of opening GK and copying across all the values, just to get the nicer user interface, because the extra work in using two programs is comparable to the extra work required just to be aware of MeGUI's problems and work around them.

Please comment

*The issue with MeGUI and cropping works like this: the fastest way to do an immediate update of cropping is to do the cropping manually in MeGUI. However, once the cropping is set and the previewed AviSynth script is opened, MeGUI is still cropping the video, and so is AviSynth. So we get double the cropping of what we should. We could turn MeGUI's cropping off when the AviSynth preview is opened, but what would the user do if he/she discovered that the cropping was wrong and had to be redone? This dilemma is completely solved in GK's approach

Doom9

24th May 2006, 09:17

I think Problem number one is having learned things one wa, that may not always be the best way. E.g. resizing: it really doesn't matter if you see it immediately or not. Of course we could resize the window too, but quite honestly, it's not really what you see is what you get anywhere because avisynth may be using a completely different resize filter. The only point where immediate preview really matters is cropping.. you may want to see that and be able to auto-correct. I guess that's the reason why people somehow expect to see the resize: they don't trust megui even though they configure everything that matters for a resize decision.

As far as the compressibility check goes: Once again having learned something comes into play, and on top of that having some tangible info about the source even though it has long since become irrelevant. Even for XviD a compressibility check has lost lots of its value (ask Syskin), and even more so for more modern codecs. On top of that, the only good compressibility check is one that goes over the entire source. Why? Because the way movies are made. If you ask a film student, they'll be able to describe that more properly than I am, but basically films tend to have a certain rythm.. there's 2-3 peaks in suspense at more or less well definied points in the timeline (relative to the movie's length). Often, these peaks coincide with scenes that have a lot of action in them. So, to have a truly representative indication of compressibility without doing the whole movie, the least you need to do is properly take into account the distribution of complex scenes. And no compressibility check can do that. So you're left with a number that is rapidly becoming meaningless, and having nothing at all and I prefer to know nothing upfront rather than something which is likely to mislead me.

I probably should get rid of the whole compressibility story in all but the divx3 guide anyway so people won't learn this anymore.

I have long since completely dumped GK because MeGUI does what I need done more effectively..

shon3i

24th May 2006, 11:39

And becaouse of this. And other things

http://img81.imageshack.us/img81/2805/filters0ne.jpg

In this you can choose any filter you want, bcause i don't always know all parameters on some filter and this helps,
i dont know why both GK and megui by default use Convolution3D and Undot for denoising when this filters are totality bad. Why not use fft3d or something better

shon3i

24th May 2006, 11:47

Resizing
Gordian Knot allows you to change the resolution and/or Aspect Ratio and immediately see what effect that has on the size/shape of the video. Why do people need this?
Like you say i want to see what is happend, one time i resize picture and i check suggested resoulutin the resoulution is 640x352 but right resolution is 640x272, and i see that streched picture more later...

Doom9

24th May 2006, 12:46

Like you say i want to see what is happend, one time i resize picture and i check suggested resoulutin the resoulution is 640x352 but right resolution is 640x272Can you provide a sample of that video.. (of course assuming the suggest resolution was performed after automatic cropping).. if with the proper AR set and automatic cropping suggest resolution gives a wrong resolution.. we need to know about it so we can fix it.

shon3i

24th May 2006, 12:58

No you not understand me correctly. MeGUI resize video correctly when select Suggest resolution but not automaticly change resoultion, for example if in box stay 640x352 and i click suggest resolution then resolution stay to 640x352 until i go one resolution up or down and when i back to 640, H res is not anymore 352 than is 272. So resizing preview window will be good thing.

buzzqw

24th May 2006, 12:59

a feauture liks "Made Comp Test script and Run It" could be very nice

may i suggest to introduce an AutoResize features based on Automatic Comp Test ? yes.. as AutoGK

btw is a matter of habitude, at first time gk is more user friendly and powerfull but after some time, you will learn that MeGui is same as features if not more.

BHH

Sharktooth

24th May 2006, 13:02

about compressibility check: http://forum.doom9.org/showthread.php?p=827225#post827225

buzzqw

24th May 2006, 13:36

@SharkTooth
compressibilty with modern codecs depends too much on settings, so a compressibility test would require the knowledge on how to use it...
ironically that knowledge is exactly the same that you require to choose how much to resize and what bitrate/quantizer to use to get a good quality backup.
so, im sorry but it will be useless for half of the video codecs supported by MeGUI and that's enough to not consider it at all.

i have to disagree.
With both XivD_encraw.exe and X264.exe is possible to do compression test. As is implemented in AutoGk, as in StaxRip and in my MkvMagic, CT can be made.

Is a matter of "personal" quality but afaik is accepted that xvid at quant 2.5 is Good quality and with x264 range of 16/22 is Good quality too.

I don't want to flame or whatever, but average people that do the average backup with full automatic average preset don't want know what "maddening" settings is used. They want just CLICK!

And so a CT test routines must be done.

just my 0.02€

BHH

Sharktooth

24th May 2006, 13:45

That's quite understandable, but doing a compression test with certain settings is very much different from doing a compression test with other settings.
in the case of xvid or mpeg4 ASP that difference is not that big but, in case of more advanced codecs (like snow and x264 for example) even simple settings, like inloop deblocking, can greatly change the comp test result.
The MeGUI workflow should be completely changed to integrate a comp. test coz it needs to be done with the same user settings.

buzzqw

24th May 2006, 14:18

i fully undestand SharkTooth. But i can suggest as user choose a profile (one of your) or do some personal management on parameters , simply KEEP these settings but apply a CRF or a CQ (for xvid) encoding.

again, i will wait for Doom9 ideas and suggestion

BHH

Doom9

24th May 2006, 14:24

but not automaticly change resoultionI don't get what you mean. When you start up with a DVD source, you have something like 640x352 set. Then you do an autocrop, and check "suggest resolution". Then if the source is is a 1:2.35 source, the resolution should be set to 640x272.

I still recall my template for the "ultimate" video encoder and one of the features in there was automatic resolution suggestion based on the comp check. Nowadays I regret coming up with that idea because these days, a compressibility check is nothing more than selling people snake oil. Forget q2.5 = good quality... you're going to run into the case where those 5% of the source give a completely different result than going over the entire source.. and people will fully believe in the comp check never doubting that the results could be anything less than the best possible match.

shon3i

24th May 2006, 14:50

I don't get what you mean. When you start up with a DVD source, you have something like 640x352 set. Then you do an autocrop, and check "suggest resolution". Then if the source is is a 1:2.35 source, the resolution should be set to 640x272.No, again in megui by default stay 640x352 when i select suggest res and crop res is always to 640x352 instead 640x272, but when i change res to one down or up and back to 640, megui automaticly change to 272.

check

24th May 2006, 14:50

Here is my suggestion. Sorry for the mockup being so horrible, but you get the idea (unless your eyes fall out ;))
http://project357.com/check_megui_avs_layout.gif
-this new layout I have shown is also more representative of the final avs script.. why *was* crop below resize? The whole thing seems a bit more logical, because a clear flow/ AVS script design can be seen. If this is confusing, I can create a new diagram.
-I miss the resolution slider most of all, clicking the up and down button or typing in the number seems slower and less efficient than dragging a great big slider around.
-The way meGUI handles the cropping in terms of doubling the cropping is very bad for me, on more than one occasion I cropped 4 when it should have been 6 or something and clicked preview, to hide my mistake. (question, can meGUI find the right AR from mkv, mp4, etc files?)
-Another niggle that is related to this (and didn't even exist in GK) is how meGUI handles anamorphic encoding. Selecting anamorphic encode should give you a resolution selector for encoded frame, and a seperate box where you can define output AR / dimensions. The current method is even less clear than the previous method imo, although I understand how it works and can use it, it doesn't feel intuitive.
All of these changes are reflected in the image above.

buzzqw

24th May 2006, 14:50

Forget q2.5 = good quality... you're going to run into the case where those 5% of the source give a completely different result than going over the entire source.. and people will fully believe in the comp check never doubting that the results could be anything less than the best possible match.

while i agree with these statement, because i am NOT the average encoder, many and more user bow at GK Compression Test.

There will be movies where CT will lead to meaningless results but many more where CT will give some hints.

a fuction can be used or not, while i can disagree on its use i will not force to USE or NOT.... and sometime can be i will use it too :)

BHH

Doom9

24th May 2006, 15:21

@shon3i: either I don't get what you're doing or what you're writing isn't correct.
I downloaded 0.2.3.2153 from x264.nl and ran it (no autoupdate, no anything). Then I go to the avisynth script creator and load a 4:3 d2v. By default, the resolution is set to 640x272. Then I check "Suggest resolution". Now the vertical resolution is no longer accessible and it's set to 480 (in accordance with the Input DAR which is 4:3).
Then I press Auto crop. MeGUI crops the way it should, and sets the vertical resolution to 352 (it's a 1:1.85 source).

Then I close MeGUI, reopen and load a 16:9 D2V source. The resolution starts out as 640x272 again, then I press suggest resolution, and the resolution becomes 640x352. Then I press autocrop and now the resolution becomes 640x272.

Then I load a 640x272 AVI source. Input DAR is custom, resolution is 640x272. Checking suggest resolution doesn't change it, and pressing autocrop doesn't change that either.

Then I tried reversing the order of pressing auto-crop and checking "suggest resolution". The end result is the same. Then I also tried just keeping "Suggest resolution" checked and crop manually to see what happens. And the suggested resolution is adapted when I change the cropping. I also tried not checking "Suggest Resolution", crop manually, then check "Suggest Resolution" but once again the suggested resolution was the proper one.

The only way I can get to an incorrect resolution is if I set my Input DAR to a value that doesn't match the source. Now there are a few DVDs that have a 4:3 DAR flag even though the source is 16:9.. in that case you'd have a mismatch but every app out there would have the same problem because the application cannot know a stream is 16:9 even though the MPEG-2 stream flag is 4:3 unless the application also analyzes the IFO (the one click encoder indicentally would get things right even in this scenario as it uses the ifo.. but you can't load ifos in the avisynth script generator).

So please teach me how I can make MeGUI suggest the wrong resolution.

Selecting anamorphic encode should give you a resolution selector for encoded frame, and a seperate box where you can define output AR / dimensions. But it does.. if you check "Clever (TM) anamorphic encoding", then all you need to do is drop.. and you can change the horizontal resolution.. the vertical resolution (which is grayed out) will be adapted and show the physical vertical resolution the encoded frame will have.

I guess one thing that's confusing is that there are two previews.. one being a 1:1 preview of the source where the only thing you see is your current cropping, and a preview of the resulting script. Perhaps the button should be called "preview end result".

shon3i

24th May 2006, 16:10

Then I close MeGUI, reopen and load a 16:9 D2V source. The resolution starts out as 640x272 again, then I press suggest resolution, and the resolution becomes 640x352. Then I press autocrop and now the resolution becomes 640x272.Same for me but when i crop resolution stay to 352 instead 272, and i don't know why. And this is a wrong

640x352 suggest resolution and megui crop

http://img209.imageshack.us/img209/8456/3523ul.png

640x272 manual setting and megui crop

http://img53.imageshack.us/img53/985/2727ra.png

So better to have resized window

Doom9

24th May 2006, 16:56

then as I said.. please provide a sample of the source..
Is the Input DAR properly set?
What is the input resolution?
What are the 4 crop values after pressing auto crop?

ChronoCross

24th May 2006, 18:40

@shon3i
The resolution that megui selects does not look good when shown in the preview window however if you use DAR upon playback it will look correct.

shon3i

24th May 2006, 19:05

@ChronoCross this is not MeGUI preview window, both frames captured in VirtualDub, first is with MeGUI suggest resolution and second is my when correcting Horisontal resolution from 352 to 272, both croped with Auto Crop in MeGUI

@Doom9 here is MeGUI window

http://img62.imageshack.us/img62/1318/res2id.jpg

Here is my step's

1. Load d2v file
2. Click Suggest Resolution
3. Check Crop
3. Auto Crop
4. Then i go to filters tab and Analyze video
5. Select Deinterlacer if need
6. Check Colour Correction
7. Save

The right resolution shows when i press 1 to incrase/decrase vertical res and then when i back to 640 the horisontal res is 272. This is probably bug but when window resize automaticly all thing will be better right?

Doom9

24th May 2006, 19:56

I have to repeat my request for a sample of this VOB.. I can't reproduce this behavior. And you can forget about your step3.. it's not necessary. And calculation wise, it makes no sense either because the virtual window megui calculates has the following dimensions: 1004/432.. which is 2.3x and that's way closer to 2.35 than 1.85.

It's been a long time since I worked on megui but what happens if you press the preview button is indeed terrible. We should call the window that opens when you load your source "Crop window", rename the button to "Preview script", and have the Preview Window load the script inline (which is done) but apply no cropping whatsoever.. just write out the script as is.

shon3i

24th May 2006, 20:07

I have to repeat my request for a sample of this VOB..I can't upload it until next month. My provider problems.

stax76

24th May 2006, 20:19

I was never interested in tweaking codec settings (or other params...) and always use the same settings for any source, it worked always good for me and I recommend those settings and use those settings as defaults in StaxRip. ATM it's XviD at q3 (needs post processing), x264 at crf 22 (produces 30-40% smaller files than XviD at q3 (using Sharktooth's CE-High)). Equivalent filesizes can be achieved with XviD at 60% and x264 at 50%.

I think comp. check is reasonable for ASP and AVC alike but keep in mind this comes from a someone (me) that don't like to tweak and thus is not a expert and from someone that *never* does multipass and comp. check, fixed filesizes appear much too awkward too me and even if multipass of some codecs is more efficient, I've never heard or seen that it's that much that it's worth to bother with a 30-50% higher encoding time.

ChronoCross

24th May 2006, 21:52

Teegedeck

25th May 2006, 08:33

I quite strongly disagree about the necessity of a compressibility test, too. It has its uses. A comp. check is vital in order to be able to determin what CQM to choose in XviD (if you care about quality) at a given resolution and target-filesize (and given filtering if applicable). It tells you quite precisely whether you will be able to encode with that low-coefficient matrix 'X' at a reasonable average quantizer or whether it will be better to choose not-quite-so-low-coefficient matrix 'Y'. Thing is, that makes for a very visible difference. You don't want a full-resolution picture encoded with the SixOfNine CQM at an average quantizer '4.5', you'll rather want EQMv3 HR at an average of '3.5' - or alternatively reduce the resolution. Without a comp. check, choosing a CQM in XviD is a mindless guessing-game that you only get away with if your chosen output-resolution has been too low to start with.

stax76

25th May 2006, 09:02

@Teegedeck

It's hard for me to grasp this, are you suggesting to do a comp. check, to not to do a comp. check, to reencode by trial and error and compare the results visually or what?

Teegedeck

25th May 2006, 09:34

Sorry for not expressing myself that well today. :)

If it was just me, I only need a filesize-prediction because my choice of matrix is clear, my resolution is a fixed one, too, and my thoughts about filtering are: don't. If a filesize prediction at constant quantizer 4 overshoots my target filesize, I either go for a full DVD-R or drop multiple audio.

But most users seem to want an 'optimum' setting for whatever target filesize they have set their minds on. In this thread (http://forum.doom9.org/showthread.php?p=796900#post796900) I've come to the conclusion that a simple comp. check with Enc will do for them in order to determin what matrix and settings to pick. The idea is not to waste quality - I think many, many people just use way-too-cautious settings, especially when it comes to choosing an output resolution, so I propose to always use full, anamorphic resolution and adjust CQM and encoding-settings according to the aimed-at filesize. Like:

Comp. check result
<30%: bad luck, decrease resolution
>30%: use preset 1
>44%: use preset 2
>60%: use preset 3
>90%: use preset 4

Edit: Using Enc as an external application only for compressibility tests is fine but, well, it relies on VfW.

check

25th May 2006, 10:09

But it does.. if you check "Clever (TM) anamorphic encoding", then all you need to do is drop.. and you can change the horizontal resolution.. the vertical resolution (which is grayed out) will be adapted and show the physical vertical resolution the encoded frame will have.

I guess one thing that's confusing is that there are two previews.. one being a 1:1 preview of the source where the only thing you see is your current cropping, and a preview of the resulting script. Perhaps the button should be called "preview end result".

The more confusing part for me is how that system works - I always expect it to display the dimensions of the encoded frame, and show the DAR seperately, you can see that in my mockup. Automatically setting the AR is useful, but you should be able to manually (or semi manually) set it too, because I find it a bit confusing now.

stax76

25th May 2006, 10:46

@Teegedeck

Problem was more my bad reading, sorry. Your restricted filesize approach is not very common but I find it interesting.

shon3i

25th May 2006, 11:20

you misunderstood me. if your using DAR to encode the playback resolution(using x264 or xvid) is will input the SAR and will resize on playback to a anamorphic resolution. The preview in vdub will always look wrong. only upon full playback will the DAR be used.
Yes but i use correct input DAR which megui suggest and for SAR i leave blank and everything is fine. 640x352 is not good, 640x272 is perfect anywhere, in playback, virtualdub etc..

quake74

26th May 2006, 13:12

Since people say that the result of the CT is not reliable b/c different parameters or luck in analyzing that particular 5% of the movie, why not do a CT using the stats file produced by the first pass?

My idea is something like this:
1) in MeGui choose a profile,a resolution and a target filesize.
2) Run the first pass and look at the stats file and figure out if the bitrate is too low/too high and advice the user ("MeGui suggests that you increase the resolution or decrease the bitrate for this particular movie" or viceversa)
3) Run the second pass with the (possibly updated) parameters.

I must admit I am not sure what info is in the stat file. If I change the resolution or the bitrate by a little bit (say 5-20%) would the 1st pass be useless then? I see that the stats file gives average QP, but is it possible to generate a CRF-equivalent value to decide on whether the "quality" was too high/low?

Sharktooth

26th May 2006, 13:17

the 1st pass must be repeated...

Dayvon

31st May 2006, 20:33

If I had a say in any of this, I would have to recommend an "unlock" button next to the "suggest resolution" button. Why? Because I guess I don't like being locked into 720 and 480 being the maximums to the resolution. I love how you guys are dummy proofing MeGUI, but this option for more advanced users would keep us from having to open up the avs file in Notepad to change this.

Doom9

31st May 2006, 21:32

Dayvon

31st May 2006, 22:29

@Dayvon: I've been out of development for two months but I distinctively recall adjusting the avisynth script creator to allow resolutions as high as the original. So if you have a 1080p source, you can go 1920x1880, but if you have an NTSC DVD then the limit is 720x480. I know there are people who are into encoding to higher resolutions than the source but that just doesn't fly with me, at all.
LOL I know, I've seen you mention it before :D

But seriously though, I know I would love this option and I think others might as well. I know the DVD maxes out at 720x480, but since I do non-anamorphic encoding, I'd like to see 1152x480 be the max for true 2.4:1 encoding with square pixels WITHOUT losing the lines of resolution (or like I said, have it a unlock "option"). Let me example this briefly. I just input a 16:9 encode auto cropped it, and suggested resolution and got this:
crop( 2, 56, -2, -62)
LanczosResize(720,304)
Now that isn't the full resolution. 304+56+62=422, which means if I use MeGUI's suggested resolution, I will downgrade 58 lines of resolution. Since 480-56-62=362, a x264 encode would capture the DVD best at 864x368 for a divisible by 16/square pixel encode.

I know that to you 864x368 sounds wrong, but for me with my setup it makes sense. I have a 32" HDTV hooked up DVI to my PC (where I am typing this) and the more I lower my resolution on my encodes, the more I see problems when the movie is fullscreen. I personally am one that doesn't back up to DVD-9s, DVDDLs or CDRs but to my hard disk, therefore the "perfect filesize" is not even considered by myself, high resolution over-sizing isnt a problem. I go for quality everytime, and that means I'd like more resolution to go with my higher bitrates :cool: .

By all means you can say no and I will go on making AVScripts in MeGUI and manually editing them in notepad, but I don't think I'm the only person who would appreciate a feature like "unlock resolutions".

sillKotscha

31st May 2006, 22:42

what I especially like about GKnots resizing is the autocrop -> smart crop all

with only autocrop enabled you'll get mod4 for sure but not allways the right resolution... as it seems with shon3i's above mentioned problem...

berrinam

31st May 2006, 23:37

By all means you can say no and I will go on making AVScripts in MeGUI and manually editing them in notepad, but I don't think I'm the only person who would appreciate a feature like "unlock resolutions".
How about an option hidden in the settings?

Dayvon

31st May 2006, 23:41

How about an option hidden in the settings?
Anything would make me smile!!! :D

As a matter of fact, I think that would be great! It would brighten all my encodings and (I think) keep me completely in MeGUI (aside from DGIndex of course).

Morte66

1st June 2006, 12:07

but since I do non-anamorphic encoding

I make my PAL DVD backup at 720x576 (cropped to mod16 if there are big borders), and set an aspect ratio flag in the mkv/mp4 muxer. I get full resolution, and only one resize (during playback) in the rip-to-view chain.

May I ask why you do non-anamorphic encoding? If you resize once during the encode, then again during playback to fit the resolution of your HDTV, you will lose quality compared to an anamorphic encode and a single resize on playback.

Doom9

1st June 2006, 13:22

Nah, I'm dead set opposed to resizing beyond the original dimensions. If you have an anamorphic encode and want to keep every last vertical line, use anamorphic encoding.. berrinam went to great lengths to facilitate that.

Sharktooth

1st June 2006, 13:24

Dayvon

1st June 2006, 14:46

Alright guys... I understand that its not a feature you want to implement. But I do have to say the more flexible your GUI, the more adoption it will have. I for one wont stop using it, and I'll either start encoding anamorphically or I'll keep doing what I have been doing.

Oh, I remember now why I don't anamorphic. I've had problems with because I render to .264 NOT .mp4 and then I wrap in mp4 with a .aac made in belight w/ YAMB. If I remember correctly, I've had trouble keeping the flag DAR when using these raw streams. Secondly, I've always used 1:1 pixel, and it sees best to keep the trend for file consistency.

Sharktooth

1st June 2006, 17:06

Dayvon

1st June 2006, 21:18

why dont you use mp4 output? also megui can mux the streams for you.
using bigger than the source resolutions only affects final quality in a bad way (due to the compressibility hit).
if you want a sharp resize during playback use MPC bicubic resize (needs a PS2.0 enabled videocard).

I don't use MP4 output because when I first started using MeGUI I was having no end to problems of audio sync. So I started rendering to .264 and .aac using x264 and Belight, and setting framerate manually in YAMB and havent had a sync issue since. So I've been hesitant(sp?) about doing this differently cause I hate fighting sync issues.

I know that MeGUI "can" mux MP4 streams, but again, I've been wary of using it since MeGUI is still developing and YAMB has worked great.

As to "Affecting final quality negatively" and "compressibility", that only makes sense to me if you are trying to hit a particular filesize (which I am not). I understand that smaller resolution does help compressability, but I use large encodes anyway. I want to have great quality with some file size reduction. I run with the rule that 2GB is max filesize and somewhere between 1GB and 2GB (depending on the movie length/type) is what I usually get.

I've been having no end to troubles with MPC and VMR9 which is required for the BiCubic Resizer. If you can help me with that, look here -> http://forum.doom9.org/showthread.php?p=835023#post835023

berrinam

1st June 2006, 22:08

As to "Affecting final quality negatively" and "compressibility", that only makes sense to me if you are trying to hit a particular filesize (which I am not). I understand that smaller resolution does help compressability, but I use large encodes anyway. I want to have great quality with some file size reduction. I run with the rule that 2GB is max filesize and somewhere between 1GB and 2GB (depending on the movie length/type) is what I usually get.I think you're wrong. It is always important to care about compressibility, because disk space, despite being cheap, is not free. The advantage to encoding anamorphic as opposed to upscaling, like you are, is that you effectively get the same resolution, but with less data to be encoded, which means you can get the same great quality with a smaller filesize. If you didn't care about filesize, then you would be keeping the original DVDs all the time, so that there was absolutely no loss in quality.

The only situation where it makes sense to upsize first is when you do super-filtering beforehand, with some of Didee's very slow scripts, because there isn't enough processing power to do them in realtime.

Dayvon

2nd June 2006, 16:43

Ok. Just to move this on, I tried a anamorphic encode last night to see if it would work properly (is hasnt seemed to in the past). So I made the whole encode in MeGUI. I used the AviSynth Script Creator and set the resolution to "retain anamorphic resolution" used auto crop and the highest suggested resolution. I set x264 to export to MP4 and loaded my prefered settings (automated 2-pass). Then I enqueued the video and let it rip.

This morning I load up the new "anamorphic MP4" and try to play it in MPC w/ FFdShow & Haali Media Splitter and this is what I get. :(
http://img473.imageshack.us/img473/9789/snapshot200606020945287ov.th.png (http://img473.imageshack.us/my.php?image=snapshot200606020945287ov.png)
Now before you start saying MPC exports the anamorphic not the stretched picture when screen capturing I know. But I use this picture to point out that the file IS NOT at the proper DAR and doesn't seem to have any sort of flag on it to force the proper 2.35:1 ratio.

Not to be undone. I thought I would see if (since I need to mux in the aac file) MeGUI's muxer might be able to help fix the problem. However, no such option exists in the MeGUI MP4 muxer.

Still persistent, I decide to try muxing with YAMB and sure enough, when importing the MP4 video file, one of the options is to set pixel aspect ratio to 16:9 NTSC. So I mux my MP4 and I will have to say, it looks great (/w correct aspect ratio), and the audio is in sync.

I did quick grabs of my square pixel encode (864x368) and compared it the anamorphic encode (bicubic resized in Paint Shop Pro to 864x368). If you look at the picture below, you can see that the anamorphic does appear more detailed in the hair and cheek area... This can been seen best if you can zoom in the picture. So it looks like anamorphic encoding wins me over :cool:
http://img482.imageshack.us/img482/1074/snapshot200606020946418yf.png (http://imageshack.us)

I guess my final question is, why doesn't the MP4 created by MeGUI play in the correct aspect ratio? It's as if the "retain anamorphic" does nothing except to keep the resolution buttons in the AviSynth Creator window at the proper values. Shouldn't the DAR flag be set automatically? And even if it isn't, with no DAR setting in the MeGUI MP4 muxer, it seems to me that one is forced to find other means to set the DAR. Is it that only when doing a full autoencode (i.e. w/ audio and using the autoencode button) that DAR is set?

This seems very confusing to me, when everyone in this thread has said "go anamorphic" and indicated that MeGUI is an all-in-one tool for anamorphic encoding. Maybe I did something wrong, and if so I'd luv to here about it.