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

[Beck38]

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.

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.

[mjmacky]

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.

[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.

[mjmacky]

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:

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.

[Beck38]

'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!

[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.

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.

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"

[Beck38]

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.

[Beck38]

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.

[Beck38]

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.

[Beck38]

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.