meguIV: The Official Akiba-Online DVD Encoder (v1.0.1.1)
- Thread starter Rollyco
- Start date
-
Akiba-Online is sponsored by FileJoker.
FileJoker is a required filehost for all new posts and content replies in the Direct Downloads subforums.
Failure to include FileJoker links for Direct Download posts will result in deletion of your posts or worse.
For more information see this thread.
guy: Does it happen if you encode without using ffmpeg or mencoder? That is, straight away with x264?
I'm asking because I have no problems with crashing on the following 3 systems:
1) Phenom II 955
2) Core i5-450M Laptop
3) Athlon II X4-640
All running Windows 7 64-bit.
I'm asking because I have no problems with crashing on the following 3 systems:
1) Phenom II 955
2) Core i5-450M Laptop
3) Athlon II X4-640
All running Windows 7 64-bit.
Back with some numbers.
First, setup:
SetMemoryMax modification was necessary, otherwise QTGMC (pre-rendering) would crash right away. I suspect when pre-rendering is disabled, x264 encoding acts as a sufficient bottleneck to slow down the large amount of data being processed QTGMC. Older, slower systems may be exempt as the CPU acts as the bottleneck, but I'm just guessing.
However, the clip I used to test is just a short 1 minute clip (IMOM-122 intro), so I have no details about stability for full feature encodes.
Some early numbers:
30fps Slower: 23fps (0.75x)
30fps Slow: 30fps (1.00x)
60fps Slower: 44fps (0.73x)
60fps Slow: 57fps (0.95x)
60fps Super Fast: 158fps+ (2.64x) [processing was over before fps had a chance to stabilize]
None of the settings have really been tweaked for performance. But already, clock for clock (compared to Vit's 1x speed using D: Slow @ 4.2ghz OC), this chip already shows some exceptional performance, around 15% or more compared to Vit's previously reported numbers.
Sadly, the i7-2600 is multiplier-locked, and highly integrated design of Sandy Bridge means FSB overclocks are extremely difficult. Encoders with an extra $30 are advised to go for the i7-2600K part (once they're available), plus a P67 or Z68. Anandtech reported they could easily hit 4.5ghz with the 2600K, on the stock Intel HSF. [In fact, even with all 4 cores / 8 threads maxed on my 2600, the fan was still dead silent.] That's a 30% speed gain over stock frequency, which (stability aside) would bring all QTGMC speeds ("Slower" and above) to 1x or faster!
Of course, anyone thinking about a 2600K should also remember that the P67 does not offer Intel FDI and QuickSync (mentioned earlier); for that you'll have to wait for Z68.
First, setup:
- i7-2600 (3.4ghz), H67, 8GB, Intel Graphics 2000.
- Win7 x64, fully updated with all VS C++ and .NET redistributables.
- meguIV 1.0.1.1 + Vit 0.2.1, scripts modified to include:
Code:
[B]SetMemoryMax(1024)[/B] SetMTMode(3,[B]10[/B]) SetMTMode(2,[B]10[/B])
SetMemoryMax modification was necessary, otherwise QTGMC (pre-rendering) would crash right away. I suspect when pre-rendering is disabled, x264 encoding acts as a sufficient bottleneck to slow down the large amount of data being processed QTGMC. Older, slower systems may be exempt as the CPU acts as the bottleneck, but I'm just guessing.
However, the clip I used to test is just a short 1 minute clip (IMOM-122 intro), so I have no details about stability for full feature encodes.
Some early numbers:
30fps Slower: 23fps (0.75x)
30fps Slow: 30fps (1.00x)
60fps Slower: 44fps (0.73x)
60fps Slow: 57fps (0.95x)
60fps Super Fast: 158fps+ (2.64x) [processing was over before fps had a chance to stabilize]
None of the settings have really been tweaked for performance. But already, clock for clock (compared to Vit's 1x speed using D: Slow @ 4.2ghz OC), this chip already shows some exceptional performance, around 15% or more compared to Vit's previously reported numbers.
Sadly, the i7-2600 is multiplier-locked, and highly integrated design of Sandy Bridge means FSB overclocks are extremely difficult. Encoders with an extra $30 are advised to go for the i7-2600K part (once they're available), plus a P67 or Z68. Anandtech reported they could easily hit 4.5ghz with the 2600K, on the stock Intel HSF. [In fact, even with all 4 cores / 8 threads maxed on my 2600, the fan was still dead silent.] That's a 30% speed gain over stock frequency, which (stability aside) would bring all QTGMC speeds ("Slower" and above) to 1x or faster!
Of course, anyone thinking about a 2600K should also remember that the P67 does not offer Intel FDI and QuickSync (mentioned earlier); for that you'll have to wait for Z68.
Thanks for the numbers!
Just to clarify, those are with pre-rendering enabled, correct?
44 fps at 60fps slower is exceptional! Off the top of my head, my Phenom II 955 gets 20fps at those settings on 64-bit mode. From my own testing 64-bit QTGMC is about 15% faster than 32-bit, so hitting 50fps with a 2600 should be no problem.
Thanks again guy... I smell a Core i7-2600K in my near future!
andalaugh:
Now, if only my ISP will fix my upload speed so that I can upload for the community
Just to clarify, those are with pre-rendering enabled, correct?
44 fps at 60fps slower is exceptional! Off the top of my head, my Phenom II 955 gets 20fps at those settings on 64-bit mode. From my own testing 64-bit QTGMC is about 15% faster than 32-bit, so hitting 50fps with a 2600 should be no problem.
Thanks again guy... I smell a Core i7-2600K in my near future!
andalaugh:Now, if only my ISP will fix my upload speed so that I can upload for the community
Absolutely. And with a 2600K overclocked to 4.5, and 64-bit QTGMC (assuming everything scales appropriately), you might be able to run Slower with Edge Cleaning at real-time (1x)!
And just think, the 2600K doesn't even represent the top of Intel's 2011 lineup. Imagine what 6- and 8-core parts would be capable of.
So to clarify, you were still running MeguIVit and its sandbox, and you fixed the problem by adding a SetMemoryMax?
____
If you tweak the number of threads with SetMTMode, you may also want to tweak the number of threads that NNEDI3 uses, like so:
I find using a few less NNEDI threads gives best performance, but it will depend on the system.
SetMemoryMax is often needed when you increase thread count. Raise it too much and AviSynth will crash. And that's a major limiting factor for this 32-bit version of MeguIVit: easy to run out of memory with the 2Gb process cap on 32-bit software when you raise the thread count too much, especially on slower presets/scripts.
____
The next two QTGMCs will mix things up a bit. The new modes in the imminent release have different speed/quality profiles (standard processing is unchanged). Presets with new modes are slower and higher quality, which means the interest switches to faster presets. In other words, the "Slow"=HQ assumption will need to change. In the very slowest modes it uses 3 NNEDI3 calls per frame so that thread count issue becomes pressing. A 64-bit MeguIVit is becoming a priority.
The release after that is going to add chroma optimizations that will speed things up.
Regarding QTGMC release, I have been delayed for good reason. I found a method to utilize the new modes for progressive material. It does a truly excellent job of fixing bad rips now. Only things I've left to do are some documentation updates and some samples to illustrate what the new modes do (and what they don't). I'm going to be careful with that latter point as the d9 crowd are very prickly.
This is the current changelog:
____
If you tweak the number of threads with SetMTMode, you may also want to tweak the number of threads that NNEDI3 uses, like so:
Code:
SetMTMode(5,10) # 5 is safer, especially for non-mpeg sources
...
SetMTMode(2) # Only the first SetMTMode needs the thread count (ignored later)
...
QuickTGMC( Preset="Slower", EdiThreads=6 ) # or whateverI find using a few less NNEDI threads gives best performance, but it will depend on the system.
SetMemoryMax is often needed when you increase thread count. Raise it too much and AviSynth will crash. And that's a major limiting factor for this 32-bit version of MeguIVit: easy to run out of memory with the 2Gb process cap on 32-bit software when you raise the thread count too much, especially on slower presets/scripts.
____
The next two QTGMCs will mix things up a bit. The new modes in the imminent release have different speed/quality profiles (standard processing is unchanged). Presets with new modes are slower and higher quality, which means the interest switches to faster presets. In other words, the "Slow"=HQ assumption will need to change. In the very slowest modes it uses 3 NNEDI3 calls per frame so that thread count issue becomes pressing. A 64-bit MeguIVit is becoming a priority.
The release after that is going to add chroma optimizations that will speed things up.
Regarding QTGMC release, I have been delayed for good reason. I found a method to utilize the new modes for progressive material. It does a truly excellent job of fixing bad rips now. Only things I've left to do are some documentation updates and some samples to illustrate what the new modes do (and what they don't). I'm going to be careful with that latter point as the d9 crowd are very prickly.
This is the current changelog:
Code:
# v2.6: Introduced source-match modes and settings for higher fidelity output - supported for interlaced and progressive input
# Most lossless settings removed - superseded by source-match, only Lossless integer remains
# Added ProgSADMask setting for progressive repair modes (InputType=2,3) to help recover stable detail
# Added RepChroma setting to allow disabling of chroma processing in repair stages (rep0,1,2)
# Added DetailRestore setting for NoiseBypass - allowing denoising with some fine detail retention
# Noise bypass with NoiseDeint="Generate" is now motion-compensated for better grain/detail restoral, NoiseDeint="Copy" removed
# TDeint added as interpolator (suitable for source-match)
# YadifPath no longer global
# EdiMode for "Ultra Fast" changed from "TDIYadif" to "Yadif" (otherwise slower than "Super Fast" for non-threaded)
# Bug fixes in Sbb and InputType=3
# Major documentation revisions and some script tidyingSounds awesome! I knew it was right for me to delay processing of some progressive vids I have lying around. ^_^
Regarding D9, they tend to be suspicious of new names on the scene, which to be honest you are, after all
Any new plugin by one of the regulars (like DD is usually welcomed with great fanfare, regardless of whether it's actually good or not.Alright, now you are just tempting me
I'm not sure whether to wait for LGA2011 or not. I think it will be more expensive than LGA1155 (obviously!), but Anandtech reports that the lowest end LGA2011 chip will start at the price of the i7-2600. If this lowest end chip is 6-core then its very good value indeed. The motherboards will definitely be more expensive than LGA1155 ones though.
To Mr.Vitreous.
I have a question that bothers me quite a while.
This is by no means a query, just a question for my personal culture.
Well, I'm starting, even posing as a moron ...
Do you think it would be possible to add variables in the AVS script, such as:
QuickTGMC (preset = "Slow ", Sharpness = 0.6)
But this time, the parameters that allow you to easily meter the brightness, contrast, sharpness ...
For "Sharpness", it certainly exists. The problem is that this is very admirable complex without your knowledge ... especially for a newbie like me.
In summary, perhaps including such profile as 30fps / 60fps with EdgeClean in Slower, Slow, Fast Mode...
With a small reminder of the type:
If the video seems too this or too that. Profile "Max Sharpness" or "Low" would be appropriate.
What do you think?uzzled:
You will reply that it will still multiply profiles.
Not totally. it would suffice to include one or two new profiles with all-purpose (=skeleton key?) parameters and leave the choice to the user to personalize his way if he wishes.
For example:
QuickTGMC (preset = "Slow", Sharpness = "Medium", Contrast = "High", Brightness = "Low")
In advance, I appreciate the time you will give reading of my post.
Regards.
I have a question that bothers me quite a while.
This is by no means a query, just a question for my personal culture.
Well, I'm starting, even posing as a moron ...
Do you think it would be possible to add variables in the AVS script, such as:
QuickTGMC (preset = "Slow ", Sharpness = 0.6)
But this time, the parameters that allow you to easily meter the brightness, contrast, sharpness ...
For "Sharpness", it certainly exists. The problem is that this is very admirable complex without your knowledge ... especially for a newbie like me.
In summary, perhaps including such profile as 30fps / 60fps with EdgeClean in Slower, Slow, Fast Mode...
With a small reminder of the type:
If the video seems too this or too that. Profile "Max Sharpness" or "Low" would be appropriate.
What do you think?
uzzled:You will reply that it will still multiply profiles.
Not totally. it would suffice to include one or two new profiles with all-purpose (=skeleton key?) parameters and leave the choice to the user to personalize his way if he wishes.
For example:
QuickTGMC (preset = "Slow", Sharpness = "Medium", Contrast = "High", Brightness = "Low")
In advance, I appreciate the time you will give reading of my post.
Regards.
QTGMC is a deinterlacer. I will only add processes that are needed for that job. Sharpness is available as a setting because this deinterlacing algorithm requires a blur/resharpen anyway. There are denoising settings in there because deinterlacing is sensitive to noise.
Brightness and contrast have almost no relationship to deinterlacing, so they will never be added to QTGMC. There are already many scripts & functions to do brightness, contrast, and other things. What you need to do is learn to use AviSynth and MeGUI manually and add what you need for each source. Functions like "tweak", and "levels" are easy to use. There are more powerful scripts around too.
Regarding MeguIVit, I am concerned about having too many presets. So I am going to allow the scripts to be tweaked with a new dialog box. That might allow some scope for what you want.
I'm curious, Vitreous, what's your PC's specs?
I just did my own speed test to reconfirm. 60fps Slower on pre-rendering mode, my Phenom II 955 does 15.5 fps.
The Phenom II 955 is a Quad Core CPU clocked at 3.2Ghz, while the Core i7-2600 is also Quad Core clocked at 3.4Ghz. guy's tests shows that even though these two CPUs are similar in core count and clock speed, Intel's architecture makes it 3 times faster than AMD's solution!
I just did my own speed test to reconfirm. 60fps Slower on pre-rendering mode, my Phenom II 955 does 15.5 fps.
The Phenom II 955 is a Quad Core CPU clocked at 3.2Ghz, while the Core i7-2600 is also Quad Core clocked at 3.4Ghz. guy's tests shows that even though these two CPUs are similar in core count and clock speed, Intel's architecture makes it 3 times faster than AMD's solution!
I have two ripping machines, a 930 and a 950, both 12Gb. If you're referring to the realtime run I did earlier, that was Slow, no edge clean on the 930 temporary OC @ 4.2Ghz. I tweaked a lot, threads, NNEDI threads, disks, and probably other stuff... A quick run with a random source just now on my current script, I get 52fps with just the main threads tweaked, the OC is down to 3.7Ghz at the moment.
Thank you Mr. Vitreous for your patience, sharing your knowledge and expertise.
I tried several times the "MeGUI + filters" adventure but the result left much to be desired. Despite the time spent trying to understand how it works and all my good will, I am not come to my ends.
I readily admit my knowledge of video processing casi are nonexistent. At least light years away from yours.
Thank you again for making available to us newbies, the tools that greatly facilitates the task and I am eagerly waiting your latest finds.
Regards.
I tried several times the "MeGUI + filters" adventure but the result left much to be desired. Despite the time spent trying to understand how it works and all my good will, I am not come to my ends.
I readily admit my knowledge of video processing casi are nonexistent. At least light years away from yours.
Thank you again for making available to us newbies, the tools that greatly facilitates the task and I am eagerly waiting your latest finds.
Regards.
i had my first big problem with meguIV yesterday.
this is the error message i get. it comes up before meguIV starts.
i re-downloaded meguIV, rebooted, removed meguIVit sandbox, changed .exe location and disabled AV but the same message. any ideas? regular meGUI starts fine.
(win 7 64 Ultimate)
this is the error message i get. it comes up before meguIV starts.
i re-downloaded meguIV, rebooted, removed meguIVit sandbox, changed .exe location and disabled AV but the same message. any ideas? regular meGUI starts fine.
(win 7 64 Ultimate)
sorry about that. here is the info:
Problem signature:
Problem Event Name: APPCRASH
Application Name: meguIV.exe
Application Version: 1.0.1.1
Application Timestamp: 00000005
Fault Module Name: StackHash_199c
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Code: c00000fd
Exception Offset: 0030b716
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 1033
Additional Information 1: 199c
Additional Information 2: 199cc907df8a4654c8ebf31545ec3b64
Additional Information 3: ac93
Additional Information 4: ac932fb721b478be6e53cf5b63cba0e7
yes, thats correct. i cant start it with, or without, the meguIVit sandbox.
Problem signature:
Problem Event Name: APPCRASH
Application Name: meguIV.exe
Application Version: 1.0.1.1
Application Timestamp: 00000005
Fault Module Name: StackHash_199c
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Code: c00000fd
Exception Offset: 0030b716
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 1033
Additional Information 1: 199c
Additional Information 2: 199cc907df8a4654c8ebf31545ec3b64
Additional Information 3: ac93
Additional Information 4: ac932fb721b478be6e53cf5b63cba0e7
yes, thats correct. i cant start it with, or without, the meguIVit sandbox.
thanks for your help. i did exactly that within the last 2 days. i figured it was something to do with a recently installed program but updates can do these things too. thanks again.
The latest QuickTGMC V3.0 is finished. This version focuses on quality improvements, not speed, but don't worry, the standard settings are largely unchanged in performance.
Haven't got time to update the QuickTGMC page here with the latest details, I've just added the download. There are reorganized instructions in the script itself that explain all the new features (and the old ones) in detail. Find some visual comparisons over at d9. I'll post some here when I incorporate it into the next MeguIVit.
The script is used widely now, so I expect to be fielding queries for a while (there will surely be problems, the script has had considerable change). Then I'll look at adding it to MeguIVit. The quality of faster presets with the new modes will exceed the current "Slow" settings. Edge-cleaning isn't needed often. Haven't really been making cross-comparisons for speed, so I don't know how those alternates will compare with current speeds.
Edit: @astrayred: When you see the d9 post, maybe you'll understand why this version took so long. And all that work demonstrates clearly to me that spatial resolution is overrated unless you're doing a major upscale or displaying on a huge screen. This new version unequivocally does super-resolution, and although I'm technically impressed with my work, it's not really ground-breaking visually. Practically, it does mean we can get great results from upscaling DVD resolution to a decent sized monitor. But for HD material it's probably not worth it unless you have a monster screen or projector... hmmm... idols filling a wall... checks bank balance...
Haven't got time to update the QuickTGMC page here with the latest details, I've just added the download. There are reorganized instructions in the script itself that explain all the new features (and the old ones) in detail. Find some visual comparisons over at d9. I'll post some here when I incorporate it into the next MeguIVit.
The script is used widely now, so I expect to be fielding queries for a while (there will surely be problems, the script has had considerable change). Then I'll look at adding it to MeguIVit. The quality of faster presets with the new modes will exceed the current "Slow" settings. Edge-cleaning isn't needed often. Haven't really been making cross-comparisons for speed, so I don't know how those alternates will compare with current speeds.
Edit: @astrayred: When you see the d9 post, maybe you'll understand why this version took so long. And all that work demonstrates clearly to me that spatial resolution is overrated unless you're doing a major upscale or displaying on a huge screen. This new version unequivocally does super-resolution, and although I'm technically impressed with my work, it's not really ground-breaking visually. Practically, it does mean we can get great results from upscaling DVD resolution to a decent sized monitor. But for HD material it's probably not worth it unless you have a monster screen or projector... hmmm... idols filling a wall... checks bank balance...