Please Help with MeGUI (new install, old working fine)

A few months ago, I decided to give x264 recoding a try, and utilize the MeGUI collection of programs as the reviews were 'top notch' and etc.

The best machine I had at the time was a Vista32 (4core), which was also 'tasked' for some other 'stuff', but I picked up what looked like a good guide at ribolabs, read up on the pieces that made it all 'work' (I started doing DVD recoded just about 10 years ago, and the early hoops one jumped through seemed LOTS more complex...!), and forged ahead.

No real problems. Worked (and still does) like a champ. Found the 'sharktooth' x264 presets, and MeGUI program has updated itself 2-3 times, and everything looks great.

But like I said, I use that particular machine for other 'tasks' in the world, and setting it off on multi-day excursions to x264 land was getting to be a hassle. So, off to the pc shop I went to have a new, hopefully faster, machine built, that I would 'dedicate' to x264. Top-line 6core, fastest ram and new SATA3 drives.

That's been done, and although I fought Win7 for several weeks (not just with MeGUI problems but with just about everything on that OS), and two different shops couldn't figure out the Win7 problems, I called a halt to that nonsense and had Vista64 installed instead.

This time, everything (appeared) to go as smooth as silk. The install of all the pieces went without fail, and it MeGUI appeared to work fine. I did all my tests of different HD video input types (VC-1, Mpeg4, Mpeg2) and MeGUI and it's associated pieces didn't complain whatsoever in leading them up, creating AVISynth scripts, all the way to the point where one would start the encode. Even did a couple, using the fastest (low quality) presets from the sharktooth presets. Everything looks like it was working.

So, I decided to try something 'full bore', and loaded up a full (short, 90min) movie, and set it on it's way. Grind. Damn fast. Too fast. The results were just short little 'clips' like I had put a 'trim' command in the script. I hadn't.

So, re-run it again, making absolutely sure I followed the guide to the letter. Did the exact same steps on my original V32 machine as I did on the V64. Note please, I'm not running ANY of the new 64-bit pieces on the new machine. From what I read they aren't that stable, so...

But still, only what appears to be a very short (<1GB) piece of what was supposed to be a 15+ GB (from 25+GB original) MKV recode.

I'm at a loss. I don't see why this is happening. The steps are very simple, and they are the same exact steps I used in my other machine, that happily (but somewhat slowly) grinds away next to it. Does not make sense.

Anyone have any ideas? What is really weird is that if I use a low-quality preset like 'DXVA-HD-Fast', it appears to work (but even I can pick out the lossy parts) but if I ramp up the quality level to 'Extra Quality' or 'Insane', it goes off the traces and produces these very small MKV's.

:wacko: at this point.

Bit of an update:

Yes, I deleted all the x264/sharktooth presets, and reloaded them from the download 'package' I got from Doom9.

Did a couple of short tests, and it appeared that things were running more 'in line' with what I had calculated, i.e., where the x4 machine (3.2G) was figuring about 30 hrs for first pass, the x6 (3.2G) is saying about 16+, so that is 'maybe' about right.

Of course, won't know (for sure) for about 2-3 days.... My extremely rough calculations (!?) told me that having the additional 2 extra cores, plus ram about twice as fast, plus the 'super SATA' would come out to around 50-70% faster. BTW, I thought about going with a ram-disc, the really super ones are pci-x based rather than sata, and my MOBO in that machine has a slew of x16 slots, so I may decide to 'give that a try' after things get 'stable'. But those new WD SATA3 drives (twin 1TB WD), are screamers already.

Cross both my fingers. Light some incense. Bang a gong.

Oh OK, makes a bit more sense now, perhaps paste your avs script, and a copy of your x264 settings (lower half of the box when you click config). I don't know if this BB system supports code tags, but something similar to that, maybe quote, would suffice.

Well maybe, just maybe, it was that old standby with windows, 'reload and try again'.

I have two machines running a recode on the same movie, same settings, and the 6core is running right at 88% faster than the 4core, which is a bit faster than my calcs but within what the older machine is doing. Like I said, the proof will be in the pudding 2-3 days from now.

Quote:

---

Originally Posted by Beck38

Well maybe, just maybe, it was that old standby with windows, 'reload and try again'.

I have two machines running a recode on the same movie, same settings, and the 6core is running right at 88% faster than the 4core, which is a bit faster than my calcs but within what the older machine is doing. Like I said, the proof will be in the pudding 2-3 days from now.

---

By default (auto) x264 always does 1.5 times threads than cores (i.e. 3 threads for 2 cores, 6 threads for 4 cores, 9 threads for 6 cores, etc.) Verification of the problem should be in the results, i.e. the final encode. Clock calculations don't necessarily translate to encoding speed, i.e. 2x GHz != 0.5 time.

Anyways I'm not quite sure if you are having an actual problem or you're just worried about optimization. The filesize you mentioned wouldn't be a problem if you're using, for instance, a low bitrate for automated 2pass. Is the resulting encode length the same as source? Also, 30 hours on the 1st pass of a 90 min clip sounds waaay too looong for a 6core.

To give you an idea, I've got my own custom x264 profile on my Win7 64bit and AMD quad core, and it gives me nearly transparent encodes. A 2 hour advanced codec clip and resize, will take about 9 hours on a 2 pass transcode. If you're testing things out, maybe just stick with tests first, using the following in your script to shorten it:

Code:

---

SelectRangeEvery(10000,240)

---

That will select about 10 seconds of material at about 7 minute intervals (~ 2.5 min worth for a 1.5 hour clip). That way you can tweak/tune/test without all the waiting. Once you've got down a working recipe, remove the "trim" from the script, and it should work just the same with the full length.

'Optimization'? What dat? haha

Because I really didn't have a machine to dedicate to it previously, I haven't done any messing around. Now that I do (well, if the current 'test' works out that is), then I'll start giving things a try.

But to me, at the speed that it looks things are going to be with the 6core AMD 'black' cpu (3.2Ghz, no overclocking yet either), that 3 days would not be a big deal. Remember that when I first started recoding DVD's 10 years ago, it took 2-3 days back then with the fastest CPU on the market (again, with the settings at maximum quality). I burned up two machines (even with added aftermarket cooling) in 6 years before going to Antec cases with high-end cpu coolers. Got 4 of those beasts now...

Once I know that it looks 'stable' with the Sharktooth presets, then I'll start fiddling with the overclocking (it's a brand new 890fx Asus motherboard with TONS of overclock options), and then I'll take your kind script and see what gives. LOTS of things 'on the agenda' once I get past the base functionality.

I figure sometime next spring after Microsoft gets the first Win7 service pack out, I'll try that OS again. But right now, Vista I can just deal with okay (I'm glad I didn't have to go to it when it first came out...).

Thanks, and like I said, hopefully it'll actually work now...

On the optimization thinking...

I just tripped over some threads on Doom9 that referenced some new presets (added this last summer/june or thereabouts) that are supposed to be built into MeGUI/x264, ones like 'Placebo' and such.

I took a look in my Megui/allprofiles/x264 folder and don't see anything like that; am still on the hunt for where they are (obviously, didn't 'auto update'). Any ideas where they are? There are some suggestions that it is 'in the preset slider' or something like that, but since I have both machines grinding away right now, I really can't fool around with it.

Okay, according to the MeGUI wiki it's supposed to be there. Guess it's the first thing I'll need to take a look at once things get 'done'. Yet more things to do!

You've got to slide the "Presets" slider all the way to the right under config, by default it's on medium. I still think 2-3 days it too long to expect, you've got a faster machine than mine, and I don't need to go half a day. The only reason you would need more time is if you're really trying to save space, i.e. better coding efficiency. But even so, you should expect no more than 12 hours for both passes combined on a 90 min clip and your processor.

edit:

Try these settings, kind of like a test kit, these should take some time for the encode but give superb quality results. See how long it takes to encode using these (just keep tweaking your settings until they match up. Use the scratchpad profile and make sure to check the box for advanced settings. Play with them on each of the tabs until they match up. Any parameters that are already default just don't show up on the bottom.

Code:

---

program --preset veryslow --pass 2 --bitrate 6000 --stats ".stats" --slow-firstpass --deblock -3:-3 --bframes 3 --ref 8 --qpmax 42 --rc-lookahead 50 --aq-strength 0.8 --merange 32 --direct spatial --no-fast-pskip --level 4.1 --vbv-maxrate 40000 --vbv-bufsize 40000 --output "output" "input"

---

Quote:

---

Originally Posted by mjmacky

You've got to slide the "Presets" slider all the way to the right under config, by default it's on medium. I still think 2-3 days it too long to expect, you've got a faster machine than mine, and I don't need to go half a day. The only reason you would need more time is if you're really trying to save space, i.e. better coding efficiency. But even so, you should expect no more than 12 hours for both passes combined on a 90 min clip and your processor.

---

The 6Core machine just ended it's first pass (took 22hours), and is reporting (although it's guestimation will wobble a b bit before it settles down) is another 15+ hours. The 4Core is on about 44hours for the first pass (still running), and all the recodes I've done on that machine were around 4.5 days/110hours or thereabouts, depending on the clip size. All done with the 'insane' settings.

When I first started out I did some test runs of all the HD Sharktooth presets, and have that data in front of me, and the 4Core is 'right on the money' for the size of the clip. If the 6core turns out ok, it will be just about twice as fast, and will end sometime tomorrow early morning 3am or so my time.

If so, and good, that will be amazing. Even 'Sharktooth' has commented he though that the 'new' presets quality was better, but I'll see. At this speed, I'm concerned way more with the quality than the time involved, as I'm recoded things to around BD25 size not the super-scrunched DVD9/<DVD9 things I see all the time, or even the 12-15Gig sizing that, to me, makes no sense.

So, if my math is correct, it's running at ~25min/1min, recode time / original time. Not bad! Of course, this isn't on either of your 'tweaked' profile, when the current test ends (successfully?) then I'll run a test with the same clip and see how fast it is, then I'll play around with these 'new' presets, bunch of other stuff. But like I said, I need to get a good run first off of a known good profile.

Quote:

---

Originally Posted by mjmacky

You've got to slide the "Presets" slider all the way to the right under config, by default it's on medium.

---

Okay, things finally finish on the 6core, I did the mkymerge to put the audio and stuff back in it, and found that I'm getting all kinds of video artifaculating and stuff. Don't know if it has something to do with the Sharktooth presets of the machine (or the s/w on that machine), but I'll find out for sure tomorrow when the 4core finishes up. Went back and rechecked the input video, and it's clean as a whistle, so...

Meanwhile, I'm seeing the slider thingy to set the x264 encoding, and if the wiki is correct (but I've found other parts that are lax in explanations, and I'm a real stickler on documentation as I used to run s/w and h/w shops in my career before I retired, but the explanation on how profile, preset, and tune interact, is not fully explained properly (IMO).

First, it says that if a profile is specified, then it over-rides everything else; but then, it doesn't say how to 'not set' it. That 'window' has to have something in it, am I right in assuming that maybe the 'x264 scratchpad' is a zero sum? Again, the wiki says that the default is 'not set' but doesn't explain what the 'not set' is.

FYI: here is where I would dress down any programmer that worked for me, the balloon text that pops up on the application both doesn't match the explanation in the guides, and right in that balloon text, are things like 'x264 tunings... default: NONE' when the actual default is 'DEFAULT'. Makes me think that the other more complex explanations/guides are suspect.

Anyway, back to the previous, I guess I'll give the internal presets a try with something fast, with the encoder settings ('profile', again, something that doesn't match the documentation, set as 'scratchpad'), and see what gives before I try 'placebo'.


Update: Well, none of the 'built--in' things work. Period. Tried a half-dozen settings on the slider, que'd up the recode, launched, and they all died after running x minutes or so. So, lack of good documentation, lack of any real testing by the programmers, I'm back where I started.

I've spent the last several hours going through what google could come up with on comments to MeGUI, and the upshot is, that it used to be a great program (like what's running on my older machine), but lately has become extremely buggy due to some programming changes that were initiated sometime earlier this year.

Some folks report no problems, but don't list their OS or setup. Others (again, no listing of OS or system types) have nothing but. Several of those have had to reload their OS several times, then loading MeGUI several times, to get it to work. Many have reported the same bad artifaculating/blocking I see.

What exactly is going on with this, I don't know. I do have the 'original' files/executables I used on my older machine, If I though that would work I'd do it. I also could 'clone' my older machines boot drive, transfer it to the new machine, and go through the whole hassle of getting all the motherboard specific things to work correctly (what a chore!).

In short, it appears that this program has seriously gone 'off the tracks' due to new management (the original developer stopped working on it several months ago) and the new guy(s) don't seem to know what they're doing, and don't respond to folks problems on the message boards. The lack of proper documentation, in the wiki no less, is a sure sign of things not going well.

At least, that's my take on it. Really sad.

If someone has any kind of 'magic bullet' to perhaps get this in line to what the 50% who report no problems, I'll try just about anything at this point, as I've spent about $2K and coming up on two months trying to get this to work.

Yet more fooling around:

Reloaded the newest Presets from the MeGUI server (new presets seem to be released 1-2 times per week, so that has me concerned) ... short answer is, same problems. If I ramp the preset down to ultrafast/single pass, it runs and finishes, but the output (of course) is pretty poor/bad. Ramp it up to where the recode goes to a double-pass (like 'medium'), and the program comes to a halt at around 98+% of that first pass, never starts the second pass.

Update:
The 4Core finally finished, looks perfect. In digging deeper into what's going on with the new install, it appears to me that the 'developers' have crossed their wires somewhere on the new 'development' version of MeGUI, and some of the new code has 'leaked' into the older system an it's 'update' system.

At least, that's how things look, from the wacky way it's operating, and the hints and clues I get from reading postings on different boards all over the place. In short, I you didn't have the system up and running before all this nonsense started (say, early 2010), you may be 'automatically' hosed.

Again, there's only one (non-x) word for it, sad.

wait you might not have a stats file set for the automated 2pass, please copy your "parameter codes" in the config like I did in post #6, it's hard to cover every aspect question by question

Quote:

---

Originally Posted by Beck38

Okay, things finally finish on the 6core, I did the mkymerge to put the audio and stuff back in it, and found that I'm getting all kinds of video artifaculating and stuff. Don't know if it has something to do with the Sharktooth presets of the machine (or the s/w on that machine), but I'll find out for sure tomorrow when the 4core finishes up. Went back and rechecked the input video, and it's clean as a whistle, so...

---

My guess about this is that you are using DXVA based video codec to play back, and the encode has specifications beyond what is compatible with DXVA. You can try setting to ffmpeg or ffmpeg-mt and see if you get the same video errors.

Figured out part/most of the bottom line today with MeGUI.

The current developers, who took over from the original guy(s) a few months ago, have been utilizing the auto-upgrade system to 'push' out beta code to folks, without disclosing (or announcing even) that practice to anyone utilizing the program.

This has resulted in many if not most of the users to be left with a non-operational system. I guess I was lucky in not running it for quite a long time, and not 'updating' it either, or else my original installation would have been hosed as well.

Luckily, I still have all of the original downloads that (hopefully) haven't been screwed up (well, they aren't on the original machine they were installed on, so....) so I will be trying out installing that on the new machine, and seeing how they run.

BTW, in doing the hoop jumping that the current developers insisted I do, the minimal parts of the program that were working, have now stopped dead in their tracks. So much for that nonsense.

So I'll be blowing all that junk away, and trying to get the original package from early this year to work, just as it is on my other machine, and hopefully let these (deleted) (deleted) 'programmers' fade away in my memory.

Quote:

---

Originally Posted by mjmacky

wait you might not have a stats file set for the automated 2pass, please copy your "parameter codes" in the config like I did in post #6, it's hard to cover every aspect question by question

My guess about this is that you are using DXVA based video codec to play back, and the encode has specifications beyond what is compatible with DXVA. You can try setting to ffmpeg or ffmpeg-mt and see if you get the same video errors.

---

Wrong path. It's not like I haven't use all this before, I've been using it for months, and had zero playback problems on the PCH boxes I use And, all my (saved) recodes have been done using the Sharktooth DXVA-HD-Insane preset (with zero probs), so...

With what I've found out today, I'll be trying to un-linstall and then re-install the original package, as I noted above.

Hopefully, you haven't been letting your setup 'auto-update' or your system will get hosed, like like myself or the crowds of people who've been left with unworkable crud.

No I pick and choose which developmental updates I get depending on the release notes for each...

Believe it or not, and despite staring down a bit of the flu this week (still got a hint a a cough), I managed to 'mix and match' bits and pieces and get something to halfway work (not completely tested, will take a couple of days to do that), but it led me down a path that it appears that others have been down before (if the Google searches are to be believed....)

It's just that the Google leads me (or should I say 'try'), to bits of a hint of what others ran into some months ago... but those threads (on Doom9) have been deleted (just cached by the Google). And what exactly are they talking about?

Well, it's what I call the 'Win7' thinking, in that the program (in this case MeGUI) doesn't have (or, perhaps I should say doesn't have NOW) a specific option/settings for using/running 32 v. 64 bit external programs. In the older documentation, it specifically points to places where one can, while running the program under a 64bit OS, that the 32bit pieces can be specified.

I call this 'win7' thinking because in that OS, Microsoft 'thinks' it's making things easier for the network manager by making way way way too many things 'automatic', depending on which version of the OS it is, and what it 'thinks' the network topology 'looks like' when it does it's network discovery routine.

Now, we all know that unless it has the thinking power of a HAL9000 it really doesn't have a chance of really doing this, and even if it did, it would still (in true HAL form) come out wrong anyway.

So, as it sits right now, the only way to get MeGUI run (or, right now, seem to run), is to 'fake' it out, unless and until the programmers of MeGUI put the options/settings pieces back in.

We shall see in the next few days if it operates okay under the 'fake out' routine under a full load recode or three.

BTW, I did spend some time trying to get the 'new' experimental version to work, to about the same level of success (i.e., pretty bad). Half the problems looked like the same as with the 'standard', plus a host of others. The current development team is claiming that it's 'almost ready to be released as stable'. That thud you just heard is my jaw dropping. How about getting the original version back operating to where it was before you took it over is my comment on that.

Might help to note that even though I am running 64bit OS, I only trust, therefore installed only 32 bit programs and features with MeGUI. As far as encoding tools go, 32bit versions are the ones that are working pretty solid.

The 'updater' downloads all the 32/64bit versions of stuff, and the MeGUI 'decides' which OS you are on and uses the version it 'thinks' you need.

I found out that MeGUI used to have a section where you did 'global settings', which allowed you to force 32bit instead of 64 on a 64OS; this apparently was taken out some 8+ months ago or so (circa Feb10). The only way I can get it to use the x264 32bit here is to copy the 32bit and rename it to the 64bit.

Now, I probably wouldn't have figured (or be forced to) this all out, if the clip I had been using to test part of things out didn't have a shot of bit errors in the ripped piece. My Vista32 machine (which uses the 32bit x264 of course), seemed to go over this bump in the road, but the V64 machine running the x264/64bit didn't.

I did a rerip and am doing some retests, unfortunately dodging some power outage issues at the same time (large UPS but not 'infinite'!). (First wave of winter storms here).

So, it will take a few more days, running 32bit and then rerun on 64bit, to see if that was one of the core problems, and if I can decide which way to go full time. The 32bit is a bit slower, but not that big of a deal (you can look at your task manager processes to see which version you are running, btw.). Well, in a couple days, I'll have some idea, then another couple even a bitter idea. It always comes down to time...

Quote:

---

Originally Posted by mjmacky

Might help to note that even though I am running 64bit OS, I only trust, therefore installed only 32 bit programs and features with MeGUI. As far as encoding tools go, 32bit versions are the ones that are working pretty solid.

---

How did you do that, and get MeGUI to not complain (loudly, I might add) that the 64bit parts aren't there? I've tried a couple of different 'methods' to 'trick' it into using the 32bit encoder, and although it did appear to work at first, the encodes are junk.

I'm on the last 'test' run right now (I've done about 10+ with both old and new versions of MeGUI), with 'standard' (non-test version), using 64bit encoder. So, I'm about to install Vista32 on that machine and go from there, unless you can give me a heads up on how you managed to 'trick' it into using the 32bit encoder 'properly' without failure(s), which is what I ran into trying to force it to use the 32bit encoder.

I might add, through all this nonsense, my 'old' Vista32 machine continues to work perfectly, running encodes without failure, just about twice as slow. Heck, if I could get the 'new' machine to work okay, even at that speed, at this pint, I'd be overjoyed.

Even though I put it in the PM, I should clarify out here as well. MeGUI and its tools are all 32 bit. There is a x264_64.exe that gets installed and used on a 64 bit OS, but it is used through vfw4x264.exe, since the 64 bit app isn't compatible with the 32 bit AviSynth.

I am just vomiting up info I've come across, I am in no way an expert. I have figured out that the current MeGUI is running this way, more info about vfw4x264 here:
http://forum.doom9.org/showthread.php?p=1385194

and in contrast to my opinion in the PM, Beck, you apparently can just rename according to this thread (I don't understand why though...)
http://doom10.org/index.php?topic=55.0