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

[Vitreous]

I don't think I can go much faster than 1-1.5fps pre-rendering 1080i content :-( on a 2.2Ghz i7 quad core.

That seems slow. Are you using a suitable preset? "Super Fast" is where to start, there isn't so much need for precision on such high resolutions. Typically you need better and better presets the more you intend to upscale. As you don't usually upscale HD, then you can use the faster presets.

Just tested on a i7@2.8Ghz and I get 13-15fps pre-render speed on 1080i with the defaults on MeguIVit 1.0 beta 3. Second pass (x264) is slower at 9-10fps. Done in a single pass (no pre-render) at 4 & 1 threads I get 6-8 fps, which shows that removing pre-render can be an advantage for HD if you can get it stable. My machines are not typical, I have some more recent plugins, and the video was fairly simple content, but this shows that your figures are off somehow...

Edit: One other note, you sometimes need to click the "Switch Parity" checkbox on the "Advanced Config" tab when ripping Blu-ray. Do this if the output is jumpy, not smooth (frame order is 2,1,4,3,6,5 etc.)

 

[Vitreous]

Follow up post from isityours's Tomoe re-encode.
You might want to re-encode a rip to make it easier to play or make it work on a particular hardware device. You might reduce the resolution, or perhaps to use Fast Decode x264 settings on a 1080p rip. You can do this easily in the latest MeguIVit (1.0b3) One-Click:

- Go to One-Click, drag your MKV/MP4/whatever in
- The audio should be automatically selected below. However, there is a bug in the audio extraction currently. If you get an error later on when you press "Go" ("Object reference not set to an instance of an object") then demux the audio manually and select that file in the Audio Track 1 box (I'll fix this when I can).
- In the "Advanced Config" tab change the output resolution to what you want (or keep it the same if you're just making a fast decode 1080p rip)
- In the "Custom Processing" tab change the Core process to "Progressive: Post Processing"
- In the "Encoder Config" tab check "Keep original track" under audio if you don't want the audio to be re-encoded. Or "Config" the audio settings if you do want the audio re-encoded
- You can switch off Pre-Render if you like to save disk space, but performance may be poor/unstable on HD - try it each way and see which is best
- You can also tweak the x264 setting. It will have automatically selected something sensible for your resolution, but you might want to change it, e.g. to select a "Fast Decode" setting for 1080p
- You can also choose MP4 output on the "Encoder Config" tab, which might be more compatible for hardware devices.
- Press "Go" and you should get a re-encoded / resized rip in a couple of hours.

Only limitation is that you can't change from 60fps to 30fps with this method (unless you start manually editing scripts).

 

[isityours]

Only limitation is that you can't change from 60fps to 30fps with this method (unless you start manually editing scripts).

the explanation for that is here, and is simple to follow. thanks again vit.

 

[hofct]

Only limitation is that you can't change from 60fps to 30fps with this method (unless you start manually editing scripts).

It solves one big problem in viewing my IVs. Some of them are just too complex for viewing in the iOS devices (eg. Bitrate too high, incompatible H.264 profile....etc.).

Just tried few 1080p encoded mkv, use the suggested "post-processing" re-code the video down to 720p mp4, all playback smoothly on my iPad (using the app "AirVideo")....

Big time savers...Thank you so much!! :yahoo:

 

[anandneemish]

Changing default settings

Vitreous,
AWESOME! I've only been playing with the latest beta for a month and I really like what you have done. I can now set levels etc with a few clicks instead of mucking with text configs.

I have a couple of questions about streamlining my workflow.

To compress a rip, after clicking "One Click" I always do the following:

Under General:
- I select location for the output (located on a different disk than the source)

Under Advanced:
- I select yet another different disk for working directory.

Under Custom:
- I select Single (Frame Rate) most of the time unless it's special DVD.
- I select "1" for Source Match
- For levels, each DVD is different and I make adjustments accordingly

Under Encoder:
- I always de-select "Add pre-rendering job"
For some reason, pre-rendering always causes my jobs to crash. Since I have a fast machine, not pre-rendering works for me.

My first real question is: is there anyway to set the defaults so I can reduce the number of clicks. For example, is there a config file where I can specify the default location for output files and working dirs? Can I default to no pre-render? Can I default to 1 for Source match? etc.

The reason is that I have now accumulated a largish library of DVD rips which I want to clean up and compress to save disk space. So normally I set up a queue of several jobs. After inputting the configs for 10 disks at a time, it starts to get really old.

My second real question is: is there an easy way to script a batch process? What I mean is this. If something hiccups and MeguVIT gets thrown into an error state (such as when I forget to de-select pre-render), or when Windows decides to update and re-boot my machine, I have to go through the entire set up again. Many repetitive clicks. This second question becomes less important if the workflow is more streamlined a la the first question.

Thanks so much again.

 

[Vitreous]

Next version, which I'm part way through, allows you to save presets, which answers the first question. I haven't considered batch processing. As each rip takes a long time, it doesn't seem a major priority. I'm not sure how a batch process would help you if you get a crash...

However, work on MeguIVit has been slow as I'm occupied with something complex and completely unrelated. I've been able to find time for ripping because that mainly takes machine time, but I need to be much less busy to do serious coding development. I will get back to it though...

 

[Vitreous]

Just an alert to those who use mkvmerge manually, which came up after a problem with one of CMoarIdols rips.

[Edit:]
They introduced header compression (also called header stripping) into mkvmerge in about version 4.5. It is switched on by default. But this feature causes some hardware players to choke on the MKVs. So mkvmerge creates potentially incompatible MKVs unless you explicitly tell it not to. Dunno why they've done this since the compression gained is minor...

Anyway to avoid the potential problems, open mkvmerge and go to File>>Options. Then under the "mmg" tab check "Disable header removal compression...". Then close mkvmerge to save that setting.

 

[shank]

Hi,

I am using MeguIVit for the first time and having issues getting it to complete an encode.

I downloaded beta 3 and followed the installation instructions posted in the thread. I then followed the picture tutorial, so all I really did was drag and drop the .vob file as the input, and left all settings at default.

Initially I received a "missing msvcr71.dll" error (I forget which exact step in the status window), but rectified that by grabbing the dll and dropping it into my sysWOW64 folder as described by Blackdance in post #172 of this thread.

I no longer received that error, but then when the status window shows it is encoding video, I got a blank Runtime error dialog window like Monteyuma describes here in post #448 and this is my current problem I'm unable to resolve. I read several pages past that and couldn't find a real solution as to what was causing it.

I followed your advice from back then and installed the visual c++ redistributables in order from 2005, 2008 and 2010 and tested it after each install. After installing 2005, the error dialogue window was no longer blank and now I can see it is a runtime error concerning mencoder.exe (screenshot attached below). Since it seems to be a problem concerning mencoder, the next thing I tried was downloading the latest Mplayer and dropping the latest mencoder.exe into meguIVit. I noticed the mencoder.exe included with meguIVit is only 17KB and the latest one included in Mplayer is almost 17,000KB. I didn't get the runtime error, but got the video encode still aborts with an error within the Megu log window that says:

-[Information] [8/12/2011 11:57:29 AM] Job commandline: "C:\meguIV\MeGUI\tools\mencoder\mencoder.exe" "E:\DVD\VTS 01 1_Rip.avs" -o "E:\DVD\hfyu_VTS 01 1_Rip.avi" -of avi -forceidx -ovc lavc -nosound -lavcopts vcodec=ffvhuff:vstrict=-2:pred=2:context=1 -nofontconfig
-[Information] [8/12/2011 11:57:29 AM] Encoding started
-[Error] [8/12/2011 11:57:29 AM] Process exits with error code: 1
-[Information] [8/12/2011 11:57:29 AM] Standard output stream

though I didn't expect that to work, given the file size difference of the executables. So, I can at least say that given this troubleshooting, I believe I've narrowed down our problems to mencoder. Has there been anymore information on what's causing this issue? Those posts I linked are from Nov 2010.

This is on Windows 7 64bit
8 gigs ram
90 gigs free on that drive

(Thanks for all your work on this, Vit. Your work will definitely improve the quality of rips everywhere)

 

[Vitreous]

I am using MeguIVit for the first time and having issues getting it to complete an encode.

That 17KB Mencoder isn't the real executable, it's a kind-of placeholder for the real file, which is extracted when you run MeguIVit. You shouldn't replace that small file. Delete your sandbox and start again.
- A first thing you can try: when setting up a One-Click rip go to the "Encoder Config" tab and check "Use FFmpeg for pre-render encoding". That will use FFmpeg instead of Mencoder. I don't think that's the problem, but you could try it. If it doesn't work, uncheck the box because Mencoder is faster.

I've seen this blank error message on Win 7-64 now myself. For me it was caused by threading bugs in Avisynth, which is the video scripting language used inside MeguIVit. Unfortunately the Avisynth developers are not very interested in multi-threading and don't care much for fixing the issue. This is pretty dumb in my opinion given the processing demands of video editing and the fact that everyone is multi-core now...

So what to do? First we need to identify if it is actually a threading issue you're experiencing:
- Set up a MeguIVit one-click rip and go to the "Custom Processing" tab.
- Uncheck "Auto" next to "Main Threads" and decrease the main threads value to 1
- Test the rip. It will be slower than normal, but do you get the error? And is it immediate or after a while?

Report back and I can suggest what to try next. BTW is it HD that you're processing? And what CPU do you have?

 

[shank]

ok, I deleted the sandbox and extracted a fresh meguivitb3 sandbox.

The first test by checking ffmpeg results in the same runtime error dialogue, it just points to ffmpeg.exe instead of mencoder.exe.

I unchecked that ffmpeg setting to put it back to its original setting and tried the second test, unchecking auto main thread and dropping it to 1. But now i get an error before it gets to encoding the video. When the status window shows it's "Finalizing Preprocessing", I get an error "cannot open video input. the file e:\blahblah.avs cannot be opened. Error message for your reference: The script's return was not a video clip." Then a second error that basically says the same thing, that says there's an error in the AviSynth script that the return is not a video clip.

I feel like i did something wrong or I'm overlooking something simple to cause this new avisynth error, but I've tried it multiple times. I can recheck Auto by the Main Threads settings and there's no AviSynth error. I uncheck Auto and drop it to 1, then I get the Avisynth error about the return not being a video clip.

The project is standard def. The vob is ripped from a DVD and the video is 720x480, 4:3 AR.
The cpu is a PhenomII x6 1090T (6 cores at 3.2ghz).

 

[Vitreous]

Sorry that was my mistake. I forgot about a bug that I have since fixed in my current development version. Let's fix it on your version:

- Run MeguIVit, and go into One-Click
- Select the "Advanced Config" tab
- Next to the "Avisynth Profile" you should see "[Vit] Custom Processing", then a Config button. Press the Config button.
- You'll see the avisynth script being used. Scroll to the bottom and near the end you will see a line that says:

(Inc_MainThreads != 1) ? Distributor() : NOP()

- Replace the NOP() with the word last so it reads:

(Inc_MainThreads != 1) ? Distributor() : last

- Press the "Update" button at the bottom, then press "OK"
- Now quit right out of MeguIVit, which will make the change permanent (you can verify that the change has been saved into the profile when you rerun MeguIVit if you wish).

Now try the 1 thread test again.

 

[shank]

The fix to the Avisynth script worked. I no longer get the Avisynth error when set to use 1 main thread.

However, I get the runtime error when encoding video again. Before this troubleshooting, it consistently happened around the 40 frame mark. Now it happens consistently around the 290 frame mark with these settings. Also noteworthy is I guess the blank runtime error window was not actually fixed by installing the visual c++ runtime redistributables, because this runtime error when encoding video is blank again.

 

[Vitreous]

I have been able to consistently reproduce that blank dialog crash myself, with just 1 thread. That means it may not be to do with threading [although it is certainly to do with avisynth or its plugins regardless of the error message blaming something else]. I've attached an updated avisynth.dll that fixes it for me.
- Go into the Sandbox folder to this location:

\Sandbox\meguIV\1.0.1.1\Virtual\MODIFIED\@SYSTEM@

- Overwrite the avisynth.dll there with the one attached to this post
- See if that fixes your problem

 

[shank]

I wanted to check in, since troubleshooting from this point forward will take big chunks of time.

That updated AviSynth dll appears to resolve the original mencoder.exe runtime error!

However, now I'm getting a different crash several minutes into video encoding. I have tried a few times and have received a couple different behaviors. The crash happens about 15 minutes into the video encoding. I'll either get a BSOD referencing a system service exception or just the mencoder.exe crashes and i received the usual win7 error dialogue box "this exe has crashed, check online for solution or Close the program".

 

[anandneemish]

Next version, which I'm part way through, allows you to save presets, which answers the first question.

No rush. I love your work regardless.

I haven't considered batch processing. As each rip takes a long time, it doesn't seem a major priority. I'm not sure how a batch process would help you if you get a crash...

There are a couple of answers here, so let me tease it apart.

1. Batch processing is useful when one starts a rip just before retiring to bed. Let's say that a rip takes 3 hours. That means the machine is idle until I get up. I accidentally discovered the queuing feature and it has been a godsend. I set up a bunch of rips to compress while I'm sleeping, or while I'm at work. It's like Christmas to come back to a bunch of finished jobs. (Although it's kinda tedious to go back and review each one to see if the level and sharpness settings came out right).

2. Having a script would be helpful in two cases a) if a job crashes, I do not need to re-enter all the parameters for the subsequent job, and b) in case I need to re-encode to tweak settings. Modifying a script would be easier than going the tedium of manually clicking on all the settings.

ANYWAY, I must say that the use cases I presented may not be very common. I totally understand if you don't implement these.

As always, a big fan of your work.

 

[Vitreous]

shank: Now that sounds like the standard multi-threading crash. Occurs randomly. Now as you have a 6-core machine the system will be defaulting to 12 threads. That might be too many, so try reducing the Main Threads to 8 (or to 1 again to confirm whether this is multi-threading related). But as you're getting a BSOD, it suggests that your system might not stable, you shouldn't get anything worse than an error dialog box. MeguIVit is a major stress test for your machine, CPU, memory and harddrive. I wonder if your system is overheating, or maybe you have a bad memory stick?

____

anandeemish: If you get a crash you can go into the MeGUI job queue, find the job that says "Error", double-click it until it says "Waiting". Then press "Start" and it will have another go at it. Or just press the delete key and remove all its dependent jobs when prompted, then press "Start" to continue onto the next rip in the queue.

Coupled with customizable presets (which will speed up setting the initial parameters), won't that achieve what you need?

 

[shank]

and yep, the last problem was because of the overclock on my cpu. That's crazy because I had read up extensively on overclocking my 1090t. With a better third party cooler, I had it at 3.8GHz at 1.45 vcore and that was a common point to hit from my research. There were a lot of people getting 4ghz on a normal fan cooling solution, but mine wouldn't get that far stable. I've tested it with hours of Prime95, a day and a half straight session of gaming, streaming (involves video encoding) my pc gaming to justintv with no errors or crashes, so I dismissed the oc initially. I put it back to the default 3.2ghz at 1.35 vcore and:

We have success! I was able to finish an encode in 2hrs total time (of a 40 min movie) using default settings after all this troubleshooting.

I compared the quality of this encode to one I made of the same dvd a few years ago and the new one is far far better. One of the key quality differences is from this encode being 60 fps. I've never seen this done before and I'm interested in how this is done since I thought source media (DVDs, bluray, etc) are at 23/29.97 fps. It's crazy that additional frames are created, doubling the amount of original frames at some step in this process and it appears perfectly smooth. I notice no quality problems from these created frames to make the video run at 60 fps. And with 60fps, the movie and motion is so smooth, it looks like you're watching live action.


So to summarize for users that cant get MeguIVit beta3 to run on Win7 64bit, this is what I had to do to get it working after the standard setup:

1. "Missing msvcr71.dll" error:
I downloaded the dll from dll-files.com and copied it to the

c:\windows\syswow64

directory.

2. Crashes during the video encoding:
Sometimes you'll see a runtime error pointed at mencoder.exe. Sometimes the error window is blank with no info at all. Either way, grab the updated AviSynth.dll from Vitreous' post here and replace the one in

\Sandbox\meguIV\1.0.1.1\Virtual\MODIFIED\@SYSTEM@

That's all you should have to do.


Thanks for all the help, Vitreous. Looks like we got this thing figured out.

 

[Vitreous]

Yes, I've had a few people observe that multi-threaded QTGMC (the core of MeguIVit) is a tougher stress test than Prime95. It's because it accesses much more memory and hits the harddrive continuously as well as the intense CPU activity. I'm quite proud ^^

Glad to hear that you sorted it out. And thanks for the simple summary of tweaks you needed. I suppose I should release a beta4 with those changes...

Regarding 60fps, an interlaced stream is 60fps but in an unusual way. I explained it in this old post (back when there was still some resistance against 60fps rips). It's not completely inventing frames, it's filling in missing lines, although that's still pretty tough to do well.
Creating entirely new frames can be done, that's what the "Synthesize In-between Frames" option does on the One-Click "Custom Processing" tab. Switch that on and you'll get a 120fps rip! However, that setting is operating sub-par at the moment, I have a better version of it. Not that 120fps rips are especially useful, goes beyond what the eye can perceive for most video (useful for sport footage perhaps) and few monitors can display it....

 

[shank]

Neat, so if the source is interlaced (which up until this point, I hated running into interlaced sources) this setup can make a 60fps encode. Which is good for gravure dvds. Not so common with ntsc movies. Though I have dvd's in mind. I haven't looked into blurays yet, so I'm not sure if the video techniques are the same.

I have sad news regarding the meguivit setup though. Looking back, outside of that silly missing msvcr dll, the only real problem was mencoder crashing which I believe is due to Avisynth. This updated avisynth.dll (2.6.0.2) helps, but isn't completely fixed. The original will crash every time shortly after the encode begins. This updated one fixes the guaranteed initial crash, but it can still randomly crash during the encode. I got through a couple 40 min source encodes with one crash and didn't think too much of it. But now I am working on a source that is 90 minutes long, have gone through 3 attempts and it has crashed every time at different points during the video encode. It appears you just have to get lucky that your encode doesn't hit whatever bug this is in avisynth and hope it finishes. Very frustrating when working on longer material now, where the video encoding takes several hours and it can crash at any point... like 10 minutes before it's done on the third attempt T_T.

I looked around and that is the latest avisynth.dll and it's dated 7/19, so hopefully that means it is currently being worked on.

 

[isityours]

in the beginning i too had problems with random crashes. since about 0.2.1 i have not had more than one or two and since switching to beat3 have not had a single one (that wasnt my fault).
i am always careful to:

encode on an internal disk that doesnt contain the os/os partition.
avoid cpu stress during encoding
avoid data transfers to/from the disk being used accessed during encoding (again refraining from using the OS partition disk).
use the prerendering feature (this is actually because i do dual 30/60 rips but stability did also improve).

i also reduced the clock (which you have already done)

this is all very elementary practice but it has had me crash free for at least 6 months (20-30 encodes)