meguIV: The Official Akiba-Online DVD Encoder (v1.0.1.1)

[Vitreous]

From another thread (thanks isityours):

deinterlacing ran at about 23fps (slower than 0.1.3/4 but on par with a first rip on a new sandbox which seems to be a little slower for me anyway). second pass started out at almost 100fps but cycled down to about 50 and then up to about 60 (roughly a 10% speed hit) so it took about an hour to finish. explorer crashed toward the end of the first pass and i restarted it successfully between first and second pass. the rip completed without incident. thanks vitreous, looking forward to the new meguIVit version.

This version is intended as an interim stability release, so that Explorer crash concerns me a little. Was it a situation where a window locks up and you need to kill explorer.exe to get things back? In any case I'm hoping it's unrelated as it didn't affect the rip.

Regarding speed:

• The first pass is certainly slower, by about 10% or so. That will be the price of stability (hoping that it does help in that regard)
• I've measured both speed increases and decreases in the second pass depending on rip. This version uses a newer x264 encoder (r1745 vs r1538), so it depends on what changes are in there.
• You can try switching off the pre-render pass (during "One-Click", in the "Encoder Config" tab). This will do everything in a single pass - it may be faster. The 2 pass system was added for stability but it may not be needed for some people now. More powerful machines have most chance to benefit. Weaker machines may run out of memory and crash. Just try it. Obviously the fps will go down, but the overall time may go down too having one less pass. You can make an estimate based on your typical encoding fps: get your calculator out and compare (1/FPSPass1) + (1/FPSPass2) with (1/FPSSinglePass), the smaller number is faster. [In fact overal rip time is that number * length of vid in seconds * output fps (30 or 60)]. Going one pass also removes the need for the huge intermediate file and saves wear on your disk drives. It also gives you an idea of final rip size much sooner so you can change settings if necessary. If anyone tries this, please report your experience.

The next version of MeguIVit will have some more interesting GUI features, but as ever, time is the enemy. I'm just using this release to (a) test whether to permanently switch to ffmpeg encoding, and (b) check that my own builds of MeGUI are working correctly.

 

[isityours]

using x64 MPC-HC today caused an explorer crash and MPC-HC also crashed itself a couple of times (when adding specific files). i was watching something using it when the crash occurred last night so i think it is safe to assume that was the cause. while explorer was "not responding" i was able to move open windows but couldnt select anything on the task bar.
the fact i was able to restart explorer (i timed it right in between first and second pass) without causing meguIV to crash speaks to its stability (or not, depending on which running processes are affected by restating explorer. i dont know).
i will give your suggestions re first/second pass a go when i next encode something.

 

[no__One]

Hello,

It's been a while since I embarked on a quest ... which for me boiled down to almost win the holy grail :hero:

But which wonderful project could transcend and animate me ?

Understanding and the crazy idea of bieng able to, as some do-gooders (Mr. Vitreous, M.isityours Mr. Kaleb 2727 and many others), to bring my stone to the edifice, making my small contribution to this wonderful community that is AO.

I pause a few seconds to tell you (but I think most of you will have guessed long ago, English is not my mother tongue and thus my level is rather poor, even ridiculous, I apologize for phrases that might seem strange and different turn with no sense ...) :bow-pray:

Ps: GooGle is not really my best friend in this case... I have lost a lot of time to correct all GooGle's non sence sentences... :silence:

After this Long prologue very interesting, I propose you the main dish...

I am absolutely very, very disappointing. :furious:

I know Mr. Vitreous works for the good of all and above all provides us with a formidable and powerful tool to bring out the quintessence of any video... but ... but ... I can not help feeling frustrated ... damn and flute ... :innocence:

First, I spent these last days to do so many tests with meguIVit 1.14, I came to wonder if it's too late to go to sleep or too early to go to work ...
I had lost all sense of time so I applied myself to my task. A bit too much... :dotdotdot:


Second, I learned at that time that Mr. Vitreous had released meguIVit 0.20 (beta).
I was, I confess, totally disappointed, confused and annoyed fair ...
All my work has swept by a wave of a hand...

I had nearly completed a dissertation topic which could be:

"meguIVit, or the art of revealing to the world the joy of the encoding by our master at all of us: Mr. Vitreous". :exhausted:


I was most saddened man on Earth ... (Well, almost certainly in fact ...) oor:

Well, I will still expose what seems interesting of all the tests I have performed. :miserable:

I can confirm it and for sure what Mr. Vitreous told about 2 pass:

The 2 pass system was added for stability but it may not be needed for some people now. More powerful machines have most chance to benefit. Weaker machines may run out of memory and crash immediately.

In fact, whenever I did an encode by this method I never had a single crash while if I use method 1 Pass was the random crash insured.

Finally, after exposed my ridiculous little report, I feel even more useless and ridiculous than my report.
I'll go out and calm down because I'm extremely tense and frustrating ... issed:
....
...
..
.
Second degree inside...
Ps: M.Vitreous, your new avatar suits you perfectly, congratulations. :tea:

 

[Vitreous]

Errr... Thanks IceManZ. Can I check that this is what you said:
- Version 0.2.0 works without problems in 2-pass mode, but it crashes randomly in 1-pass mode.
Please answer simply or it doesn't help me.

M.Vitreous, your new avatar suits you perfectly

Aki is in a Halloween mood...

 

[no__One]

I apologize if my comments could be misleading. This is exactly right.

The only problem, as far as I'm concerned is how to use the pre-render pass "One-Click" if I want to encode something other than DVD since meguIVit only take VOB format in that mode ? uzzled:

If I did not have pre-render pass, I have everytime a crash ... :notagain:

 

[Vitreous]

The only problem, as far as I'm concerned is how to use the pre-render pass

Don't worry, this is not a problem. Unchecking "Pre-Render Pass" might make things a bit faster on powerful machines, that's all. It really doesn't matter if you can't uncheck it safely on your machine.

I am making a version of MeguIVit that can One-Click Blu-rays, Avis etc. That will come in the future. It has no connection with the pre-render pass.

 

[no__One]

I immediately feel much better ... so relieve...

my dream ...

a version of MeguIVit that can One-Click Blu-rays, Avis etc.

:cheer:M.Vitreous:cheer: you are really a :hero:

I'll take my troubles patiently and quietly wait for this version comes to light.:goodboy:

 

[Authorised-BMN]

ffmpeg.exe crash

Unfortunately, ffmpeg.exe crashed when doing a 60fps 480p encoding, standard settings, light edge cleaning, with new meguIVit:

Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	ffmpeg.exe
  Application Version:	0.0.0.0
  Application Timestamp:	4cbe8749
  Fault Module Name:	mvtools2.dll
  Fault Module Version:	0.0.0.0
  Fault Module Timestamp:	4c23d514
  Exception Code:	c0000005
  Exception Offset:	000146c5
  OS Version:	6.0.6002.2.2.0.768.3
  Locale ID:	1033
  Additional Information 1:	6e59
  Additional Information 2:	2e15982db849e5762ddcd5f406947be2
  Additional Information 3:	6570
  Additional Information 4:	7cc79d3ca205be70b135a50d005e8c98

Read our privacy statement:
  [url]http://go.microsoft.com/fwlink/?linkid=50163&clcid=0x0409[/url]

My environment is 32-bit, Vista, Core Duo. It has been nearly 100% stable across all meguIV builds, until this one. I could even multi-task while encoding -- Microsoft Word, Outlook, VLC media, web browsing, Vuze and an autodownloader all running seamlessly. Literally the only things that have caused the program to hang up (but never crash) have been heavy access to external hardrives (Vuze handling 15 simultaneous streams on an external) and, oddly, Flash/Adobe notifying that it needs an update. That update notification always stops the program dead in its tracks -- go figure. This is one reason increased speed has never been an issue for me -- sure 16 to 24 hours to encode, but it was never really in the way. Oh, well. I hope this is helpful.

P.S. The crash was about 4.5 hours into a 6-hour first pass. I was not running anything else at the time.

 

[Vitreous]

Unfortunately, ffmpeg.exe crashed when doing a 60fps 480p encoding, standard settings, light edge cleaning, with new meguIVit:

Disappointing... :sigh: :notagain:

Did you leave the Pre-Render Pass checked?

I've considered this outcome and have thought to allow a choice of mencoder or ffmpeg in the GUI. FFmpeg is definitely better for me, but looks like mencoder for you. I'll do it now...

 

[Authorised-BMN]

Check

Did you leave the Pre-Render Pass checked?

Yep, I left it checked.

 

[Vitreous]

OK, here's a new version.

Download MeguIVit 0.2.1 (beta)

The changes are:

• Can use mencoder or ffmpeg for 1st pass encoding. It defaults to mencoder. If you get mencoder.exe crashes then go to the main window and select Options>>Settings. Then check "Use FFmpeg for pre-render encoding" and it will use ffmpeg instead. Use whichever is more robust for you - mencoder is faster.
• QuickTGMC has moved up to version 2.51, this one includes a bunch more speed tweaks.

If you try this version, please feedback here - thanks!

 

[bodyseeker04]

I tried the ripping using MeguIVit 0.2.0 (beta) on a short ISO,
x254 [Vit] 480p 60fps standard
[Vit] 60fps D: Slow + Light EdgeClean
and it was fine, no crashes at all. :grassdance: I'll post it as soon as i finish uploading it. I can't really comment on the speed 'coz my machine is awfully slow. :notagain:
Great job Vitreous! your work is truly appreciated! :cheer:

 

[Vitreous]

OK, here's a new version.

Away from stability and back to speed. The 0.2.1 version above marks a milestone for me, I can now do the 1st pass rip in realtime, i.e. it rips at 30fps for 30fps vids and 60fps for 60fps vids. That's on "D: Slow" without edge cleaning (i.e. original MeguIV style). I cheated slightly and raised my OC from 4.0 to 4.2Ghz to get the 60fps figure, otherwise it's about 57-58fps.

The speed gains were mainly from tweaks to the NNEDI3 settings. Each preset ("Slow", "Slower", etc.) now uses settings that are close to, but slightly better than the original NNEDI2 settings in both quality and speed. "Super Fast" and "Ultra Fast" are exceptions: "Super Fast" now uses NNEDI3 rather than Yadif - it's an excellent preset: NNEDI3 quality at 140fps. "Ultra Fast" needed an unrelated tweak to remove some excessive motion blur and is a little slower than before.

 

[Authorised-BMN]

Stability restored

OK, here's a new version.

Download MeguIVit 0.2.1 (beta)

Stability restored! I even did some VirtualDub resizing of other clips while a 60fps with light edge cleaning was encoding.

By the way, I noticed that the log file no longer ends up in the folder, along with the completed video and chapter file. This is no big deal to me, but I thought I would mention it.

Thanks! :grassdance:

 

[Vitreous]

By the way, I noticed that the log file no longer ends up in the folder, along with the completed video and chapter file.

It is created, but is now deleted as part of the clean up at the end of the process. You can retain the intermediate files (that log file, the avisynth scripts, the huge 1st pass uncompressed vid etc.) by going to the main window, Options>Settings, and uncheck "Delete Intermediate Files".
____

Tip for everyone: if you get a mencoder or ffmpeg crash right at the start of a pass, you might be able to recover. Go to the "Queue" tab and double click the text "error" by the failed job until it turns to "waiting". Then press "Start" at the bottom to try again. Sometimes it works fine on a second attempt.

 

[Kaleb2727]

I completed one rip using meguIVit_0.2.1 without any problems and another is close to finishing. I disabled the pre-rendering pass to see if it would save time -- the fps rate went down maybe 15% or so but without the second pass it was basically a wash. But I like not having that huge intermediate file.

 

[Vitreous]

I completed one rip using meguIVit_0.2.1 without any problems and another is close to finishing. I disabled the pre-rendering pass to see if it would save time -- the fps rate went down maybe 15% or so but without the second pass it was basically a wash. But I like not having that huge intermediate file.

Thanks for the info. Glad I'm not the only one who can get one-pass to work. Actually, I still often use two-pass because I can rip a second time quickly from the intermediate file - for a 30fps version or to try different post-processing etc. But for one-click, one-pass is good even just to save disk wear.
____

Enough people have tested the 0.2 versions now to convince me that my internal reworking is OK. I've made MeguIVit 0.2.1 the "official" release on its original page. I haven't updated the Win7 64-bit alternates though - I don't know if they're still needed...?
____

A note for manual rippers: I've also upped the latest QuickTGMC 2.51. It's already used in MeguIVit 0.2.1.

Full QuickTGMC 2.51 change list:
[HIDE]

• The default interpolator for almost all presets is now "NNEDI3" rather than "NNEDI2" (ensure you have the NNEDI3 plugin). This improves the quality and speed of the majority of presets, provided you use version 0.9.2 or above of NNEDI3.
• To accomodate the change above a number of presets have had their settings tweaked - with the objective of returning similar/better quality at similar/better speeds using the new interpolator. However, two presets are noticably different:
  • The "Super Fast" preset now uses NNEDI3 with the fastest possible settings rather than a Yadif variant as before. This reduces aliasing considerably, but it's a tiny bit slower than before
  • The "Ultra Fast" preset now gives higher quality output. Before it wasn't using any repair mode, which created much motion blur. Now it uses tr2=3. However, this means a ~6% loss in speed. Set tr2=0 for the old faster behavior
• There's a new setting "EdiThreads", which allows you to specify how many threads EEDI3 and NNEDI2/3 will use. By default they will use one thread for each (logical) processor in your system. You may get better speeds on some scripts with more or less threads (experiment). Using less threads will also use less memory, which may help some complex/HD scripts, especially when also using MT or SetMTMode. Example:
  

  QuickTGMC( Preset="Very Slow", EdiThreads=6 )

• EdiMode can be set to "EEDI3+NNEDI3", which will use EEDI3 with its sclip parameter created with NNEDI3 - this should give a slightly improved EEDI3 result (but slower). This uses more memory - so be careful not to use too many threads if you're multithreading (EdiThreads or MT). E.g.
  

  QuickTGMC( Preset="Slower", EdiMode="EEDI3+NNEDI3" )

• Another new setting is "LosslessPreset". This is only used in lossless mode - it works exactly like the Preset setting except the default is "Fast". The quality difference between the lossless presets is minor so you can move towards faster settings here. The LosslessEdi setting overrides the LosslessPreset edi mode setting. Example:
  

  QuickTGMC( Preset="Very Slow", Lossless=1, LosslessPreset="Faster" )

• The output from ShowSettings has been made clearer and a minor bug fixed in that code
• Fixed a serious bug when using lossless modes on the higher speed presets

[/HIDE]

 

[isityours]

my most recent rip using 0.2.0 completed successfully (without the prerendering file). similar to kaleb i got an average of 20fps (234,924 frames @ 3h 10min). average speed for 2 pass would take about 200min. disk wear was saved but ripping pegged the CPU at 100% whereas making 2 passes ran between 85-95%. i will try 0.2.1 when i rip something next. thanks.

 

[Kaleb2727]

Yes I forgot to mention, the CPU was maxed out at 100% -- I just noticed this as well.

 

[isityours]

tried 0.2.1 last night and awoke this morning to find the rip had taken over six hours! i thought it was another 'slow-down' but when i opened the output folder there were 2 instances of the same file. when i started encoding my computer crashed. after rebooting i set meguIV running again and gave the output file the same name as usual. this usually leads me through having to remake the d2v, audio file etc but after blindly clicking yes at the first dialogue box, encoding started almost instantly. i assume from looking at he queue file that it used the previous file in queue, then ripped the one i told it to after the crash. otherwise no problems. CPU usage was back to normal too.