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

[Vitreous]

Try deleting the sandbox and run meguIV without it. It will create a sandbox folder when it runs - maybe it's appearing somewhere else...? If so, quit out and find where it is.

 

[snakeboy]

OK, tried deleting it and running meguIV on it's own. It creates the sandbox folder, no problem. Exit, delete sandbox folder, extract the one from the .rar, restart and still no Vit profiles. Some sort of path issue I suspect for two reasons, firstly, I have "normal" Megui installed and I also have sandboxie software installed. Perhaps between the two of them there's some confusion as to where to look.

And now the good news: All I did was MOVE the C:\MeguIV\* to E: which is a SATA3 drive. Extracted nothing new, changed nothing, just ran it and viola, I get Vit profiles! So the short answer is that some issue is preventing it from running off C: or D: (both SSD drives - coincidence?), regardless of the reason, I have no problem running it of E: drive. So, problem solved? Well, not quite.

After playing with the (30fps) vit profiles a little, at first ALL would crash with mencoder. I then switched to the first x64 option, and that problem went away.
Now they all seem to work just fine EXCEPT for "A: Placebo" and "B: Very Slow". By changing NOTHING else except the one click profile I cannot get these two to work. I get:

The file E:\TEST\VTS 01 1.avs cannot be opened.
Error message for your reference: FFT3DFilter: Can not load FFTW3.dll

Followed by:

Your AviSynth clip has the following problem:
Error in AviSynth script:
FFT3DFilter: Can not load FFTW3.DLL !
(E:\test\VTS 01 1.avs, line 7)
Continue Anyway?

Here's the .avs:
[hide]global MeGUI_darx = 52
global MeGUI_dary = 25
SetMTMode(3)
LoadPlugin("C:\meguIV\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("E:\TEST\VTS 01 1.d2v")
SetMTMode(2)
QuickTGMC( Preset="Placebo" )
SelectEven()
crop( 26, 74, -68, -74)

Spline36Resize(720,496) # Spline36 (Neutral)
Distributor()
[/hide]

Again, for the record, changing NOTHING but the profile, this clip encodes from start to finish with all the other 30fps profiles EXCEPT for Placebo and Very Slow. And yes, the file FFTW3.DLL is present in:

E:\MeguIV\Sandbox\meguIV\1.0.1.1\Virtual\MODIFIED\@SYSTEM@

I'm guessing that this version of FFTW3.DLL is not compatible with 64bit Win7 Ultimate...?

Any idea's?

 

[no__One]

Hello Mr.Snakeboy, I had the same problem and Mr.Vitreous totally met my expectations. I'll let you read his solution on the attached link:

http://www.akiba-online.com/forum/showpost.php?p=974620&postcount=414

PS: My question is just above his answer. This should relieve your pain. :tea:
Regards.

 

[Vitreous]

I suspect Iceman is correct to highlight my earlier solution. The key is to put the dll in "SysWOW64". I probably didn't notice this as I already have the dlls elsewhere. [I should test on a clean VM...].

 

[snakeboy]

Thank you both! Moving FFTW3.DLL to "SysWOW64" did the trick!

Question: I was under the impression that when something runs in a sandboxed environment that it is independent of the host OS and the DLL's available there.
I would think that placing the FFTW3.DLL somewhere within the Sandbox tree would be a better solution, no? Could this file not be included in MeguIV (or MeguVit)'s sandbox folders in future version(s) in order to avoid having to inject files into the host os to make it work?

I would like to see it be as idiot-proof as possible, and while providing a missing FFTW3.DLL may not be rocket science, I'm sure there may be those who would rather just "give up" at the first failure to run without this file...

 

[Rollyco]

The build process can handle FFTW3.DLL for all platforms just fine, but the haphazard nature of transplanting a Sandbox folder is troublesome.

 

[snakeboy]

How about a new build of MeguIV incorporating this and all the Vit Profiles? I think I saw this mentioned elsewhere. MeguIV V2.0 ?

 

[Vitreous]

FFTW3 is already in the Sandbox "System" folder. Maybe just putting another copy in a SysWow64 folder would do the trick. I'll give it a go in the next release.

 

[guy]

Heehee, I just got this in the mail.

[FULLATTACH]398334[/FULLATTACH]
[FULLATTACH]398335[/FULLATTACH]


It's a completely new build (LGA1155, not compatible with any previous Core products), so I'll be busy getting it set up. Just to note: early benchmarks put the Sandy Bridge i7-2600 (quad-core) at nearly the same performance as the previous i7-980X (hex-core), for less than 1/3 the price. Of course, I can't wait to post some QTGMC numbers.

 

[astrayred]

Heehee, I just got this in the mail.

[FULLATTACH]398334[/FULLATTACH]
[FULLATTACH]398335[/FULLATTACH]


It's a completely new build (LGA1155, not compatible with any previous Core products), so I'll be busy getting it set up. Just to note: early benchmarks put the Sandy Bridge i7-2600 (quad-core) at nearly the same performance as the previous i7-980X (hex-core), for less than 1/3 the price. Of course, I can't wait to post some QTGMC numbers.

OMG!!! Thank you thank you!

I was considering getting a 2600K myself, and the only thing holding me back is that I don't know how fast it will be at QTGMC!

Looking forward to those numbers!

BTW, if you don't mind, could you give it a quick go at these specific settings?

QTGMC: Preset "Slower"
x264: --crf 23 --preset "slower" --tune "film" --aq-mode 2

Because that's the settings I usually use. Thanks!

 

[guy]

BTW, if you don't mind, could you give it a quick go at these specific settings?

QTGMC: Preset "Slower"
x264: --crf 23 --preset "slower" --tune "film" --aq-mode 2

QTGMC I can test, but you'll need to tell me what media you usually encode (a 720x480 DVD frame processes much faster than a 1920x1080 full HD frame, naturally).

I will skip reporting any x264 performance numbers for now, because 1) x264 is used as a benchmark on professional tech review sites already (and its accuracy will vary with the type of media you're using, just as above); and 2) the new 2nd gen Core i-series have a feature called Intel Quick Sync Video, which combines the CPU cores and integrated GPU cores to enable hardware-based H.264 encoding/transcoding. I don't necessarily intend to switch (depending on how much control over H.264 encoder options I have), but I'm really interested in seeing how it performs.

Intel Quick Sync Video demo:
[youtube]vHpz04qPX-U[/youtube]

Some early performance numbers for Quick Sync, nVidia CUDA, ATI APP, and software:

http://www.tomshardware.com/reviews/sandy-bridge-core-i7-2600k-core-i5-2500k,2833-5.html
http://www.anandtech.com/show/4083/the-sandy-bridge-review-intel-core-i7-2600k-i5-2500k-core-i3-2100-tested/9

 

[astrayred]

Oh, the media I need you to help me test is just plain old 720x480 DVD media.

With regards to 1), well I would need have some numbers of encoding with x264. That's because I usually don't use a lossless intermediate (add pre-rendering job in MeGUI), I just encode straight away with x264. Also, even though x264 numbers were posted on tech sites (I have seen those numbers, and they are impressive!), they typically use the TechArp benchmark which uses 720p media, so I can't really extrapolate from there.

For 2), well I'm sure you know this already but you need a H67 (or the upcoming Z68) chipset to use QuickSync. Also, it doesn't use the GPU cores, but dedicated transcoding hardware.

Quick Sync is indeed fast, but quality is another concern. It's getting a lot of bashing from D9, but I do think their bashing is rather unsubstantiated. My main concern though is that most likely you will not be able to feed Avisynth scripts into it. I doubt Cyberlink will add support for Avisynth scripts anytime soon. But for simple transcoding, like converting a video to watch on your phone for example, I think Quick Sync is great.

 

[guy]

Yep, already got H67. Anandtech reviews seem to say quality is better than traditional GPU transcodes. But we'll have to see how it stacks up to x264. As for Avisynth, I already encode using pre-rendering (to HFYU raw), then feed the raw into x264, so it wouldn't be a significant change in my workflow.

Anyway, I'm not committing to anything yet, just excited to see what's possible with the new hardware.

 

[guy]

Sorta got my new system up. Clean install of Win7 x64. Running meguIV 1.0.1.1 with Vit 0.2.1, and getting the same "blank error" as monteyuma (#448). I have the following VC++ Redistributables installed: 2005 x86, 2005 x64, 2008 x86, 2008 x64, and 2010 x86.

Crash occurs on both mencoder and ffmpeg pre-rendering, repeatably after processing 19 frames. MeGUI log provides a helpful error message: "Process exists with error code: 3" (google yields no hits).

Did this get fixed and I just missed it, or?

 

[Vitreous]

Did this get fixed and I just missed it, or?

Ah, you'll make a good victim test subject for something I'm intending to add to the new MeguIVit. This is a zip file with most of the plugins required for MeguIVit:

http://hotfile.com/dl/97202348/f25a2b3/AviSynth_Plugins.zip.html

They contain a tentative hack to get round the threading problems of AviSynth. They also have no dependencies on redistributables or similar. There are two versions, compiled with Visual Studio 2010 and Intel C++ 2011. The Visual Studio ones should be more reliable, but slower (Intel optimizations are rather aggressive).

Put one set in this location, overwriting the dlls already there:

Sandbox\meguIV\1.0.1.1\Virtual\MODIFIED\@SYSDRIVE@\meguIV\Avisynth 2.5\plugins

Of course this won't help if it's something to do with the setup of your new rig...

 

[no__One]

This suggestion may seem stupid but did you install the Microsoft. NET Framework + latest updates? uzzled:

Regards.

 

[guy]

Script error: there is no function named "MSuper"
(QuickTGMC.avsi, line 411)

Happening with both VS and IC compiles; dropped one set of them on top of 0.2.1 sandbox. Am I missing something?

This suggestion may seem stupid but did you install the Microsoft. NET Framework + latest updates?

Already got latest .NET Framework 4 + updates via Windows update, still no luck (same "blank" crash, happening after 19 frames).

 

[no__One]

I'm really sorry that my suggestion would you have been useless.

I tried to get a reply by PM from users who seemed to have managed to encode DVDISO not completely downloaded.
Unfortunately, none of them answerd me. :miserable:

Let me ask the question openly.
How to encode a DVDISO non 100% downloaded ? uzzled:

Thank you in advance for all your advices.
Regards.

 

[Vitreous]

Script error: there is no function named "MSuper"
(QuickTGMC.avsi, line 411)
Happening with both VS and IC compiles; dropped one set of them on top of 0.2.1 sandbox. Am I missing something?

Odd, that's what would happen if mvtools2.dll wasn't there...?

First, I should note, you shouldn't be making any new folders in the Sandbox folders, the new files overwrite the old. Also delete and re-extract the sandbox folder each time you try something new
A few other ideas:

1. I should have noted to delete "mt_masktools-26.dll" from that folder in the sandbox. I've provided a -25 version which replaces it.
2. Check that mvtools2.dll has been copied over.
3. Try keeping the mvtools2.dll from the original sandbox

 

[guy]

First, I should note, you shouldn't be making any new folders in the Sandbox folders, the new files overwrite the old. Also delete and re-extract the sandbox folder each time you try something new

Yep, that's what I did. I'll check the other ideas.


In the meantime, I took the auto-generated avs script (for the pre-render), added SetMemoryMax(1024), and fed it back into Megui; the blank error crashes have stopped for now, but I've only been testing on short clips so I have no idea how stability will be for full length features.